Patchman
========

Summary
-------

Patchman is a django-based patch status monitoring tool for linux systems, that
provides a web interface for monitoring host package updates.

Patchman clients send a list of installed packages and enabled repositories to
the patchman server. The patchman server updates its package list for each
repository and determines which hosts require updates, whether those updates
are normal or security updates, and shows installed packages that are not part
of any repository. Hosts, packages, repositories and operating systems can all
be filtered (using features or arbitrary tags). For example, it is possible to
find out which hosts have a certain version of a package installed, and which
repository it comes from.

Patchman does not install update packages on hosts, it calculates and keeps
track of what updates are available for each host. The patchman yum and apt
plugins can send reports to the patchman server every time packages are
installed or removed.


Source
------

The current code is available on github:

   https://github.com/furlongm/patchman


Server-side dependencies
------------------------

python-django-tagging
python-django-south
python-django-extensions
django-andsome
python-debian
python-rpm
python-progressbar
python-lxml
python-argparse

The server can optionally make use of celery to asynchronously process the
reports send by hosts. The appropriate python database library is also needed.


Client-side dependencies
------------------------

The client-side dependencies are kept to a minimum. rpm and dpkg are required
to report packages, yum and apt are required to report repositories. These
packages are normally installed by default on most systems.

rpm-based OS's can tell if a reboot is required to install a new kernel by
looking at uname -r and comparing it to the highest installed kernel version.
deb-based OS's do not alway change the kernel version when a kernel update is
installed, so these clients need the 'update-notifier-common' package installed
to enable this functionality.


Usage
-----

The  web interface presents a dashboard with items needing attention, and the
ability to manipulate packages, repositories, operating systems and hosts.

To populate the web interface, run the client on some hosts, this should
provide some initial data to work with. The cli can be used to run cronjobs
and process the reports send from hosts. Run 'patchman-cli -h' for a rundown of
the usage. 

Depending on your setup, there may be some initial work to organise the data
sent from the reports. The following explanations may help in this case.

An OSGroup differs from an OS, in that an OSGroup is a collection of OS's.
For example, a "Debian 6" OSGroup could be comprised of machines with the
following OS's -> "Debian 6.0.1", "Debian 6.0.2", "Debian 6.0.5".
The OS names are obtained from the client hosts, so these may differ
depending on patch-level version, even though they are the same operating
system. Likewise, a "CentOS 5" OSGroup could cover "CentOS 5.4",
"CentOS 5.7", etc. The "CentOS 6" group could cover "CentOS 6.0" through
"CentOS 6.3". Repositories can be linked to an OSGroup, or to a host itself,
and

Repostiories and mirrors are a similar concept. Each repository URL is
counted as a separate mirror, unless the repositories are linked together.
For Red Hat based hosts, this occurs automatically. Currently, for Debian-
based hosts, you need to manually link which mirrors form each repository.