Mid-range infrastructures (10-500 servers) running free software badly need a central host management application.


Currently there is no simple, central, free software way to manage a moderately sized infrastructure. RedHat partially fulfills this need with a proprietary solution, RHN (redhat network). RHN offers a sysadmin a wide overview of their network, notices on security updates, ability to manage configs, create kickstart CDs, documentation, overview of packages, pretty much the whole deal.

There are tools around to fulfill most of these needs, there is just no elegant glue to put them all together. While ServerLand could be considered an RHN knock-off, it is not. Using plenty of pre-existing F/OSS apps, it would become much more powerful.

Use cases

  • Polvi, as a sysadmin, wants to see which hosts need security updates. Polvi heads to ServerLand and finds that two hosts, ham and eggs, need new kernels by noting the eye pleasing red icons next to their hostnames. Out of will to see those icons turn green he clicks on the hostname 'ham'. He is promptly reminded that 'ham' is his mysql database, so he schedules 'ham' to download and install the new kernel, but not to reboot until a planned outage. Clicking on the 'eggs' hostname shows that it is a development machine. Since Polvi is up late and his developers are not, he logs into 'eggs', updates the kernel, and reboots the machine. Once 'eggs' comes back one more eye pleasing red icon is defeated by a green one.

  • Karen, as an office manager, wants to see which hosts we own for an upcoming audit. Karen runs a quick search in ServerLand returning the purchase dates and serial numbers of all the hosts. Karen is happy because it was easy, the sysadmin is happy because they did not need to go to the colo and write down serial numbers.

  • Dave, a woken up by a pager sysadmin, sees that a development host, 'eggs', is down. He connects to the KVM-over-ip by clicking a link on the host record in ServerLand and sees that it had kernel panicked. Dave then jumps over to ServerLand and sees in the changelog that Polvi upgraded a kernel earlier that night. Dave reverts the kernel (in case a developer wakes up), reboots, and sleeps soundly knowing they can fix it in the morning.

  • Paul, a marketing guy, wants to see the latest statistics on the companies website -- so he can market it. Paul pulls up the host page(s) for the web nodes in ServerLand, and uses them to better market things.


This specification is a brain dump, just a lesser technical high overview.


Most of this can be implemented out of existing software, it just needs to be wrapped up in a manageable form.

Host configuration and management

  • apt-get: with some sort of deamon that updates ServerLand with current packagelist, ServerLand could decide what needs updates, and why. This would also update the web interface putting red icons next to security issues.

  • cfengine: easily adapted to deal with particular configs. Heck, cfexecd could even be used to update the package list for apt.

Host details

Combining information entered by the admin and statistics (graphs) would prove oh so helpful.

  • Server registration process: While it might seem silly to have to register all your hosts with a particular service, it actually makes a lot of sense. The server registration process would guarantee that the installing admin takes note of predetermined information. This could be, but is not limited to:
    • Serial numbers
    • HW type
    • Type (production, build, etc)
    • Person responsible
    • Purchase date, price, vendor
  • mrtg/cacti: Integrating some sort of snmp poll-er that is setup upon registration.
  • CHANGELOG: Sorry for the caps, but this is important and often forgotten. A neat and elegant solution to this would be to ingrate syslog-ng. Then a sysadmin could run 'logger "I updated the kernel, hope it is stable!"' and it would be added to the host detail.

  • services running: nmap combined dynamically configured nagios (and nrpe) would allow for an unparralelled view of a host.

Imagine a screen where you could check a few boxs and turn on graphs or monitoring... all the way down to the service level!! Game over!

System Overview

Out of the box nagios allows you build rich network diagrams (switches and all). What nagios cannot do, however, is push configurations and monitor security updates.


ServerLand could start as just a place to register servers local to your network. Initially it would trivial to have a central place for human created data. Modules containing computer generated data could be deployed as they are created. This process too should be rather simple, since it is using pre-existing software (for the most part).

Data preservation and migration

RSS feeds of local security issues.

Outstanding issues

It needs to be implemented. Dynamic generation of monitoring and graph configs could be tricky, but it is do-able.

Creating the apt service that phones home the current package list needs implementing too.

Pretty much it all needs implementing (except the underling technologies).

Why should we care?

This section was not part of the original template, but still, it is worth noting.

  • Most infrastructures pull this all off somehow... but it is generally pretty tedious and painful to setup. While following the unix philosophy would say to keep all these different services separated, we validate breaking this since the services themselves are so closely related. There is a need and advantage to having them work together.

  • Most of the organizations that have mid-range server infrastructures make money.
  • This would further promote great F/OSS utilities and show how well they work together.

BoF agenda and discussion

In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC1925: The Twelve Networking Truths

I think what should be built is a sparse framework that can be expanded on as needed.


ServerLand (last edited 2008-08-06 16:20:17 by localhost)