Blue:

• First revision 21st December 2001

Green:

• Second revision 21st January 2002

Red:

• Third revision 7th February 2002

Orange:

• Forth revision 28th February 2002

Default and group user environments will need to be configured; this 
includes both shell variables and X customisation.

The initialisation setup at CS uses differently named init files from those bash usually uses (~/.brc instead of ~/.bashrc etc). At first it was believed that the CS bash binary did not source .bashrc, .bash_login and .bash_profile files if they existed in the user's home directory. Further investigation has shown that this is not in fact the case. This has ramifications for legacy systems which are dealt with below.

First year students at CS now have KDE as their default window manager. This setup appears to have been minimally changed from the 'out of the box' installation.

The current default DCS setup is based on the "fvwm2" window manager.
This is looking rather dated, with the majority of students using
more modern window managers, such as KDE. It would be adequate though.

• All DICE user accounts will have Bash as their default shell. Note that this is not a blanket prohibition on users using other shells. If they wish, users can start up alternative shells from the shell prompt or within their Bash initialisation files. Depending on staffing levels when DICE goes online, we may wish to not offer support for any other shells users may wish to use.

As it stands, some aspects of the DCS mechanism are probably somewhat over-engineered for our needs. For instance , there are two mechanisms by which users can modify their setup, through the use of the .benv etc. files or by putting short scripts into the ~/share/bash directory. The existing mechanism has the ability to modify the user's setup on the basis of two environment variables, $GROUP and $ENVIRONMENT. Since $ENVIRONMENT is nearly always set to the value of $GROUP, it may be thought that the two mechanisms could usefully be folded into one. One exception to this general rule is if a .environment file exists in the user's home directory in which case $ENVIRONMENT is set to the contents of that file. This useful facility allows staff to test out the environments of other user groups and it is suggested that it be retained, albeit with its use restricted to those in group 'staff'

It has been pointed out that the .environment mechanism has proved useful for postgrads involved in tutoring. In view of this, it may be preferable to make the .environment mechanism more widely available.

In summery, we propose that the current DCS setup be simplified somewhat to modify user's environments on the basis of a single variable, $ENVIRONMENT, which will normally be set to the value of $GROUP but which can be altered through the use of a .environment file in the user's home directory. On the question of mechanisms for allowing the users to modify their own environment, the ~/share/bash mechanism is more elegant but it is probably more trouble than it is worth to remove the .benv etc. facility. We suggest therefore that both mechanisms be retained but that only the ~/share/bash one be advertised.

The decision that DICE will only use two groups, "real" users and pseudo users raises the question of whether the environment mechanism should vary between the two sets of users. There should be little problem in arranging things so that those pseudo users which have a shell specified in the password file on startup run a very much restricted set of startup files, probably one rc file shared between all pseudo users and a set of individual files per pseudo-user. This would allow us to tailor individual pseudo-user's environments without overloading them with unnecessary clutter.

The use of kdm as the login manager will give users the opportunity to select the window manager they wish from a menu provided at the login screen. The list of available window managers will include at least KDE, Gnome, Fvwm2 and a fallback option which only starts up an xterm. We will need to provide support and a default setup for at least one window manager and, given that there seems little to choose between KDE and Gnome and that KDE seems more popular than Gnome within the Division, it would seem sensible to select KDE as our supported window manager.

KDE differs from older window managers in that it is configured mostly by a control panel rather than though various configuration files. Given that no two users will have the same preferences for the way their windows look and behave, we suggest that users should be provided with a minimalist windowing environment and left to set it up to their liking, something that is easy to do with the tools KDE provides. In particular, the somewhat overpopulated 'K' menu should have applications which we wouldn't wish the average user to have access to removed.

KDE's configuration is held in two directories in the user's home directory, .kde and Desktop. When KDE starts up, it checks if these directories exist and if they do not, creates them from the contents of two skeleton directories. This mechanism will be expanded to allow the different groups of users to have different initial setups. Computing staff for instance will probably wish to retain some of the entries removed from the 'K' menu for other groups.

