Chapter 4: The NERC File Structure

The NERC directory structure - the user view

The directories concerned are:

/users - home directories. This is the means by which a user has the same home directory, regardless of which host on the network he is logged on to. A user entry in the password file says his home directory is /users/[<group>]/<id.> and does not mention a host. The automounter and NIS are used to achieve this.

/nerc/.. - file system infrastructure.This is a 'virtual directory' on which are mounted all the specific NERC filestructures. It is created by the automounter, as are its subdirectories. It has one special subdirectory:


which is where applications software appears to users - after they have invoked a package it appears to be mounted on /nerc/packages/<packagename> no matter where it actually lives or which architecture it pertains to.
The 'setup' command which is the key component of the interface between users and applications software is built on this. In fact, iTSS applications supporters will not normally touch a host which does not have this in place!

/nerc/etc, /nerc/bin and the rest of /nerc

This is where all the scripts live which form the basis of vendor-independence. They are described in detail below.
 /data - separate data areas (may be communal)

/scratch - scratch areas ( not on all sites)

/working - working areas ( not on all sites)
Back to contents page

Vendors supported

In what follows there will be frequent reference to the <arch> variable. This is a NERC-specific definition which is related to the operating system and indicates a distinct flavour of executable. Vendor-independence is only possible if the vendors are recognised and catered for. New architectures are added as required but this is a rare occurrence now. Old ones are removed when the last such system is scrapped - unfortunately this is also not common so the list has grown.

The currently supported vendors and operating systems supported are:

alpha DEC ALPHA running Digital UNIX (previously known as OSF/1)

convex Convex running Convex OS V10

hpux Hewlett Packard running HPUX 8.07 and later

ip12 Silicon Graphics running IRIX 4.0x

irix Silicon Graphics running IRIX 5.1.1 and later

sun4 SUNs running Sunos 4.1.1 and later

solaris SUNs running Solaris 2.2 and later


Where /nerc is and how to reference it

The /nerc part of the NERC directory structure is installed on the NIS master of each domain as two directories ../master (e.g. /local/master) and ../`domainname` ( e.g. /local/windermere).

Back to contents page

 The physical NERC directory structure.

The NERC structure can be split into two distinct parts. One part, under ../master, is controlled and maintained by the central support groups and should NEVER be changed by the local administrator. This part of the structure contains domain- (site-) independent utilities written and maintained by the system support groups. This should be owned by the nercman id ( see below). There are a number of standard user ids and groups which will be activated when necessary.
 ../master - | - <arch> - | - bin
             |            | - man
             | - etc
             | - scripts

The second part of the structure, under `domainname`, contains the site-dependent material and is the responsibility of the local staff.
 ../`domainname` - | - domain - | - yp
                                | - startups
                                              | - exec

The 'logical' NERC directory structure.

Parts of the physical structure are mounted on an empty directory /nerc on each host, to give the logical structure. Thus the 'physical' structure can only be seen on the NIS master but the 'logical' structure can be seen from any host. This mounting is usually done by the automounter  but can be done with explicit mounts or even a symbolic link in special cases.

 /nerc - | - bin
         | - man
         | - etc
         | - scripts - | - newuser
         |             | - systems
         |  - <domainname> - | - yp
                             | - startups
                             | - exec

Back to contents page

Root Access and Passwords

Systems will be set up wherever possible in such a way that the root id will not be allowed to login directly, except on the console. Instead there will be a limited number of ids which can su to root. This is implemented, where possible, by listing the ids in the wheel group (sun) or equivalent. Other than the ability to "su" to root these userids have no special privileges. The list of such ids will be site-specific and set up by the local staff.

The root id password is controlled by the local staff but changes should be notified to Systems Group so that they can help in emergencies.

A small number of ids will be set up on the system as part of the initial installation. These include:

operator Used by systems admin scripts and for automated tasks. Its mail is often sent to another user using an alias.

susa Used by Systems Group for access to each site and with a password set by them. This id must be allowed to su to root.

nercman Used by Systems Group to own the "central" part of the /nerc struc ture.

These ids will be set up as normal users under the ncs group, not under /master. Usually susa is assigned a home directory on the NIS master, and may also have an entry in the /etc/passwd file on other hosts ( with a home directory of /tmp), so that it will be able to login if NIS and the automounter are not running. operator normally owns a data area /data/operator as well as its normal home directory.

There are also two aliases secman and confman needed by certain packages. At times certain packages will need root access but this should be done temporarily. We strongly discourage staff from using the root userid other than when strictly necessary for specific commands. It is simply too dangerous!

Back to contents page

System Directories and Files

/nerc/etc, /nerc/bin, /nerc/man

These directories contain scripts and the relevant man pages. /nerc/etc and /nerc/bin are both in the user's default PATH and /nerc/man is in his default MANPATH. These default paths and others are set up when /nerc/etc/cshrc is executed at login. /nerc/etc is common to all architectures while /nerc/bin has a different version for each architecture so it can contain binary executables. /nerc/man also has different versions for each architecture since there may be different utilities available.

