I have been setting up Linux desktops for a non-profit radio observatory. For me, this was the first time I had to think about "deploying" several identical machines, centralizing login, home directories and so on. It quickly became clear to me that, perhaps contrary to intuition, the "everything is textual" philosophy does not necessarily make that an easy task, and I wondered what seasoned admins do about this.

In my case, I was installing Ubuntu 10.04 LTS on each machine. After installation, I ran a custom script that alters config files, removes and installs software and copies some files, like background images or browser bookmarks, from the server. I think, however, that my questions are distro-independent.


I was mainly encountering two problems: Firstly, inconsistent tools and config files, both across distributions and across versions, and secondly some crucial software not exposing settings to config files in an easy and intuitive manner.

Let me give two short examples for what I mean:

The ifconfig tool is being replaced by ip. All scripts relying on the presence of the former will break if, for example, run on a current ArchLinux box. So, I would need to check which tools in which versions are present on a machine I run a script on... this somehow feels like reinventing autoconf on a small scale.

For the second problem, consider that I wanted to give the desktops some sort of "common identity". In my post-install-config-script, I use the following lines to achieve this:

scp user@server:/export/admin/*.jpg /usr/share/backgrounds/
scp user@server:/export/admin/ubuntu-wallpapers.xml /usr/share/gnome-background-properties/
sed 's/warty-final-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/10_libgnome2-common
sed 's/warty\-final\-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/16_ubuntu-wallpapers
sed 's/ubuntu-mono-dark/ubuntu-mono-light/' -i /usr/share/gconf/defaults/16_ubuntu-artwork
sed 's/Ambiance/Clearlooks/' -i /usr/share/gconf/defaults/16_ubuntu-artwork

I suppose that creating a CI is a common task for organizational admins. So, how come there is no central config facility, perhaps even cross-desktop? Having to set two (identical!) undocumented values in two distinct config files strikes me as odd.


In an organizational environment, how do you handle central, unified configuration across multiple clients?

Do systems like Debian's FAI offer significant advantages (aside from not having to change CDs) over my method of "install first, run script afterwards"?

What are good practices for the transition between major versions of your distribution? And, apart from the technical stuff: Is there a desktop environment that promises long-term stability as far as the user experience is concerned? I don't think I can migrate my users to KDE 4 or GNOME 3, but XFCE still has some functional drawbacks...

Is there a *nix system that adresses this type of configuration issues? For example, I'd assume there are systems that ask you for some imagery of your organization (logos, background images, colour and font sets etc) and apply them to the login manager, users' desktops, web apps (!) and so on. Note: In our case, I have to work with fat clients, so a purely thin-client solution won't help.


Using Puppet or CFEngine or Chef is the right solution for your problem. Of course it will consume some time and trial & error approach to write the Puppet script which just work. These tools are widely used for automating complex installations on cloud and have simplified the lives of admins like us. :)

| improve this answer | |
  • Thanks for the hint! As I've asked MaxMackie before, does Puppet provide any sort of "centralized, crowdsourced intelligence" with regard to rewriting rules when switching between major versions of my distribution? E.g., if I know $DISTRO switches from GNOME 2 to 3, will there be a semi-automatic migration path? – jstarek Aug 30 '11 at 23:26
  • You can write a file for, let's say, Gnome3 config and include it in the configs of hosts on which you want Gnome3 to be installed. but it also depends upon how you create puppet configuration. If you follow modular approach then it will be easier. Puppet itself won't be able to identify Gnome3 or 2. (hope I got your question right) – Abhishek A Aug 31 '11 at 7:56

First off, don't expect this is going to be easy working with multiple distributions.

I've not run large desktop rollouts. For me the best tradeoff was using a LAN boot/tftp to bootstrap the system then running the install over NFS. Most Linux distro's ask you for all the initial config up front - then you can leave the installer to run for, say 40 minutes, unattended (no "Do you really want run this program?" prompts). At that point I was looking after Redhat and Suse machines - and had an RPM prepped with all the custom configs which I installed after the standard installation completed. However its quite possible to automate all of this on a variety of distros.

I'm not a big fan of the Ubuntu distribution for various reasons but Canonical's Lanscape is a very impressive tool. And if you're going to be doing a lot of large scale Ubuntu installs/managing multiple Ubuntu desktops its definitely worth a closer look.

| improve this answer | |
  • Looking at Landscape's site, I get the impression that it doesn't handle config file entries -- so, would I create local packages that do the changes I need on installation? – jstarek Aug 4 '11 at 16:24

I've been working a lot with software called CFEngine. It's an open source configuration manager which reads "rules" that you set and insures that every machine it is tied in to and respects those rules. It's completely open source and so useful our company has decided to use the supported version of the software called Nova.

This is a broad view of how it works. Let's say you have 4 computers on your managed network. They all need to have a file /etc/syslog.conf, owned by root, all the same (according to a master) and chmod 777. You would create this rule in CFEngine's configuration file. From your central computer, you have the "master" /etc/syslog.conf file. Every X amount of time, your computer's version of CFEngine will go through the network and ask each box about it's /etc/syslog.conf file. The local copy of CFEngine running on each client will query the file in question and report back it's contents, permissions, etc. If they do not EXACTLY match your caster copy, CFEngine will push your copy to the client and check the files again. They will match and he will move on to your next rule.

As for simplicity, the syntax used in CFEngine's "rules" (which they call promises) may take a little getting used to, but they are well worth learning (adds another great skill to your skillset).

| improve this answer | |
  • Thanks for the hint, I'll take a look at CFEngine. However, from what I've read about it until now, it seems that it won't save me from rewriting the rules when switching to a new major version of my distro, right? – jstarek Aug 30 '11 at 23:23

So, how come there is no central config facility,

Gnome has GConf which can perform all such minor tasks:



Ubuntu LTS is the almost the only option for long term support on the desktop.

Deploying multiple machines is almost possible with just a simple dd, the desktops distributions are slowly making this a less attractive route.

Also consider an option now is the so called fat client.

| improve this answer | |
  • I am already using fat clients, but that doesn't make configuration easier by itself -- they just get the homedir and passwd info from a central server. If GNOME didn't use GConf and put important config files in /usr/share/gconf/defaults/, one might just keep a central /etc/ somewhere on a server and have the fat clients mount it, but no, the GNOME guys seem to know better. Sigh... – jstarek Aug 30 '11 at 23:20
  • @jstarek fat clients mount /, GConf overrides live in /etc/gconf/gconf.xml.*/ – Steve-o Aug 31 '11 at 2:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.