A user logs in. They are instantly presented with an `environment', courtesy of their startup files (.profile, .login, or whatever), in which they hope to start doing some useful work.

How does an administrator ensure that every user lands in a `good' environment? How do you fix bugs in the environment so that every user benefits? How do you keep that environment `good' as the system changes over time? How can users customize their own environment without losing the benefits

Some common solutions are: (a) No standard environment is provided; users have to come up with startup files on their own. (b) A minimal and typically entirely inadequate environment is provided to new users. They randomly copy startup files from their friends until something seems to work.

We reject all of these `solutions'.

Features of the Sidai scheme

The standard-environment scheme that we describe here has the following features:

A user's environment is built up from world-wide (provided by the Sidai team), site-local, and personal components.
For example, the hair-raising code to set a terminal correctly is usually not site-specific, and can be maintained once-for-all in the Sidai component.
Insofar as possible, users get the same environment across all platforms.
Users are not forced to use the scheme, and can override any aspect of it. Our experience is that they typically make one or two tiny tweaks, but are otherwise happy with the environment as it comes.
In particular, users are offered a choice of shells for interactive use (e.g. bash, ksh, tcsh, or zsh), and we try to make all choices behave the same way. So, for example, if we have an alias in tcsh, we offer the same alias under bash, too. And so on. Ditto for completion control, and so on.
It should be very easy for users to try different shells.

How the Sidai environment works

The idea is: every user is given a set of startup files (.login, .zshrc, .emacs, ... whatever), and they are all built up of pieces that look like this (from a .profile):

#<our-insert name="main">
if [ -r /our/share/user-setup/sidai/sh.main ] ; then
    . /our/share/user-setup/sidai/sh.main
fi
#</our-insert>

Points to note:

The sections inside the <our-insert> bits belong to the system administrator! (and might be changed)
The sections outside the <our-insert> belong to the user, and must be preserved in the face of any system `improvements'.
The startup file calls out to a Sidai-supplied file to do its business.
That file will, near the end, call out to a site-local file (probably /our/share/user-setup/<local-team>/sh.main) to add on any site-specific stuff.
All startup files work this way.

Customizing your environment

The main customization you can do is change your interactive shell. Before the main `insert' in your main startup file (.profile or .login, as appropriate), add:

# if Bourne-family shell:
export ARK_SHELL; ARK_SHELL=/usr/local/bin/zsh

# if C-shell family:
setenv ARK_SHELL /usr/local/bin/zsh

The environment will `flip' you to that shell, if it finds it on the machine.

If you want, you can give it (up to) three shells to try, in order:

export ARK_SHELL;ARK_SHELL=/usr/local/bin/zsh
export ARK_SHELL_ALT1;ARK_SHELL_ALT1=/usr/local/bin/bash
export ARK_SHELL_ALT2;ARK_SHELL_ALT2=/usr/local/bin/rc

General

For the shell configurations, if you set a variable before the startup stuff gets to it, it will honor your choice.

For example, if you do (csh) setenv EDITOR emacs before the `main' insert in .login, but your site-local default for EDITOR is axe, your choice will prevail.

(Of course, in that and many cases, you could let the default get set, then just override it later.)

We also intend that you can set variables which will `guide' the configuration. For example, your site might want to support three different email-reading styles. You could set a variable which says which one you want. (NB: no known cases yet :-)

Therefore: ToDo, mostly.

Customizing specific startup files

ToDo

Anti-customizations (don't do these)

Things we'd rather you didn't do... ToDo, mostly.

The main thing is: instead of working around bugs that you find in the Sidai or site-local startup files, please report the bugs!

Installation and setup

Creating your local team's setup files

Create a set of files in your ARK sources, probably in <your-team>/sidai-user-setup/, which will be your site-local startup stuff.

Lacking a better idea, copy those of another team (e.g. `verilab2' or `glasli1'), and adapt.

In the same directory (and, again, examples are available), create a user-setup.spec file [name not important]. This specifies the `shape' of the startup files for the users at your site, including which files are in play. It is used by the manage-user-setup script, described below.

Still: ToDo, mostly.

Installing the setup stuff

The Sidai and local user-setup files are installed with the normal Sidai package machinery. You now have startup files you can use on every host, perhaps in /our/share/user-setup/.

See the

Creating the startup files for a new user

Typically, for new user fred:

sudo -u fred manage-user-setup

Upgrading a user from pre-Sidai startup files to this scheme

You will first need to create a site-specific upgrade-user-setup script. The Sidai team provides samples, in the user-setup directory.

Then either run that script or have users run it for themselves.

Upgrading an existing Sidai-style setup after changes have been made to the spec

If you need to change what's in users' <our-insert>s... Either do it for our friend fred:

sudo -u fred manage-user-setup

or let Fred do it for himself:

manage-user-setup

Alternative implementations and ideas

ToDo, mostly.

`Usepackage' is a tool by Jonathan Hogg is ``a tool for managing the Unix environment for a multi-tool, multi-platform site.'' It is simpler and `lighter' than `Modules' (next).

`Modules' is a venerable tool (dating from about 1990) that allows for dynamic management of a user's set. That is, a .profile (for instance) might simply load a few `modulefiles'. Dependent modules are automagically loaded. As the user is working, s/he can load/unload additional modules, and PATHs, etc., are modified to do the Right Thing (TM).