<!--
Gnucomo - Gnu Computer Monitoring Tutorial
Original author : Peter Roozemaal
- Version : $Revision: 1.3 $
+ Version : $Revision: 1.6 $
This document is prepared for XMLDoc. Transform to HTML,
LaTeX, Postscript or plain text with XMLDoc utilities and
</verbatim>
<para>
-With the default installation of PostgreSQL on RedHat 8.0,
-you will probably encounter an authentication problem when you try to
-use the Gnucomo web interface. The problem will look somewhat like this:
-</para>
-
-<para>
-<strong>
-Warning: pg_connect() unable to connect to PostgreSQL server:
-FATAL 1: IDENT authentication failed for user "arjen"
-</strong>
-</para>
-
-<para>
-Refer to PostgreSQL Administrator's guide, Chapter 4: Client Authentication.
-You probably have this line in the /var/lib/pgsql/data/pg_hba.conf:
-</para>
-
-<verbatim>
- local all ident sameuser
-</verbatim>
-
-<para>
-(I know RedHat 8.0 does this). You need to change this into:
-</para>
-
-<verbatim>
- local all password
-</verbatim>
-
-<para>
-This tells PostgreSQL to allow any UNIX user to log into the database
-as any database user on a local socket, using his database password.
+[TODO] How to set up database security is yet to be described.
</para>
</section>
<para>
The most useful application of the abuse list is to maintain a firewall
and block all IP addresses that have the 'dropped' status.
-A short shell script will do this job:
+To do this automatically, you need to provide access to the database from
+a script that is probably run by root.
+A special user 'firewall' that can only read the abuse list can be created
+with the following SQL commands:
+</para>
+<verbatim>
+CREATE USER firewall WITH PASSWORD 'secret';
+GRANT SELECT ON object_abuse TO firewall;
+</verbatim>
+<para>
+When the Gnucomo database runs on a different system than the one
+on which the firewall is maintained, the database server needs to
+provide access from external systems. This implies setting up the
+PostgreSQL configuration and firewall rules.
+The following script then augments the firewall with the information
+from the Gnucomo abuse list:
</para>
<verbatim>
#!/bin/sh
# Create a firewall script from the gnucomo abuses table
#
-psql -h samos -t gnucomo arjen -c "select source from object_abuse
+psql "sslmode=require host=server.gnucomno.org dbname=gnucomo user=firewall password=secret"
+ -c "select source from object_abuse
where status='dropped' and objectid=$1"|grep -v '^$'>/tmp/gnucomo-abuses
while read ADDRESS
</para>
<section>
+<heading>System resources</heading>
+<para>
+By monitoring the resources of a system, such as memory, cpu, file systems and
+network interfaces, you can keep track on the system's performance and capacity.
+The utilization of these resources varies frequently over time.
+Viewing the values of resource properties provides an excelent insight in
+the system's behaviour.
+Gnucomo can maintain a record of the system resources by using DYNAMIC properties
+in parameters.
+You can define classes of parameters with properties that will reflect the state
+of your systems and feed the numbers into the Gnucomo database by using scripts
+that extract the information from a system and convert this into XML format.
+</para>
+<para>
+As an example, consider the processing load of a system.
+Two metrics can be of interest to keep an eye on the system load:
+The total number of processes and the number of runnable processes.
+These numbers are easily obtained with standard UNIX commands <code>ps</code>
+and <code>uptime</code>.
+To maintain this in Gnucomo, a <emph>class</emph> is needed to define the
+properties we want to maintain.
+For this example, we create a class <strong>systemload</strong> with the properties
+<strong>processes</strong> and <strong>runqueue</strong>.
+Note that both these properties are DYNAMIC.
+The properties for the <strong>systemload</strong> class can be defined by using
+Gnucomo's web interface or typing SQL statements directly into the database:
+</para>
+<verbatim>
+INSERT INTO parameter_class (name, property_name, description, property_type, min, max, notify)
+ VALUES ('systemload', 'processes', 'Total number of processes', 'DYNAMIC', 0, 1000, 'f');
+INSERT INTO parameter_class (name, property_name, description, property_type, min, max, notify)
+ VALUES ('systemload', 'runqueue', '5 minute average length of the run queue', 'DYNAMIC', 0, 5.00, 'f');
+</verbatim>
+<para>
+When the class is defined in the Gnucomo database, we are ready to feed the
+information into Gnucomo through <code>gcm_input</code>.
+The following shell script will create the appropriate XML document with the
+parameter values:
+</para>
+<verbatim>
+#!/bin/sh
+#
+# Gnucomo system load report.
+#
+# Create a parameter report with two values:
+# The total number of processes and the 5-min load average.
+#
+
+
+HOST=`hostname`
+TIME=`date`
+
+echo "<?xml version='1.0'?>"
+echo "<gcmt:message xmlns:gcmt='http://gnucomo.org/transport/'>"
+echo " <gcmt:header>"
+echo " <gcmt:messagetype>XML</gcmt:messagetype>"
+echo " <gcmt:hostname>$HOST</gcmt:hostname>"
+echo " <gcmt:time>$TIME</gcmt:time>"
+echo " </gcmt:header>"
+echo " <gcmt:data>"
+
+echo " <gcmt:parameters gcmt:class='systemload'>"
+
+PROCESSES=`ps ax|wc -l|awk ' {print $1}'`
+LOADAV=` uptime|awk ' { print $11 }' | tr -d ,`
+
+echo "<gcmt:parameter name='Load'>"
+echo " <gcmt:description>System processing load</gcmt:description>"
+echo " <gcmt:property name='processes'>$PROCESSES</gcmt:property>"
+echo " <gcmt:property name='runqueue'>$LOADAV</gcmt:property>"
+echo "</gcmt:parameter>"
+
+echo " </gcmt:parameters>"
+echo " </gcmt:data>"
+echo "</gcmt:message>"
+</verbatim>
+<para>
+Filesystems are predefined in Gnucomo.
+Gcm_input understands the output of most <code>df</code> implementations directly.
+The following examples show how to feed filesystem information into Gnucomo:
+</para>
+<example>
+df -lPk -x tmpfs | gcm_input -h `hostname`
+df -lPi -x tmpfs | gcm_input -h `hostname`
+</example>
+<para>
+Make sure to add the <code>-k</code> option so <code>df</code> reports
+the filesystem sizes in kilobytes.
+</para>
+</section>
+
+<section>
<heading>Installed packages</heading>
<para>
input for <strong>gcm_input</strong>.
You need to strip off two siffixes off the filenames to make it look like
a <code>rpm -qa</code> output.
-The following script will do just that:
-</para>
-
-<verbatim>
-
-#!/bin/sh
-#
-# Turn an 'ls' listing of RPM files into an 'rpm -qa' listing
-# Reads a list of filenames, possibly preceeded by a directory and
-# strips the directory path from the beginning and the two suffices
-# from the end of each filename. For example, the name
-# "/mnt/cdrom/RedHat/RPMS/kernel-2.4.20-13.7.i686.rpm" gets turned
-# into a simple "kernel-2.4.20-13.7".
-
-while read filename
-do
- case $filename in
- *.src.rpm)
- ;;
-
- *)
- filename=`basename $filename .rpm`
- case $filename in
- *.athlon)
- rpm=`basename $filename .athlon`
- ;;
- *.i386)
- rpm=`basename $filename .i386`
- ;;
- *.i486)
- rpm=`basename $filename .i486`
- ;;
- *.i586)
- rpm=`basename $filename .i586`
- ;;
- *.i686)
- rpm=`basename $filename .i686`
- ;;
- *.noarch)
- rpm=`basename $filename .noarch`
- ;;
- esac
- echo $rpm
- ;;
- esac
-done
-
-</verbatim>
-
-<para>
-Suppose this script is stored as <code>ls-rpm</code>, you can apply it
-like this:
+Futhermore, a repository of updates often contains multiple versions of a package
+file.
+You want to make sure that the latest version of each package is recorded in the
+Gnucomo database.
+The (python) script <code>report_repository.py</code> will perfom these tasks:
</para>
<verbatim>
- ls /mnt/cdrom/RedHat/RPMS | ls-rpm | sort | uniq | gcm_input -h redhat-7.3
+ python report_repository.py /mnt/cdrom/RedHat/RPMS | gcm_input -h redhat-7.3
</verbatim>
<para>
projects / gnucomo.git / blobdiff