<author>Brenno J.S.A.A.F. de Winter, De Winter Information Solutions</author>
<author>Arjen Baart, Andromeda Technology & Automation</author>
- <date>November 15, 2002.</date>
+ <date>December 6th, 2002.</date>
<docinfo>
<infoitem label="Version">0.22</infoitem>
</docinfo>
Added parameters of monitored objects.
</col>
</row>
+ <row>
+ <col>0.23</col><col>Brenno de Winter</col><col>Dec 6, 2002</col>
+ <col>
+ Added new elements to the database
+ </col>
+ </row>
</table>
</section>
<heading>action</heading>
<para>
+This table stores the actions that are recognized by the system.
+Whenever a situation in the database has been raised (through the table notification)
+one expects steps to be taken to resolve these issues.
+All these steps are stored in this table.
+Each step beginning with detection until a case is closed can be traced back through this table.
+This will support the <strong>accountability</strong> (who is responsible for which action)
+and <strong>non-repudiation</strong> (being able to trace what exactly happened to each notification).
In the table action all recognized actions that can be taken are stored.
-Several actions will lead to change in <emph>statuscode</emph>.
-However this doesn't apply to all actions<footnote>A status NEW
+Several of the taken actions will lead to change in <emph>statuscode</emph>.
+When this is the case either the server-side of the interfaces or the gcm_daemon will perform this task.
+This doesn't apply to all actions though.<footnote>A status NEW
of a notification that cannot be dealt with automatically will
<strong>not</strong> change before a user looked at it.</footnote>.
Actions take place through background processes and the interface.
+Each action known by the system will be delivered by the software.
This table mainly is used for retrieval so indexing will be done as much as possible.
</para>
<row>
<col> actionid </col> <col> Bigserial </col> <col> 8 </col>
<col>
- Autonumber bigint (eight bit)
+ Autonumber bigint (eight bit). Unique identifyer to refer to when this action is taken.
</col>
</row>
<row>
<col> actionname </col> <col> Text </col> <col> <para/> </col>
<col>
- Short descriptive name for the type of action
+ Short descriptive name for the type of action.
</col>
</row>
<row>
<col> statuscode </col> <col> Varchar </col> <col> 3 </col>
<col>
New status that will be given to a notification when this action takes place.
+ If the action occurs the status in the notification can change because of this.
+ The statuscode will indicate what the new status has to be.
+ If this field is left empty no change to the status will occur.
</col>
</row>
<row>
<row>
<col> actionid </col> <col> action_notification_user </col>
<col>
- Each action that takes place will be log. The Actionid will bring
- classification to the individual records. This relationship has to be enforced.
+ Each action that takes placed will be stored. The Actionid will bring
+ classification to the individual records (that reflect what it means if the action-occurred).
+ This relationship has to be enforced.
</col>
</row>
</table>
</subsection>
<subsection>
- <heading>Action_notification_user.</heading>
+ <heading>Action_user.</heading>
<para>
-In the table action_notification_user each step that is taken regarding a
-notification is logged. This table is very important for later use if
+This table stores each actual action taken.
+Where the action basically stores the type of actions that can be taken,
+this table says 'at this point in time for this notification this action was taken'.
+Using this table it is traceable who did what at which moment in time.
+The table is very important for later use if
something goes wrong, but is also relevant for the interface.
-All steps of a notification can be traced here.
+All steps of a in the process of a notification can be traced using this table.
There will be a lot of entries here, but retrieval is more crucial for
performance than data entry. So indexing on logic fields is very relevant.
Processing might be slower, but that's worth the price.
<row>
<col> actionstepid </col> <col> Bigserial </col> <col> 8 </col>
<col>
- Autonumber bigint (eight bit)
+ Autonumber bigint (eight bit). A unique identifyer to indicate each step in the process.
</col>
</row>
<row>
<col> actionid </col> <col> Bigint </col> <col> 8 </col>
<col>
- Reference to the action that is being registered here.
+ Reference to the action that is being registered here. This field refers to the actual action taken.
</col>
</row>
<row>
<col> username </col> <col> Text </col> <col> <para/> </col>
<col>
- The username of the user that is involved in the action.
+ The username of the user that is involved in the action. This field refers to the table <strong>usr</strong>
</col>
</row>
<row>
<col> notificationid </col> <col> Bigint </col> <col> 8 </col>
<col>
- Reference to the notification.
+ Reference to the notification. This will link the action to the notification.
</col>
</row>
<row>
<row>
<col> statuscode </col> <col> Varchar </col> <col> 3 </col>
<col>
- The status of the Notification
+ The status of the Notification AFTER this action has been taken.
</col>
</row>
<row>
<heading>The fields of log.</heading>
<para>
-The fields in log are focussed around the raw data and the data needed
-to link this to other tables in the system.
+The fields in log are focussed around the raw data arriving from log-files and output
+from processes that deliver status information.
+The log table is the one and only place used to automatically deliver data to the gnucomo-system.
+This makes the facts very traceable and ensures that there is one point where the data isn't
+yet fragmented (usefull if new insights are usefull). The log table also provides the
+integrity of the data as it was delivered. The data will be needed to provide
+a link to other tables in the system that handle processed derrivates of the
+original data (added intelligence).
</para>
<table cpos='lllp{6cm}'>
<col> servicecode </col> <col> Text </col> <col> <para/> </col>
<col>
This field explains what service was recognized (for instance 'kernel, 'httpd' or 'smtp')
+ this make later processing easier.
</col>
</row>
<row>
<row>
<col> object_timestamp </col> <col> Timestamp </col> <col> 8 </col>
<col>
- Timestamp as has been written into the log.
+ Timestamp of the moment the data was written into the log-file itself.
+ This is the time on the remote system.
</col>
</row>
<row>
<row>
<col> rawdata </col> <col> TEXT </col> <col> <para/> </col>
<col>
- The raw log data
+ The raw log data as it was handed to gnucomo.
</col>
</row>
+ <row>
+ <col>processed</col><col>BOOLEAN </col> <col> <para/> </col>
+ <col>This record is a flag (true or false).
+ If a record that has been entered into the log-table has been processed
+ (mostly into several log_adv-tables) this flag is set to true.
+ The flag indicates that gcm_daemon processed the record.
+ This doesn't nescessarily mean that they have been used.
+ By default the setting is false.
+ So the flag helps in the detection of new arrivals in the log-table.</col>
+ </row>
+ <row>
+ <col>recognized</col><col>BOOLEAN</col> <col><para/> </col>
+ <col>This record is a flag (true or false).
+ If the processing by gcm_daemon of this particular record has been done the flag
+ will only be set to true when gcm_daemon could process the record.
+ If there was no support for this particular entry the status remains false.
+ The main aim of this functionality is relevant when a new version of the daemon is present.
+ Unrecognized records will then be transferred to unprocessed again and a
+ new attempt will be made to process these records.</col>
+ </row>
</table>
</subsubsection>
</subsubsection>
<subsubsection>
+<heading>Log_adv</heading>
+<para>
+As soon as new data is detected in the log-table processing takes place.
+If the data is recognized by the gcm_daemon one or more log_adv records
+will be written where data is separated. Due to the high diversity multiple
+types of the log_adv table will be created.
+All of them will be an inheritance of the log_adv-table.
+</para>
+</subsubsection>
+<subsubsection>
<heading>The fields of log_adv.</heading>
<para>
</col>
</thead>
<row>
- <col> logid </col> <col> Bigint </col> <col> 8 </col>
- <col>
- Bigint (eight bit) 1-to-1 relationship with log
- </col>
- </row>
- <row>
- <col> source_ip </col> <col> Inet </col> <col> <para/> </col>
- <col>
- This is the IP-address (V4) of the host that sended the data.
- </col>
- </row>
- <row>
- <col> destination_ip </col> <col> Inet </col> <col> <para/> </col>
- <col>
- This is the IP-address (V4) of the host that was targetted.
- </col>
- </row>
- <row>
- <col> mac_address </col> <col> Macaddr </col> <col> <para/> </col>
- <col>
- This is the MAC-address logged
- </col>
- </row>
- <row>
- <col> packetlength </col> <col> Int </col> <col> <para/> </col>
- <col>
- The length of the packet
- </col>
- </row>
- <row>
- <col> protocol </col> <col> Text </col> <col> <para/> </col>
- <col>
- The protocol used for transmission(mostly TCP/UDP/ICMP).
- </col>
- </row>
- <row>
- <col> source_port </col> <col> Int </col> <col> <para/> </col>
- <col>
- The portnumber used at origin.
- </col>
- </row>
- <row>
- <col> destination_port </col> <col> Int </col> <col> <para/> </col>
- <col>
- The portnumber for the target
- </col>
- </row>
- <row>
- <col> messageid </col> <col> Text </col> <col> <para/> </col>
- <col>
- Messageid for e-mails
- </col>
- </row>
- <row>
- <col> system_username </col> <col> Text </col> <col> <para/> </col>
- <col>
- Username on the object
+ <col>log_advid</col><col>Bigint autonumber</col><col>8</col>
+ <col>Since some records can generate several log_adv records a unique identifyer is needed.
+ This record provides that.
</col>
</row>
<row>
- <col> networkdevice </col> <col> Text </col> <col> <para/> </col>
+ <col> logid </col> <col> Bigint </col> <col> 8 </col>
<col>
- When this is about network-traffic the device that worked the data
+ Bigint (eight bit) 1-to-1 relationship with log
</col>
</row>
</table>
+
</subsubsection>
<subsubsection>
<row>
<col> Remark </col>
<col>
- <para>A replacement system is available at the office location. The following persons have been authorized to enter the data room at the ISP:</para>
+ <para>A replacement system is available at the office location.
+ The following persons have been authorized to enter the data room at the ISP:</para>
<para>* Arjen Baart</para>
<para>* Peter Busser</para>
<para>* Brenno de Winter</para>
<para>RedHat Linux (.rpm packages)</para>
</item>
</itemize>
- <para>We will try and facilitate as many operating systems client-side and as many unices server-side, but efforts on testing out of the projects will be very minimalistic to ensure that the project keeps delivering new version and new features. </para>
+ <para>
+ We will try and facilitate as many operating systems client-side and
+ as many unices server-side, but efforts on testing out of the projects
+ will be very minimalistic to ensure that the project keeps delivering
+ new version and new features.
+ </para>
</section>
<section>
projects / gnucomo.git / commitdiff