<author>Brenno J.S.A.A.F. de Winter, De Winter Information Solutions</author>
<author>Arjen Baart, Andromeda Technology & Automation</author>
- <date>December 6th, 2002.</date>
+ <date>December 12th, 2002.</date>
<docinfo>
- <infoitem label="Version">0.22</infoitem>
+ <infoitem label="Version">0.24</infoitem>
</docinfo>
</titlepage>
<heading>About this document.</heading>
<para>
+<LaTeX command='\setlength{\parindent}{0cm}'/>
+<LaTeX command='\setlength{\parskip}{0.4cm}'/>
This document describes the technical specifications for the Gnucomo project.
It will describe the functionality achieved, design specifications and choices made.
The document will be the manifest for the developers to work in the same direction
Added new elements to the database
</col>
</row>
+ <row>
+ <col>0.24</col><col>Brenno de Winter</col><col>Dec 12, 2002</col>
+ <col>
+ Updates to the database to reflect the most recent changes.
+ </col>
+ </row>
</table>
</section>
<heading>notification. </heading>
<para>
-In this table all detected issues per object will be written.
+The main task of gnucomo is detection issues.
+As soon as something has been detected based on the queries run a notification will be created.
+This notification will be the warning towards the system that something has been detected.
Issues are entered based on immediate detection, periodical detection or manually.
-Since this table is mostly used to work from in the interface being in control is crucial.
+In an ideal case no notification will occur, but as time goes by issues will occur.
When systems function properly more retrieval than data entry will take place.
-Also data retrieval will be done in all sorts of ways. Indexing must be huge to facilitate that.
+Also data retrieval will be done in all sorts of ways. One can think of immediate display,
+but also updates due to actions and ultimately reporting.
+Indexing must be huge to facilitate all these queries.
+
+There will be one single point-of-contact with the gnucomo-system.
+This point-of-contact will be the XML/SOAP interface.
+By doing that we can set user-rights (as has been impleted in this table)
+without communicating that to the user.
+Also the gnucomo-XML/SOAP-interface will verify if the attempted action is allowed.
</para>
<subsubsection>
</col>
</thead>
<row>
- <col> notificationid </col> <col> Bigserial </col> <col> 8 </col>
+ <col> notificationid </col> <col> Bigint Autonumber </col> <col> 8 </col>
<col>
Autonumber
</col>
</col>
</row>
<row>
- <col> type_of_notification_id </col> <col> Bigint </col> <col> 8 </col>
+ <col> type_of_issue_id </col> <col> Bigint </col> <col> 8 </col>
<col>
- Reference to the <emph>type_of_notification</emph> indicating what
+ Reference to the <emph>type_of_issue</emph> indicating what
type of notification we have here and what basic rules apply.
+ Notifications are always created on an issue that can be raised.
</col>
</row>
<row>
<col> timestamp </col> <col> Timestamp </col> <col> <para/> </col>
<col>
- Timestamp that this notification was created.
+ Timestamp used to indicate the moment when this notification was created.
</col>
</row>
<row>
<col> statuscode </col> <col> Varchar </col> <col> 3 </col>
<col>
The status the actual status a notification has.
+ This can be new, open, pending, waiting for verification, rejected, closed, needs investigation
</col>
</row>
<row>
<row>
<col> escalation_count_timestamp </col> <col> Timestamp </col> <col> <para/> </col>
<col>
- Timestamp since the last escalation took place<footnote>The system offers
+ Each notification has a basic priority-level but if certain time-constraints
+ are not met it is possible to do an automatic escalation.
+ By doing that new rules may apply and more priority can be given.
+ This field has the timestamp since the last escalation took
+ place<footnote>The system offers
the possibility to automatically escalate issue if no action has been
- taken within a certain amount of time.
- Based on the status and the type of notification escalation can take place.</footnote>.
+ taken within a certain amount of time. Based on the status and the type
+ of notification escalation can take place.</footnote>.
</col>
</row>
<row>
<row>
<col> securitylevel_view </col> <col> Int </col> <col> 4 </col>
<col>
- The securitylevel that is needed to view this entry.
+ The securitylevel that is needed to be allowed to view this entry. This field builds the opportunity to have certain specific issues only handled by certain persons. <footnote>This feature may be beneficial to make monitoring more discrete. For instance if a check is being done on who is looking on pornographic websites privacy issues play as well. By setting this value only certain users can undertake action. Something else would be a feature to have fraud protection. If this happens it goes beyond the work of a normal administrator and only certain officers are allowed to deal with these issues. One last example would also be privacy related. Suppose a system logs all the unix-commands given by a certain user. If something is found based on the actions of the users a protection mechanism is needed. Only special users are allowed to view this notification.</footnote>
</col>
</row>
<row>
<col> securitylevel_add </col> <col> Int </col> <col> 4 </col>
<col>
- Securitylevel to add information to this item or to undertake action
+ There is a fundamental difference between letting users see notification and actually work on notifications. This field indicates what security level needs to be present to edit this notification.
</col>
</row>
<row>
<col> securitylevel_close </col> <col> Int </col> <col> 4 </col>
<col>
- The securitylevel needed to be able to close this notification.
+ The securitylevel needed to be able to close this notification. After working on an issue one ultimately hope to close the notification. This field indicates who is allowed to do so. If one attempts to close the issue, but is lacking sufficient rights the status will be changed to 'waiting for verification'. This will enable the superuser to quickly tick of the list of issues to be verified and still be in control.
</col>
</row>
</table>
<heading>object</heading>
<para>
-The <emph>object</emph> table contains general information on the objects being monitored.
-The table object will more be used for retrieval, since adding objects will be an
+The <emph>object</emph> table contains general information on the objects being monitored. Mostly objects will be computers, but it may also be something else in the future like routers, switches, gateways, PDA's or other devices. The table object will more be used for retrieval, since adding objects will be an
occasional process. Anything that for some reason can be indexed ought to be indexed.
</para>
</col>
</thead>
<row>
- <col> objectid </col> <col> Bigserial </col> <col> 8 </col>
+ <col> objectid </col> <col> Bigint Autonumber </col> <col> 8 </col>
<col>
Autonumbering code for the computer or device.
</col>
<row>
<col> objectname </col> <col> Text </col> <col> <para/> </col>
<col>
- The hostname of the object
+ The hostname of the object as it can be recognized by the gcm_input-application.
</col>
</row>
<row>
<para/>
</col>
<col>
- Description of the object. What type of system is it
+ Description of the object. What type of system is it, what specifics are there to know, etc.
</col>
</row>
<row>
<heading>object_issue. </heading>
<para>
This table will store the policy on a certain issue like the priority being
-recognized and special actions to take.
+recognized and special actions to take. Since values in this table are bound to the object, responses to the same incident can lead to different alert levels based on the importance of the object.
Since policies are utilized by the systems continuously all other process will rely on this index,
while users will change the values occasionally.
</para>
</row>
<row>
<col>
- <para>type_of_notificationid</para>
+ <para>type_of_issueid</para>
</col>
<col>
<para>Bigint</para>
<para>8</para>
</col>
<col>
- <para>Reference to the <emph>type_of_notification</emph> indicating
- what type of notification we have here and what basic rules apply.</para>
+ <para>Reference to the <emph>type_of_issue</emph> indicating
+ how we will handle this type of issue for this particular object. If nothing is entered here, the default rules apply.</para>
</col>
</row>
<row>
</col>
<col>
<para>The priority that will be set automatically when this type of
- notification is entered into the system.</para>
+ issue is entered into the system.</para>
</col>
</row>
<row>
<para/>
</col>
<col>
- <para>The maximum priority given to this type of notification.</para>
+ <para>The maximum priority given to this type of notification. This will prevent an endless escalation of the issue. No priority can be higher than 1.</para>
</col>
</row>
<row>
<para/>
</col>
<col>
- <para>type_of_notification_id</para>
+ <para>type_of_issue_id</para>
</col>
<col>
<para>Primary key</para>
</row>
<row>
<col>
- <para>obi_type_of_notificationid</para>
+ <para>obi_type_of_issueid</para>
</col>
<col>
- <para>type_of_notification_id</para>
+ <para>type_of_issue_id</para>
</col>
<col>
<para/>
<para>Objectid</para>
</col>
<col>
- <para>Type_of_notification_id</para>
+ <para>Type_of_issue_id</para>
</col>
<col>
<para>Default Priority</para>
<heading>object_priority.</heading>
<para>
-This table stores per object how a certain level of priority is being dealt with.
-What policies do apply. This table is mostly used for retrieval, so firm indexing is logic.
+By default a prioritycode has a certain meaning. But default behaviour can be used for most cases, but not all. For some objects a deviation would be usefull. For instance a very important webserver under an attack should maybe alarm more agressive than a printer-server that is used only marginally. This table stores per object how a certain level of priority is being dealt with. The main issue is the question: What policies do apply? If nothing is available default behaviour as defined in the table priority will apply. This table is mostly used for retrieval, so firm indexing is logic.
</para>
<subsubsection>
<para/>
</col>
<col>
- <para>Repeat this notification if no action occurs since the notification. Yes = T / No = F</para>
+ <para>Repeat this notification if no action occurs within a certain timeframe. Yes = T / No = F</para>
</col>
</row>
<row>
</row>
<row>
<col>
- <para>obi_type_of_notification_id</para>
+ <para>obi_type_of_issue_id</para>
</col>
<col>
- <para>type_of_notification_id</para>
+ <para>type_of_issue_id</para>
</col>
<col>
<para/>
<heading>object_service</heading>
<para>
-The object service table indicates which services can be expected on the system.
+The object service table indicates which services should report itself to the Gnucomo-system.
If input fails to show up a notification can be generated.
</para>
<heading>object_system_user</heading>
<para>
-This table will derive a list of users that can be identified based
-on the log-files in the system. This table is filled during data entry.
-But the filling of the table is dependent on the fact if the user has been entered before.
-So during the processing the read will be done more than the data entry and
+Every object knows users either by the security of the object itself or through a central database (like LDAP for instance). Initially a new object can sent the userlist to gnucomo. Any username that isn't in the userlist is potentially dangerous. To avoid any mis-understandings this user is not a gnucomo-user, but a user on a remote system. So during the processing the read will be done more than the data entry (one account will most likely do multiple actions) and
that makes heavy indexing logic.
</para>
<subsubsection>
<para>osu_pk</para>
</col>
<col>
- <para>objectid</para>
+ <para>objectid, system_username</para>
</col>
<col>
<para>Primary key</para>
</row>
<row>
<col>class</col><col>text</col><col> </col>
- <col>Similar parameters are in the same class</col>
+ <col>Similar parameters are in the same class. Refers to the
+ <emph>parameter_class</emph> table.
+ </col>
</row>
<row>
<col>description</col><col>text</col><col> </col>
</subsubsection>
</subsection>
+
+<subsection>
+<heading>parameter_class</heading>
+<para>
+Each parameter is defined to be of a certain <emph>class</emph>.
+The class defines which properties a parameter of that class may have.
+</para>
+
+<subsubsection>
+<heading>The fields</heading>
+<para>
+The fields of the <emph>parameter_class</emph> table are listed below:
+</para>
+<table cpos='lllp{6cm}'>
+ <thead>
+ <col> Fieldname </col> <col> Fieldtype </col> <col> Size </col>
+ <col> Remarks </col>
+ </thead>
+ <row>
+ <col>name</col><col>text</col><col> </col>
+ <col>Name of the class</col>
+ </row>
+ <row>
+ <col>property_name</col><col>text</col><col> </col>
+ <col>Name of the property. Used in property table.</col>
+ </row>
+ <row>
+ <col>description</col><col>text</col><col> </col>
+ <col>A verbose description of the property</col>
+ </row>
+ <row>
+ <col>property_type</col><col>text</col><col> </col>
+ <col>Either 'STATIC' or 'DYNAMIC'</col>
+ </row>
+ <row>
+ <col>min</col><col>float</col><col>4</col>
+ <col>The default minimum value of the property.</col>
+ </row>
+ <row>
+ <col>max</col><col>float</col><col>4</col>
+ <col>The default maximum value of the property.</col>
+ </row>
+ <row>
+ <col>notify</col><col>boolean</col><col>1</col>
+ <col>If TRUE, create a notification when something about the property or
+ the parameter changes.
+ </col>
+ </row>
+
+</table>
+
+<para>
+The combination of name and property_name must be unique.
+Note that the <emph>min</emph> and <emph>max</emph> fields are used
+only for properties of a numerical nature.
+</para>
+
+</subsubsection>
+<subsubsection>
+<heading>Sample data</heading>
+
+<para>
+The table below lists a few examples of parameter classes
+</para>
+<table cpos='lllllll'>
+ <thead>
+ <col>name</col><col>property_name</col><col>description</col><col>property_type</col>
+ <col>min</col><col>max</col><col>notify</col>
+ </thead>
+ <row>
+ <col>package</col><col>version</col><col>The installed version</col><col>STATIC</col>
+ <col> </col><col> </col><col>true</col>
+ </row>
+</table>
+</subsubsection>
+</subsection>
+
+
+<subsection>
+<heading>parameter_notification</heading>
+<para>
+The parameter_notification table defines the relationship between <emph>parameters</emph>
+and <emph>notifications</emph>.
+Whenever a parameter is changed, i.e. the parameter is created, one of its
+properties changed or a parameter is removed, this may result in a notification.
+This table provides the link between that notification and the change in
+parameter that the notification is about.
+Note that a single notification may be created for a number of changes in
+parameters.
+</para>
+
+<subsubsection>
+<heading>The fields</heading>
+<para>
+The fields of the <emph>parameter_notification</emph> table are listed below:
+</para>
+<table cpos='lllp{6cm}'>
+ <thead>
+ <col> Fieldname </col> <col> Fieldtype </col> <col> Size </col>
+ <col> Remarks </col>
+ </thead>
+ <row>
+ <col>notificationid</col><col>bigint</col><col>8</col>
+ <col>The notification for the changed parameters. Refers to the notification table.</col>
+ </row>
+ <row>
+ <col>paramid</col><col>bigserial</col><col>8</col>
+ <col>The parameter for which the notification is made. Refers to the parameter table.</col>
+ </row>
+</table>
+
+<para>
+The combination of notificationid and paramid must be unique.
+</para>
+
+</subsubsection>
+</subsection>
+
<subsection>
<heading>priority</heading>
<para>Is this check currently being used in the system.</para>
</col>
</row>
+ <row>
+ <col><para>automated_check</para></col><col><para>Boolean</para></col><col><para>1</para></col>
+ <col><para>Is this an automated check that can be executed by gcm_daemon</para></col>
+ </row>
+ <row>
+ <col><para>alter_level</para></col><col><para>Integer</para></col><col><para>4</para></col>
+ <col><para>This field indicates what the default priority-level for a notification will be if this issue is raised.</para></col>
+ </row>
+ <row>
+ <col><para>last_run</para></col><col><para>Timestamp</para></col><col><para/></col>
+ <col><para>The time that the last processing took place.</para></col>
+ </row>
+ <row>
+ <col><para>recheck_interval</para></col><col><para>Timestamp</para></col><col><para/></col>
+ <col><para>The interval that is needed before rerunning this check.</para></col>
+ </row>
+
</table>
</subsubsection>
projects / gnucomo.git / commitdiff