Pakiti

0 Comments
Samuel MARTIN MORO

Pakiti is a patching status monitoring tool developed within the CERN, more recently took over by CESNET and an other CERN (Czech Educational and Research Network).

It is quite handy dealing with RHEL and debian-flavored operating systems.
Having tried to add FreeBSD/OpenBSD support, I can tell it is doable, although I haven’t succeeded yet.

pakiti dashboard

pakiti dashboard

Common pakiti setups involve a main server and several clients.
The main server usually has its own MySQL database. Periodically, it would retrieve update digests from configured repositories.
The client side consists on a small script, which main purpose is to list all packages locally installed and corresponding. Finishing its processing, the client connects to its master, send its report and eventually prints a list of outdated packages.

Obviously, the main advantage of this, over the direct alternatives (such as apt and apt_all plugins from munin) is that you don’t have to periodically retrieve latest packages headers from your repositories. The pakiti master does it once, sparing you what could become IO storms (assuming you have a physical host running around 20 VMs, having the apt_all plugins activated on all of them: statistically, you are running apt-get update once per minute).

The dark side of Pakiti, is the lack of official packages, updates, … The fact you need to patch, to have it work with latest PHP versions, …
Don’t expect running Pakiti right after unpacking their archive. Beware of their incomplete documentation. You might prefer to have a look at my puppet module, which prepares almost everything.

 

(2015/06/08) edit: discussing with Lafouine41 a few weeks ago, I misunderstood pakiti3 was ready to be released. After further investigations, I noticed the client wasn’t even Debian capable.
On a late night, I contributed the following patches: