Pakiti: A Patching Status Monitoring Tool

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


NEW Pakiti v3 will be available soon, see further information here.

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

Once installed on a client host, Pakiti will send every night the list of installed packages to the relevant Pakiti Server(s). After the client sends the list of installed packages, Pakiti server compares the versions against versions which Pakiti server obtains from packages repositories (ordinary packages repositories maintained by Linux distribution provider) and OVAL definitions from MITRE. Optionally client reports back the packages which should be upgraded, security updates are specially marked.

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 all Linux distributions which has packages repositories based on rpm (yum) or dpkg (apt) and has different location for normal and security updates.

For Linux distributions based on the RedHat, Pakiti is able to check packages against CVEs ( In the next release Linux distros based on SuSE will be also checked. Debian based distros are also a candidate, but Debian currently does not provide approved data in CVE format.

Information about older versions:


The packages (RPM) and sources are available here.

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

Pakiti 2.1.5 has been released on 12/02/2013:

Pakiti 2.1.4 has been released on 16/09/2010: Pakiti 2.1.3 has been released on 04/06/2010: Pakiti 2.1.2 has been released on 22/03/2010: Pakiti 2.1.1 has been released on 19/03/2010: Pakiti 2.1 has been released on 01/06/2010: 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:


server view 1 Pakiti
server view 2 Pakiti
server view 3 Pakiti
server view 4



The Pakiti Client is a small bash script, which will gather list of actually installed packages and report them to the central Pakiti Server.

What does it do?

It simply gather packages installed on the host using rpm -qa or dpkg-query respectively.

How available packages are gathered?

Pakiti currently uses two methods how to find out if the package is not up-to-date:

Pakiti server once a day downloads information from the vendors repositories and stores them. Location of the repositories can be found on the clients machines, for example on Debian systems in /etc/apt/sources.list, on RedHat systems in /etc/yum.repos.d/. When the client machine reports the list of installed packages Pakiti server checks whether the version is older then that one in the repository.

Second method is actually applicable only on systems based on RedHat. Once a day Pakiti server downloads OVAL definitions for the RedHat systems. Packages' versions from Linux systems based on RedHat are also check against these information.

Of course, the tool you choose MUST be first properly configured.

How are they reported to the server?

The Pakiti client send an HTTP message to the server containing the list of installed 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 or directory where is 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.

Where can I configure pakiti client?

There are two ways how to install the Pakiti client. After installing the pakiti-client-manual-*.rpm package all files are extracted into /usr/share/doc/pakiti-client-2/ and you have to do manual installation described in the README file. The second option with the package pakiti-client-*.rpm do complete installation. Pakiti client script is installed into /usr/sbin/pakiti2-client, the configuration file is located in /etc/pakiti2/pakiti2-client.conf and the cron script is installed into /etc/cron.daily/pakiti2-client-update.

There are two ways how to configure Pakiti client. You can directly edit Pakiti client script pakiti2-client and set default values there, of course you have to comment the variable CONF. Or you can use configuration file pakiti2-client.conf and copy it to the /etc/pakiti/ or specify -c command line option.

It contains the following information:
# Configuration file for Pakiti.

# Pakiti servers, use space as delimiter
# Exmaple: servers_name =
servers_name =

# URL of Pakiti script on the server, default /feed/
#server_url = /feed/

# CA Path, where is located certificate of the CA which issued SSL certificate for the Pakiti server, default /etc/ssl/certs
#ca_certificate = /etc/ssl/certs

# The client certificate and the key for the host authentication
#host_cert = /etc/ssl/host.pem

# Connection method: 'autodetect' (default) or 'curl' or 'openssl' or 'stdout'
#connection_method = curl

# OpenSSL binary, with the options you like, by default openssl is located by
# command which
#openssl_path = /usr/bin/openssl

# Curl binary, with the options you like, by default curl is located by
# command which
#curl_path = /usr/bin/curl

# Put something small that can identify your site/host/team, without spaces.
tag = TEST

# Does the client should report back the list of packages needs upgrade?
# (default 0 - off)
# report = 0

# If the pakiti client works as a proxy. It can send results to the server on
# behalf of other pakiti client. Pakiti client can produce results to the
# stdout, these results can be passed to the proxy pakiti client over the stdin.
# The host, which runs proxy pakiti client has to be listed in the Pakiti
# server configuration file in section: trusted_proxy_clients 
# (default 0 - off)
# is_proxy = 0

# If the host has more then one interface, it can be setup which is used for outgoing communication, 
# for example: eth0 or IP address
# Warning: This option works only with curl connection method
# (default "")
# interface =

# Prints statistics to the stdout about number of successful reports to the Pakiti servers
# (default 0 - off)
# server_rep_stats = 0

Pakiti client should be run at least once a day. There is prepared cron script in /usr/share/doc/pakiti-client-2/pakiti2-client.update.cron.daily:

# Wait for random time (0-240s), so we do not overload the server
RANDOM_NUMBER=`od -An -N2 -d /dev/random`
WAIT_TIME=`echo $(( 1+( $RANDOM_NUMBER )%(240-1) ))`
sleep $WAIT_TIME

# Run the client
path to the pakiti2-client

exit 0

How can I configure a pakiti server?

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

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

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 pakiti2

Fill the tables

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

You can use default configuration

# /usr/bin/mysql -u root -p pakiti2 < /usr/share/doc/pakiti-server-*/pakiti2_initial_configuration.sql

Create a Pakiti user

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

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/www/pakiti2/www/
ErrorLog logs/pakiti-error
CustomLog logs/pakiti-access common

Alias /feed "/var/www/pakiti2/www/feed"

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

Alias /link "/var/www/pakiti2/www/link"
<Directory "/var/www/pakiti2/www/link">
  Options +FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
  DirectoryIndex index.php

<Directory "/var/www/pakiti2/www/pakiti">
  # Restrict access to this directory by your own auth mech, authorization can be made by the Pakiti itself
  Options +FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
  DirectoryIndex index.php


5. Configure the Pakiti Server

The top level configuration of the Pakiti server can be changed in /etc/pakiti2/pakiti2-server.conf

# Configuration file for the Pakiti webinterface.

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

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

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

6. Setting up the Pakiti Server

Now, try to access web GUI of your Pakiti server. It everything is OK, you should see main page, where there are no hosts listed. Click the "Settings" link in the right-top corner.

Settings are devided into three sections:

RedHat OVAL Definitions

Provide URLs to the OVAL definitions. Then you can select which one will be checked once a day for the updates. It is useful to add all OVAL definitions, then manually run /var/www/pakiti2/scripts/process_oval_rh.php, this will fill Pakiti database with information from all OVAL definitions. Afterwards, for OVAL definitions which were actual in the past, you can uncheck "Check this source for updates", because old definitions are not updated any more, this will save Pakiti server resources.

Pakiti server view 5

Os Group Definitions

This section can be configured after all of your host (or the majority of them) report to the Pakiti server. Each host will report its OS name to the Pakiti server and in this section you can define OS groups. OS groups are used for repository definitions. Some package repositories are used by several versions of one OS, for example Debian 5.0, 5.0.1, 5.0.2 and 5.0.3 uses one repository. After Os groups are set up, we can define repositories.

Pakiti server view 6

Repositories Definitions

On the bottom of the page, there is a from with fields:

Pakiti server view 8

Above the form you can see the list of Oses which does not have assigned any repository. You should create corresponding Os groups and add to them these Oses, then you can add repositories for that Os groups.

Pakiti server view 7

Legend of the icons used on the Settings page:

CVE Tags

Some important CVEs can be tagged and then view in the CVE Tags report page. Usually we don't care of all CVEs, some has no impact on the infrastructure, but others describes really dangerous security issue, so we can tag that CVE and monitor occurence of that CVE on the machines on single report page. Is some administrator manually fix the issue and little bit change the version of the package, Pakiti is unable to detect, that the software is fixed. Therefore we can create an exception for the particular package version, that won't be shown in the reports.



Pakiti supports authorization. Edit config/config.php and set $enable_authz = 1;. Now you have to provide list of administrators in config/config.php:

# DNs of logins of the users, who can setup authz
# Example for SSL AuthN: $admin_dns = array ( "/DC=cz/DC=cesnet-ca/O=Masaryk University/CN=xxx1", "/DC=cz/DC=cesnet-ca/O=Masaryk University/CN=xxx2" );
# Example for Basic AuthN" $admin_dns = array ( "user1", "user2" );
$admin_dns = array ( );
Afterwards you can also specify other users, who will have access to certain domain. On the web GUI you can see ACL link in the right-bottom menu.

Asynchronous mode

If $asynchronous_mode = 1; is set in the config/config.php Pakiti won't check the vulnerabilities when the host reporting, but only after manual run of the scripts/recalculate_vulnerabilities.php.

HTTP proxy

If your Pakiti server is behind the HTTP proxy, you can specify the proxy in config/config.php:

# Repository_updates and process_oval_rh access remote sites, you can setup proxy here
# $web_proxy = "tcp://";

Proxy clients

Pakiti client can also work as a proxy for other Pakiti clients. Set is_proxy = 1 in pakiti2-client.conf and add the hostname of the Pakiti proxy client in config/config.php:

# Array of the trusted proxy clients, that can send results on behalf of other pakiti clients
# Example $trusted_proxy_clients = array ( "", "" );
$trusted_proxy_clients = array ( );

TLD filtering

On every page you can add "tld=(list of TLDs separated by comma)" to the URL and the hostnames in the results will be filtered by provided TLDs.

For example:,de,uk

Only hosts from cz, de and uk will be listed.

Outdated/Missing packages

This page is intended to help site admins to find at a glance outdated or missing locations for a specific package throughout their cluster. The list of found and available packages versions is listed at the beginning with

Next, the list of nodes with an outdated packages is displayed. The matching is done using the OS group id and the assigned repo. The current installed version is also displayed for verification purposes.

Last, the list of nodes where the considered package is not installed are displayed.

In order to enable this page, set the variable $ext_pages_outdated = 1.

The Outdated/Missing packages page was made by Catalin Dumitrescu from Fermilab.

Known Bugs



Please contact Michal Prochazka <> for any information.