HEPiX Rio Meeting Report

HEPiX Rio Meeting Report

Minutes of the Meeting held September 24th-26th, 1995

  1. CBPF and LAFEX Intro - Prof Amostope and Prof Santoro
    CBP was the first research institute in Brazil, created in 1949. It had a long tradition of hosting famous teachers and visitors.

    LAFEX was one branch of CBPF and Prof Santoro presented the structure of the research establishments in Brazil together with a description of the range of physics and cosmology done at LAFEX.

  2. Requirements for UNIX from Physics Experiments

  3. Site Reports

  4. Security Issues on Digital UNIX by R.Lauer
    Ms Lauer described why security auditing was important, password protection, X access, etc, and the features which were present in ULTRIX to assist this if the so-called "enhanced security" mode was enabled. Some of these were missing in D-UNIX, at least in the early releases. She then described the various tools which were present in D-UNIX 3.2 and how they were controlled by the system administrator. The use of NIS complicated the security tasks.

    She believed that auditing could be a useful, perhaps even one day essential, tool in case of troubles such a serious security incident. D-UNIX offers to build an audit demon and to provide reports. Many paramters were configurable. She had found D-UNIX enhanced security easy to use and considered it to be a good starting point but stated that it required better documentation and a more consistent user interface.

  5. Lights-Out UNIX - C.Boeheim
    The speaker described plans at SLAC for cutting back on overnight operator cover in their computer centre. SLAC had adopted the Control Console Server from FNAL; it was an RS/6000 with a patch panel connecting the console lines of up to 128 nodes with a console package from Purdue and a log watch package. SLAC had developed a control program with ideas from CASPUR as presented at HEPiX in Paris the previous year. Messages were passed to a control host module where they were filtered by the log watch program and the "interesting" ones forwarded to specific destinations where appropriate actions could be taken.

    For reporting problems, they had considerd several tools, including direct alerts via pagers, Zephyr-grams and eventually they had purchased a commercial tool, TelAlert.

    For system monitoring they used Patrol which checked for healthy status (for example adequate swap space, free memory, a list of required processes). They used home-grown tools for some of these checks and they had a policy of reducing priority on CPU-bound jobs on their interactive servers.

    Other automated tasks included scripts to clean up the disc space periodically, removing temporary and core dump files, producing audit summaries and so on. Another important area handled by such tools was of course security and some of the tools used in security checking were described at the previous HEPiX and they had now been merged into this automated scheme.

  6. User Training for Migration by A.Silverman
    As part of CERN's plan to migrate several thousand users off its IBM mainframe, the migration team was setting up a series of seminars on very specific subjects. These would be typically one to two hours long and would include online demonstrations. For example, a course on emacs would be illustrated by editing a file via an X Terminal connected to an overhead projector. Some subjects would be treated in more depth by arranhing courses of several half days.

    In choosing speakers, it was hoped that experts from different labs could be used where possible but in all cases it was necessary to allocate suffucuent time for the speaker to prepare the material, a non-trivial time often. And it was also the case that the author or person responsible for a product was not always the best teacher.

  7. Work Group Servers at CERN by T.Cass
    At CERN, the speaker is responsible for a team supporting both Work Group Servers (WGS) for particular experiments or groups and Public Login UNIX Servers (PLUS) for general interactive use. Both offer a similar user environment and this is also offered to users with their own desktops. The support team has developed management tools to be independent of platforms since they must currently support a range of systems from IBM, HP and SUN. They aim at one systems specialist per platform and so adding a new cluster of the same architecture as is already present is relatively cheap in resources. Next year however they plan to add a Digital Alpha PLUS system. One tool they use is the SUE scheme described in the Saclay and Prague HEPiX meetings.

    The decision to have a cluster of nodes in a given WGS or PLUS rather than a single large configuration was partly in order to minimise the single point of failure risk although every cluster did have one node which had special roles (account registration and accounting for example). Nevertheless, jobs were shared across all nodes in a cluster using a tool called acrontab developed by CERN's AFS team. Similarly, incoming accesses from users were shared across the nodes by the ISS scheme of crude load balancing.

    In the past months, a lot of effort had gone into understanding the system behaviour and many monitoring and analysis scripts had been developed. From the results, they could now plot the rise in use of CERNSP compared with the gradual rundown of CERNVM.

    The next question was system modelling - what effect would be gained by adding extra memory for example for the same number of logged-in users? Other tools under study or in some cases in development were --

    Concentration this year was on consolidation of existing clusters and services plus some help to be given to the LEP experiments to assist them to migrate off CERNVM,

  8. Plans for a Central Mail Server at CERN by T.Cass
    For some years, DXMINT had been the main central gateway for mail both within CERN and between CERN and the outside world, linking non-similar mail schemes and providing the Internet access. Now however, CERN believed it required a machine-independent mail scheme which permitted users moving between hosts, even between sites, to be able to access their mails from anywhere. Also, mail addresses should be independent of particular user hosts.

    The first attempt to satisfy this demand had been afsmail - storing the incoming mail spool in AFS which could then be read from any AFS client. However, use of Berkeley mail's flat file scheme for the inbox meant that the AFS file was read afresh with every incoming mail, hence continuous file transmission as the user's mail spool was updated; if the inbox was not cleared regularly this could, and did, generate a lot of AFS traffic. It did not scale.

    Use of IMAP as a mail protocol was much more efficient that AFS, only the headers were transferred as they changed until the user actually requested a specific mail. CERN had therefore installed a Digital UNIX Alpha twin host server with RAID discs as an IMAP-based mail server. The configuration included several fail-safe options and automatic failover of the discs. Incoming mails were stored on the server but once saved into a user's mail folder, they were transferred to files on the user's normal home directory, usually AFS. Today the service was IMAP2-based but there were plans for IMAP4. There was also some support for POP.

    Another feature of the Mail Server was that it generated so-called user-friendly addresses of the form Tony.Cass@cern.ch in the sender field automatically so that the recipient could reply to a host-independent address and the mail server would be able to deliver the reply wherever the originator accessed the server from.

  9. Mail List Server at CERN - M.Marquina
    Together with the above central mail server, CERN had recently introduced an AFS-based mail list distribution service based on the Majordomo package. This was to replace the popular LISTSERV service on the CERNVM IBM mainframe. The speaker explained the file layout of the new service including how AFS ACLs were used to protect the lists and permit list administrators to manipulate their own lists.

    A user interface package had been developed and was made independent of Majordomo, just in case the latter was later replaced by something newer and better. With this package, a list administrator could use his or her choice of editing or updating scheme, based for example on ORACLE, Filemaker Pro, a simple text editor, etc. Other tools were planned, including some using WWW.

    The service had been in production for some months and many users had already successfully migrated to it, including the LHC experiments.

  10. FNAL VMS Migration update by J.Nicholls
    Since the Prague meeting of HEPiX, UNIX use in Fermilab had increased rapidly with most major software packages being ported now. But use of VMS had remained fairly constant. Among the impediments to migration were cited

    The goal of the migration team was now to provide a home, either on UNIX or on a PC which was as comfortable as VMS. The migration task force included representatives from the major user groups and experiments. Communication within the community was considered very important and to this end UNIX User Meetings were held fortnightly although they had not yet attracted a lot of user interest. On the other hand, the first VMS to UNIX public meeting held in August had attracted a large audience.

    A VMS migration questionnaire had been issued to help identify the hot topics. People had been appointed to specific responsibilities such as mail, batch, editors, information schemes, etc. A training schedule was in preparation and they hoped to share material with other labs. The UNIX at FNAL Guide was being updated and a UNIXHelp scheme developed at Edinburgh University seemed to be interesting. All this was pulled together within the Web.

    For electronic mail, they would prefer something more advanced than Pine, perhaps based on mh, for example exmh. VMS to mh folder conversion tools existed.

    They expected most general VMS users to have migrated by the end of summer 1996 although some specific groups, (e.g. CMS and D0) were setting their own timetables.

  11. Report from the IEEE Mass Storage Meeting - C.Boeheim
    It had been a smaller meeting than usual with little new material since the previous occasion. Minor refinements were made to the Mass Storage Reference Model which was planned to be released to the vendors in Spring 1996. The question for HEP was, do we have any interest in this?

    Between the use of ATM and Fibrechannel switches, there was still no clear consensus. Both were featured but they had different target markets, different features, and different problems.

    At CHEP the previous week to the HEPiX meeting, J.Shiers and R.Melen had run a BOF on Mass Storage where it had been agreed that

  12. WABI - A Solution to Windows Access to UNIX - D.Fagan
    This was a report on an evaluation performed at FNAL. They had started with Softwindows to provide access to desktop office products from UNIX but found it to be incompatible with AFS on all platforms. Also, support for some specific fonts was missing, although the speaker agreed that use of a specialised font server might have helped here. Lastly, Softwindows had been found to be a major consumer of CPU cycles.

    The evaluation had then switched to WABI which appeared to have fewer limitations and offered better application performance. Licensing of WABI was free on SUNs but not on some other platforms.

Alan Silverman, 2 April 1996