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.
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
security.debian.org 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
security.debian.org. This logic can be reversed so that the looping
occurs over the security.debian.org 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.