[Demi-devel] Screen shots
Andrew Pollock
apollock@debian.org
Tue, 8 Mar 2005 07:30:12 +1100
On Mon, Mar 07, 2005 at 02:39:02PM -0500, John Morrissey wrote:
> I've begun some coding, since my employer is interested in seeing something
> like this implemented. It's unpackaged and fairly unreleasable right now,
> but here are some screen shots to give you an idea of what's there so far.
Awesome. I'm glad someone's had some time to do something because I sure as
hell haven't :-(
> It's written in Python with a database backend. Server-pull from clients
> running an XML-RPC server (unencrypted currently). Pulls DSAs from the
> Security Team's RDF feed. Shows up-to-date, out-of-date, and inactive hosts.
> Currently, version comparisons are simple equalities based on the server's
> APT cache, and do not respect APT preferences for weighting. Out-of-date
> packages are shown, and those with a correponding DSA mentioning that
> package are displayed (in other words, it's considered DSA-affected whenever
> a DSA mentions that package, whether or not the package has a version
> greater than the fixed version from the DSA).
Hmm. I was trying to make the client requirements as lightweight as
possible, which is why I was pulling the /var/lib/dpkg/status file via SSH.
No new holes to poke in firewalls, excrypted channel with strong
authentication for little extra effort.
> I have a larger to-do list that I can post; I've built it up from
> suggestions posted to the list and web site. Right now, I think my next
> target is encryption in the XML-RPC client agent, and then package
> installation. Packages will probably be client-fetched at first (via
> apt-get(8)) with server-push possibly coming later.
So the client would do an apt-get? The scenario that made me want to build
this in the first place was one where the clients didn't have external
access, only the central server in the management zone, so the management
server would suck down the packages and push them out to the client.
> I also need to have a reasonable way to add machines to Demi, since the only
> method now is INSERTing them manually into the proper table. I would also
> really like to investigate ASAP the best way to do unit/regression testing
> in Python, so Demi has smoke tests from the very beginning and I don't have
> an excuse to avoid them later.
>
> Comments/feedback?
Nice work. I wish I'd got something more significant off the ground before
now :-(
> http://horde.net/~jwm/demi/
>
> john
> --
> John Morrissey _o /\ ---- __o
> jwm@horde.net _-< \_ / \ ---- < \,
> www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
>
> _______________________________________________
> Demi-devel mailing list
> Demi-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/demi-devel
>
--
linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux
April 18th to 23rd - http://linux.conf.au/ - LINUX
Canberra, Australia - http://linux.conf.au/ - Get bitten!