[sabayon] Desktop mass-configuration experiences..

[William Lachance <wlach nit ca>]

Ok, as promised (on irc), here are some notes on my experiences as a 
"sysadmin" (using this word loosely because I was programming at the
same time) of a network of somewhere around 20-30 workstations running
Gnome (sorry, I don't know the exact number offhand, but that's the
ballpark of how many people are using this system at any particular
time). 

Our userbase was basically our salespeople, although we converted a few 
people in accounting and QA downstairs (we used the same profile for all
of them). This was in a technology company, the userbase possesses some
technical ability but had not seriously used Linux before to my
knowledge. The base platform was Ximian Desktop 2 (with RedHat 9 as a
base) running off an NFS mounted root filesystem on a central server
which was shared between all workstations. Home directories were also
NFS mounted using autofs, name service and authentication were provided
via PamLdap and NssLdap. 

In general, Ximian Desktop 2 (or Gnome today) isn't really that
horrible. Most of the configuration tweaking we did was to make
administration easier (the argument here is: if I already know how my
network works, and I know who I'm configuring this stuff for: why on
earth should I have to set stuff up by hand?). To that end, most of our
modification to the user's configuration occurred the first time they
logged in, via a set of shell scripts.

These include:
- A script to setup an IMAP account and an LDAP addressbook in
Evolution, basically by providing a somewhat tweaked out evolution
directory to the user who is logging in, if it doesn't already exist.
Later, this script was extended to do the same thing for our ExchangeIt
connector to Evolution. 
- A script to populate a "teams" folder on their Desktop, so they could
easily access files which were accessible to the unix groups that they
belonged to (this varied by user, naturally).
- Several scripts to automatically populate the OpenOffice.org data
sources list with whatever MySQL databases they had access to on the
central server.

There were also some settings that could only be changed by altering the
filesystem itself. The most egrerious of these was CUPS, where much hand
tweaking was required to get the right set of printers to appear for
every user (since there was no way to centralize this information in a
central database where it really did belong). The other big one was the
Gnome menus (which were a royal pain in the arse to change in 2.2): we
modified these some, but would have changed them much more if it had
been easier.

Finally, there were at least a few things either we or our users set by
hand (but probably would have been in some sort of centralized
directory, in an ideal world). The main thing which comes to mind here
was the default printer for each user: if this isn't set properly,
you're liable to generate a great deal of wasted paper. :-)

"Pushing" changes to the client involved, basically, rsyncing a new root
filesystem over to the target machine. Usually, this new filesystem
would be prototyped with a few clients before universal deployment. This
saved more than a few embarassing mistakes. This implies that it would
be a good idea for Sabayon to have built-in facilities for promoting a
profile from "prototype" to "production". 

Looking back on the whole experience, it was fairly infrequent for us to
want to change a configuration once it had been set up. In the few cases
where we did want to do this though, it was quite painful. For example,
at one point we decided to change the default web browser from Galeon to
Epiphany (after it seemed like development on the former had all-but
stopped). The switchover involved creating a script to sed 'galeon' to
'epiphany' in the panel icon directory. Yuck.

Wrt "profiles" for different users: As I said earlier, we didn't/don't
use these. The primary use I can think of for them offhand is presenting
the right view of applications/data. Certain programs shouldn't be run
by everyone (e.g.: a sales/marketing database app probably shouldn't be
run by someone in quality assurance). This policy should, obviously, be
expressed in both the user interface AND in the access permissions on
the filesystem/network (we only use the latter, but it's sub-optimal).

Anyway, to sum up:
- Minor "tweaking" of the default desktop (e.g.: putting new icons on
the panel, changing the background, default homepage), while obviously
useful, is only part of the puzzle.
- Would be really nice to have an easy way to deploy menus and printer
preferences/availability.
- Being able to automagically configure Evolution's settings is
essential.
- We sometimes needed to push new changes to existing clients.
- Profiles useful.

Questions/comments/etc. most welcome. I'm interested in this project
primarily because I found the whole experience of desktop sysadmining
rather demoralizing, so anything that would streamline the process and
reduce the amount of gruntwork involved would be most welcome. :) I'm
personally hoping that this project will help drive the development of
better deployment technologies for the Linux desktop (which, if you look
at my notes closely, are really the source of most of my complaints).

P.S.: It may also be worth talking to Dave Richards @ The City of Largo,
who helped manage an even bigger deployment of Linux desktops. You
should be able to get his e-mail addy through google.
-- 
William Lachance <wlach nit ca>