Computer Center Proposal

Computer Center Proposal Jefferson Lab Common UNIX Environment (CUE)

Revision 4.1

The Jefferson Lab Common UNIX Environment (CUE) is designed to meet two primary goals:

Provide users with a common environment across the site involving minimal or no changes as the user moves back and forth between UNIX systems at Jefferson Lab--from the central scientific systems, to data acquisition, data reduction, or batch farm systems. The initial implementation addresses integration of SunOS (Solaris), AIX, and HP-UX systems only (Jefferson Lab's supported UNIX operating systems). Separate discussions with Linux users across the site will explore similar configuration of Linux systems (Linux is currently self supported only.)

Simplify and thereby enhance systems management.

The plan is to establish the Common UNIX Environment in early August, 1996, and migrate all of the specialized systems at the earliest possible date consistent with the accelerator operation schedule. A web page devoted to CUE is under development (http://www.cebaf.gov/ccc/cue/cue.html) and will contain status information as the environment is implemented on the site.

Major Elements of CUE (See Appendix A for a description of each element considered.)

The standard management of UNIX systems at Jefferson Lab will be consolidated around a robust, fault tolerant, central NFS fileserver (currently on order). This environment will potentially be migrated towards a wide area file system such as DFS when these products become robust and seamless for common user access. The CUE environment is currently being developed on a SunOS system.

The standard configuration for all UNIX servers and local workstations will be to configure a standard root partition (plus swap space) on a local disk and to mount a set of directory trees from the central fileserver. (See Section 1). There should be few exceptions to this configuration in order to maintain both a manageable operation as well as to provide a standard, site-wide configuration for Jefferson Lab users. The exceptions, which we will call Specialized Workgroup Clusters (SWC), are limited to those serving site critical functions such as on-line data acquisition which mandates their isolation from planned and unplanned interruptions. It is to the advantage of Jefferson Lab's users for these clusters also to maintain configurations consistent with CUE. (See Appendices B, C, and D for details of the implementation of directory and link structures for Standard CUE Systems, SWC servers and satellites).

1. Clustering: Except for Specialized Workgroup Clusters, all systems (both common use central systems and individual workstations) will conform to the following configuration:

Locally attached disk will contain: (a) standard, non-customized root partition appropriate for its platform (operating system) and version, including standard configurations for /usr/local and /opt; (b) swap space; (c) a NON-BACKED UP scratch area with any remaining disk space (/scratch).

/usr/local Contains all site-customizations including /usr/local/bin which contains a standard set of utilities (Perl, GNU, etc. See Section 8) (platform specific; distributed from /osroot/platform/version on the central fileserver. (Initial implementation of CUE may mount /usr/local from the central fileserver.)

/opt Contains all operating system vendor layered software (compilers, etc.). (Initial implementation of CUE may mount /opt from the central fileserver.)

/scratch Local scratch space. Owned by the group or primary user of the workstation. (NOT BACKED UP)

Mounted from the central file server or other hosts:

/apps Contains all software packages not in the standard set to be located in /usr/local/bin (See Section 4) (platform specific; mounted from /appsroot/platform on the central fileserver).

/home User home directories across the site (platform independent).

/var/mail Common site mail directories (platform independent;

/usr/spool/mail however, mounted appropriate to the platform from /mail on the central fileserver).

/workn See details in Sections 3 and 10 of the scratch and work disk pools to be implemented.

/net Contains mount points to support all of the network based directories above.

Specialized Workgroup Clusters (SWC) will vary slightly from this configuration:

A central standalone server will contain a full copy of the operating system plus provide alternate copies for some of the standard site directories listed above (/apps, /home). An individual satellite that participates in the SWC will be configured identically to a satellite configured for CUE with the exception that it will mount some of the above directories from the SWC server instead of the central fileserver.

Naming structures on Specialized Workgroup Clusters will follow the same pattern as Standard CUE systems, with some specific variations (See Appendix C):

/apps /apps will contain all applications stored locally on the SWC server. Satellites to a SWC server should also mount this area as /apps. Applications to be referenced from the central fileserver or other hosts should have soft links configured in the /apps directory pointing to /net/host/apps (remote host) or /net/fs1/apps/links (for the set of links to central applications). Note that some SWC servers may also custom locate applications in /usr/local directories.

/home /home will contain home directories for users who must work in a fully local mode in this cluster. Satellites to a SWC server should also mount this area as /home. Users with remote home directories should have soft links configured in the /home directory pointing to /net/host/home (remote host) or /net/fs1/home/links (for the set of links to central home directories).

/net/apps Pointer to /net/fs1/apps/links. A shorter path to reference applications on the central fileserver(s).

/net/home Pointer to /net/fs1/home/links. A shorter path to reference home directories on the central fileserver(s).

/net/host/... Other disk areas which have to be mounted from other hosts. (NOTE: The Computer Center strongly recommends that on-line data acquisition systems minimize remote mounts to avoid interruptions to on-line operations when remote systems are down.)

Using this configuration, all Third Party packages can be installed at one location (/apps) and can be customized for a particular workgroup via group-customized login scripts. Workgroup areas will be located in the /home area (e.g. /home/clas, /home/theory, etc.). All requirements for additional disk space for a workgroup will be added to the central fileserver area (i.e. groups with large storage requirements should use their funds to add to the central site storage area as opposed to locating disks on group machines).

Upgrades to the operating system can be implemented by (a) upgrading a master node for each platform to be maintained by the Computer Center; and (b) upgrading and configuring one master satellite for each operating system and cloning the configuration to other systems. For this reason, there should be minimal variation to the configuration for satellite systems (host and IP name, ownership of /scratch, etc.) and in general no local disks other than the root/swap disk physically located on the local system. (In all cases, local disks on Standard CUE Systems will NOT BE BACKED UP.)

2. Central File System/Home Directories: The Computer Center will implement a Central File Server environment on a commercial NFS fileserver (currently under procurement). These commercial fileservers are designed for high fault tolerance and high performance NFS operations. The Computer Center will maintain a spares kit on the site so that any mechanical failure can be repaired with little delay. These servers use RAID configurations and hot swap drives so that the failure of any one disk will not be noticed by users. The server will contain dual network interfaces so that it can be accessible directly to the backbone network as well as the experimental physics network.

NOTE: While this design of a central file server facilitates a standard, cross-platform environment for users, there are still several potential drawbacks in today's technology: All (most) user files will reside in this one location. This has ramifications in terms of network traffic load, I/O performance, effect to the site of any required downtime for the RAID system including job interruptions where files on the Central File System are accessed, and NFS mounting considerations. Our current experience with cross mounting disks is that any unscheduled interruption leaves "NFS server not responding" delays on systems that mount the now absent file system. Down the road we may be able to mitigate these effects through failover NFS capabilities and the implementation of DFS. However, from the beginning this consideration needs to be clearly recognized.

The Central File System (See Section 1) will contain (a) all user home directories; (b) central master copies of all site utilities (commercial as well as freeware, CERNLIB, etc.); (c) centralized mail directories; (d) centralized printer configuration files. The Central File System will be cross-platform in that a user will have one home directory for all HP-UX, SunOS (Solaris), and AIX systems.

An initial installation of the Central File System will implemented during FY96 by using a commercial NFS fileserver (under procurement). We expect this to be expanded during the next few years. A second generation implementation will be the migration to an OSF/DCE DFS (Distributed File System) environment which will be essential for Wide Area Network access to this file system. The use of an NFS-to-DFS Gateway may initially provide this access.

3. Naming conventions:

Directory naming conventions: See Section 1.

System naming conventions:

jlabxn Central, common use system. x refers to the platform (a=AIX, s=SunOS, h=HP-UX). n refers to a number. Examples: jlaba1, jlabs5, jlabh4. Note the Computer Center recommends that UNIX-based email be run only on jlab systems. (The Computer Center will continue to support POP mail and VMS mail at the current time.)

farmxn Similar naming structure for the off-line data reduction farm systems.

chdrxn Similar naming structure for the Counting House data reduction systems.

XXn Dedicated systems (not for general login). Examples: fs1 (fileserver #1), web2 (web server #2), mss1 (storage server #1), wk1 (mounts work disk pool areas ), etc.

Disk pool naming conventions:

/scratch Scratch area on the locally attached root/swap disk on a system. NOT BACKED UP. Not NFS mounted to other systems. No quotas. Intended for temporary storage use on the local CPU.

/work Large disk pool areas available to all CUE. NOT BACKED UP. Intended for temporary storage of copies of data already on the silo as well as other files. Disk space and directories allocated to various groups (experiments) and individual users.

/data temporary storage on local data acquisition systems for experimental raw data on its way to the STK silo.

Network interface naming conventions:

XXn-ll Systems that have multiple network interfaces will require a separate name for each interface. The standard name for these separate interfaces will follow this pattern. (e.g. mss1-ep for the interface on mss1 to the experimental physics LAN; mss1-bb for the interface on mss1 to the site backbone). The extensions for the current LAN segment are as follows:

bb site backbone LAN

ep experimental physics LAN

sa slow controls subnet for Hall A

sb slow controls subnet for Hall B

sc slow controls subnet for Hall C

vr VARC subnet

tc Trailer City subnet

Domain Name serving for systems with multiple LAN interfaces works according to a complex algorithm that includes whether you, the name server, and the target host are in the same LAN segment as well as the order in which definitions appear in the configuration files. In general, if you attempt to access a multi-interface system from the backbone (where the primary nameserver resides), you should be routed via the interface on the target host on the backbone. You can always specify a specific LAN interface by interface name when the routing path is critical.

4. Provisions for Multiple Versions / Access to Software Products: The Jefferson Lab Common UNIX Environment will combine the use of the "setup" product (written for site use to model the original FNAL version) plus support a limited number of public domain utilities in the platform-specific /usr/local/bin directories.

The products to be supported in /usr/local/bin are the current production versions of:

setup

perl

tk/tcl

The following GNU utilities: emacs, rcs, gcc, g++, gdiff, gmake, ghostview, ghostscript, gnuzip, gnuplot, bash, less, gawk, bison, find, and g77.

The actual binaries will be located in /usr/local/bin (which resides on the local system disk) as opposed to just links to some other location. All other commercial and public domain products as well as other (older or newer) versions of the above products will be supported via the setup utility. (The Computer Center anticipates that the soft link structure outlined in Appendices B,C,D will significantly enhance the performance of setup which will now find all applications under /apps. If necessary for performance, setup scripts could be relocated to a central directory -- /net/fs1/site/setups). The local configuration of /apps on a SWC server will insure that software replicated on a SWC server is accessed first.

From the users' perspective, they will have immediate access at standard locations to the production version of the above utilities (as well as the production version of CERNLIB, WWW, etc.) for the platform logged into, no matter where they login. To use an older or newer version of a product, for example, they will have to issue a setup command using the "setup product/version" syntax (e.g. setup perl/v4). To use some other product such as FrameMaker, the user will always have to issue a setup command.

From the administrator's perspective, each on-line version of the above products will still be maintained in the /apps directory so that we can provide setup access to it once it is superseded by a newer production version. Once testing of a new version is completed, the version will be implemented as the production version by (a) installing it appropriately on one master server for each platform; (b) creating a copy in the master /usr/local areas on the central file server; and (c) using rdist (or other software distribution tool) to distribute it to /usr/local/bin areas on local systems.

5. Cross Platform Environment: A standardized cross-platform environment will be supported by the use of: (a) the Central File Server for all home directories; (b) use of the /apps/product software structure (Software such as CERNLIB that stores codes and libraries under a "product/platform" structure will be visible to all platforms; only the platform-specific version of a code will be visible for software stored in the CUE model - "platform/product.") ; (c) standard system and user login scripts that will determine the current platform and initialize the appropriate environment for that platform; and (d) platform-aware setup scripts that will setup a package appropriately for the current platform.

The default user login script (.login, .cshrc, .profile) provided to each user will source (a) a standardized platform-aware login script (/site/etc/sylogin, /site/etc/sycshrc, /site/etc/syprofile) which will provide default Path initializations, terminal characteristics, Mail environment variables, file protection masks, etc.; and (b) a central setup script (/site/etc/sysapps) that will appropriately set up a number of common applications that most users will want to access, including CERNLIB, World Wide Web, news, and service (for Computer Center and Plant Services service requests). The sylogin script (or syprofile, depending on the selected shell) will be a standard script developed to determine the current platform logged into and configure the default environment appropriate to that platform.

Note that the default assumption for a user's Path is that /usr/local/bin comes before /usr/bin so that GNU utilities that duplicate the functionality of a UNIX binary with the same name (GNU diff vs. UNIX diff) will be used rather than the UNIX binary. Alternate system-wide scripts will also be available to users who prefer to have /usr/bin precede /usr/local/bin: /site/etc/sylogin.alt or /site/etc/syprofile.alt. The skeleton .login (or .profile) supplied to a user will document these two alternatives:

# The following line calls a system script to configure the default

# environment on this system, plus define your default path so that

# /usr/local/bin precedes /usr/bin to access GNU utilities by default over

# similarly named UNIX utilities (i.e. diff, make, etc.)

source /usr/local/etc/sylogin

# If you prefer to use standard UNIX utilities like diff & make, put a #

# before the "source" line above and remove the # in the next line:

# source /usr/local/etc/sylogin.alt.

# Below here, add any personal definitions you want to make.

...

Workgroup customizations will be implemented by the use of alternate login scripts to configure the environment appropriate to a workgroup as opposed to an alternate configuration of the actual CPUs used by a group. A workgroup whose needs vary from the general site needs can work with the Computer Center to develop an alternate set of login scripts for users in their workgroup.

6. Mail: Sendmail will be configured on all jlabxn systems so that users can send and receive UNIX-based mail directly from one of those systems. Mail daemons on systems other than jlabxn systems, will be configured to send mail via a jlabxn system. Common site mail directories, located on the central fileserver, will be mounted on local systems as /usr/spool/mail (HP-UX) or /var/mail (AIX,SunOS), depending on the platform. Users receiving their mail on on-site systems will be instructed to set a mail forward from the VMS-based cebaf.gov mailserver to one of the jlabxn systems (a user might for instance forward their mail to something like: username@jlabs1.cebaf.gov), however, mail daemons on local systems will be configured that that users can in actuality read and send email from their local host.Users should be cautioned to read their mail from one specific host only to avoid getting their mail files out of sync.

In the long run, "cebaf.gov" (as well as a new domain, jlab.org?) may be migrated to one of the master servers in the CUE. Available alternatives for mail interfaces include dtmail (CDE mail, See Section 11), Netscape mail, elm, and pine. The Computer Center will continue to explore alternatives for cross-platform mail interfaces to select one preferred mail interface to meet the needs of the largest cross section of users. While this mail interface would then be taught in user training courses, the other common mailers would still be supported for users preferring them. All mailers supported on CUE should use standard UNIX mail directory structures. Support will be maintained at Jefferson Lab for MIME, POP (Eudora, etc.), and eventually the IMAP4 mail standard.

7. Printing: Distributed print spooling will be managed by identifying one master print spooler for each platform (i.e. the master server for that platform), plus one special purpose print spooler system to handle printers requiring unique software configurations (Appletalk printers, etc.). The rdist (remote distribution) utility will be used to maintain consistency between the master print spooler and all other systems of the same type. This configuration will provide the capability to automate the addition of a new printer by (a) making changes to files in 3 locations - one for each supported platform; and (b) invoking rdist to propagate these printer definition files to all systems across the site. With certain exceptions, all printers should be available from all systems.

8. Supported Utilities: As budgets permit, the Computer Center will implement support on all three UNIX environments for a defined set of commercial products such as the following:

FrameMaker

Boston Business EDT+

Nu/TPU

Netscape

JAVA

IMSL

Mathematica

Workshop/Softbench

Centerline Suite: Testcenter/Objectcenter/Codecenter

Others? VMAIL? (does not support standard UNIX mail directories) Maple?

The following standard publicly available utilities will be supported on all three platforms:

CERNLIB

GNU utilities (see listing under #4)

Mosaic

Netnews

Perl

Tk/Tcl

TeX/Latex, xdvi, etc.

CVS

pdf, xpdf

Others? Python? nedit? xmgr? (recent requests)

9. Shells: The Jefferson Lab Common UNIX Environment will support both the C shell (csh and tcsh) and Bourne shell (sh). Most existing system scripts at Jefferson Lab (such as "setup") are written in csh, therefore the initial phase of the CUE will use only csh. The target date for full sh support is Oct. 1, 1996. As this environment is established on the site, the Computer Center will evaluate other shells, such as POSIX-based shells, that might be of value to the community.

10. Disk Quotas/Scratch Disks: The Central File System will provide disk space support for users at no cost to the Workgroup up to reasonable standard levels (10 MB is the default initial quota). A supervisor approved request for disk space up to 100 MB will generally be approved. Due to the costs involved not only for primary but also for backup storage, supervisors are strongly encouraged to monitor cost effective use of such primary storage. Users requiring over 100 MB must submit a formal Disk Resources Request form signed by their supervisor. Such requests may involve a funding requirement on the part of the Workgroup. Scratch and work disk pools will be provided (See Section 3) for temporary disk space for processing. These areas will NOT BE BACKED UP and will be purged on a regular basis to insure the availability of adequate processing space. Workgroups with very large disk requirements also have the option to add additional disk space to the central fileserver for their use.

11. X Configuration: The Jefferson Lab Common UNIX Environment will support the Common Desktop Environment (CDE) for X Windows support (which is based on Motif). The currently supported versions of the operating system for both the Sun (SunOS 5.5/Solaris 2.5) and IBM (AIX 4.1.4) systems already provide full CDE support. HP-UX 10.0 also provides this capability. (Central systems running HP-UX 9.x releases will be upgraded to 10.0 as soon as practical considering the compatibility with the on-line systems running HP-UX 9.x.) Support will be provided on all platforms for dtterm, the CDE version of xterm. A standard X configuration (including .Xdefaults, keymapping, fonts, etc.) will be developed to provide a default, usable, environment for each user on first login. Support for the less resource intensive (but more less full featured) fvwm windowing environment will be studied.

12. License Management: License servers for compilers, etc. will be run on multiple central servers to provide fault tolerant serving of central licenses. SWC servers should also serve as local license servers.

13. NIS/DNS: Defined central Computer Center servers will act as the central NIS server and Primary and Secondary Domain Name Servers. Each Specialized Workgroup Server should run both an NIS (Network Information Service) slave (for password file management) as well as a DNS slave server (for Domain Name resolution).

14. Backups: The SM-Arch backup application (commercial product) will be used to backup all files on the central fileserver and on SWC servers. NO BACKUP will be performed for any satellite system, which should not contain any specialized or user files. The backups will be integrated with the central mass storage silo so that the process can become entirely automated. System administrators will continue to monitor the operation to detect and correct any failures. Because backups of user data demand continuously replicated copies, the volume set(s) for system backups will be vaulted on a scheduled basis.

15. Security: The Computer Center is currently testing an OSF/DCE cell, particularly to enable the distributed file system, DFS. DCE includes an authentication capability based on Kerberos Version 5. During the coming months, as we evaluate the use of this product to provide authentication and central password management without the network transmission of clear text passwords, we will also monitor other product possibilities to provide such capabilities as central password management, password aging, password shadowing, and other functions to simplify yet improve secure access to Jefferson Lab's systems and data.

Another aspect of security is the management of system passwords. Because workstations across the site will boot into CUE, the root password for security reasons must be maintained only by the Computer Center. Specialized Workgroup Clusters, on the other hand, should have one or more individuals identified to the Computer Center as the primary contact(s). Wherever permitted by operating system restrictions, the workgroup contact(s) should manage the system (root) password, maintaining an accurate list of who has access to the root password, minimizing this list as much as possible, providing the password to the Computer Center whenever it is changed, and using appropriate measures to safeguard the password (i.e. keeping any written copy in a secure location, using hard-to-break passwords, and not logging into any root account via off-site Internet access). The Computer Center is responsible to insure that SWC root accounts do not have access to central or other SWC root accounts and files. While access to the workgroup root password is essential to allow the cluster contact to perform emergency system functions, standard system maintenance duties (adding users, system configurations, upgrades, and troubleshooting) should be performed by Computer Center personnel in coordination with the primary cluster contact.

16. Support for Off-Site Users: The Computer Center is committed to providing high quality, access to Jefferson Lab's computational resources and experimental data for off-site users. The recent upgrade of the LAN to a 100BaseT switched backbone and its interface to the ESnet T-3 through a high capacity network router is a first step in providing enhanced network access. The implementation of a Jefferson Lab DCE cell and the OSF Distributed File System (DFS) may potentially provide wide area access to site file systems. The Computer Center will provide import/export tape facilities to meet the tape standards in use across the Energy Research community (Exabyte, DAT, possibly DLT). Although non-supported CPU platforms cannot be fully integrated into the environment, provision will be made for file system space to store and distribute (anonymous ftp, etc.) physics codes and other files developed in the user community for these platforms. The development of advanced web-based applications promises to be one of the most effective avenues to provide user friendly access to collaborative information.

Users who plan to bring supported systems (SunOS (Solaris), AIX, HP-UX) onto the site should coordinate in advance with their Jefferson Lab sponsor to insure that property agreement, network attachment, licensing, and maintenance issues are addressed. These systems may be fully integrated into the CUE environment (which is required to NFS mount central home directories, applications, and work areas), but in this case, the local disk must be configured according to the CUE standard. With advance notice and planning, the Computer Center will copy existing local disk contents to tape and build the CUE environment on the system. Note that in this fully integrated model, the local user will not have access to root. Users who for whatever reason cannot conform to this model, will still be allocated an IP address and physically attached to the network. Systems in this model can only access the CUE environment through login to a CUE host. In this case, the local user is responsible for all system management and backup duties, but must register their host with the Computer Center to insure that adequate security safeguards are addressed. A document outlining the specific requirements for User systems on the site (Bringing Computer Systems to Jefferson Lab: Guidelines for Jefferson Lab Users and their Sponsors) is under development.

Appendix A: Major Decision Areas

The following elements of the UNIX environment were considered in the development of the Common UNIX Environment (CUE) at Jefferson Lab:

1. Clustering: Should we use some version of a "dataless" client where some portion of the operating system for a workstation is actually stored on a workgroup server or should each system have a complete version of the operating system?

2. Central File System/Home Directories: How shall we configure home directories so the configuration is easy to understand, easily expandable, users have one home directory for all platforms, with the possible exception of maintaining a clear separation between the on-line systems and the central systems. Should there be one central file system for user files or local workgroup file systems/ user files as well? Where should we replicate major utilities like CERNLIB, GNU, etc.

3. Naming conventions for user disks, site-accessible software areas, etc.

4. Provisions for Multiple Versions / Access to Software Products: What should be in /usr/local/bin, /opt , etc.? Should we use setup or some modified version of a method to "setup" products?

5. Cross-Platform Environment: (Closely related to #2/#4) This includes developing the required scripts to configure the appropriate software environment for the platform logged into, as well as setting up the user's Path.

6. Mail: How can we set up mail to be seamless and easy for users yet clean and easy to manage and robust enough to survive system interruptions?

7. Printing: How can we configure central printing services to provide easy accessibility to printers for users yet simplify the steps to interface a printer to a large number of systems?

8. Supported Utilities: What publicly available utilities will be supported in the standard UNIX environment? What general commercial programs should we support across all platforms?

9. Shells: What shells will be supported?

10. Disk Quotas/Scratch Disks: Configurations and policies for disk usage on the central file system and servers.

11. X Configuration: How can we configure a clean, default, GUI environment for users including considerations such as the Common Desktop Environment, terminal type, keyboard definitions, etc.?

12. License Management: Where should license managers run?

13. NIS/DNS: Where should we run NIS and slave NIS servers? DNS and slave DNS servers?

14. Backups: Configurations and policies for backups, assuming our migration of backups to use the STK silo.

15. Security: How can we enhance the security of our systems and data, but simplify password management and file access for users?

16. Support for Off-Site Users: What provisions can facilitate access to Jefferson Lab's computing resources and experimental data for off-site users and collaboration members?

Appendix B: Directory Structure for a Standard CUE System

Directories where all the files are located on the local hard disk: (All local disks on Standard CUE systems are identical with the exception of (a) the specific group which owns the /scratch partition, which may vary in size according to the disk size; and (b) the hostname and IP address in its network configuration. However, the structure is similar enough to that of a SWC server that alternate mount points and local work areas could be customized if absolutely critical.)

/bin {standard root directories}

/dev

/etc

/lib

/opt {compiler codes are stored locally, but access central license servers; in early implementations, may be a pointer to /net/fs1/opt}

/usr {/usr/local directories --bin,lib,etc-- contain the standard, platform-specific version customized by the Computer Center

... for Jefferson Lab; modifications to /usr/local/... are distributed by automated software distribution scripts.}

/scratch {owned by the local group; not NFS mounted; not backed up.}

Directories which are really only pointers. In many cases, these links provide a second level of abstraction to accommodate the possibility of multiple fileservers.

/var/mail {or /usr/spool/mail; pointer to /net/fs1/mail}

/apps {pointer to /net/fs1/apps/links}

/home {pointer to /net/fs1/home/links}

/work {pointer to /net/fs1/work/links}

/net/apps {pointer to /net/fs1/apps/links; for consistency with SWC server directory structure.}

/net/home {pointer to /net/fs1/home/links; for consistency with SWC server directory structure.}

Directories which are mount points for directories on the central fileserver(s) or other hosts:

/net/fs1/mail {central mail directory on fileserver fs1}

/net/fs1/usr/local {mount point for central copy of platform specific /usr/local. Eventually these files should be stored locally.}

/net/fs1/opt {mount point for central copy of platform specific /opt. Eventually these files should be stored locally.}

/net/fs1/apps {mount point for platform-specific applications. Contains the

links directory which has links to specific application directories; i.e. a softlink frame in /net/fs1/apps/links might point to /net/fs2/apps/frame if the application actually resides on fileserver fs2; a soft link cernlib, on the otherhand, will point to /net/fs1/site/cernlib}

/net/fs1/home {mount point for home directories on central fileserver. Contains

links directory of links to user directories: i.e. a soft link smith in /net/fs1/home/links might point to /net/fs2/home/smith if the actual home directory resides on fileserver fs2.}

/net/fs1/work {mount point for links directory containing links to work disk pool areas: i.e. a soft link expe98 in /net/fs1/work/links might point to /net/wk2/expe98, a group work directory actually located on the system wk2.}

/net/wkn/work mount point for work disk pool areas located on other hosts (wk1, wk2, etc.).

/net/fs1/site {mount point for platform-independent applications and scripts; in particular CERNLIB, cdev, CODA, etc.}

Appendix C: Directory Structure for a Specialized Workgroup Server

Directories where all of the files are stored on the local server disks:

/bin {standard root directories}

/dev

/etc

/lib

/opt {compiler codes are stored locally and access a local license server}

/usr {/usr/local directories may be customized to meet the requirements of the local work group.}

...

/scratch {local scratch space; not NFS mounted; not backed up.}

Directories which may contain actual files as well as pointers to remote directories:

/var/mail {or /usr/spool/mail; pointer to /net/fs1/mail}

/apps {contains directories of all locally stored applications. All applications stored locally and to be available for SWC satellites must be locally stored in /apps. Also, pointers for other applications stored on a central file server or other system. Examples: frame --> /net/fs1/apps/links/frame; coda --> /net/alcor/apps/coda}

/home {contains actual user home directories for some users. Users with remote home directories should contain either a link to /net/fs1/home/links or to some other host. Example: smith --> /net/fs1/home/links/smith; heyes --> /net/alcor/home/heyes}

/work {Could contain actual work disk pool directories for some users or groups. In this case, any remote work areas to be accessed will require specific pointers. Example: expe98 --> /net/fs1/work/links/expe98. Otherwise, could just be a pointer to /net/fs1/work/links.}

/net/apps {pointer to /net/fs1/apps/links. Alternate shorter name for central fileserver application areas.}

/net/home {pointer to /net/fs1/home/links. Alternate shorter name for central fileserver home areas.}

Directories which are mount points for directories on the central fileserver(s) or other hosts:

/net/fs1/mail {central mail directory on fileserver fs1}

/net/fs1/apps {mount point for platform-specific applications. Contains the

/net/host/apps {mount point for applications residing on some other host}

/net/fs1/home {mount point for home directories on central fileserver. Contains

links directory of links to user directories: i.e. a soft link smith in /net/fs1/home/links might point to /net/fs2/home/smith if the actual home directory resides on fileserver fs2.}

/net/host/home {mount point for home directory residing on some other host}

/net/host/work {mount point for work disk pool area residing on some other host}

/net/wkn/work mount point for work disk pool areas located on other hosts (wk1, wk2, etc.).

/net/fs1/site {mount point for platform-independent applications and scripts; in particular CERNLIB, cdev, CODA, etc.}

Appendix D: Directory Structure for a Specialized Workgroup Satellite

Directories where all the files are located on the local hard disk: (A SWC satellite should mirror the structure of a Standard CUE System as much as possible.)

/bin {standard root directories}

/dev

/etc

/lib

/usr {/usr/local directories --bin,lib,etc-- contain the standard, platform-specific version customized by the Computer Center

for Jefferson Lab; may be a version customized for the SWC; modifications to /usr/local/... are distributed by automated software distribution scripts.}

/opt {compiler codes are stored locally, but access license server on the SWC server}

...

/scratch {owned by the local group; not NFS mounted; not backed up.}

Directories which are really only pointers. In many cases, these links provide a second level of abstraction to accommodate the possibility of multiple fileservers. (swc = Specialized Workgroup Cluster server)

/var/mail {or /usr/spool/mail; pointer to /net/fs1/mail}

/apps {pointer to /net/swc/apps}

/home {pointer to /net/swc/home}

/work {pointer to /net/fs1/work/links}

/net/apps {pointer to /net/fs1/apps/links; shorter path to central fileserver applications}

/net/home {pointer to /net/fs1/home/links; shorter path to central fileserver home directories}

Directories which are mount points for directories on the central fileserver(s) or other hosts:

/net/fs1/mail {central mail directory on fileserver fs1}

/net/swc/apps {applications residing on the SWC server}

/net/fs1/apps {mount point for platform-specific applications. Contains the

/net/swc/home {home directories residing on the SWC server}

/net/fs1/home {mount point for home directories on central fileserver. Contains

links directory of links to user directories: i.e. a soft link smith in /net/fs1/home/links might point to /net/fs2/home/smith if the actual home directory resides on fileserver fs2.}

/net/wkn/work mount point for work disk pool areas located on other hosts (wk1, wk2, etc.).

/net/fs1/site {mount point for platform-independent applications and scripts; in particular CERNLIB, cdev, CODA, etc.}

This document is maintained by {helpdesk@jlab.org}