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