The HEPiX Shells and X11 Login Scripts Project

Implementation at CERN

System Administrator Guide

Arnaud Taddei - Arnaud.Taddei@cern.ch


Abstract:

This document describes how system administrators can install and customise the HEPiX scripts according to what they manage: a single system, a cluster of machines or the computing environment for a group of users.


Contents


1 Introduction

This guide explains to system administrators how they can install and customise the HEPiX scripts.

The HEPiX shells and X11 login scripts are a package of shell scripts, perl programs, manual pages and documentation which provides the Common HEP Environment to your users when they are using a shell interface or an X11 interface.

All the concepts are detailed in [6]. You will also find a reference guide in [7] and you can give a short user guide [8] to your users. These 3 documents should come in the same package as this one otherwise you can access them through: http://wwwcn.cern.ch/hepix/wg/scripts/www/Welcome.html

In this paper we distinguish between 3 classes of system administrators according to what they manage:

Of course, you might correspond only to one class but in the other hand you can be the same person who is fulfilling the 3 roles.

Although there are 3 classes, we could add 2 more classes:

A paper will come later with another set of programs in order to give site system administrators the ability to change some defaults at 'site level' (see [6]) in an easy way.

Anyway, we will see in the following how to:


2 Installation

The HEPiX login scripts can be installed into 2 modes:

Indeed we considered two target situations:

The initial target of this package was the new systems as we wanted to provide a good and standardised environment to users for all the new services; but as a side effect, the deployment of this package affects the 'old' services as well. Although it is possible to enforce an environment each time a user starts a shell on a new service, it is probably not wise to do on an existing service where a certain number of users are not used to this new environment. Thus, in the latter case, the environment should not be enforced and the user should have the choice whether to start the HEPiX login scripts or not.

How is it possible to enforce an environment? Simply by configuring a certain number of shell configuration files under /etc on a system. This does not work for all shells gif and this is why we provide a default template file for each shell which has to be used by the user. In these templates a central auxiliary file is called and checks if the HEPiX scripts have already been started and if not it runs them gif .

Thus depending on your case, the installation procedure will put some files under /etc (in enforced mode) or not (in weak or non-enforced mode).

Once you have stated that you are in situation where you are dealing with a new or an existing service, you can install the package by following the installation in enforced or weak mode.

Warning: perl 4 is required and it is expected that the binary is under
        /usr/local/bin/perl
with its libraries under
        /usr/local/lib/perl
It is required both for the installation and the usage of the HEPiX shells and X11 login scripts.

The default and the recommendation for installing this HEPiX package is to install the shells login scripts locally on the machines file systems and in enforced mode. This means that you should install the etc, hepix, bin and man1 collections (see table 1).

For system administrators who want to trace the behaviour of the HEPiX scripts, they can use the so-called debug mode installation. It means that each time a user will start a shell, a log file will be produced under /tmp. The naming scheme of these files is:

       /tmp/hepix-log.$USER.$$
The same apply for the HEPiX X11 login scripts in debug mode a file
       /tmp/hepix-X-log.$USER.$$
is produced each time the user is doing an Xsession or is starting an Xsession in fake mode.
So, be very carefull while using this mode and make sure that /tmp is cleaned periodically! You must understand that this mode is only used to debug problems. Never use it in production services!

2.1 Installation in enforced mode

 

At CERN, if you are using the so-called 'SUE' system it can or it will be able to automatically install or update the HEPiX scripts for you (refer to [9]).

Using SUE, the HEPiX login scripts are defined in the cern profile (see 4.2 in [9]) and are installed by default.

If you are not using SUE, you must get the HEPiX package and then install it. The following explains how to do it.

2.1.1 Where to get the package from

If you can access the /afs/cern.ch cell via AFS or via an NFS translator

In this case, you just need to go to the proper place and you can use the command to install the HEPiX scripts in any mode from there.

This means that if you want to install the scripts on AIX 3.2 then:

cd /afs/cern.ch/project/hepix/wg/scripts/unpack/3.0.2/rs_aix32/hepix-3.0.2-rs_aix32/
and then report to 2.1.2 in this document.

If you cannot access the /afs/cern.ch cell via AFS or via an NFS translator

The default place is now the CERN official anonymous FTP:
asisftp:pub/HEPiX/pro/sysname/archive

sysname must be one of:

archive follows the form:
hepix-Version.Release.Patch-sysname.tar.Z

For example, if you want to get the HEPiX login scripts for AIX 3.2.5, with the production version being 3.0.2, simply get the file:

asisftp:pub/HEPiX/pro/rs_aix32/hepix-3.0.2-rs_aix32.tar.Z

Then you can download the package into a local file system and we assume in the following of the paper that it will be under:

/usr/local/src/hepix

This is for convenience you can put it elsewhere but not under /usr/local/lib/hepix of course.

Once you get the package, you must uncompress it:

> uncompress hepix-3.0.2-rs_aix32.tar.Z

then you have to untar it:

> tar xf hepix-3.0.2-rs_aix32.tar

which will create you a directory:

hepix-3.0.2-rs_aix32

2.1.2 How to install the HEPiX package in enforced mode

  Once you get the package uncompressed or you checked you could access it through the /afs/cern.ch cell, you can install the package on your system.

You can achieve it using make.pl command. For a formal descrition of this command consult Annex A.

su to root, go under hepix-3.0.2-rs_aix32/ directory and then you have different possibilities which are listed below. The default is to install the HEPiX shells login scripts in enforced mode and locally on the machine. So the collections etc, hepix, bin, man1 should be installed locally on the machine (refer to table 1).

- get the help:
> ./make.pl -h

- use the fake mode to check what the default would do:
> ./make.pl -n

- install the recommended default:
> ./make.pl

- install the recommended default in verbose mode:
> ./make.pl -v

- install some components, overwriting the previous version:
> ./make.pl -v -F 1 -C hepix:cern:etc:bin:man1:xdm

- install only the system part under /etc (this allows you not to put the scripts locally under /usr/local/lib/hepix but to make them accessible via NFS):
> ./make.pl -v -F 1 -C etc

- install the scripts in 'debug' mode:
> ./make.pl -d

- install the hepix and the xdm collections in enforced mode:
> ./make.pl -v -F 1 -C hepix:etc:xdm

- install the CERN customisation of the HEPiX scripts:
> ./make.pl -v -F 1 -C cern

Table 1 gives you all the collections and the flags which control their installation.

  
Table 1: The files and directories installed by make.pl vs specified collections

The procedure saves any vendor shell configuration file under /etc under a name with extension .std. The restore (-r flag) part resets the vendor shell configuration files under /etc.

The procedure make.pl has a force option -F nb a verbose option -v and an option to install the debug mode -d.

In addition an option -n will fake the installation.

You must be aware that this command will not try to overwrite an existing file from a previous version. Use the flag -F 1 to do so. Using the flag -F 2 will force the creation of the directories themselves and might delete completely your old versions. Warning, if for example you have a symbolic link

    /usr/local/lib/hepix --> /afs/cern.ch/asis/@sys/usr.local/lib/hepix
then this link will be removed and a local directoy will be created if you are using the -F 2 flag. So be aware of what you want to do!

2.2 Installation in non-enforced or weak mode

The following explains how to install the HEPiX shells and X11 scripts in non-enforced or weak mode. You would do it on existing services where you don't want to migrate your users to HEPiX but you want to allow new users to use HEPiX without perturbating the service. This requires that your users will have to use the proper template files in their home directory to make sure they access the HEPiX package. Once installed in weak mode the templates are available in /usr/local/lib/hepix/templates.

2.2.1 Using ASIS

At CERN, the recommended way is to use ASIS. If your machine is running ASISUpdate then, you have simply to specify to ASISUpdate (using epip) that you want to get the HEPiX scripts. You can even specify if you want to have a local copy or a set of symbolic links which points to AFS or NFS part of ASIS. Of course it is recommended to use a local copy as you are independent from network problems.

Machines which are still using make_asis (the ancestor of ASISUpdate) to get the HEPiX scripts remotely, should use ASISUpdate now. You can consult [1] for more informations.

2.2.2 Not using ASIS

If ASIS is not running on your system, you can follow the same steps as for the installation in enforced mode (refer to 2.1), only the last step will differ:

