Debian Enterprise Management Interface

What is Demi?

Demi is currently vapourware, it's in the design and planning stage. What it's aimed to be is something similiar to what the Redhat Network is for Redhat Enterprise Linux, without requiring you to outsource (or trust) that component to a third party. There are a number of goals, and to make them achievable they have been broken down into chunks with them being assigned to a release. Bear in mind that this is subject to change, so visit often to see what's happening.

Design overview (or What's in Andrew's Head Right Now)

Background: I work(ed) in a secure Internet gateway environment, that has a number of infrastructure servers running Debian, and external HTTP access was not permitted, nor was internal HTTP access to a central location. Applying security updates was a royal PITA. I also recently updated my RHCE and I'd like to see Debian be able to compete against Red Hat Enterprise Linux on a more level footing in the Enterprise space.

Two packages, demi-client and demi-server. Initially all demi-client does is create a demi user on the satelite node. The demi-server package provides the user interface and all the backend processing script smarts, and creates an SSH DSA key on initial postinst, which the administrator has to use ssh-copy-id(1) or other to propagate to the satelite nodes.

The central server periodically uses scp to retrieve the /var/lib/dpkg/status file from each satelite server, storing it in a per-host directory. Ideally a bit of MD5 checksumming should go on to determine if the list of installed packages has actually changed between polls, as this will save on processing time later...

The central server maintains an up to date list of what has on offer (the central server requires HTTP access, or some means of keeping it's package list up to date). A script on the central server then proceeds to loop over the list of installed packages on each host (this is  where the checksumming comes in handy to skip unchanged hosts), highlighting cases where the installed version of a package is lower than what's available on This logic can be reversed so that the looping occurs over the package list once the database backend is happening, and can be done in real time in a stored procedure or something, so the latest information is always available.

Somehow this will tie together with the DSA's issued by the security team (haven't figured that one out yet). The central server can then maintain a pool of required packages, so that they're already on the central server available for pushing out to the satelite nodes for manual installation later (would be great to bung them straight into /var/cache/apt/archives for easy apt-get installation).

That's pretty much all that's in my head at the moment. Please, I welcome feedback, suggestions, criticism (preferably constructive). I think this thing will be good for Debian. Oh yeah, if you haven't got the picture yet, this thing is designed to be run in an environment that has the stable distribution deployed. It's of no value with testing or unstable, but then I wouldn't envisage them being used in an Enterprise environment.


Release targets

Note that these are a guideline only, and subject to change, based on public feedback.

Version 1

Web interface
Interface reports on all servers managed, number of packages installed
Drill down report on packages installed on host, version, and latest security update version (if available) highlighting mismatches
Central server pulls from satelite nodes
Database backend

Version 1.5

Interface allows filtering based on package name, version, compliance status
Interface allows sorting
More efficient processing of satelite nodes, using checksums
Support central acquisition of security updates

Version 1.9

Additional frontends
Support pushing from the satelite nodes to the central server if desired
Support pushing packages to satelite nodes for manual installation