/nerc/etc/cshrc, /nerc/etc/login

These scripts, executed by all C-shell users, are the basis of the NERC filestructure. They identify the host architecture ( using uname or the like) and provide this information as an environment variable to the user session. They also set up other variable and paths, and a few aliases, among which the most important is


which is used in conjunction with /nerc/etc/_setup, /nerc/bin/env_clean and /nerc/bin/setup_type to show which packages are available or to mount a specific one, executing any special code associated with that package to create environment variables or add to paths. It should be noted that currently most users have the C Shell as their default. The tcsh shell is also becoming popular and is the default at a few sites.

/nerc/etc/cshrc and /nerc/etc/cshrc are executed by all users, who are provided with .cshrc and .login files in their home directory which contain the line "source /nerc/etc/cshrc." or "source /nerc/etc/login". Users are free to add anything they like to their .cshrc file but are asked not to delete the "source.." line, similarly for .login and .logout. /nerc/etc/login displays the message-of-the day files, and /nerc/etc/logout simply sources the site-specific script if it exists and is not otherwise used.

Two versions of /nerc/etc/cshrc are provided, differing in their treatment of the backspace and. delete keys. One is called cshrc and the other cshrc.stdkeys. The former sets the delete key to be appropriate for the user's own keyboard, regardless of the architecture he is logged on to; the latter always sets it to be backspace ( except for keyboards such as DEC Alpha which have no backspace key). A site can choose which of these to make the default. In general this is likely to be the original cshrc if there is a preponderance of users with SUN keyboards, and to be cshrc.stdkeys if there are mostly Silicon Graphics or PC users.

Note that .login is not always executed, as for example if one logs in via Vista eXceed from a PC or from an X-terminal, and not (by default) under Solaris 2.5 CDE. It is wise therefore to have very little in your own or the site's .login, particularly not commands to start up Openwindows!

Back to contents page


stores scripts which are used in installing new systems, and for setting up new users. This is the 'systems group toolkit'. Users should not have any need to concern themselves with this branch.


Domain Dependent Directories and Files

Within the NERC structure there is a directory called /nerc/<domain> which holds files unique to that particular NIS domain and which the system administrator may edit frequently .


The motd.* files are 'message of the Day' files which are 'cat'ed when a user logs in motd.common is seen by everyone and motd.<architecture> is seen only by specific-architecture hosts. The files are simple text files which are supplied empty (usually!) just as a reminder that they are there. You can delete them without consequence.

/nerc/<domain>/cshrc, and /nerc/<domain>/login

These files are templates for the site administrator to edit and will be sourced, by all users on the NIS domain, If you have some commands or definitions which you want to make for all local users, put them in cshrc. On the other hand, be aware that whatever is in cshrc is executed every time a new shell is started and you should try to keep this script "lean and fast". /nerc/etc/login should ONLY cat the motd.* and not do anything else. There are arrangements on CDE and Xterminal logins to cat the motd even though they don't execute the user's .login.


This directory holds the domain specific NIS maps sources. The maps include:

passwd, group, hosts, netgroup

All the domain's users, groups and internet hosts are registered in these files. Netgroup is used for security .

Back to contents page

auto.packages<arch>,, auto.users

These are used by the automounter to implement the /users, /packages and /data directories.


In the directory /nerc/<domain>/startups live files with the same name as the startup script to be executed.Its existence (as an empty file) or its contents ( a list of hostnames) will define which hosts will execute the startup at boot time


Apart from the files and directories mentioned above local administrators may choose to put other files, or to keep local versions of system-supplied ones, in the /nerc/<domain> directory. Scripts to recycle various logs live here, as does frec-file which controls the frec utility for user execution of a limited set of predefined commands such as mounting a floppy disk or an optical disk.

Packages installed with the NERC filestructure


This directory is intended for home-grown software which is too small or simple to be a fully-fledged package and does not need any extra environment variables or paths set up. It has subdirectories bin, lib, man (and if needed, include). Like all packages it is architecture-dependent, and can reside anywhere on the site disks, being accessed by the automounter - its contents are not part of the centrally-maintained software. The directory /nerc/packages/local/bin is put into the user's default PATH, and /nerc/packages/local/man into his MANPATH, by /nerc/etc/cshrc.


This contains the centrally-maintained utilities which need X resources, such as xgopher, ghostscript, xmosaic and so on. It also includes others which do not need X ( such as perl) but are too small or simple to be a package by themselves, and do not need special environment variables. The directories /nerc/packages/utilities/bin and /nerc/packages/utilities/man are put into the user's default PATH and MANPATH respectively.

Simple /nerc File Structure

Sometimes it is necessary to implement a very simple version of the NERC file structure, for example if a machine is to be standalone for an exhibition. In this case NIS and the automounter are not used, and the system is configured as in the Logical Directory Structure, using only the directories relevant to that architecture, with a symbolic link from /nerc to .. /master. The interface to the users and application software is exactly the same as with the full /nerc file structure. Instructions  exist for doing this for Solaris and SunOS.

Back to contents page

This page last updated February 18th by