Pakiti: A Patching Status Monitoring Tool

Pakiti provides a monitoring and notification mechanism to check the patching status of systems.


Pakiti is using a client/server model, in which clients and servers are exchanging information using HTTP(S).

Once installed on a client host, Pakiti will check every night if new patches are available and report them to the relevant Pakiti Server(s).

As a result, while no updated packages are installed on the clients, Pakiti uses a Web page provides a list of the registered systems and the list of the pending patches for them. This helps the system administrator keeping multiples machines up-to-date and prevent unpatched machines to be kept silently on the network.

In addition, a security module in Pakiti is able to distinguish security fixes from normal bug fixes/product improvement for the following Linux distributions:
- Scientific Linux 3.x
- Scientific Linux 4.x
- Ubuntu (The Breezy Badger Release)
- Ubuntu (The Warty Warthog Release)

The security module is expected to support Scientific Linux CERN around February 2006.

Pakiti should work with the following distributions:
- Scientific Linux 3.x using yum or apt-get
- Scientific Linux 4.x using yum or apt-get
- The Breezy Badger Release) using apt-get
- Ubuntu (The Warty Warthog Release)
- Red Hat Entreprise Linux 3 AS/ES/WS using up2date
- Red Hat Entreprise Linux 4 AS/ES/WS using up2date
- Fedora Legacy Linux (Red Hat 7.x, 8, 9) using yum
- Fedora Core 1/2/3/4 using yum

While Pakiti clients are sending data to Pakiti servers, the Pakiti servers can also send each other general statistics or a detailed reports. The list of trusted Pakiti servers is configurable in the server configuration file.


The packages (RPM) and sources are available here.

It is also possible to access the Pakiti CVS server hosted on Sourceforge here.

Pakiti 2.0 "beta" has been released on 03/04/2008: Pakiti 1.0.1 has been released on 26/04/2006: Pakiti 1.0 has been released on 27/01/2006:


Pakiti server view 1 Pakiti server view 2 Pakiti server view 3 Pakiti server view 4 Pakiti server view 5 Pakiti server view 6 Pakiti server view 7 Pakiti server view 8 Pakiti server view 9



The Pakiti Client is a small Perl script, which will check what packages are available to install on the system and report them to the central Pakiti Server.


It simply gather packages provided by your vendor and send the list to the server.


Pakiti can currently use 3 tools to gather information about available packages:
- yum
- up2date
- apt-get

Of course, the tool you choose MUST be first properly configured to be able to install updated packages relevant to your distribution.

For instance, if you decide to go for yum, it MUST point to a relevant yum repository.


The Pakiti client send an HTTP message to the server containing the list of available packages.

It is recommended to use HTTPS to authenticate the remote server and to send information through a secure channel. To use HTTPS, your Pakiti configuration file MUST contains the full path of the certificate of the CA who issued the Pakiti server's certificate. In this way, the Pakiti client will be able to check the Pakiti server's certificate. Of course, to use HTTPS, your Pakiti server MUST be HTTPS enabled.


There is only on configuration file to setup the Pakiti client. It is located here:
It contains the following information:
# Configuration file for Pakiti.

# URL of your local Pakiti server. HTTPS is strongly recommended!
server_url =

# CA Path for HTTPS connection to your local Pakiti server.
# This is mandatory for HTTPS.
ca_certificate = /etc/grid-security/certificates/

# Curl binary, with the options you like
curl_path = /usr/bin/curl -s

# Delay (minutes)
delay = 0

# Package handling tool: 'up2date' or 'yum' or 'apt-get'
method = apt-get

# section: the contact for the system.
# Put something small that can identify your site.
admin = My_Organization Production

# Log file location.
log = /var/log/pakiti/pakiti.log


On a RHEL/SL system, the following steps should be sufficient:

1. Install Apache, PHP, mysql-server, mod_ssl, php-mysql and pakiti-client

# apt-get install httpd php mysql-server php-mysql mod_ssl pakiti-client

If some other dependency are needed, the packages should be available through your vendor.
For more information about installing the client, please see the previous section.

2. Install Pakiti-server

Download the latest RPM and run:
# rpm -i pakiti-server-*.rpm

3. Configure the MySQL server

Configure MySQL to start at boot
# chkconfig --level 235 mysqld on

Start the mysqld service
# /etc/init.d/mysqld start