Indeed, instead of running make.pl as proposed you simply enter:

> ./make.pl -w

where the -w flag means weak mode or
> ./make.pl -C hepix:cern

You can always use the debug mode as well with

> ./make.pl -d -w

where the -d flags means debug or
> ./make.pl -d -C hepix:cern

and the -v flag to get a verbose output or the -n flag to see what it would do.

2.2.3 Warning - require user templates

In both cases (using ASIS or getting the files trough FTP) the users must get the recommended templates files if they want to use the HEPiX scripts. The so-called uco command is a tool which might help you and your users to get these templates. Indeed

> /usr/local/bin/uco -shell

and then choose the proper menu choice. It may reset the default dot files to the templates according to the login shell found in the passwd file or in NIS. Run:

> uco -h

for help.


3 Customisation

In order to customise the HEPiX scripts you must understand the file layout and the HEPiX way of classifying the system administrators.

Figure 1 shows the main idea of the HEPiX scripts file layout.

  
Figure 1: The mechanical levels of the HEPiX scripts

Table 2 gives the list of the auxiliary files which are used to make the HEPiX scripts accessible.

Note that for HEPiX X11 login scripts the xdm wrappers are put under a directory:

        /usr/sue/lib/xdm
The sue directory resides on a local file system directory. It refers to the CERN SUE project (see [9]) although the HEPiX scripts package can be installed with the CERN SUE system, it doesn't require it. So, it had been decided that the xdm wrappers would go into this directory no matter if SUE exists or runs for the machine on which you are performing the installation.

  
Table 2: Auxiliary files

Table 3 gives the names of the files for each shell flavour and for the HEPiX-X11 part, at each level. They can be used to provide a customised environment which suites your needs.

So if you want to provide a customisation for the C-shells on the machine you administer, you simply have to add lines in the files whose names are in the column System level and in the raw C-shell.

Thus you can customise your environment using the following files in /etc/hepix for the C-shells:

  
Table 3: HEPiX file layout

Moreover, the user can use templates files. In each newly created account all the templates files for the customisation of the shell should be provided. This applies as well for the X11 customisation files under $HOME/.hepix. Each user can edit these files using the examples described in the previous section to customise their environments.

In these templates the user will find 3 parts:

1
the header part which gives the address mail in case of serious problems, the version number, the generation date, the authors, etc.
2
the hook to the HEPiX scripts. This hook is not required if the HEPiX scripts are installed in enforced mode. The user should anyway NEVER remove these 3 lines for the C-shell users
        if ( -r /usr/local/lib/hepix/central_env.csh ) then
           source /usr/local/lib/hepix/central_env.csh
        endif
or the following lines for the Bourne-shells users:
        if [ -r /usr/local/lib/hepix/central_env.sh ]; then
           . /usr/local/lib/hepix/central_env.sh
        fi
These lines might be slightly different in future versions.
3
commented lines. All these lines can be uncommented. They give users examples of what they can do and this is their part. They can use it, remove it, update it as they wish.

These templates give other examples and, for tcsh or zsh shells, there are other related documents like [5], [2], [3], [4].

In the following, the filename extension notation .[c]sh means that there are two such files one to customise the C shells (.csh) and the other to customise the Bourne shells (.sh).

3.1 Customising the scripts for a single machine

 

If you want to customise the HEPiX scripts for a single machine, consider all the files under /etc/hepix, as belonging to you. It is these files and these files alone that you should customise. You should understand what they do, in which order they are executed and what changes are allowed.

These files are not overwritten by any installation procedure. They are your files and you simply must know that they are executed and what you must put in what file.

3.1.1 Setting environment variables

 

For the setting of environment variables you should only use the sys.conf.[c]sh file in /etc/hepix. So you have always an overview about the variables you set and there is only one location for Bourne and C shell flavours at each level.

The syntax is very simple:

ENVIRONMENT_VARIABLE=value; export ENVIRONMENT_VARIABLE for Bourne shells

setenv ENVIRONMENT_VARIABLE value for C-shells

Note: If you use variables in this file you have to quote them. After the variable definition additional spaces on the line are not allowed.

