CERN HEPiX Workshop Report March 28/29 1994 Alan Silverman Introduction This workshop attracted nearly 40 people from various groups and divisions within CERN, including representatives of 5 major CERN experiments, as well as visitors from 7 outside laboratories, mainly European. It was kept informal, very interactive, and was held in a positive atmosphere of cooperation with a general desire to arrive at a consensus where possible in the direction of providing a common working environment for HEP users migrating off mainframes towards UNIX systems. The meeting focused on shells and associated startup scripts and on topics in X11 as they affect the user environment. Shell Startup Scripts The work done on this has been presented before (see Minutes from the 1993 NIKHEF and Pisa HEPiX meetings). Over the past two months, Axel Koehler from DESY, one of the original authors of the scripts, and Arnaud Taddei from CERN have worked together in CERN on making the scripts more portable, easier to install and to understand. They presented their work. The main points were as follows - * A Make file has been added to make installation easier. It includes options to allow an individual user to test the scripts in his/her environment before making them standard for a given user or system. * More documentation has been produced, principally in the form of a full report on the scripts from the point of view of both user and system administrator; in both cases, examples are given on how to tailor the scripts for individual or group use. * Some changes were made to the scripts to make them faster in execution (especially using a suggestion supplied by Thomas Finnern) and usable in an AFS environment. * With a view to maintaining a single source copy of the scripts usable by different sites, a code management (CVS) was added. In this way, a site taking the scripts from DESY may make its own changes within CVS and feed them back to DESY for incorporation to the single master source. In the discussion following the presentation, a few points were noted: * The resize command causes its own particular problems across the various platforms; it was suggested to create a global alias (rs) for it to take care of these. * These startup scripts should not (many people said must not) be used by the superuser account. * Templates must be provided for the user's $HOME startup scripts. Shells Many laboratories have long since decided on which of the many shells available they wish to promote and/or recommend. CERN is now in the process of deciding its choice of recommended shells and Tony Cass presented the current status. CN wishes to recommend one shell from each of the C and Bourne flavours. The basic C and Bourne shells themselves are too restrictive compared to the rich set of features offered by their various derivatives. On the C shell side, it seemed clear that the "market favourite" is tcsh and this is the one recommended. For the Bourne shell, the three contenders are ksh, zsh and bash. Of these bash seems to fall in the middle and be less commonly-found than the other two. Both ksh and zsh have their positive and negative points and some sites have opted for one and some for the other. However, feedback from DESY and RAL, plus comments made during the discussion would seem to indicate a slight preference for zsh. Nevertheless, more feedback is required before a more definite recommendation can be made. Other points from the discussion: * It was agreed that where a non-vendor shell is recommended, a local copy of that shell should be placed on the system disc; one should not rely on AFS for the shell. In CERN, this will be the responsibility of the so-called SUE (Shrink- wrapped UNIX Environment) tailoring package to ensure this when the system is installed and adapted to the CERN environment. * More feedback is needed on the use of the history file. Should it be local to that session or should it be saved and restored over logout/login. This is complicated by the use of X terminals and AFS; users without dedicated workstations may login to different platforms on successive sessions. * Should the cwd (.) be placed in the path and if so, where? Many people argued that it must be present, usually (but not always) at the end of the path. SUPPER SUPPER was presented by Wolfgang Friebel of DESY. It is a software distribution utility from CMU and based on a "pull" system, that is the client requests it from a server. The name comes from Software Update Protocol in PERl, which gives the clue to the language used. Because it is client-initiated, it can be easier to establish a cron entry than to try to guess when files on the master server have been modified. Also, being client-initialised, it is the local system administrator who decides when or how frequently to risk updating local files or programs. At the present time, IBM holds some copyrights but these are under discussion. X at DESY Presented by Thomas Finnern from DESY, Hamburg. Current work was in the area of X terminal support, especially on boot servers. It was noted that DESY did not recommend window managers in the X terminal because of the need felt for low-memory terminals. Thomas presented some questions being studied: * what is the definition of an X terminal? * which special files are needed for an X session? * do we need load balancing and how to achieve it? * how much resources does an individual X terminal user need? * how to make life easier for user and for the system administrator? Thankfully, Thomas also offered some answers: he recommended to "keep it simple and as standard as possible", where standards should include standards we define for HEP use. A new login server should be established to setup the system and user environments, a defined keyboard mapping, the required X resources (the $HOME/.files); it should start a window manager and a login window and perhaps also a control panel in the X terminal. And all these steps should be performed in the user's chosen shell. He had made available a template in the file ftp.desy:pub/salad/XDMNEW.ALL.tartar.Z. He was still looking for * A reliable font server * COSE/CDE * SALAD for XDM, Xsetup * Limited VMS Login * Intelligent load balancing He had not yet decided whether to try to restrict in some way X terminal access and he did know what to do about PEX. On all of these, he would like to collaborate with CERN. X at CERN Lionel Cons then described current thinking on X in CERN. CERN is looking to establish a so-called anonymous workplace and therefore seeks to use XDM since it is common to both X terminals and workstations. There should be a shrink-wrapped installation procedure and cloned X terminal servers. Steps in X terminal startup included * booting terminal from a boot server * loading the configuration from a configuration server * loading fonts from a font server * connecting to a login server (displaying a login prompt or a chooser menu; the latter may allow some form of load balancing) * performing work on one or more work server (which may be the same as the login server). The plan is to establish replicated boot servers; to try to avoid broadcasts to search for boot servers and to support several vendors with the same boot servers. Regarding the setting of X terminal parameters, the following points were noted: * setting all the parameters is a good method of having a "sane" configuration for the device after a reboot; * X terminal parameters cannot be changed by using the X resources; * however, a user may change "important" things in the appearance and usage of his or her X terminal via X resources: these could include colours, fonts and so on. Also he or she may customise the X environment with XDM, by defining the list of applications to be started by default for example. Fonts can be made available by several methods, including AFS if the screen is attached to a workstation (not possible for an X terminal). Tests are currently underway to determine the best method. X Graphics Environment This was presented by Arnaud Taddei. It should be pre-configured but tailorable by the user, should include a few standard clients and implement some basic security. It will be based on an XDM server. An XDMCP query should interrogate an XDM server which should reply with an XDM chooser menu arranged according to current load on those systems. A second alternative for allowing for load balancing would be to display a second client window showing relative loads on the available systems. Some files must be provided centrally to customise the X environment but the user must be able easily to override this. Keyboard support is very important and particular keyboard map files will be provided. Of course a user can add his/her own mapping as required. Nevertheless, keyboard mapping is expected to be one of the biggest sources of trouble. Security may be implemented by means of the MIT magic cookie method with versions of xrlogin modified to pass this and the DISPLAY variable correctly. xrsh usage is under investigation. Alan Silverman Fri Nov 11 17:00:29 MET 1994