From: arjen Date: Wed, 5 Feb 2003 09:56:07 +0000 (+0000) Subject: Added tables parameter_class and parameter_notification. X-Git-Tag: V0_0_4~3 X-Git-Url: http://www.andromeda.nl/gitweb/?p=gnucomo.git;a=commitdiff_plain;h=f656e2dd35f289477022b24070033d7b2d2ecfc5 Added tables parameter_class and parameter_notification. Notifications and issues further explained. --- diff --git a/doc/manifest.xml b/doc/manifest.xml index ed99bdd..cf570a7 100644 --- a/doc/manifest.xml +++ b/doc/manifest.xml @@ -11,9 +11,9 @@ Brenno J.S.A.A.F. de Winter, De Winter Information Solutions Arjen Baart, Andromeda Technology & Automation - December 6th, 2002. + December 12th, 2002. - 0.22 + 0.24 @@ -24,6 +24,8 @@ About this document. + + 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 @@ -129,6 +131,12 @@ and not run into unneeded disappointments. Added new elements to the database + + 0.24Brenno de WinterDec 12, 2002 + + Updates to the database to reflect the most recent changes. + + @@ -2243,11 +2251,21 @@ Some sample data: notification. -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. @@ -2265,7 +2283,7 @@ The fields of the notification table are: - notificationid Bigserial 8 + notificationid Bigint Autonumber 8 Autonumber @@ -2277,22 +2295,24 @@ The fields of the notification table are: - type_of_notification_id Bigint 8 + type_of_issue_id Bigint 8 - Reference to the type_of_notification indicating what + Reference to the type_of_issue indicating what type of notification we have here and what basic rules apply. + Notifications are always created on an issue that can be raised. timestamp Timestamp - Timestamp that this notification was created. + Timestamp used to indicate the moment when this notification was created. statuscode Varchar 3 The status the actual status a notification has. + This can be new, open, pending, waiting for verification, rejected, closed, needs investigation @@ -2307,10 +2327,14 @@ The fields of the notification table are: escalation_count_timestamp Timestamp - Timestamp since the last escalation took placeThe 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 + placeThe 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.. + taken within a certain amount of time. Based on the status and the type + of notification escalation can take place.. @@ -2326,19 +2350,19 @@ The fields of the notification table are: securitylevel_view Int 4 - 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. 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. securitylevel_add Int 4 - 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. securitylevel_close Int 4 - 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. @@ -2470,8 +2494,7 @@ The following data is an example of a notification placed in the database. object -The object 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 object 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. @@ -2489,7 +2512,7 @@ The fields are: - objectid Bigserial 8 + objectid Bigint Autonumber 8 Autonumbering code for the computer or device. @@ -2497,7 +2520,7 @@ The fields are: objectname Text - The hostname of the object + The hostname of the object as it can be recognized by the gcm_input-application. @@ -2566,7 +2589,7 @@ The fields are: - 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. @@ -2785,7 +2808,7 @@ left column and the data in the right column. object_issue. 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. @@ -2828,7 +2851,7 @@ The fields of object_issue: - type_of_notificationid + type_of_issueid Bigint @@ -2837,8 +2860,8 @@ The fields of object_issue: 8 - Reference to the type_of_notification indicating - what type of notification we have here and what basic rules apply. + Reference to the type_of_issue indicating + how we will handle this type of issue for this particular object. If nothing is entered here, the default rules apply. @@ -2853,7 +2876,7 @@ The fields of object_issue: The priority that will be set automatically when this type of - notification is entered into the system. + issue is entered into the system. @@ -2895,7 +2918,7 @@ The fields of object_issue: - The maximum priority given to this type of notification. + 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. @@ -2950,7 +2973,7 @@ These are the indices: - type_of_notification_id + type_of_issue_id Primary key @@ -2969,10 +2992,10 @@ These are the indices: - obi_type_of_notificationid + obi_type_of_issueid - type_of_notification_id + type_of_issue_id @@ -3042,7 +3065,7 @@ Some sample data: Objectid - Type_of_notification_id + Type_of_issue_id Default Priority @@ -3183,8 +3206,7 @@ Some sample data: object_priority. -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. @@ -3289,7 +3311,7 @@ The fields are listed below: - Repeat this notification if no action occurs since the notification. Yes = T / No = F + Repeat this notification if no action occurs within a certain timeframe. Yes = T / No = F @@ -3363,10 +3385,10 @@ Indices of the object_priority table: - obi_type_of_notification_id + obi_type_of_issue_id - type_of_notification_id + type_of_issue_id @@ -3431,7 +3453,7 @@ In the model this look like this: object_service -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. @@ -3705,10 +3727,7 @@ Relationships with other tables: object_system_user -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. @@ -3815,7 +3834,7 @@ The table is indexed on the following fields: osu_pk - objectid + objectid, system_username Primary key @@ -4138,7 +4157,9 @@ The fields of the parameter table are listed below: classtext - Similar parameters are in the same class + Similar parameters are in the same class. Refers to the + parameter_class table. + descriptiontext @@ -4178,6 +4199,124 @@ The table below lists a few examples of parameters + + +parameter_class + +Each parameter is defined to be of a certain class. +The class defines which properties a parameter of that class may have. + + + +The fields + +The fields of the parameter_class table are listed below: + + + + Fieldname Fieldtype Size + Remarks + + + nametext+ Name of the class + + + property_nametext+ Name of the property. Used in property table. + + + descriptiontext+ A verbose description of the property + + + property_typetext+ Either 'STATIC' or 'DYNAMIC' + + + minfloat4 + The default minimum value of the property. + + + maxfloat4 + The default maximum value of the property. + + + notifyboolean1 + If TRUE, create a notification when something about the property or + the parameter changes. + + + +
+ + +The combination of name and property_name must be unique. +Note that the min and max fields are used +only for properties of a numerical nature. + + + + +Sample data + + +The table below lists a few examples of parameter classes + + + + nameproperty_namedescriptionproperty_type + minmaxnotify + + + packageversionThe installed versionSTATIC + true + +
+ + + + + +parameter_notification + +The parameter_notification table defines the relationship between parameters +and notifications. +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. + + + +The fields + +The fields of the parameter_notification table are listed below: + + + + Fieldname Fieldtype Size + Remarks + + + notificationidbigint8 + The notification for the changed parameters. Refers to the notification table. + + + paramidbigserial8 + The parameter for which the notification is made. Refers to the parameter table. + +
+ + +The combination of notificationid and paramid must be unique. + + + + + priority @@ -5044,6 +5183,23 @@ Fields of type_of_issue are: Is this check currently being used in the system. + + automated_checkBoolean1 + Is this an automated check that can be executed by gcm_daemon + + + alter_levelInteger4 + This field indicates what the default priority-level for a notification will be if this issue is raised. + + + last_runTimestamp + The time that the last processing took place. + + + recheck_intervalTimestamp + The interval that is needed before rerunning this check. + +