<author>Brenno J.S.A.A.F. de Winter, De Winter Information Solutions</author>
<author>Arjen Baart, Andromeda Technology & Automation</author>
- <date>August 28, 2002.</date>
+ <date>October 05, 2002.</date>
<docinfo>
- <infoitem label="Version">0.19</infoitem>
+ <infoitem label="Version">0.20</infoitem>
</docinfo>
</titlepage>
<chapter>
<heading>About this document.</heading>
-<para>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 and not run into unneeded disappointments.</para>
+<para>
+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
+and not run into unneeded disappointments.
+</para>
<section>
<heading>History of the document.</heading>
-<table cpos='lp{3cm}lp{4cm}'>
+<table cpos='lp{3cm}lp{5cm}'>
<thead>
- <col> Version </col> <col> Author </col> <col> Date </col> <col> Remarks </col>
+ <col>Version</col><col>Author</col><col>Date</col><col>Remarks</col>
</thead>
<row>
- <col> 0.l </col> <col> Brenno de Winter </col> <col> July 11th 2002 </col>
+ <col>0.l</col><col>Brenno de Winter</col><col>Jul 11, 2002</col>
<col>
Initial version
</col>
</row>
<row>
- <col> 0.11 </col> <col> Arjen Baart </col> <col> July 12th 2002 </col>
+ <col>0.11</col><col>Arjen Baart</col><col>Jul 12, 2002</col>
<col>
Additional guidelines and dataflow diagram.
</col>
</row>
<row>
- <col> 0.12 </col> <col> Brenno de Winter </col> <col> July 15th 2002 </col>
+ <col>0.12</col><col>Brenno de Winter</col><col>Jul 15, 2002</col>
<col>
Database design added
</col>
</row>
<row>
- <col> 0.13 </col> <col> Arjen Baart </col> <col> July 16th 2002 </col>
+ <col>0.13</col><col>Arjen Baart</col><col>Jul 16, 2002</col>
<col>
Entity-relationship model added.
</col>
</row>
<row>
- <col> 0.14 </col> <col> Brenno de Winter </col> <col> July 17th 2002 </col>
+ <col>0.14</col><col>Brenno de Winter</col><col>Jul 17, 2002</col>
<col>
Based on feedback. Small changes to the datamodel and finishing touches
in lay-out of the tables. Added some examples.
</col>
</row>
<row>
- <col> 0.15 </col> <col> Brenno de Winter, Arjen Baart </col> <col> July 21st 2002 </col>
+ <col>0.15</col><col>Brenno de Winter, Arjen Baart</col><col>Jul 21, 2002</col>
<col>
Additional feedback processed, indexes added, ERD added and SQL-script created.
</col>
</row>
<row>
- <col> 0.16 </col> <col> Brenno de Winter </col> <col> August 7th 2002 </col>
+ <col>0.16</col><col>Brenno de Winter</col><col>Aug 7, 2002</col>
<col>
Communication handling added.
</col>
</row>
<row>
- <col> 0.17 </col> <col> Brenno de Winter </col> <col> August 11th 2002 </col>
+ <col>0.17</col><col>Brenno de Winter</col><col>Aug 11, 2002</col>
<col>
<para>* Description of the client-side for communications.</para>
<para>* Several updates to the database descriptions, drawings added.</para>
</col>
</row>
<row>
- <col> 0.18 </col> <col> Brenno de Winter, Peter Roozemaal </col> <col> August 15th 2002 </col>
+ <col>0.18</col><col>Brenno de Winter, Peter Roozemaal</col><col>Aug 15, 2002</col>
<col>
<para>* Review done by Peter Roozemaal: adjusted intro and several clarifications made</para>
<para>* Arjen Baart: Adjustments to database drawings</para>
</col>
</row>
<row>
- <col> 0.19 </col> <col> Arjen Baart </col> <col> August 27 2002 </col>
+ <col>0.19</col><col>Arjen Baart</col><col>Aug 27, 2002</col>
<col>
Conversion to XMLDoc
</col>
</row>
+ <row>
+ <col>0.20</col><col>Arjen Baart</col><col>Oct 20, 2002</col>
+ <col>
+ Minor layout improvements
+ </col>
+ </row>
</table>
</section>
This evolves to the following list of functions gnucomo can provide:
</para>
<itemize>
+ <item> Intrusion detection </item>
+ <item> Detecting hacker attempts </item>
+ <item> Early detection of system failures </item>
+ <item> Exhaustion of system resources </item>
+ <item> Capacity planning for future expansion </item>
+ <item> Spotting bottlenecks in a system. </item>
+ <item> Verifying system integrity </item>
+ <item> Assistance with troubleshooting </item>
+ <item> Perform post-mortem forensics </item>
+ <item> Incident response system. </item>
+</itemize>
+</chapter>
+
+<chapter>
+ <heading>Decisions for the overall system.</heading>
+
+<para>
+In order to get the project running we have to make some decisions before
+we can start. Of course are the decisions always open for review,
+but initially our main aim is to get a system running. This doesn't
+mean that we allow a lesser architecture, but more that we create an
+environment that will lead to results.
+</para>
+<para>
+The following decisions apply to the system in general:
+</para>
+<itemize>
+ <item>
+ The major part of the system will be used for security features.
+ The solution itself has to be secure.
+ </item>
+ <item>
+ In general we strive to be as platform and application independent as possible.
+ However to achieve software to get ready and to assure progress some selections
+ will have to be made excluding options for applications<footnote>An example is
+ in the database. By using stored procedures and triggers MySQL cannot be used.
+ However the data integrity at that point is more important than the ability to
+ use MySQL.</footnote>. Where possible we will enable ports to other applications
+ and platforms.
+ </item>
<item>
- Intrusion detection
+ The computers collecting the data will only be Linux machines,
+ with future support for other Unices. However it is not aim our
+ to port this part of the project to other platforms just now.
</item>
<item>
- Detecting hacker attempts
+ The database system will make heavy use of stored procedures and
+ triggers and thus lock out some less feature-full database.
</item>
<item>
- Early detection of system failures
+ Although we're not married to a database system initially this will be
+ PostgreSQL only so that we can build for results. The code however
+ shouldn't be build to deliberately lock outer systems.
+ Other database that might be interesting to add: DB2, Oracle
+ (if the rainfall of security advisories seems to be over) and Informix.
</item>
<item>
- Exhaustion of system resources
+ The interface for the user will be a web-interface written in PHP
+ with PostgreSQL-database access. Despite the fact that initially
+ this will be the preferred way to communicate with our system,
+ other interfaces are welcome and should be supported.
</item>
<item>
- Capacity planning for future expansion
+ The technologies used for the daemons on the central site and remote
+ site are open for discussion. A decision is made when it is clear what
+ exactly will be needed to code.
</item>
<item>
- Spotting bottlenecks in a system.
+ The original logfiles on systems will not be harmed in any way,
+ but will be saved the way they presented to gnucomo.
</item>
<item>
- Verifying system integrity
+ In the database processed data as well as raw data will be stored.
</item>
<item>
- Assistance with troubleshooting
+ Our main aim is to ease the life of the administrator when dealing with
+ the symptoms of a machine so that he doesn't miss important notifications.
+ The project will be made around detection. We won't focus on making a
+ maintenance applications but solely on monitoring, because other applications
+ like webmin or linuxconf do already deliver such functionality.
+ We are complementary to those applications. This doesn't mean that
+ the system cannot send SMS'es, e-mails or make alarms sound.
</item>
<item>
- Perform post-mortem forensics
+ Any output of the logbook will be stored and sent within a certain
+ interval which can be set. By doing that the mechanism will not flood
+ the total mechanism and overload machines.
</item>
<item>
- Incident response system.
+ When applications for gnucomo we will try and do the non-server part
+ as platform independent as possible. This in order to prevent writing
+ a same application multiple times. For instance one for Unices, one
+ for Macintosh and one for Microsoft.
+ </item>
+ <item>
+ To ensure the quality of software and to prevent any unwanted functionality
+ rolling into the project all code will be reviewed by one of the lead members
+ before it is accepted. Since this project is aimed at throughput speed no
+ formal procedures will be enforced, but we promise not to let software in
+ that hasn't been checked.
</item>
</itemize>
-</chapter>
-<chapter>
- <heading>Decisions for the overall system.</heading>
-<para>In order to get the project running we have to make some decisions before we can start. Of course are the decisions always open for review, but initially our main aim is to get a system running. This doesn't mean that we allow a lesser architecture, but more that we create an environment that will lead to results. </para>
- <para>The following decisions apply to the system in general:</para>
- <itemize>
- <item>
- The major part of the system will be used for security features.
- The solution itself has to be secure.
- </item>
- <item>
- <para>In general we strive to be as platform and application independent as possible. However to achieve software to get ready and to assure progress some selections will have to be made excluding options for applications<footnote>An example is in the database. By using stored procedures and triggers MySQL cannot be used. However the data integrity at that point is more important than the ability to use MySQL.</footnote>. Where possible we will enable ports to other applications and platforms.</para>
- </item>
- <item>
- The computers collecting the data will only be Linux machines, with future support for other Unices. However it is not aim our to port this part of the project to other platforms just now.
- </item>
- <item>
- The database system will make heavy use of stored procedures and triggers and thus lock out some less feature-full database.
- </item>
- <item>
- Although we're not married to a database system initially this will be PostgreSQL only so that we can build for results. The code however shouldn't be build to deliberately lock outer systems. Other database that might be interesting to add: DB2, Oracle (if the rainfall of security advisories seems to be over) and Informix.
- </item>
- <item>
- The interface for the user will be a web-interface written in PHP with PostgreSQL-database access. Despite the fact that initially this will be the preferred way to communicate with our system, other interfaces are welcome and should be supported.
- </item>
- <item>
- The technologies used for the daemons on the central site and remote site are open for discussion. A decision is made when it is clear what exactly will be needed to code.
- </item>
- <item>
- The original logfiles on systems will not be harmed in any way, but will be saved the way they presented to gnucomo.
- </item>
- <item>
- In the database processed data as well as raw data will be stored.
- </item>
- <item>
- Our main aim is to ease the life of the administrator when dealing with the symptoms of a machine so that he doesn't miss important notifications. The project will be made around detection. We won't focus on making a maintenance applications but solely on monitoring, because other applications like webmin or linuxconf do already deliver such functionality. We are complementary to those applications. This doesn't mean that the system cannot send SMS'es, e-mails or make alarms sound.
- </item>
- <item>
- Any output of the logbook will be stored and sent within a certain interval which can be set. By doing that the mechanism will not flood the total mechanism and overload machines.
- </item>
- <item>
- When applications for gnucomo we will try and do the non-server part as platform independent as possible. This in order to prevent writing a same application multiple times. For instance one for Unices, one for Macintosh and one for Microsoft.
- </item>
- <item>
- To ensure the quality of software and to prevent any unwanted functionality rolling into the project all code will be reviewed by one of the lead members before it is accepted. Since this project is aimed at throughput speed no formal procedures will be enforced, but we promise not to let software in that hasn't been checked.
- </item>
- </itemize>
- <para/>
</chapter>
<chapter>
<heading>Overall system.</heading>
-<para>The overall systems aims to make maintenance data better accessible and by doing that lowering the barrier to be on alert for intrusions, system failure and other misery that can happen to computer systems. Also more systems can be monitored and even focus can be placed on desktop computers, something that nowadays rarely happens. Since the solution is only aimed at monitoring (with some responses possible) other people can watch their system(s) without being Administrator<footnote>This can be interesting for people using this service and not doing their own maintenance (smaller companies). If technical action needs to be taken a warning can be send to an administrator. This saves costs and time.</footnote>.</para>
- <para>The main system will know to sides:</para>
+<para>
+The overall systems aims to make maintenance data better accessible and by
+doing that lowering the barrier to be on alert for intrusions,
+system failure and other misery that can happen to computer systems.
+Also more systems can be monitored and even focus can be placed on desktop computers,
+something that nowadays rarely happens. Since the solution is only aimed at
+monitoring (with some responses possible) other people can watch their system(s)
+without being Administrator<footnote>This can be interesting for people using
+this service and not doing their own maintenance (smaller companies).
+If technical action needs to be taken a warning can be send to an administrator.
+This saves costs and time.</footnote>.
+</para>
+<para>
+The main system will know to sides:
+</para>
- <itemize>
- <item> Central Application - server </item>
- <item> Monitored System - client </item>
- </itemize>
+<itemize>
+ <item> Central Application - server </item>
+ <item> Monitored System - client </item>
+</itemize>
- <para>The project has been setup as a two sided system in order to be able to guard many computers at the same time. However it may be obvious that both sides of the application can very well be installed on a single system.</para>
- <para>When events<footnote>A signal can be the outcome of process that finished, logbook entries, warnings from intrusion detection systems, etc. </footnote> happen they will be stored in a file. When this file is delivered to a certain directory a daemon will detect this and start the transfer of the file. The file will be transferred to the central application or the client. This transfer will be triggered immediately after a process has finished or with a certain time-interval when it concerns a logbook. All output will be placed in a directory where the daemon detects it and ensures the transport. For transport currently only two mechanisms will be supported:</para>
- <itemize>
- <item>
- Encrypted file copy relying on the SSH protocol. On Unix-based systems this will scp (secure copy).
- </item>
- <item>
- E-Mail. The e-mail is encrypted and signed using gpg and then sent to the server. Since the file format will identify the type-of-output the Subject-field of the e-mail is not really needed.
- </item>
- </itemize>
+<para>
+The project has been setup as a two sided system in order to be able to
+guard many computers at the same time.
+However it may be obvious that both sides of the application can very
+well be installed on a single system.
+</para>
+<para>
+When events<footnote>A signal can be the outcome of process that finished,
+logbook entries, warnings from intrusion detection systems,
+etc. </footnote> happen they will be stored in a file.
+When this file is delivered to a certain directory a daemon will detect
+this and start the transfer of the file. The file will be transferred
+to the central application or the client. This transfer will be triggered
+immediately after a process has finished or with a certain time-interval
+when it concerns a logbook. All output will be placed in a directory where
+the daemon detects it and ensures the transport. For transport currently
+only two mechanisms will be supported:
+</para>
+<itemize>
+ <item>
+ Encrypted file copy relying on the SSH protocol.
+ On Unix-based systems this will scp (secure copy).
+ </item>
+ <item>
+ E-Mail. The e-mail is encrypted and signed using gpg and then sent to the server.
+ Since the file format will identify the type-of-output the Subject-field of
+ the e-mail is not really needed.
+ </item>
+</itemize>
- <section>
- <heading>Priority mechanism.</heading>
- <para>Each notification has a certain priority that requires a different handling of the issue. How each priority will be dealt with is something that can be set per server. The priority mechanism is a simple system of five categories (can be more or less). </para>
- <para/>
- </section>
+<section>
+ <heading>Priority mechanism.</heading>
+<para>
+Each notification has a certain priority that requires a different handling
+of the issue. How each priority will be dealt with is something that can
+be set per server. The priority mechanism is a simple system of five
+categories (can be more or less).
+</para>
+<para/>
+</section>
- <section>
- <heading>The dataflow diagram.</heading>
-
<para>The main dataflow will be as follows.</para>
-
<picture src="dataflow.png" eps="dataflow" scale="0.7"/>
- </para>
- </section>
+<section>
+ <heading>The dataflow diagram.</heading>
+<para>The main dataflow will be as follows.</para>
+<para>
+ <picture src="dataflow.png" eps="dataflow" scale="0.7"/>
+</para>
+<para/>
+</section>
</chapter>
<chapter>
<heading>Central Application: signal handler.</heading>
<para>
+<para>
-
<picture src="architecture.png" eps="architecture"/>
+ <picture src="architecture.png" eps="architecture"/>
Illustration 1 Basic overview of the processes on the server.
- </para>
+</para>
-On one machine signals from the network will come in. These signals can be logfiles, result files from applications, remarks entered by the administrator or whatever. Data delivery takes place into a certain directory. A daemon detects that data has come in and will enter it into the database. Once in the database stored procedures and triggers will recognize certain behavior and generate alerts. The user responsible for the server will be confronted with the alerts and can mark them, add comments to it or ignore them. Also it will be possible to do intelligent analysis on not so logical relations per computer or across computers<footnote>A good example could be a portscan on a system that takes place during a week. Normal a simple portscan takes place in a couple of minutes and will thus be easy to detect. By taking a longer period such a scan is harder to detect. </footnote>. Such scripts make detection possible, that is too time consuming to do during processing of the data. </para>
+On one machine signals from the network will come in.
+These signals can be logfiles, result files from applications,
+remarks entered by the administrator or whatever.
+Data delivery takes place into a certain directory.
+A daemon detects that data has come in and will enter it into the database.
+Once in the database stored procedures and triggers will recognize certain
+behavior and generate alerts. The user responsible for the server will be
+confronted with the alerts and can mark them, add comments to it or ignore them.
+Also it will be possible to do intelligent analysis on not so logical relations
+per computer or across computers<footnote>A good example could be a portscan
+on a system that takes place during a week. Normal a simple portscan takes
+place in a couple of minutes and will thus be easy to detect.
+By taking a longer period such a scan is harder to detect. </footnote>. Such
+scripts make detection possible, that is too time consuming to do during
+processing of the data.
+</para>
- <section>
- <heading>Data processing.</heading>
- <para>The data processing has four tasks:</para>
- <itemize>
- <item>
- <para>Extracting data from e-mail and store it in the input-buffer. This can be done by a daemon that checks the e-mail<footnote>It would be logical to place an e-mail server like sendmail or postfix on the server. In many cases the monitored computer will be featuring a SMTP daemon. If a system is comprimised no evidence that comes through will be really trustworthy. By sending it to another machine all evidence that is available will have left the system the moment a hack takes place.</footnote> with a certain interval extracts the e-mails and leave the content in a file in the input buffer. This daemon has only rights to write to the directory it has to write to. <emph>We may as well have the email captured directly by a program with a "gnucomo: |/usr/local/bin/gnucomo-input" - like alias.</emph></para>
- </item>
- <item>
- <para>Detect files in the input buffer decrypt the content and verify the signature. Another daemon will see the log-files and starts checking if the origin is correct (by verifying the signature) and decrypting the content. The legible files will be processed by entering the data into the database.</para>
- </item>
- <item>
- <para>The database will accept the data and perform a certain number of checks as the data comes in. During the processing of the data abnormalities will be detected and entered into a notification table. The database system will also carry out more complex tasks on given moments in time and enter them as well in the notification table.</para>
- </item>
- <item>
- <para>The database system must be able to undertake action when high alerts are being entered into the database. This can be a couple of things to begin with: send an e-mail or SMS. In a later stage other technologies may be added as well. In this scheme we also make a possibility to escalate problems when no action is taken in a certain amount of time.</para>
- </item>
- </itemize>
- </section>
- <section>
- <heading>Web interface.</heading>
- <para>The web interface will used to interact with the user. The interface should be intuitive and easy to understand. More important warnings should directly draw attention. The user must be able to perform settings so that warnings can be rated differently than the original settings. </para>
- <para>The interface will do the following things:</para>
- <itemize>
- <item>
- <para>Show a list of warnings that are currently open.</para>
- </item>
- <item>
- <para>It must be possible to sort the list on all the fields shown.</para>
- </item>
- <item>
- <para>Deliver detailed information (logbook entries) upon request that have led to the warning. </para>
- </item>
- <item>
- <para>Undertake certain actions like sending <reference href="mailto:abuse@internet-provider.net">abuse@internet-provider.net</reference> e-mails with information.</para>
- </item>
- <item>
- <para>Monitor actions on outstanding issues. </para>
- </item>
- </itemize>
- <para/>
- </section>
+<section>
+ <heading>Data processing.</heading>
+
+<para>The data processing has four tasks:</para>
+<itemize>
+ <item>
+ Extracting data from e-mail and store it in the input-buffer.
+ This can be done by a daemon that checks the e-mail<footnote>It would be logical
+ to place an e-mail server like sendmail or postfix on the server.
+ In many cases the monitored computer will be featuring a SMTP daemon.
+ If a system is comprimised no evidence that comes through will be really
+ trustworthy. By sending it to another machine all evidence that is
+ available will have left the system the moment a hack takes place.</footnote>
+ with a certain interval extracts the e-mails and leave the content
+ in a file in the input buffer. This daemon has only rights to write
+ to the directory it has to write to. <emph>We may as well have the
+ email captured directly by a program with a
+ "gnucomo: |/usr/local/bin/gnucomo-input" - like alias.</emph>
+ </item>
+ <item>
+ Detect files in the input buffer decrypt the content and verify the signature.
+ Another daemon will see the log-files and starts checking if the origin is
+ correct (by verifying the signature) and decrypting the content.
+ The legible files will be processed by entering the data into the database.
+ </item>
+ <item>
+ The database will accept the data and perform a certain number of
+ checks as the data comes in. During the processing of the data
+ abnormalities will be detected and entered into a notification table.
+ The database system will also carry out more complex tasks on given
+ moments in time and enter them as well in the notification table.
+ </item>
+ <item>
+ The database system must be able to undertake action when high
+ alerts are being entered into the database.
+ This can be a couple of things to begin with:
+ send an e-mail or SMS. In a later stage other technologies may be added as well.
+ In this scheme we also make a possibility to escalate problems when no
+ action is taken in a certain amount of time.
+ </item>
+</itemize>
+</section>
+
+<section>
+ <heading>Web interface.</heading>
+
+<para>
+The web interface will used to interact with the user.
+The interface should be intuitive and easy to understand.
+More important warnings should directly draw attention.
+The user must be able to perform settings so that warnings
+can be rated differently than the original settings.
+</para>
+<para>
+The interface will do the following things:
+</para>
+<itemize>
+ <item>
+ Show a list of warnings that are currently open.
+ </item>
+ <item>
+ It must be possible to sort the list on all the fields shown.
+ </item>
+ <item>
+ Deliver detailed information (logbook entries) upon request that have led to the warning.
+ </item>
+ <item>
+ Undertake certain actions like sending
+ <reference href="mailto:abuse@internet-provider.net">abuse@internet-provider.net</reference>
+ e-mails with information.
+ </item>
+ <item>
+ Monitor actions on outstanding issues.
+ </item>
+</itemize>
+<para/>
+</section>
</chapter>
<chapter>
<heading>Sending messages to the central gnucomo system.</heading>
-<para>One of the main tasks is getting all the messages to the database. Ultimately gnucomo will support multiple ways of receiving the data. Basically anything goes, but two mechanisms will be supported in the project to begin with:</para>
+<para>
+One of the main tasks is getting all the messages to the database.
+Ultimately gnucomo will support multiple ways of receiving the data.
+Basically anything goes, but two mechanisms will be supported in the project
+to begin with:
+</para>
<enumerate>
<item>
- <para>E-mail. Messages and elements from logfiles will be sent through e-mail.</para>
+ E-mail. Messages and elements from logfiles will be sent through e-mail.
</item>
<item>
- <para>File copy. Using technologies like scp or ftp (not preferred due to the insecure nature) can place files directly in the receiving directory. </para>
+ File copy. Using technologies like scp or ftp (not preferred due to
+ the insecure nature) can place files directly in the receiving directory.
</item>
</enumerate>
- <section>
- <heading>Ensuring data integrity.</heading>
-
<para><TO BE DESCRIBED></para>
- </section>
+<section>
+ <heading>Ensuring data integrity.</heading>
+<para><TO BE DESCRIBED></para>
+</section>
- <section>
- <heading>Directories and filenames on the server.</heading>
+<section>
+ <heading>Directories and filenames on the server.</heading>
<para>
Files will be dealt with as if gnucomo were a user (actually there will
<para>Urgency</para>
</col>
<col>
- <para>This indicates the urgency of the file. The lower the number the higher it will rank when an overview is given. Standard files are ranked value 3. The ranking works as follows:</para>
- <para>* 1 <strong>Urgent flash message.</strong> Something urgent needs to be reported. This is only used for emergencies like serious alarms.</para>
- <para>* 2 <strong>Rapid delivery.</strong> An important message has to get through that is more important than normal delivery, but is not top priority like an emergency.</para>
- <para>* 3 <strong>Normal.</strong> This is used in most case for normal messages.</para>
- <para>* 4 <strong>Low priority.</strong> This is data would be useful to place into the system as nice to have.</para>
+ <para>This indicates the urgency of the file. The lower the number the higher
+ it will rank when an overview is given. Standard files are ranked value 3.
+ The ranking works as follows:</para>
+ <para>* 1 <strong>Urgent flash message.</strong> Something urgent needs to
+ be reported. This is only used for emergencies like serious alarms.</para>
+ <para>* 2 <strong>Rapid delivery.</strong> An important message has to get
+ through that is more important than normal delivery, but is not top
+ priority like an emergency.</para>
+ <para>* 3 <strong>Normal.</strong> This is used in most
+ case for normal messages.</para>
+ <para>* 4 <strong>Low priority.</strong> This is data would be useful
+ to place into the system as nice to have.</para>
</col>
</row>
<row>
<para>TypeOfMessage</para>
</col>
<col>
- <para>This is an indicator what type of data is delivered to gnucomo. There are several categories:</para>
+ <para>This is an indicator what type of data is delivered to gnucomo.
+ There are several categories:</para>
<para>* <strong>cron.</strong> This data comes from the /var/log/cron-log (unix).</para>
<para>* <strong>httpaccess.</strong> This data comes from the normal http-log (Apache).</para>
<para>* <strong>httperror.</strong> This data comes from the http_error-log (Apache).</para>
<para>* <strong>maillog.</strong> This data comes from the /var/log/maillog (unix).</para>
- <para>* <strong>messages.</strong> The data delivered here comes from the /var/log/messages file (unix)</para>
- <para>* <strong>text.</strong> This file contains a message in plaintext generated by a gnucomo-client and can be anything. It will be dealt with as plaintext.</para>
+ <para>* <strong>messages.</strong> The data delivered here comes from
+ the /var/log/messages file (unix)</para>
+ <para>* <strong>text.</strong> This file contains a message in plaintext
+ generated by a gnucomo-client and can be anything.
+ It will be dealt with as plaintext.</para>
</col>
</row>
<row>
<para>Timestamp</para>
</col>
<col>
- <para>The timestamp is made in war-log (YYYYMMDDHHMMSS) format. The timestamp is generated on the client in GMT (to discover discrepancies in timing).</para>
+ <para>The timestamp is made in war-log (YYYYMMDDHHMMSS) format.
+ The timestamp is generated on the client in GMT (to discover
+ discrepancies in timing).</para>
</col>
</row>
<row>
<para>Objectid</para>
</col>
<col>
- <para>The objectid is the id that is used within the central gnucomo system to recognize the client. Based on this entry the database can link the data to the correct object. Also gpg can obtain the correct e-mail address (by running a query in the database) for verification of the signature of the crypted message.</para>
+ <para>The objectid is the id that is used within the central
+ gnucomo system to recognize the client.
+ Based on this entry the database can link the data to the correct object.
+ Also gpg can obtain the correct e-mail address (by running a query
+ in the database) for verification of the signature of the crypted message.</para>
</col>
</row>
<row>
<para>Indicates the file type:</para>
<para>* <strong>asc.</strong> Plaintext ASCII</para>
<para>* <strong>gpg.</strong> gpg-crypted data.</para>
- <para>* <strong>und.</strong> Undertermined data. When files come in by e-mail it is not 100% sure if they are crypted or not. These data has first to be analyzed before it is moved to the correct queue. </para>
+ <para>* <strong>und.</strong> Undertermined data. When files
+ come in by e-mail it is not 100% sure if they are crypted
+ or not. These data has first to be analyzed before it is
+ moved to the correct queue. </para>
</col>
</row>
</table>
<subsection>
<heading>Directory for incoming data.</heading>
-<para>For incoming messages there will be separate directories (<code>/home/gnucomo/incoming/</code>)for:</para>
+<para>
+For incoming messages there will be separate directories
+(<code>/home/gnucomo/incoming/</code>)for:
+</para>
<enumerate>
<item>
- <para>Dropbox. This directory is ready to receive data from all sorts of systems. This directory is world writeable (<strong><emph>but not deleteable!</emph></strong>): <code>/home/gnucomo/incoming/dropbox/</code></para>
+ Dropbox. This directory is ready to receive data from all sorts of systems.
+ This directory is world writeable (<strong><emph>but not deleteable!</emph></strong>):
+ <code>/home/gnucomo/incoming/dropbox/</code>
</item>
<item>
- <para>Encrypted messages. In this directory messages will be placed that are still gpg-crypted. In this directory the files await decryption and verification of the signature. This directory is: <code>/home/gnucomo/incoming/crypted/</code></para>
+ Encrypted messages. In this directory messages will be placed that are still
+ gpg-crypted. In this directory the files await decryption and verification of
+ the signature. This directory is: <code>/home/gnucomo/incoming/crypted/</code>
</item>
<item>
- <para>Decrypted with errors. During the decryption exercise anything can go wrong. Decrypting can fail or the signature may show errors. If this happens the original message is moved to a different directory: <code>/home/gnucomo/incoming/cryptfail/</code></para>
+ Decrypted with errors. During the decryption exercise anything can go wrong.
+ Decrypting can fail or the signature may show errors. If this happens the
+ original message is moved to a different directory:
+ <code>/home/gnucomo/incoming/cryptfail/</code>
</item>
<item>
- <para>Inbox. After successful decryption the decrypted message is moved to the inbox. Data that is not encrypted can be moved here from the dropbox after certain verifications. The directory is: <code>/home/gnucomo/incoming/inbox/</code></para>
+ Inbox. After successful decryption the decrypted message is moved to the inbox.
+ Data that is not encrypted can be moved here from the dropbox after certain
+ verifications. The directory is: <code>/home/gnucomo/incoming/inbox/</code>
</item>
<item>
- <para>Processed. After processing the data the file is stored in the directory processed for further reference for a certain amount of time. The directory is: <code>/home/gnucomo/incoming/processed/</code></para>
+ Processed. After processing the data the file is stored in the directory
+ processed for further reference for a certain amount of time.
+ The directory is: <code>/home/gnucomo/incoming/processed/</code>
</item>
<item>
- <para>Archive. After a certain period the files will be archived. Since not every system will archive everything this directory may also be a symbolic link to <code>/dev/null</code>. The used directory is: <code>/home/gnucomo/archive/</code></para>
+ Archive. After a certain period the files will be archived.
+ Since not every system will archive everything this directory may
+ also be a symbolic link to <code>/dev/null</code>.
+ The used directory is: <code>/home/gnucomo/archive/</code>
</item>
</enumerate>
</subsection>
<subsection>
<heading>Directory for outgoing data.</heading>
- <para>For outgoing messages the directory <code>/home/gnucomo/outgoing</code> will be used. This directory knows a couple of sub directories:</para>
+<para>
+For outgoing messages the directory <code>/home/gnucomo/outgoing</code> will
+be used. This directory knows a couple of sub directories:
+</para>
<enumerate>
<item>
- <para>Dropbox. This directory is used by the central gnucomo system to place outgoing messages in. The used directory is: <code>/home/gnucomo/outgoing/dropbox/</code></para>
+ Dropbox. This directory is used by the central gnucomo system to
+ place outgoing messages in.
+ The used directory is: <code>/home/gnucomo/outgoing/dropbox/</code>
</item>
<item>
- <para>Outbox. After processing the message (including signing and encrypting when applicable) the messages are placed in the outbox: <code>/home/gnucomo/outgoing/outbox/</code></para>
+ Outbox. After processing the message (including signing and encrypting
+ when applicable) the messages are placed in the outbox:
+ <code>/home/gnucomo/outgoing/outbox/</code>
</item>
<item>
- <para>Processed. After processing the data the file is stored in the directory processed for further reference for a certain amount of time. After sending a message a confirmation will be made that is saved as an incoming message. The directory is: <code>/home/gnucomo/outgoing/processed/</code></para>
+ Processed. After processing the data the file is stored in the
+ directory processed for further reference for a certain amount
+ of time. After sending a message a confirmation will be made that
+ is saved as an incoming message.
+ The directory is: <code>/home/gnucomo/outgoing/processed/</code>
</item>
<item>
- <para>Archive. After a certain period the files will be archived. Since not every system will archive everything this directory may also be a symbolic link to <code>/dev/null</code>. The used directory is: <code>/home/gnucomo/archive/</code></para>
+ Archive. After a certain period the files will be archived.
+ Since not every system will archive everything this directory
+ may also be a symbolic link to <code>/dev/null</code>.
+ The used directory is: <code>/home/gnucomo/archive/</code>
</item>
</enumerate>
<section>
<heading>Directories on the client-side.</heading>
-<para>On the client-side the files that need to be transmitted will be placed in a directory system as well. In the future this system may not be in use at all devices (routers, certain MS Windows-machine, IP Telephones, etc.). For those systems a different mechanism will become be described here. Initially we focus on Linux systems that will enter data into the database.</para>
- <para>The filename convention will be totally identical to the filename convention on the server, since this the same mechanism.</para>
- <para>To facilitate gnucomo client and server on one and the same machine the gnucomo-client should have a different default user. For this purpose the user <strong>gcm_client</strong> will be created. </para>
+<para>
+On the client-side the files that need to be transmitted will be placed in a
+directory system as well. In the future this system may not be in use at all
+devices (routers, certain MS Windows-machine, IP Telephones, etc.). For those
+systems a different mechanism will become be described here.
+Initially we focus on Linux systems that will enter data into the database.
+</para>
+<para>
+The filename convention will be totally identical to the filename
+convention on the server, since this the same mechanism.
+</para>
+<para>
+To facilitate gnucomo client and server on one and the same machine
+the gnucomo-client should have a different default user.
+For this purpose the user <strong>gcm_client</strong> will be created.
+</para>
<subsection>
<heading>Directory for incoming data.</heading>
- <para>For incoming messages there will be separate directories (<code>/home/gnucomo/incoming/</code>)for:</para>
+<para>
+For incoming messages there will be separate directories
+(<code>/home/gnucomo/incoming/</code>)for:
+</para>
<enumerate>
<item>
- <para>Dropbox. This directory is ready to receive data from all sorts of systems. This directory is world writeable (<emph><strong>but not deleteable!</strong></emph>): <code>/home/gcm_client/incoming/dropbox/</code></para>
+ Dropbox. This directory is ready to receive data from all sorts of systems.
+ This directory is world writeable (<emph><strong>but not deleteable!</strong></emph>):
+ <code>/home/gcm_client/incoming/dropbox/</code>
</item>
<item>
- <para>Encrypted messages. In this directory messages will be placed that are still gpg-crypted. In this directory the files await decryption and verification of the signature. This directory is: <code>/home/gcm_client/incoming/crypted/</code></para>
+ Encrypted messages. In this directory messages will be placed that
+ are still gpg-crypted. In this directory the files await decryption
+ and verification of the signature.
+ This directory is: <code>/home/gcm_client/incoming/crypted/</code>
</item>
<item>
- <para>Decrypted with errors. During the decryption exercise anything can go wrong. Decrypting can fail or the signature may show errors. If this happens the original message is moved to a different directory: <code>/home/gcm_client/incoming/cryptfail/</code></para>
+ Decrypted with errors. During the decryption exercise anything can go wrong.
+ Decrypting can fail or the signature may show errors.
+ If this happens the original message is moved to a different directory:
+ <code>/home/gcm_client/incoming/cryptfail/</code>
</item>
<item>
- <para>Inbox. After successful decryption the decrypted message is moved to the inbox. Data that is not encrypted can be moved here from the dropbox after certain verifications. The directory is: <code>/home/gcm_client/incoming/inbox/</code></para>
+ Inbox. After successful decryption the decrypted message is moved
+ to the inbox. Data that is not encrypted can be moved here from
+ the dropbox after certain verifications. The directory is:
+ <code>/home/gcm_client/incoming/inbox/</code>
</item>
<item>
- <para>Processed. After processing the data the file is stored in the directory processed for further reference for a certain amount of time. The directory is: <code>/home/gcm_client/incoming/processed/</code></para>
+ Processed. After processing the data the file is stored
+ in the directory processed for further reference for a
+ certain amount of time. The directory is:
+ <code>/home/gcm_client/incoming/processed/</code>
</item>
</enumerate>
<subsection>
<heading>Directory for outgoing data.</heading>
- <para>For outgoing messages the directory <code>/home/gcm_client/outgoing</code> will be used. This directory knows a couple of sub directories:</para>
+<para>
+For outgoing messages the directory <code>/home/gcm_client/outgoing</code> will be used.
+This directory knows a couple of sub directories:
+</para>
<enumerate>
<item>
- <para>Dropbox. This directory is used by the central gnucomo system to place outgoing messages in. The used directory is: <code>/home/gcm_client/outgoing/dropbox/</code></para>
+ Dropbox. This directory is used by the central gnucomo system to place
+ outgoing messages in.
+ The used directory is: <code>/home/gcm_client/outgoing/dropbox/</code>
</item>
<item>
- <para>Outbox. After processing the message (including signing and encrypting when applicable) the messages are placed in the outbox: <code>/home/gcm_client/outgoing/outbox/</code></para>
+ Outbox. After processing the message (including signing and
+ encrypting when applicable) the messages are placed in the outbox:
+ <code>/home/gcm_client/outgoing/outbox/</code>
</item>
<item>
- <para>Processed. After processing the data the file is stored in the directory processed for further reference for a certain amount of time. After sending a message a confirmation will be made that is saved as an incoming message. The directory is: <code>/home/gcm_client/outgoing/processed/</code></para>
+ Processed. After processing the data the file is stored in the
+ directory processed for further reference for a certain amount
+ of time. After sending a message a confirmation will be made
+ that is saved as an incoming message.
+ The directory is: <code>/home/gcm_client/outgoing/processed/</code>
</item>
</enumerate>
</subsection>
<chapter>
<heading>Getting data into the database.</heading>
- <para>The files in the /home/gnucomo/incoming/inbox/ should be stored in the database. For this purpose there is a table <emph>unprocessed_log</emph>. The data of the filename as well as the content of the file need to be placed in one record.</para>
- <para>There are some fields that have to be addressed immediately:</para>
+
+<para>
+The files in the /home/gnucomo/incoming/inbox/ should be stored in the database.
+For this purpose there is a table <emph>unprocessed_log</emph>.
+The data of the filename as well as the content of the file need
+to be placed in one record.
+</para>
+<para>
+There are some fields that have to be addressed immediately:
+</para>
<enumerate>
<item>
- <para>Servicecode: The servicecode will be obtained out of the filename the is the type_of_message-field in the filename. </para>
+ Servicecode: The servicecode will be obtained out of the filename the
+ is the type_of_message-field in the filename.
</item>
<item>
- <para>Objectid: This data is given in the filename it can be found in the <emph>objectid</emph>-part of the filename.</para>
+ Objectid: This data is given in the filename it can be found
+ in the <emph>objectid</emph>-part of the filename.
</item>
<item>
- <para>Logdata: The data is saved as follows: filename (unaltered) <CR>textual data of the file.</para>
+ Logdata: The data is saved as follows: filename (unaltered)
+ <CR>textual data of the file.
</item>
</enumerate>
- <para>The daemon application that delivers the data is called <strong>gcm-input</strong>. It performs the following steps with no extra functionality:</para>
+<para>
+The daemon application that delivers the data is called <strong>gcm-input</strong>.
+It performs the following steps with no extra functionality:
+</para>
<enumerate>
<item>
</item>
</enumerate>
- <para>To write the data in the database a database user gcm_input exists. This user has only the right to enter data into the database. There are no deletion, update or select-permissions.</para>
- <para/>
+<para>
+To write the data in the database a database user gcm_input exists.
+This user has only the right to enter data into the database.
+There are no deletion, update or select-permissions.
+</para>
+
</chapter>
<chapter>
- <heading>The database.</heading>
+ <heading><label name='database'/>The database.</heading>
- <para>The database is the heart of the system. It will contain all event-data of multiple computers. The intelligence that can be performed on the database will be placed there. To do this as integrated as possible stored procedures and triggers will be used. To begin with we have selected checks to be performed that will be expanded throughout time.</para>
- <para>Since the gnucomo database and files contain sensitive data security measures have to be in place. Several database users will be exist that have limited rights to perform a certain task ensuring some protection against unauthorized access. However these mechanisms on it's own will work fine, bad maintenance may still screw-up good security. Good database maintenance is needed. For the gnucomo the protection of the valid authentic nature of the data in the database has our highest priority.</para>
- <para>A <emph>table-name</emph> in this chapter is written in cursive writing.</para>
+<para>
+The database is the heart of the system.
+It will contain all event-data of multiple computers.
+The intelligence that can be performed on the database will be placed there.
+To do this as integrated as possible stored procedures and triggers will be used.
+To begin with we have selected checks to be performed that will be
+expanded throughout time.
+</para>
+<para>
+Since the gnucomo database and files contain sensitive data
+security measures have to be in place. Several database users
+will be exist that have limited rights to perform a certain task
+ensuring some protection against unauthorized access.
+However these mechanisms on it's own will work fine, bad maintenance may still
+screw-up good security. Good database maintenance is needed.
+For the gnucomo the protection of the valid authentic nature of
+the data in the database has our highest priority.
+</para>
+<para>
+A <emph>table-name</emph> in this chapter is written in cursive writing.
+</para>
<section>
<heading>Database conventions.</heading>
- <para>The database will be built according the following conventions:</para>
- <itemize>
- <item>
- <para>All names for tables, indexes and fields will be written in lower case and will be singular. Spaces in names are not allowed.</para>
- </item>
- <item>
- <para>If a table contains field referring to other tables the mother-tables are mentioned in alphabetical order with an underscore between the table-names. So <emph>object</emph> and <emph>user</emph> will make a third table <emph>object_user</emph></para>
- </item>
- <item>
- <para>A data access user (being the interface) is not allowed to write to the log-entries and the warnings. To change the state of a warning a stored procedure will do so by having a different entry in a table. This should make it possible to discover who did what at which moment in time.</para>
- </item>
- <item>
- <para>The name of two related fields that make the relationship between two tables will be the same to avoid confusion.</para>
- </item>
- </itemize>
+
+<para>
+The database will be built according the following conventions:
+</para>
+<itemize>
+ <item>
+ All names for tables, indexes and fields will be written in lower
+ case and will be singular. Spaces in names are not allowed.
+ </item>
+ <item>
+ If a table contains field referring to other tables the mother-tables are
+ mentioned in alphabetical order with an underscore between the table-names.
+ So <emph>object</emph> and <emph>user</emph>
+ will make a third table <emph>object_user</emph>
+ </item>
+ <item>
+ A data access user (being the interface) is not allowed to write to
+ the log-entries and the warnings. To change the state of a warning
+ a stored procedure will do so by having a different entry in a table.
+ This should make it possible to discover who did what at which moment in time.
+ </item>
+ <item>
+ The name of two related fields that make the relationship between two
+ tables will be the same to avoid confusion.
+ </item>
+</itemize>
</section>
<section>
<heading>Database design.</heading>
- <para>In the design we anticipate to deliver an as best as possible database performance. That means that data that needs to be entered occasionally can be heavily indexed to increase performance. However data that is mainly stored will only be indexed marginally to have the best possible performance on data entry. If during one of the checks on data-entry a notification is made, the information related to that notification will be indexed very well to increase retrieval performance. What we will try to avoid is that the user interface will cause full table scan and affect the performance of the overall system dramatically. One of the techniques to increase performance on display is to work with views. So where it is feasible we will use them.</para>
- <para>In general the database must also be maintained well. So daily maintenance scripts should keep the performance good<footnote>PostgreSQL seems to have very good features to do proper maintenance and they have to be exploited to the full extend.</footnote>. </para>
+<para>
+In the design we anticipate to deliver an as best as possible database performance.
+That means that data that needs to be entered occasionally can be heavily indexed
+to increase performance. However data that is mainly stored will only be indexed
+marginally to have the best possible performance on data entry. If during one of
+the checks on data-entry a notification is made, the information related to that
+notification will be indexed very well to increase retrieval performance.
+What we will try to avoid is that the user interface will cause full table
+scan and affect the performance of the overall system dramatically.
+One of the techniques to increase performance on display is to work with views.
+So where it is feasible we will use them.
+</para>
+<para>
+In general the database must also be maintained well.
+So daily maintenance scripts should keep the performance good<footnote>PostgreSQL seems
+to have very good features to do proper maintenance and they have to be exploited to
+the full extend.</footnote>.
+</para>
- <subsection>
- <heading>Actual design.</heading>
+</section>
+<section>
+ <heading>Actual design.</heading>
- <para>In this part of the chapter the tables will be explained and then described with all important elements. Per table a sub-chapter will be created. Each table will have a table design, indexes, relationships and the required data (for those tables where the data itself is relevant in the design or sample data (for those cases where no set data is needed). For the relationships beside a description the subset of the total schema has been incorporated in the document so that it is more clear what exactly is meant. Due to the complex nature of the design those drawings sometimes will seem funny.</para>
- <para>For the fieldtypes the types of PostgreSQL will be used. These values can be found in Chapter 3 of the PostgreSQL User Manual (<reference href="http://www.postgresql.org/">http://www.postgresql.org</reference>). </para>
- <para>For indexes primary keys are always <emph>unique</emph> and called primary key in the name. Since unique indexes within PostgreSQL only work on B-Tree indexes (which is default) we will use B-Tree for all indexes. In cases where an exception is made the used type of index will be indicated in the characteristics. A footnote will explain why a different type of index has been selected.</para>
+<para>
+In this part of the chapter the tables will be explained and then described
+with all important elements. Per table a sub-chapter will be created.
+Each table will have a table design, indexes, relationships and the required data
+(for those tables where the data itself is relevant in the design or sample data
+(for those cases where no set data is needed). For the relationships beside a
+description the subset of the total schema has been incorporated in
+the document so that it is more clear what exactly is meant.
+Due to the complex nature of the design those drawings sometimes will seem funny.
+</para>
+<para>
+For the fieldtypes the types of PostgreSQL will be used.
+These values can be found in Chapter 3 of the PostgreSQL User Manual
+(<reference href="http://www.postgresql.org/">http://www.postgresql.org</reference>).
+</para>
+<para>
+For indexes primary keys are always <emph>unique</emph> and called
+primary key in the name. Since unique indexes within PostgreSQL only
+work on B-Tree indexes (which is default) we will use B-Tree for all indexes.
+In cases where an exception is made the used type of index will be indicated
+in the characteristics. A footnote will explain why a different type of
+index has been selected.
+</para>
-<subsubsection>
+<subsection>
<heading>action</heading>
<para>
-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 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. This table mainly is used for retrieval so indexing will be done as much as possible.
+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
+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.
+This table mainly is used for retrieval so indexing will be done as much as possible.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</table>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</table>
<para/>
-</paragraph>
-<paragraph>
+</subsubsection>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-action.png" eps="erd-action"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Default data in table.</heading>
<para>
The user cannot change this or add value to it.
</para>
-<table cpos='llp{4cm}p{6cm}'>
+<table cpos='p{1cm}p{2cm}p{1.5cm}p{6cm}'>
<thead>
<col> Actionid </col> <col> Actionname </col> <col> Statuscode </col>
<col>
</col>
</row>
</table>
-</paragraph>
-
</subsubsection>
-<subsubsection>
+</subsection>
+
+<subsection>
<heading>Action_notification_user.</heading>
<para>
Processing might be slower, but that's worth the price.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> anu_statuscode </col> <col> statuscode </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
+<para>
+Relationships with other tables:
+</para>
<table cpos='llp{7cm}'>
<thead>
<col> Fieldname </col> <col> Remote Table </col>
<picture src="erd-anu.png" eps="erd-anu"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample data.</heading>
<para>
Since no data is delivered automatically a couple of sample records are shown here.
</para>
- <table cpos='llllllp{4cm}'>
+ <table cpos='p{1cm}p{1cm}p{1cm}lllp{4cm}'>
<thead>
<col> Actionstepid </col> <col> Actionid </col> <col> Notificationid </col>
<col> Username </col> <col> Timestamp </col> <col> Status </col>
</col>
</row>
</table>
- </paragraph>
-</subsubsection>
+ </subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>log & log_adv. </heading>
<para>
To store the log-data there are two tables in use that have a one-on-one relationship. The logic behind this is the difference between raw-always needed data and the somewhat processed data to support basic retrieval. The last category isn't always used and when it's used it is redundant. Also the raw log is very important to the integrity of the system. For these reasons the processed data has been physically separated in a second table called <emph>log_adv</emph>. If needed a view will be available that combines the two tables. Despite the load indexing on <emph>log_adv</emph> will be done thoroughly.
</para>
-</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>log.</heading>
-<paragraph>
+<subsubsection>
<heading>The fields of log.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> log_timestamp </col> <col> timestamp </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
</para>
-</paragraph>
-<paragraph>
+</subsubsection>
+<subsubsection>
<heading>The fields of log_adv.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> networkdevice </col> <col> networkdevice </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample data combined from log and log_adv.</heading>
<para>
<col> Networkdevice </col> <col> eth0 </col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>log_notification. </heading>
<para>
In the log_notification the logbook entries that have caused an alert to occur are saved. When this table is used something has been detected. As this is clearly an intermediate table we anticipate to design checks where multiple entries in a log-file can lead to one notification. For forensics indexing will be focussed on retrieval speed.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</row>
</table>
-</paragraph>
-<paragraph>
+</subsubsection>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> lon_logid </col> <col>logid </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-lognotif.png" eps="erd-lognotif"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample data.</heading>
<para>
Some sample data:
<col> 11 </col> <col> 2 </col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>notification. </heading>
<para>
In this table all detected issues per object will be written. 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. 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.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> repeat_notification_timestamp </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-notif.png" eps="erd-notif"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample data.</heading>
<para>
<col> Securitylevel_close </col> <col> 4 </col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<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 occasional process. Anything that for some reason can be indexed ought to be indexed.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
<col> obj_mail_from </col> <col> mail_from </col> <col> <para/> </col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-object.png" eps="erd-object"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample data.</heading>
<para>
There is no preset data and therefor it's an example has been created. The table has quite some fields so the example has the fieldname in the left column and the data in the right column.
</para>
-<table cpos='ll'>
+<table cpos='lp{6cm}'>
<thead>
<col>
<para>Fieldname</para>
</row>
</table>
<para/>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<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. Since policies are utilized by the systems continuously all other process will rely on this index, while users will change the values occasionally.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
- </paragraph>
+ </subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<picture src="erd-objissue.png" eps="erd-objissue"/>
</para>
-</paragraph>
-<paragraph>
+</subsubsection>
+<subsubsection>
<heading>Sample data.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<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.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
- </paragraph>
+ </subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-objprior.png" eps="erd-objprior"/>
</para>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>object_service</heading>
<para>
The object service table indicates which services can be expected on the system If input fails to show up a notification can be generated.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-objservice.png" eps="erd-objservice"/>
</para>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<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 that makes heavy indexing logic.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
- </paragraph>
+ </subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
- </paragraph>
+ </subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-objsysusr.png" eps="erd-objsysusr"/>
</para>
- </paragraph>
-</subsubsection>
+ </subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>object_user</heading>
<para>
This table will enable users to get access to the information belonging to an object. Also this table is mainly used for data retrieval and will rely on the indexes.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
The indices of the <emph>object_user</emph> table:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>In the model this look like this:</para>
<picture src="erd-objusr.png" eps="erd-objusr"/>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>priority</heading>
<para>
The priority table contains information on the levels that are recognized by the system. Mainly data retrieval so depending on indexing. It needs to be said that most likely only a couple of states will exist<footnote>By default we will use five states, but many states can be given to enable all types of differentiation.</footnote>.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
<para>
<picture src="erd-prior.png" eps="erd-prior"/>
</para>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>service</heading>
<para>
The table <emph>service</emph> indicates the service that can be handled by the system. Out of the servicelist the administrator can indicate what services to expect.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
Relationships with other tables:
<para>
<picture src="erd-service.png" eps="erd-service"/>
</para>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>status.</heading>
<para>
The table <emph>status</emph> contains the possible states that a notification can have. As with the table <emph>priority</emph> these statuses are limited in number by default but can be expanded. Also here retrieval prevails above data entry and therefor indexing is important.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
The table is indexed on the following fields:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
Relationships with other tables
<para>
<picture src="erd-status.png" eps="erd-status"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Default values.</heading>
<para>The status values are default for the system and for that reason are predefined.</para>
-<table cpos='lllp{6cm}'>
+<table cpos='p{2cm}lp{1cm}p{6cm}'>
<thead>
<col>
<para>Statuscode</para>
</col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>type_of_issue.</heading>
<para>This table will contain a list of all available issues that can be detected. All issues have a suggested priority setting. This is typically data retrieval and good indexing is needed.</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
The table is indexed on the following fields:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<table cpos='lll'>
<thead>
<para>
<picture src="erd-toi.png" eps="erd-toi"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Default values.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>unprocessed_log</heading>
<para>
The <emph>user</emph> table contains the users that can login the monitoring application. It will also store if the users maintains the system. Mainly used for retrieval so properly indexed.
</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes.</heading>
<para>
The indices of the table:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
Relationships with other tables:
<para>
<picture src="erd-unplog.png" eps="erd-unplog"/>
</para>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>Sample values.</heading>
<para>To do</para>
-</paragraph>
</subsubsection>
+</subsection>
-<subsubsection>
+<subsection>
<heading>user_gnucomo</heading>
<para>The <emph>user</emph> table contains the users that can login the monitoring application. It will also store if the users maintains the system. Mainly used for retrieval so properly indexed.</para>
-<paragraph>
+<subsubsection>
<heading>The fields.</heading>
<para>
The fields are listed in the table below:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The indexes</heading>
<para>
The table is indexed on the following fields:
</col>
</row>
</table>
-</paragraph>
+</subsubsection>
-<paragraph>
+<subsubsection>
<heading>The relationships.</heading>
<para>
Relationships with other tables
<para>
<picture src="erd-usr.png" eps="erd-usr"/>
</para>
-</paragraph>
</subsubsection>
</subsection>
</section>
</section>
</chapter>
- <chapter>
- <heading>Dependency on other free software.</heading>
- <para>The following list is a set of applications that will be used on to make our application work:</para>
+<chapter>
+ <heading>Dependency on other free software.</heading>
+
+<para>The following list is a set of applications that will be used on to make our application work:</para>
<table cpos='lp{8cm}l'>
<thead>
<col>
</col>
</row>
</table>
- <para/>
- </chapter>
+<section>
+<heading>Related projects</heading>
+
+<para>
+There are a number of projects that can help <strong>Gnucomo</strong> or perform
+similar funtions:
+
+<itemize>
+ <item>
+ <reference href='http://crm114.sourceforge.net/'>CRM114</reference> - The Controllable
+ Regex Mutilator.
+ </item>
+</itemize>
+</para>
+</section>
+</chapter>
<chapter>
<heading>Settings on the server machine.</heading>
projects / gnucomo.git / commitdiff