/etc/hepix/env.[c]sh

In the environment files /etc/hepix/env.[c]sh you can make any modifications to your environment, but be careful with commands producing output to the standard output or that set terminal characteristics. This output prevents the usage of remote commands like rcp.

3.1.2 Actions performed by a login shell

The login files /etc/hepix/login.[c]sh are provided for the login part. Here you can modify terminal settings with stty.

If you have problems with your current window size after a login via telnet you can use the resize command to set TERMCAP capabilities to the current window size.

Example for csh:

  if ( $term == "vt100" || $term == "xterm" || $term == "xterms" ) then
        if ( $OS == "SunOS" ) then
               set noglob;/bin/sh -c "eval `resize`"
        else
               set noglob;eval `resize -c`
        endif
  endif

Example for sh:

  if [ "$TERM" = "vt100" -o "$TERM" = "xterm" -o "$TERM" = "xterms" ]; then    
          eval `resize -u`
  fi

/etc/hepix/aliases.[c]sh

The files /etc/hepix/aliases.[c]sh can be used to add some aliases or functions in addition to the standard set of aliases and functions. It is recommended however to keep additional definitions to a bare minimum in order to stay compatible with other sites. There should ideally be a repository that keeps track of all additional definitions that HEP sites have made in order to avoid name clashes and different namings of the same command sequences.

Each file can contain resetting of the shell parameters, the shell options, completion of commands, etc. Of course, there is one file for each specific shell: kshrc for ksh, bashrc for bash, zshrc for zsh, tcshrc for tcsh, cshrc.rc for csh.