Change the MySQL root password
# /usr/bin/mysql mysql
~ update mysql.user set Password=PASSWORD('strong_root_password') where User='root' and Host='localhost';
~ flush privileges;
~ quit;

Create the pakiti database
# mysqladmin -u root -p create pakiti

Fill the tables
# /usr/bin/mysql -u root -p pakiti < /usr/share/doc/pakiti-server-*/pakiti.sql

Create a Pakiti user
# /usr/bin/mysql -u root -p mysql
~ GRANT SELECT,INSERT,UPDATE,DELETE ON pakiti.* TO  'mysql_user'@'localhost' IDENTIFIED BY 'mysql_password';
~ flush privileges;
~ quit;
Of course, 'mysql_user'and 'mysql_password' are up to you.

Note: MySQL (>4.0.2) requires mysql_user to have LOCK TABLES privileges:
~ GRANT LOCK TABLES,SELECT,INSERT,UPDATE,DELETE ON pakiti.* TO  'mysql_user'@'localhost' IDENTIFIED BY 'mysql_password';
Details here.

4. Configure Apache

It is *strongly* recommended to use HTTPS and client authentication.
One way of doing this is to create a /etc/httpd/conf.d/pakiti.conf containing:
SSLEngine on

SSLCertificateKeyFile <YOUR_HOST_KEY_PATH>
SSLCACertificatePath /etc/grid-security/certificates

DocumentRoot /var/lib/pakiti/www/
ErrorLog logs/pakiti-error
CustomLog logs/pakiti-access common

Alias /feed "/var/lib/pakiti/feed"

<Directory "/var/lib/pakiti/feed">
Options -All
AllowOverride None
DirectoryIndex index.php

<Directory "/var/lib/pakiti/www/">
SSLVerifyClient      require
SSLVerifyDepth       5
SSLCACertificatePath /etc/grid-security/certificates/
SSLOptions           +FakeBasicAuth
AuthType             Basic
require              valid-user
AuthUserFile         /var/lib/pakiti/users
Options -All
AllowOverride None
DirectoryIndex index.php

Then people can be authenticated by putting their DN in /var/lib/pakiti/users such as:
/C=CH/O=CERN/OU=GRID/CN=Romain Wartel 7120:xxj31ZMTZzkVA
Note that FakeBasicAuth must have ":xxj31ZMTZzkVA" as a suffix of every DN.
The format is the following:
<DN of user 1>:xxj31ZMTZzkVA
<DN of user 2>:xxj31ZMTZzkVA
<DN of user 3>:xxj31ZMTZzkVA
For more details refer to Apache's FakeBasicAuth documentation.

5. Configure the Pakiti Server

The configuration of the Pakiti server can be changed in /etc/pakiti/pakiti-server.conf
# Configuration file for the Pakiti webinterface.

# Set the parameters for connecting to
# the Pakiti database.

hostname = localhost
dbname   = pakiti
username = mysql_user
password = mysql_password

# URL of your local Pakiti server
url =
title = My_Organization

# Reference URL to download the list of security RPMs.
# This setting should normally *not* be changed.
security_rpms =

# This section contains details about statistics and full reports
# that can be exported from this local Pakiti server to central Pakiti servers.

# URLs of trusted *central* Pakiti servers, separated by ';'
# that would receive statistics from this local Pakiti server
#send_stats_to =

# URLs of trusted *central* Pakiti servers, separated by ';'
# that would receive detailed reports from this local Pakiti server
#send_detailed_report_to =

# CA Path for HTTPS reporting to the central servers. This is mandatory for HTTPS
ca_certificate = /etc/grid-security/certificates/

# Curl binary to connect to the central Pakiti servers, with the options you like
curl_path = /usr/bin/curl -s

Known Bugs

RHEL 2.1 is using curl 7.8.1, which does not support SSL. This version of curl has also limited buffers. As a result, if the system tries to report a large number of packages to be installed (>50), the reporting process might be broken.
There are two workarounds:

1. Apply a few patches to reduce the number of outstanding updates. your system should not have a large number of fixes to apply!
2. Update the curl package to curl 7.9.8. The installation might not be nice, you might need to install it with "--no-deps" and you might need to create the following synlink:
ln -s /usr/lib/ /usr/lib/
Note that curl 7.9.8 handles SSL.


Please contact Romain Wartel <> for any information.