ServerLand and NetworkWideUpdates considerations

Mon Jan 16 01:46:31 UTC 2006

Hi,

just jumped in so, hello everybody.

I'm currently reading up specs and stuff to tune in with the -server 
development, and doing so I happened to read the two pages mentioned in 
topic:
.1 https://wiki.ubuntu.com/NetworkWideUpdates
.2 https://wiki.ubuntu.com/ServerLand

1 is obviously a subset of 2 (so 2 should link 1).
2 mentiones cfengine, and that's what I'd definitely use (see comments later) 
to implement 1. Cfengine perfectly fits the features listed in "Scope and Use 
Cases" paragraph. It might not be strightforward and elegant in some 
parts,compared to the proposed one, but it's definitely doable and, if we go 
that way, we already have in place the structure to implement 2.

- Comments about cfengine
Actually, rather than cfengine I'd use puppet[1], which could be said to be 
the next-generation cfengine. Quoting from the faq[2]:

"The overall design is heavily influenced by cfengine, but the language is 
more powerful than cfengine's and the library is more flexible. In addition, 
Puppet's client and server use standard protocols like XMLRPC and are easy to 
enhance with new functionality, so they are well-positioned to become the 
platform for the network applications of the future, while cfengine's client 
and server rely entirely on cfengine-specific protocols and are quite 
difficult to enhance."

For more details you can see "How Puppet compares to Cfengine" page [3].

Besides technical details let me quote something I consider very important:

"Puppet will be supported by an organization[4] dedicated to creating the best 
system automation software, and I expect to have a staff of at least a few 
people dedicated to development, support, consulting, and custom development. 
Constrast this with cfengine, which is supported by a professor whose primary 
use for the software is in research into anomalies."

Puppet is written in ruby
Puppet is licensed under GPL.

There are only 2 cons I can see: 
- puppet is newer than cfengine
- cfengine can be run in windows under cygwin, puppet isnt supported yet (it's 
being worked on)

Nonetheless puppet is moving *much* faster than cfengine, and via ruby's 
windows port you can have something running natively instead of the cygwin 
"hack" (cyg->cfengine->activeperl->Win32::OLE),which is better when deploying 
nodes.

- A long shot: ServerLand, runnels[5] and Adminotaur
ServerLand saying "Using plenty of pre-existing F/OSS apps" has an important 
implication:  that plenty of FLOSS must talk to each other and/or to the 
ServerLand "server". Now, the problem with this is a common language all the 
apps speak, and runnels happens to be the answer:

"Runnels is a new project to create a networked message bus for passing 
information between system administration applications. The basic idea is 
that different applications across the network would produce and/or consume 
small chunks of data on the message bus."

Runnels is *very* cool and incidentally is developed by the same guys of 
puppet, with obvious benefits for integration, support, and development of 
the ServerLand project.

Runnels is released under GPL
Runnels uses xml-rpc as IPC

Last comes Adminotaur, which is a project of mine.

<disclaimer>
In no way I'm trying to advertise my project, and things I mention here are 
only because of their relevance with the ServerLand project.
</disclaimer>

There's no code yet but the design is sort of done, hopefully I'll put online 
a page with the specs soon. The project aims to collect and process messages 
produced by systems it controls (dispatched by runnels), and render them in a 
web interface. In concepts it's very similar to OS-SIM[6], but for the fact 
it's not targeted at security but at a more generic system administration.
Compared to ServerLand it's just a small subset.I dont aim to create a control 
panel, rather, when I started Adminotaur, I had in mind a ticketing system 
and was looking for:
- grouping and displaying events in a cohesive way.
Example: nagios/munin/cacti alerts, available system updates,commit of a 
config file managed under RCS
- be able to turn any event into a ticket or refer to it into a ticket
Example: nagios detects a service problem and that automagically becomes a new 
ticket the admin can then solve and close, maintaining an history.
- be able to have a complete networks and systems overview
Example: all the systems should be registered within the application, so the 
admin can easily access a report of the machines status, installed 
applications,available updates and so on. A map of the network should be also 
autobuilt, nagios like.
- offer a wiki/diary so the admin can easily make a note of info and things
- offer the ability to define a "job". A "job" doesnt depend on a ticket but 
is something like a new project the company starts, which might imply stuff 
like a new set of dedicated servers. The admin should be able to define a 
gantt like schema, with resources involved,timeline,milestones and so on.
- BE ABLE TO CORRELATE EVERYTHING OF THE ABOVE.
Example: 
1) system runs out of disk space
2) that becomes a ticket
3) the admin is notified
4) the admin investigates the problem and finds out it depends on bad option 
the FS has been formatted with, which caused it to run out of inodes. Doing 
so he/she finds some interesting links documenting the issue and makes a note 
of them.
5) the admin fixes the problem
6) If necessary someone is notified of that
7) this could happen during the development of a new project, causing a 
release date to be postponed.

the advantages offered by being able to correlate all those events are 
enormous imho, of course proportional to the complexity of the network and 
number of admins. With such system it's also easier to generate reports for 
upper management and the like, they all love those nice graphs and 
schemas :).

Adminotaur will be released under GPL
Adminotaur will be probably based on Trac[7], unless I decide to go with ruby.

-------------- Conclusions -------------- (Sorry for the long post.)
I'm not yet enough into ubuntu to understand all the implications and 
problems, but to me, investing time on puppet is the best solution for both 
"ServerLand" and "NetworkWideUpdates", and maybe more.

bye

Spike

[1]http://reductivelabs.com/projects/puppet/
[2]http://reductivelabs.com/documents/faq
[3]http://reductivelabs.com/projects/puppet/documentation/notcfengine
[4]Reductive Labs http://reductivelabs.com/
[5]http://reductivelabs.com/projects/runnels/
[6]http://www.ossim.net/whatis.php
[7]http://www.edgewall.com/trac/

-- 
"And then the lord said to John: "Come forth and gain eternal life."
But John came fifth and won a toaster."

						some guy on irc