Arnaud Taddei - Arnaud.Taddei@cern.ch
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:
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
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
.
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/perlwith its libraries under/usr/local/lib/perlIt 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!
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.
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.
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
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/hepixthen 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!
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
.
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.
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.
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.
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/xdmThe 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 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:
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:
if ( -r /usr/local/lib/hepix/central_env.csh ) then source /usr/local/lib/hepix/central_env.csh endifor 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 fiThese lines might be slightly different in future versions.
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
).
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.
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.
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.
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/xprofileTable 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./etc/hepix/xclients
. /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)!/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.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.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. /etc/hepix/font-servers
for example:xtsoft1 xtsoft2The 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. ).
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.
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.
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/binin
group_sys.conf.csh
\verb+GROUPPATH=/afs/cern.ch/group/c3/bin; export GROUPPATH+in
group_sys.conf.sh
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.
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
).
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]
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.
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 |---docThe collections are listed as follow:
Refer also to table 1
/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/templatesand files:
/usr/local/lib/hepix/central*
/usr/local/bin
/usr/local/man/man1
/usr/local/doc/hepix
/etc
/usr/sue/lib/xdm
/usr/local/lib/hepix/X11/site /usr/local/lib/hepix/shells/site
Thanks to Roger Jones, Anne Ryan, Francesco Giacomini, Alessandro Miotto and Alan Silverman for their feedback and help on this documentation.
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
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!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.