/etc/hepix/*rc*

The files kshrc, cshrc.rc, tcshrc, zshrc, bashrc under /etc/hepix can contain modifications of the option settings, special parameters dependent on the shell. It is however not really recommended to do that as it can really affect your users' way of working. Be careful in this area.

/etc/hepix/termset.[c]sh

The files /etc/hepix/termset.[c]sh ensure that the term variable has a reasonable value and redefine it otherwise. This is not a standard file but it has proved to be useful to have in all cases a term variable that matches entries in the terminfo database or in the termcap file.

3.1.3 Setting of the X11 environment

 

In order to set up the X11 environment, you must understand how the X session is controlled. Figure 2 illustrates the possible behaviours you can get from the customisation of the xsession.

  
Figure 2: Model of the HEP_Xsession

The X11 environment provides a reasonable working default to the user through the so-called HEPiX Desktop (to be compared with the COSE/CDE, HP-VUE etc. desktops).

Although the session management is still poor, this setting is a way to solve resources problems caused by the too heavy COSE/CDE, HP-VUE, etc. desktops. It will evolve with the technology and might enable in the future a real X11R6 session manager (OK, this is one reason why it is "beta" as well!!).

Through the so-called Major Switches it is easy to customise the session at the user level or for a machine, a site, a group of users, etc. in the same way as it is possible with the HEPiX shell scripts.

There is a way to control what is and is not allowed.

The major switch is the key idea for the customisation of the X11 environment. After a 4 months collaboration between CERN and DESY we finally managed to understand how a theoretical X session should be decomposed, and then we found a flexible way to handle this environment.

You can then control the session with the following Major Switches:

                 HX_WM            # the window manager: fvwm, mwm, etc.
                 HX_DESKTOP       # the desktop: CDE, HP-VUE, DXSESSION,HEPIX
                 HX_STARTUP       # the startup script: .xsession, 
                                  # HEP_xsession.default
                 HX_LAST_CLIENT   # the control or last client of the session
                                  # adam, xterm, window-manager, etc.
                 HX_ROOT_WINDOW   # the command which sends a root window
                                  # on your screen
                 HX_KEYBOARD      # the name of an xmodmap file
                 HX_SOURCEPROFILE # do you want to source your
                                  # user profile files or not 
                                  # (might be dangerous because of stty's)

Once the HEPiX scripts are installed have a look at the file

       /usr/local/lib/hepix/templates/xprofile
Table 3 tells you that if you customise a file /etc/hepix/xprofile you can specify what is the default window manager for this system. You can even specify that for this or that value of HX_VENDOR you want this or that window manager.

You can specify which are the clients which are started at the beginning of the session in the file /etc/hepix/xclients.

You can specify mandatory clients with the file /etc/hepix/xclients.m which will be executed even if the user or the group levels don't want it (so be careful when you set such a file)!

Don't forget that you can use the tool /usr/local/lib/hepix/tools/Xinfo to determine some characteristics of Xservers connecting to your system and the uco -X11 command provides a menu which offers you the possibility to fake the session. It produces a log file in $HOME/.hepix/xsession.log and you can use this output to understand what would happen for users' sessions when they connect to your system.

As usual root, all users with uid less than 100, and users listed in /etc/hepix/list- don't get the HEPiX X11 scripts but get what was provided by the vendor of your system. Although you may not have the vendor default login panel, if you login as root.

If they are detected, PC Xservers will have a special setting if these are Windows based Xservers.. Indeed HX_WM=local, because they are going to use Windows as a window manager which optimises the resources and integrates very well with Microsoft Windows. Of course if you prefer fvwm, then you can specify it.

The new assignments of port numbers are respected; the HEPiX scripts append a fontpath from the port 7100 of your XFontServers which you can specify in a list /etc/hepix/font-servers for example:
      xtsoft1
      xtsoft2
The HEPiX-X11 customisation of xdm doesn't set MAGIC-COOKIE although the installation procedures gives some hints on how to do this. There are many reasons for not doing it with the HEPiX scripts and the best one is that, it is probably not the HEPiX scripts' role to setup the security (This is a very "system" level thing to do and requires some checks on some directories, etc. ).

Keep in mind that:
1
HEPiX X11 has been designed to cooperate with MAGIC-COOKIE and even an xhost - is started in the preliminary tasks of the session.
2
it is recommended that you enable it.

It is possible that in the future the installation procedure installs this feature. At CERN, an xauth feature of the SUE project will do it and will be effective by the end of 1995.

3.2 Customising the scripts for a cluster of machines

If you want to customise the HEPiX scripts for a cluster of machines, each member of the cluster must be able to read files in /etc/hepix/cluster. Of course, this is your private directory. If the person who is administering each member of the cluster is different from you, make sure /etc/hepix/cluster is a link to a mounted file system on which are the real files otherwise use rdist, supper or other distribution tools to 'push' the files to each member of the cluster.

If you want to customise, you can use the same file names as described in 3.1.

Moreover, if in 3.1.1 at system level, the variable CLUSTER_DIR is set to something different from /etc/hepix/cluster then you will have to put the files under the value set in CLUSTER_DIR

You can control and ask the system administrator of each machine (if not yourself) to update the value of CLUSTER_DIR to another place.

Apart from that you have the same way to customise the cluster level as explained in 3.1.

3.3 Customising the scripts for a group of users

You can customise the environment for a group of users, independently of the service on which they will run. Of course each service must run the HEPiX scripts but, if there are different groups of users who are working on a service, it is important that you keep stability in the environment of the group of users you are supporting.

Thus there exists a 'group level' in the HEPiX scripts in which you can specify specific group variables, specific programs to run at login, specific shell settings (refer to figure 1).

At cern, the default value for the variable GROUP_DIR is /afs/cern.ch/group/gidname. For example it could be /afs/cern.ch/group/c3. All the files which are there are your files, they will be executed by all the users who are belonging to 'c3' unix group. Of course, if a machine is not an AFS client but supports group specifications like in /u/c3/pubc3 then you simply can ask that the value of GROUP_DIR is reset to /u/$GROUP/pub$GROUP by the administrator of the machine (see 3.1.1).

All the files which you can customise are the same as in 3.1 but their names start with the prefix group_. For example, if under /afs/cern.ch/group/c3 you put two files group_sys.conf.csh and group_sys.conf.sh where you set specific environment variables for the group c3, these file will be executed by the shell.

The special variable GROUPPATH enables you to insert a group specific PATH in the CERN default USERPATH variable. For example, you can set

       setenv GROUPPATH /afs/cern.ch/group/c3/bin
in group_sys.conf.csh

and
\verb+GROUPPATH=/afs/cern.ch/group/c3/bin; export GROUPPATH+
in group_sys.conf.sh

This means that the PATH will look like (when logged in):
/afs/cern.ch/user/t/taddei/bin:/afs/cern.ch/user/t/taddei:scripts/afs/cern.ch/group/c3/bin:
/usr/sue/bin:/usr/bin:/usr/bin/X11:/usr/ucb:/usr/local/bin:/usr/local/bin/X11:/cern/pro/bin:.
for an AIX machine.

You can do all sorts of things, like having one more indirections to subgroups in one group as far as you are able to distinguish them.

Examples:
                       source                           
   group_env.[c]sh    --------->  $MY_GROUP.env.[c]sh   

                       source                           
   group_login.[c]sh  --------->  $MY_GROUP.login.[c]sh

This is very convenient if you want to have an indirection to some group-test directory where you can test your group setting for your users.

For X11 customisation, simply look at what is explained in 3.1.3 and replace /etc/hepix by the location of your group customisation directory (for example /afs/cern.ch/group/c3). Don't forget to consult table 3 in order to get all the required file names for the group customisation of the X11 part (group_xprofile, group_xclients, group_xclients.m).


A Formal description of the make.pl command

 

A.1 Description

The make.pl command installs the various collections and modes of the HEPiX shells and X11 login scripts.

       make.pl [ [-X] [-w] [-g] [-u]| -C collection-list | 
               [-r] | -D collection-list] [-d]  [-F n] [-n] [-v] [-h]
               [-H install|deinstall]

A.2 Arguments

          NIY:      Not Implemented Yet.
           
          -d:       the installation of the debug mode.
          -X:       the installation of the xdm area.
          -w:       the installation in weak mode.
          -F n:     the flag to Force the installation. n can be:
                       1 - force only on the target objects.
                       2 - force the target collections (NIY).
          -n:       the flag to fake the installation.
          -g:       the flag to install etc and xdm areas only.
          -C collection-list:  
                    the option to list the collections to be
                    installed:
                       hepix ---> /usr/local/lib/hepix/shells/hep
                                  /usr/local/lib/hepix/X11/hep
                                  /usr/local/lib/hepix/shells/wrappers
                                  /usr/local/lib/hepix/X11/xdm
                                  /usr/local/lib/hepix/tools
                                  /usr/local/lib/hepix/templates
                                  /usr/local/lib/hepix/special
                       bin   ---> /usr/local/bin
                       man1  ---> /usr/local/man/man1
                       doc   ---> /usr/local/doc/hepix
                       etc   ---> /etc
                       xdm   ---> /usr/sue/lib/xdm
                       cern  ---> /usr/local/lib/hepix/shells/site
                                  /usr/local/lib/hepix/X11/site
                    example:
                       -C hepix:cern:etc
          -D collection-list:   
                    the option to list the collections to be de-
                    installed. 
                    The names must be chosen in the above list.
                    example:
                       -D hepix:etc
          -H install|deinstall:
                    this option installs or deinstalls the hepix scripts
                    in your HOME directory.                             
          -r:       the option to restore the installation
                    of etc and xdm areas.
          -u:       the option not to install the bin area.
          -v:       the verbose mode.
          -h:       this help.

A.3 Description of the program

The program can install or de-install several collections from the "pre-compiled sources" which are available with the package:

The "pre-compiled sources" are:

       hepix*
          |---inpro
          |      |----X11
          |      |     |---hep
          |      |     |---site
          |      |     |---xdm
          |      |----shells
          |      |     |---hep
          |      |     |---site
          |      |     |---wrappers
          |      |----tools
          |      |----templates
          |      |----special
          |---debug
          |      |----X11
          |      |     |---hep
          |      |     |---site
          |      |     |---xdm
          |      |----shells
          |      |     |---hep
          |      |     |---site
          |      |     |---wrappers
          |      |----tools
          |      |----templates
          |      |----special 
          |---doc
The collections are listed as follow:
1
hepix
2
bin
3
man1
4
doc
5
etc
6
xdm
7
cern

Refer also to table 1

1
The 'hepix' collection represents the core programs and scripts which are the hepix package. It is recommended that these files are copied localy on the file systems as they are sensible to any network unavailability: they control your environment both shell and HEPiX level. However you can find them on a distributed file system to which /usr/local/lib/hepix is linked.

Target directories:
       /usr/local/lib/hepix/X11/hep
       /usr/local/lib/hepix/X11/xdm
       /usr/local/lib/hepix/shells/hep
       /usr/local/lib/hepix/shells/wrappers
       /usr/local/lib/hepix/tools
       /usr/local/lib/hepix/templates
and files:
       /usr/local/lib/hepix/central*

2
The 'bin' collection represents the hepix program which must go into the binary path. Typically, the 'uco' command goes into the 'bin' collection. It can be local or on a distributed/remote file system.

Target directory:
       /usr/local/bin

3
The 'man1' collection represents the hepix manual pages which must go in the man path. Typically, the 'uco.1' file goes into the 'man1' collection. It can be local or on a distributed/remote file system.

Target directory:
       /usr/local/man/man1

4
The 'doc' collection represents all the hepix documenta- tion. It can be local or on a distributed/remote file system.

Target directory:
       /usr/local/doc/hepix

5
The 'etc' collection represents the wrappers for the shells which are on the local system. These wrappers must be copied locally and are going to replace the vendor files if any. The latter will be saved.

Target directory:
       /etc

6
The 'xdm' collection represents the wrappers which must be installed for xdm to start the HEPiX X11 package. In fact this collection displays on your terminal what you must do as system administrator to enable a proper xdm. Basically you must call xdm with the proper options.

Target directory:
       /usr/sue/lib/xdm

7
The 'cern' collection represents the site customisation used at CERN. You can use it `asis' or you can use it as an example and then adapt it to your own needs.

Target directories:
        /usr/local/lib/hepix/X11/site
        /usr/local/lib/hepix/shells/site


B Acknowledgments

Thanks to Roger Jones, Anne Ryan, Francesco Giacomini, Alessandro Miotto and Alan Silverman for their feedback and help on this documentation.


References

1
Philippe Defert, Alain Peyrat, and Ignacio Reguero. ASIS - User's and Reference Guide. Guide CN/CO/152, CERN, Geneva, April 1995. Version 3.00.

2
Arnaud Taddei. Customising your shell - tcsh specific . Guide CN/DCI/172, CERN, Geneva, April 1994.

3
Arnaud Taddei. Customising your shell - zsh options . Guide CN/DCI/171, CERN, Geneva, April 1994.

4
Arnaud Taddei. Customising your shell - zsh specific . Guide CN/DCI/175, CERN, Geneva, April 1994.

5
Arnaud Taddei. Shell Support - tcsh and zsh for pedestrians . Guide CN/DCI/163, CERN, Geneva, April 1994.

6
Arnaud Taddei. HEPiX Login Scripts Project - Implementation at CERN: Concepts. Guide, CERN, Geneva, April 1995.

7
Arnaud Taddei. HEPiX Login Scripts Project - Implementation at CERN: Reference Guide. Guide, CERN, Geneva, April 1995.

8
Arnaud Taddei. HEPiX Login Scripts Project - Implementation at CERN: User Guide . Guide, CERN, Geneva, April 1995.

9
Rainer Többicke. SUE. Specifications, CERN, Geneva, April 1995. Version 1.0.


This document had been translated from LaTeX source using the command:
latex2html -split 0 -t "HEPiX Shells and X11 Login Scripts - Implementation at CERN: System Administrator Guide" -no_navigation -info "" -show_section_numbers sysadmin-guide.tex

...Taddei
CERN - Arnaud.Taddei@cern.ch

...shells
In particular, vendor shells are sometimes not behaving the right way, in particular for sh, csh, ksh and for some of them you cannot enforce a behaviour in all or partial cases. You cannot customise it unless you have time to rewrite these shells!

...them
Note that in enforced mode, by default, root and all users with a uid less than 100 don't start the HEPiX scripts as well as all the users whose login name appears in a flat ascii file /etc/hepix/list-. The latter file is a rejection list file which can be used by the system administrator to disable the HEPiX login scripts for users who have to run special environments. Of course, only root can control, create and use this file.



Arnaud Taddei
Tue Dec 12 13:16:26 MET 1995