Existing KDE users will of course already have these directories. Fortunately, the version of KDE currently in use in the division is KDE 1 and the version which comes with Red Hat 7.1 is KDE 2. We will therefore be able to detect if a user is using an old setup in the KDE startup script and modify it appropriately.

It is anticipated that once a user has been given the default setup, the only modifications we will wish to make globally or on a per group basis will be to the 'K' menu and (possibly) to the contents of the desktop. This can easily be accomplished, the default contents of the 'K' menu are held and can be modified centrally (or at least on a per-machine basis), similarly, the contents of the desktop can be modified by the use of central .xinitrc files. Once again, there should be no problem in modifying the KDE startup script to take account of a user's $ENVIRONMENT when consulting these files.

A setup such as described above should fulfil the joint ideals of giving the users freedom to mould the desktop environment to their liking while allowing us to retain the ability to modify this environment as needs dictate.

Users will use the same home directory on DICE and legacy machines. Given that the DICE version of Bash will use .bprofile, .benv and .brc as init file names rather than the default names, the old and new environments should be able to happily co-exist, .bashrc and the like being referenced on legacy machines and .brc etc. being used on DICE machines. The one group of users to whom this does not apply are those who continue to use the remaining legacy solaris machines at DCS. Further investigation is required into the extent of this problem

There is one situation where the initialisation mechanism will produce incorrect, or at least unforseeable, results. If a user whose DICE home directory resides on an AI or Cogsci file server logs onto a legacy machine at the 'other' site (i.e. a Cogsci legacy machine for an AI user or vice-versa), the .bashrc file for the wrong site will be sourced with uncertain results. It is anticipated that this will be sufficiently rare an event to allow it to be coped with on an individual basis.

The discovery of the true state of affairs regarding how the DCS bash binary deals with .bashrc and .bash_profile files in the user's home directory poses a potential problem for the successful combining of DICE and legacy environments. In theory, the default ~/.bashrc and ~/.bash_profile files at AI and Cogsci should simply fall through (albeit with the Cogsci files printing out an error message) but we feel it would be more prudent to produce a Bash binary which behaves in a way corresponding to our original understanding, that is a Bash binary which ignores any .bashrc, .bash_profile, .bash_login and .profile files found in the user's home directory. The production of this binary and the corresponding RPM is a task which will have to be added to this group's tasklist.

It has been suggested that using .brc, .benv and .bprofile as the names of the user initialisation files rather than the standard .bashrc and .bash_profile may be an example of retaining elements of the legacy setup for no very good reason. It has been suggested that it might be preferable to accept the pain of moving to using the usual file names now for the sake of standardisation with the rest of the world.

In our view, the DCS names should be retained for the good reason that the usage of .bprofile and .brc does not correspond exactly to the use of .bash_profile and .bashrc by an unmodified version of Bash. For example when slogging into a remote host, the DCS mechanism would source the .brc file but the 'normal' version of Bash would not source the .bashrc file.

Simon seems confident that this kind of information can be incorporated into the LDAP database. A notion of the role of the user (syssie, staff, ug1, ug2, ug3, ug4, msc, phd) and their default location (jcmb, sb, fh, bp, at) should be sufficient. Investigations are currently under way as to the best way of populating LDAP from the information held in the Division database.

Timescales

Since the majority of the setup proposed here is either heavily based on the existing DCS setup or the default KDE installation, implementing the above should not prove a major strain on resources. I would estimate that two to three weeks work would be sufficient to have a working system up and running.

Preliminary List of Actions

bash

• Modify Bash to ignore standard environment files.
• Build RPM for new version of Bash.
• Finalise role/location information held in LDAP database.
• Rewrite Main.bashrc, Main.profile and Environment for DICE.
• Identify RPMs which contribute rc files and rewrite them as necessary.
• Identify 'orphan' rc files (i.e. those not belonging to an RPM) and rewrite as necessary.
• Create new defenv.bash RPM.
• Rewrite pathfix config file for DICE.
• Create new pathfix RPM.

X

• Determine contents of KDE desktop and K menu.
• Rewrite system .xinitrc and KDE skeleton files to provide this environment.
• Modify startkde script to take care of old KDE1 environments.
• Create new KDE RPM.