patchman is a django-based linux patch status monitoring system.
Handle no OS in /etc/lsb_release
|etc||django 1.4 / STATIC_URL fixes|
|patchman||add auth_required for novell update servers|
|templates||minor template bugfixes and updates|
|.gitignore||use new andsome arguments to change alt text|
|AUTHORS||update copyright year, website, add sam to authors|
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/VPAC/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. 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.