2 <!DOCTYPE doc SYSTEM "/usr/local/xslt/doc.dtd">
3 <?xml-stylesheet type="text/xsl" href="/usr/local/xslt/html.xsl"?>
4 <doc style="gnucomo.css">
7 Gnucomo - Gnu Computer Monitoring Tutorial
8 Original author : Peter Roozemaal
9 Version : $Revision: 1.6 $
11 This document is prepared for XMLDoc. Transform to HTML,
12 LaTeX, Postscript or plain text with XMLDoc utilities and
13 XSLT sheets from http://www.andromeda.nl/projects/xmldoc/
18 <title>Gnucomo - User's Manual</title>
19 <para><picture src='logo.png' eps='logo' scale='0.7'/></para>
20 <author>Peter Roozemaal<code><mathfox@xs4all.nl></code></author>
21 <author>Arjen Baart <code><arjen@andromeda.nl></code></author>
22 <date>October 25, 2007</date>
24 <infoitem label="Version">0.2</infoitem>
25 <infoitem label="Organization">Andromeda Technology & Automation</infoitem>
26 <infoitem label="Organization">De Winter Information Solutions</infoitem>
35 <heading>What is GnuCoMo ?</heading>
38 The aim of the GnuCoMo (GNU COmputer MOnitoring) project is to build a
39 set of applications that will help administrators to monitor networks as
40 a whole for errors, attacks and security-breaches in a very user-friendly
41 way. It is free (GPL) software, sources are available and you are free
42 to modify it to suit your needs.
45 GnuCoMo collects system and application logfiles from the monitored
46 systems (this can be computers, routers and other devices) and stores them
47 in a database. This collected data is further interpreted and analyzed
48 until reports and alerts are generated. Because GnuCoMo can combine data
49 from multiple sources and longer timespans than common IDSs it is able
50 to recognize attacks that previously remained undetected.
53 Remeber, this manual is work in progress.
54 Although it contains some usefull pointers to help you get started
55 with Gnucomo, it is still quite incomplete.
56 You can help us improve this manual and, in fact, Gnucomo itself,
57 by sending your comments and suggestions to the mailinglist:
58 <code>gnucomo@dewinter.com</code>.
62 <heading>About this Document</heading>
65 This document aims to guide you through the installation of GnuCoMo on
66 a Unix (Linux) workstation. When we have completed the installation this
67 document will give a quick guided tour through the functionality GnuCoMo
68 offers. The procedures described here aim at getting the GnuCoMo demo
69 up and running as quickly as possible and may not be suited for your
70 production environment. I assume you have some experience with installing
71 software on your system.
75 This document is part of the Gnucomo package. Gnucomo is released under
76 the Gnu General Public License, see the file COPYING.
82 <heading>Reporting Bugs</heading>
85 If you think you have found a bug in GnuCoMo, this tutorial or the
86 other GnuCoMo documentation, please report it by sending an e-mail to
87 the mailinglist: <code>gnucomo@dewinter.com</code>.
88 Please include in your bug report:
92 <item>the GnuCoMo version you've found the bug in</item>
93 <item>what you did to provoke the error</item>
94 <item>the output (or error message) you got</item>
95 <item>(if relevant) which output you expected</item>
96 <item>processor type and kernel version you use</item>
97 <item>the versions of the packages that gnucomo depends on</item>
104 <heading>Installation</heading>
107 Most of the GnuCoMo installation can be done from an ordinary Unix
108 account; when you need root rights you will be told so explicitly. It is
109 however a good idea to create a gnucomo account.
113 <heading>Getting the software</heading>
116 GnuCoMo can be downloaded from the
117 <reference href='http://www.gnucomo.org/'>GnuCoMo website</reference>.
118 If you read this file you are likely to have a
119 copy of GnuCoMo on your system. If you are serious about using GnuCoMo
120 it would be a good idea to periodicly check the website for updates
124 To be able to install and run GnuCoMo you'll need several other packages:
128 <item tag='PostgreSQL'>
129 PostgreSQL is the database we use for GnuCoMo. Most
130 linux distributions provide ready to install packages for
131 PostgreSQL. We need at least the postgresql, postgresql-server,
132 postgresql-libs and postgresql-devel packages.
133 If you want to compile PostgreSQL from source: go to the
134 <reference href='http://www.postgresql.org/'>PostgreSQL homepage</reference>
135 and download the sources via one of the ftp sites. We need libpq++
137 Though we appreciate the performance improvements that the
138 PostgreSQL 7.3 server provides, we recommend sticking to the
139 PostgreSQL 7.2 client versions for now; at least until we've
140 solved the problems with the libpq++ libraries and PostgreSQL 7.3.
144 The C++ client interface for the PostgreSQL database server
145 is a separate project, not distributed with PostgreSQL.
146 This library replaces the old libpq++ library.
147 The place to find libpqxx is
148 <reference href='http://gborg.postgresql.org/project/libpqxx/projdisplay.php'>
149 the Gborg website</reference>.
150 Make sure you install libpqxx in a default library path or
151 set your LB_LIBRARY_PATH environment variable to include
152 the directory in which libpqxx is installed. The default
153 for libpqxx is /usr/local/libpqxx/lib.
157 PHP is used as programming language for gcm_deamon. If you
158 have packages you would want to install at least the php and
160 You can get PHP sources and documentation from the
161 <reference href='http://www.php.net/'>PHP website</reference>.
162 If you're compiling yourself, don't forget
163 to include PostgreSQL support.
167 We use XML for configuration that we can't (or don't want
168 to) store in the database and for documentation in XMLDOC
169 format. The libxml2 library usually comes with your linux
170 system and you would want to install both the libxml2 and
171 libxml2-devel packages. The libxml2 sources can be downloaded
172 via <reference href='http://xmlsoft.org/downloads.html'>the XMLSoft site</reference>.
176 It's not likely that you'll find precompiled AXE packages on
177 the net, so you'll have to compile from source. Get the AXE
178 sources from the <reference href='http://www.andromeda.nl/projects/AXE/AXE.html'>
179 AXE page</reference>;
180 you'll need version 0.3 or better.
181 Instructions on compiling and installing AXE are given later in
188 The following packages are optional and provide additional functionality
194 Recommended for encryption and signing of data that is transported
195 over the network. Not used at this moment.
199 We use XMLDoc to process our documentation. Download
200 and installation instructions can be found on the
201 <reference href='http://www.andromeda.nl/projects/xmldoc/xmldoc.html'>
202 XMLDoc site</reference>.
206 [HELPME: basic instructions]
209 <item tag='Python + tkinter'>
210 A GUI based configuration tool named MalfisInter (mi) is being
211 worked upon. This tool is programmed in Python and requires XML
220 <heading>Compiling</heading>
223 If you're lucky enough to find precompiled packages for your system and
224 have root permissions to install them, things are easy for you; otherwise
225 you would have to compile from source, which takes a bit more time if
226 you allready have the standard developer tools (C and C++ compilers,
227 make, (f)lex and yacc or bison) installed. You will need those tools
229 You will also need the GNU automake and autoconf packages.
232 Another essential utility is the bzip compressor package; you will need
233 it to unpack the archives. bzip2 and bunzip2 come standard with Linux,
234 but may not be available on older Unix distributions. Sources for bzip2
235 can be found at http://sources.redhat.com/bzip2/.
236 Most of the packages mentioned in this document come with detailed
237 compilation and installation instructions and I recommend to read the
238 README and INSTALL files before compiling and installing them.
242 <heading>Compiling AXE</heading>
245 For compiling AXE you need the X-windows (X11) headers and
246 libraries. Under Linux you might need to install the XFree86-devel
247 package, but these headers are usualy available whenever the C compiler
248 is installed (also on propriatary unixes).
255 <heading>Compiling GnuCoMo</heading>
258 The usual <code>./configure; make install</code> will compile
259 the binary applications and install <code>gcm_input</code> and
260 <code>logrunner</code> into <code>/usr/local/bin</code>.
261 You will need to copy the web interface scripts and gcm_daemon
262 manually to the appropriate directories.
270 <heading>Setting up the database</heading>
272 Gnucomo won't do anything usefull without a PostgreSQL database, so you will have to
274 Make sure you have the PostgreSQL server running and you have a valid userid
275 and password to access the server.
276 You also need to have the permission to create new databases.
277 If not, you will need to log in as the database administration user (usually
278 a user called <emph>postgres</emph>) and create a new user for the database.
282 To create the initial Gnucomo database, you need to use the SQL script
283 <code>create.sql</code>, which is in the <code>src/database</code>
284 directory of the Gnucomo distribution.
285 Type the following commands to create the database:
291 psql gnucomo -f create.sql
296 [TODO] How to set up database security is yet to be described.
301 <heading>The Gnucomo configuration file</heading>
304 <label name='configuration'/>
305 All Gnucomo applications use a single configuration file, named
306 <code>gnucomo.conf</code> by default.
307 There are three places where this configuration file is stored.
308 Gnucomo applications first look for the configuration file in <code>/etc</code>,
309 and if the file is not found there, it should be in
310 <code>/usr/local/etc</code>.
311 Furthermore, you can have an additional configuration file in your home
312 directory, named <code>$HOME/.gnucomo.conf</code>.
313 The configuration file in <code>/etc</code> or in <code>/usr/local/etc</code>
314 holds the system-wide parameters.
315 The configuration file in a user's home directory may hold user-specific
317 The system-wide configuration is mandatory; any user-specific configuration
321 The configuration parameters are organized as a two-level tree, written
323 The first level of the tree constitutes the 'sections', referring to a
324 set of related paramaters.
325 The second level contains the parameters themselves.
326 Each parameter is a single value, i.e. there are no provisions to create
327 structured parameters.
328 Here is an example of what the Gnucomo configuration file may look like:
332 <?xml version='1.0'?>
333 <gnucomo version='0.0.8'>
335 <type>PostgreSQL</type>
336 <name>gnucomo</name>
337 <user>arjen</user>
338 <password>guess-again:-)</password>
341 <method>file</method>
342 <destination>/var/log/gcm_input</destination>
343 <level>0</level>
350 At the root of the tree is an XML element, called <code>gnucomo</code>.
351 The direct children of the root element in the example above are
352 <code>database</code> and <code>logging</code>.
353 These are the 'sections', corresponding to different aspects of the Gnucomo
355 As you may have guessed, the <code>database</code> section holds information
356 we need to access the Gnucomo database on the PostgreSQL server and the
357 <code>logging</code> section specifies how much logging we want the
358 Gnucomo applications to generate and where we want that information to go.
361 Here is a full list of the parameters that are used by Gnucomo, subdivided
362 in their various sections:
367 <strong>database</strong>
369 All parameters that provide Gnucomo applications access to the database.
373 The type of the database server. Currently, only PostgreSQL is supported.
376 The hostname of the system on which the database server runs.
379 The TCP port used by the database server.
382 The name of the database to use for Gnucomo.
385 The user name with which to log in on the database server.
387 <item tag='password'>
388 The password used for logging in to the database server.
394 <strong>logging</strong>
396 The amount of logging generated by Gnucomo applications and where to send it.
400 The method for sending log information.
402 <item tag='destination'>
403 Where the logging information is sent.
406 Choose a higher level for more information.
412 <strong>logfile</strong>
414 Primarily used by <emph>logrunner</emph>.
415 A list of files that are scanned for system logging that in sent to the Gnucomo server.
416 There can be more than one <strong>logfile</strong> element in a Gnucomo configuration file.
420 Name of the file to scan for logging, e.g. <code>/var/log/messages</code>.
423 The type of the logging information.
424 Types supported by Gnucomo are <code>system log</code>,
425 <code>apache access log</code> and <code>apache error log</code>.
427 <item tag='fromhost'>
428 Hostname (not a FQDN) of the system for which the log entries are sent.
429 Only log entries that originate from this host are sent to the Gnucomo server.
430 This option applies to system log files that may have log entries for several hosts,
431 in case the system acts as a syslog server.
434 A regular expression to filter out log entries before sending to the Gnucomo server.
435 There may be several <strong>filter</strong> elements in a single
436 <strong>logfile</strong> element.
445 <heading>Getting the web interface up and running</heading>
447 Your primary view onto Gnucomo is through the web interface.
448 Gnucomo uses a web server, e.g. Apache, with PHP scripts to implement
450 At the present, the web interface is the only way to manage the
451 information in the Gnucomo database and view the results that
455 To be able to use the web interface, you need to copy the PHP
456 scripts from the <code>src/web</code> and <code>src/phpclasses</code>
457 directories into a directory accessible through the web server.
458 On most Red Hat Linux systems, this is usually in
459 <code>/var/www/html</code>.
460 One way to accomplish this is to create a subdirectory <code>gnucomo</code> under
461 the Document Root of the webserver.
462 The main gnucomo scripts go into this directory and the PHP class library can be copied
463 either in a subdirectory <code>classes</code> or <code>../phpclasses</code>.
464 Here's an example installation:
467 [gnucomo] # mkdir $DocumentRoot/gnucomo
468 [gnucomo] # cp src/web/* $DocumentRoot/gnucomo
469 [gnucomo] # cp -r src/phpclasses $DocumentRoot
475 <heading>And now...</heading>
477 If you like GnuCoMo [TODO]
478 Report success under Non-Linux [TODO]
484 <heading>Using Gnucomo</heading>
487 Once you have the database and the web interface set up, Gnucomo is almost
489 To put Gnucomo to work, you need to enter at least one object into the database
490 and create your methods to feed information to gnucomo.
494 <heading>The initial entries</heading>
497 Gnucomo maintains information about monitored systems such as servers,
498 work stations, switches and that sort of thing.
499 In Gnucomo, these are called <emph>objects</emph>.
500 The <emph>objects</emph> are distinguished by their name, usually
501 a hostname in your network. Or, better still, a fully qualified name
503 You can use the web interface to create an <emph>object</emph> by logging
504 in and selecting the picture that looks like a computer cabinet
505 in the button bar at the top.
506 Enter the object's name, for example <code>server.gnucomo.org</code>,
507 and click the <strong>Create</strong> button.
513 <heading>Feeding log files</heading>
516 Once an object is known by Gnucomo, i.e. the object's name is stored in the
517 database, you can start to fill the database with log entries.
518 Log entries are stored by a variety of programs into one or more log
519 files on the object's harddisk.
520 For example, system messages on most Linux distributions are put
521 in a file called <code>/var/log/messages</code>.
522 There are several ways to transfer the contents of a log file into the
523 Gnucomo database, each of which involves <code>gcm_input</code>.
524 <code>Gcm_input</code> is the Gnucomo application that reads various kinds
525 of raw input and tries to scan for as much information as possible.
526 The usefull information that is extracted from the input is stored
527 into the Gnucomo database.
531 The most direct way to invoke <code>gcm_input</code> maually and read
532 the log file through its standard input:
535 gcm_input -h server.gnucomo.org </var/log/messages
538 You'll have to explicitly specify the hostname of the object because
539 there is no way for <code>gcm_input</code> to know where the log
541 Take care not to feed the same log file another time through
542 <code>gcm_input</code>.
543 This will lead to duplicate log entries in the Gnucomo database.
546 Feeding information into the Gnucomo database can also be done through
547 a mail server, such as sendmail or postfix.
548 Create a mail alias that invokes <code>gcm_input</code> as a mailer program.
552 gnucomo: "|gcm_input"
555 With such an email alias, Gnucomo clients can simply send log files and
556 other reports to this email address:
559 mail gnucomo@server.gnucomo.org </var/log/messages
562 The third method to feed log files into the Gnucomo database is by
563 using <code>logrunner</code>.
564 Where the previous methods can only feed complete logfiles as a whole,
565 logrunner can feed partial logiles to the Gnucomo server.
566 Logrunner keeps track of the growth of a logfile and converts the newly
567 added log entries into an XML message suitable for gcm_input.
568 A practical way to deploy logrunner is:
571 /usr/local/bin/logrunner -1 | mail gnucomo@gnucomo.server
574 Note the '-1' option for logrunner. This option is needed to keep
575 logrunner from generating multiple XML documents in one output stream.
576 Which logfiles are scanned by logrunner is specified in the Gnucomo
577 <ref to='configuration'>configuration file</ref>.
582 <heading>Viewing results</heading>
584 Use the web interface to review log entries, notifications and parameters.
585 The <emph>Objects</emph> page shows statistics about the data that is collected
586 for each monitored object.
587 Clicking on the links in the statistics will display the specific data for that object.
588 The icon of each object takes you to a form for editing information about that object,
589 such as an identification code, physical location and services used by that object.
593 After feeding the log entries of monitored objects to the Gnucomo server,
594 these log entries can be analyzed by the Gnucomo analyzer daemon, <code>gcm_daemon</code>.
595 The present version of Gnucomo does not yet support the operation of a real
596 daemon, so you will have to start <code>gcm_daemon</code> explicitly.
597 This performs a number of analyses on the log entries and updates the statistics
599 When the <code>gcm_daemon</code> finds something out of the ordinary, it will
600 create a <emph>Notification</emph>.
601 Notifications are created to alert you to the fact that something may be wrong
605 The checks made by Gnucomo are related to services that run on a monitored object.
606 A few checks are predefined in Gnucomo.
607 You can add more checks to tailor your situation through the <emph>Services</emph> page.
608 Click on the icon of a specific service to edit the list of checks that are
609 performed for log entries generated by that service.
610 Each check consists of a <emph>pattern</emph> in the form of a regular expression
612 For example, the following pattern matches a log entry from postfix which states that
613 outgoing mail is delivered:
616 to=.+, relay=.+, delay=[0-9]{1,2}, status=sent \(250 .+\)
619 The action is performed when the regular expression matches with a log entry.
620 Each check is tagged with a rank number for defining the order in which the
622 The first pattern that matches is used to perform the action.
623 The very last check is a 'catch all' pattern, predefined in the Gnucomo database.
624 When a pattern matches, one of four actions is executed:
628 Simply ignore this log entry.
631 Create a notification.
632 The <emph>Issue</emph> for the notification is stated in the <emph>Argument</emph> field.
635 Add one to the number of abuses detected for the IP address or hostname that is mentioned in
637 The argument for this action is almost always "$1", which is the first part of the pattern
639 Note that this requires a special form of regular expression in the pattern which will select
640 certain parts as a sub expression.
643 Remove one abuse for the IP address of hostname in the argument.
647 A notification is always created with a specific <emph>Issue</emph> which states
648 what Gnucomo thinks is going wrong.
649 A number of issues are predefined in the Gnucomo database.
650 You can create your own issues and have Gnucomo generate notifications with these
651 issues on the Issues page.
656 <heading>Abuse and intrusion detection</heading>
658 Gnucomo maintains a list of IP addresses that have committed some kind of abuse.
659 This can be attempts to send spam, attempts to intrude a system from the internet
660 or any other kind of malicious action.
661 These abuses are detected by creating the proper patterns in checks for log entries
662 as discussed in the previous section.
663 Each time an abuse is detected in the log, one abuse is added to the record for
664 that <emph>Object</emph> and IP address.
665 A reference to the log entry in which the abuse was detected is also maintained.
666 When the number of abuses for a certain IP address exceeds the limit (32 in this
667 version of Gnucomo), the status for the IP address is set to 'dropped'.
668 You can review the list of abusing IP addresses by clicking on the 'Abuse list'
669 in the <emph>Objects</emph> page.
672 The most useful application of the abuse list is to maintain a firewall
673 and block all IP addresses that have the 'dropped' status.
674 To do this automatically, you need to provide access to the database from
675 a script that is probably run by root.
676 A special user 'firewall' that can only read the abuse list can be created
677 with the following SQL commands:
680 CREATE USER firewall WITH PASSWORD 'secret';
681 GRANT SELECT ON object_abuse TO firewall;
684 When the Gnucomo database runs on a different system than the one
685 on which the firewall is maintained, the database server needs to
686 provide access from external systems. This implies setting up the
687 PostgreSQL configuration and firewall rules.
688 The following script then augments the firewall with the information
689 from the Gnucomo abuse list:
694 # Create a firewall script from the gnucomo abuses table
697 psql "sslmode=require host=server.gnucomno.org dbname=gnucomo user=firewall password=secret"
698 -c "select source from object_abuse
699 where status='dropped' and objectid=$1"|grep -v '^$'>/tmp/gnucomo-abuses
703 echo iptables -I INPUT -s $ADDRESS -j DROP
704 done < /tmp/gnucomo-abuses
712 <heading>Managing system parameters</heading>
715 Besides log entries which represent the transient events that occur in
716 an object, Gnucomo also maintains the state of the object.
717 The state of an object is defined by the set of parameters and
719 Examples of parameters are the file systems, users, processes, installed
721 By managing those parameters with Gnucomo, you can hold a firm grip on
722 the state of your systems.
723 Especially on large sites with many workstations, servers, switches
724 and other objects, managing the state of all those systems is not
726 The following sections explain how Gnucomo can help.
730 <heading>System resources</heading>
732 By monitoring the resources of a system, such as memory, cpu, file systems and
733 network interfaces, you can keep track on the system's performance and capacity.
734 The utilization of these resources varies frequently over time.
735 Viewing the values of resource properties provides an excelent insight in
736 the system's behaviour.
737 Gnucomo can maintain a record of the system resources by using DYNAMIC properties
739 You can define classes of parameters with properties that will reflect the state
740 of your systems and feed the numbers into the Gnucomo database by using scripts
741 that extract the information from a system and convert this into XML format.
744 As an example, consider the processing load of a system.
745 Two metrics can be of interest to keep an eye on the system load:
746 The total number of processes and the number of runnable processes.
747 These numbers are easily obtained with standard UNIX commands <code>ps</code>
748 and <code>uptime</code>.
749 To maintain this in Gnucomo, a <emph>class</emph> is needed to define the
750 properties we want to maintain.
751 For this example, we create a class <strong>systemload</strong> with the properties
752 <strong>processes</strong> and <strong>runqueue</strong>.
753 Note that both these properties are DYNAMIC.
754 The properties for the <strong>systemload</strong> class can be defined by using
755 Gnucomo's web interface or typing SQL statements directly into the database:
758 INSERT INTO parameter_class (name, property_name, description, property_type, min, max, notify)
759 VALUES ('systemload', 'processes', 'Total number of processes', 'DYNAMIC', 0, 1000, 'f');
760 INSERT INTO parameter_class (name, property_name, description, property_type, min, max, notify)
761 VALUES ('systemload', 'runqueue', '5 minute average length of the run queue', 'DYNAMIC', 0, 5.00, 'f');
764 When the class is defined in the Gnucomo database, we are ready to feed the
765 information into Gnucomo through <code>gcm_input</code>.
766 The following shell script will create the appropriate XML document with the
772 # Gnucomo system load report.
774 # Create a parameter report with two values:
775 # The total number of processes and the 5-min load average.
782 echo "<?xml version='1.0'?>"
783 echo "<gcmt:message xmlns:gcmt='http://gnucomo.org/transport/'>"
784 echo " <gcmt:header>"
785 echo " <gcmt:messagetype>XML</gcmt:messagetype>"
786 echo " <gcmt:hostname>$HOST</gcmt:hostname>"
787 echo " <gcmt:time>$TIME</gcmt:time>"
788 echo " </gcmt:header>"
789 echo " <gcmt:data>"
791 echo " <gcmt:parameters gcmt:class='systemload'>"
793 PROCESSES=`ps ax|wc -l|awk ' {print $1}'`
794 LOADAV=` uptime|awk ' { print $11 }' | tr -d ,`
796 echo "<gcmt:parameter name='Load'>"
797 echo " <gcmt:description>System processing load</gcmt:description>"
798 echo " <gcmt:property name='processes'>$PROCESSES</gcmt:property>"
799 echo " <gcmt:property name='runqueue'>$LOADAV</gcmt:property>"
800 echo "</gcmt:parameter>"
802 echo " </gcmt:parameters>"
803 echo " </gcmt:data>"
804 echo "</gcmt:message>"
807 Filesystems are predefined in Gnucomo.
808 Gcm_input understands the output of most <code>df</code> implementations directly.
809 The following examples show how to feed filesystem information into Gnucomo:
812 df -lPk -x tmpfs | gcm_input -h `hostname`
813 df -lPi -x tmpfs | gcm_input -h `hostname`
816 Make sure to add the <code>-k</code> option so <code>df</code> reports
817 the filesystem sizes in kilobytes.
822 <heading>Installed packages</heading>
825 Gnucomo can maintain a list of all packages installed on an object.
826 This list is stored in the database as parameters of class
827 <emph>package</emph>.
828 Each <emph>package</emph> parameter has one property: the version number
830 Gnucomo keeps an historical record of the version number for each package,
831 so you will know when the version of a package changes.
832 Furthermore, you can compare the installed packages of two objects, so
833 you can easily find the differences between two installations.
837 To maintain the installed packages of an object, all you need is to
838 feed a complete list into the Gnucomo database through <emph>gcm_input</emph>.
839 The package list is a text file with a package on each line of the form
840 <code>packagename-version</code>.
841 Not the dash ('-') between the name and the version.
842 On many Linux systems that use the RedHat Package Manager (RPM), such
843 a list is easily obtained and fed into <emph>gcm_input</emph>:
847 rpm -qa | gcm_input -h example.gnucomo.org
851 You will have to repeat this procedure at regular intervals.
852 Each time you feed a new package list to Gnucomo, Gnucomo will
853 compare the new list with the package parameters in the database
854 and notify you of any changes.
857 For keeping your systems up-to-date, it is often convenient to maintain
858 a repository of the most recent packages.
859 Gnucomo can help you with this task.
860 To enter the list of packages and updates from a distribution into the
861 Gnucomo database, you can create a virtual <emph>object</emph> and
862 create the <emph>package</emph> parameters for this object.
863 For example, to maintain a list of RPMs for RedHat Linux 7.3, create an
864 object (using the web interface) with the name <code>redhat-7.3</code>.
865 Using this object, enter the first batch of package parameters from a directory
866 listing of the CD-ROM.
867 However, you can not use the output from <strong>ls</strong> directly as
868 input for <strong>gcm_input</strong>.
869 You need to strip off two siffixes off the filenames to make it look like
870 a <code>rpm -qa</code> output.
871 Futhermore, a repository of updates often contains multiple versions of a package
873 You want to make sure that the latest version of each package is recorded in the
875 The (python) script <code>report_repository.py</code> will perfom these tasks:
879 python report_repository.py /mnt/cdrom/RedHat/RPMS | gcm_input -h redhat-7.3
883 You can repeat this command to enter additional packages into the database.
884 For example, to add packages from other CD-ROMs or from a directory where
885 you keep downloaded updates.
886 Remember, however, to use the <strong>-i</strong> option for "incremental"
888 Without this option, gcm_input will regard the list of packages as a <emph>full</emph>
889 list and remove any parameters that are not present in the new list.
892 With a list of available packages for a specific distribution in the Gnucomo
893 database, along with the list of packages installed on your systems, you
894 can easily obtain an overview of which packages you need to update.
895 To make this overview, use the web interface to compare the packages
896 on an object with the packages on the virtual object.