4 Customizing the System Environment

This chapter describes how you can customize your system environment in the following areas:

System initialization files, which you use to initialize and control the system's run levels
National language directories, which you use to supply support for language-specific and country-specific programs
Internationalization features, which you tailor to support programmers and users developing and running programs for international audiences
System time zone directories and envrionment variables, which you use to administer local and worldwide time zone information on your system
System security tasks, which you employ to administer the security policy of your organization
Performance monitors, which you set up and use to measure diverse aspects of system performance
Power manager elements, which you set up and use to control power consumption in Energy Star-compliant peripherals and processors

4.1 Identifying and Modifying the System Initialization Files

To define and customize the system environment, you modify certain initialization files that specify and control processes and run levels. Digital UNIX provides you with default files that define the available run levels and the processes associated with each run level. You can easily change or customize the system environment by using these files as templates. In addition, if you support internationalization standards, you must be familiar with the structure and requirements of the corresponding files on your system.

This section describes the Digital UNIX software and provides instructions for identifying, using, and modifying the files that initialize and control the system environment. To understand and utilize available functionality, you should familiarize yourself with the init program and the specific files and commands associated with the program. Refer to the init(8) reference page for a description of the program and its behavior.

Before you make any changes to the system initialization files, you should examine the default setup, evaluate the needs of your system, and make a copy of the entire set of default files. Taking precautions is wise when making changes to system files or to files that alter the working environment. If you discover that your modifications do not create the environment that you intended, you can reinstate the default files while you fix the problems in your customization.

The following system files and directories influence system startup and operation:

/etc/inittab: One of the key initialization files whose entries define run levels and associated processes and administer terminals. Section 4.1.1 describes this file.
/etc/securettys: A text file that marks whether a given tty line allows root logins. Section 4.1.1.7 describes this file.
/sbin/bcheckrc: A system initialization run command script associated with checking and mounting file systems at startup time. Section 4.1.1.2 describes this file.
/sbin/init.d: The initialization directory that contains executable files associated with system startup and the available run levels. Section 4.1.2.1 describes the directory structure and contents.
/sbin/rcn .d: A set of individual directories that correspond to the various run levels. Each directory contains linked files that the system acts on when starting or changing a particular run level. There are three /sbin/rcn .d directories available: /sbin/rc0.d, /sbin/rc2.d, and /sbin/rc3.d. Section 4.1.2.2, Section 4.1.2.3, and Section 4.1.2.4 describe the rc directory structure and contents.
/sbin/rcn: The run command script that corresponds to a particular run level. There are three /sbin/rcn scripts available: /sbin/rc0, /sbin/rc2, and /sbin/rc3. Section 4.1.2.2, Section 4.1.2.3, and Section 4.1.2.4 describe the contents and use of these scripts.
/etc/rc.config: A file that contains run-time configuration variables. Scripts in the /sbin/init.d directory use these variables to configure various subsystems (for example, NFS or NTP). You (or a program) can use the rcmgr command to define or access variables in the /etc/rc.config file. Refer to the rcmgr(8) reference page and the Network Administration manual for more information.
/etc/sysconfigtab: The database file that contains information about the subsystems that can be dynamically configured. Chapter 5 describes this file.
/usr/sbin/getty: The executable file that sets and manages terminal lines. Section 4.1.1.4 and Section 4.1.1.5 describe this program. Refer to the getty(8) reference page for more information.
/etc/gettydefs: The file used by getty that contains entries to identify and define terminal line attributes. Refer to the gettydefs(4) reference page for more information.
/var/spool/cron/crontabs/*: The files that contain entries to identify and define the regular or periodic activation of specific processes. Refer to Section 4.1.3 for more information about these files.
/var/spool/cron/atjobs/*: The file that contains entries to identify and define the once-only activation of specific processes. See the at(1) reference page for more information.

The following files contain information on kernel configuration:

/usr/sys/conf/NAME: The text file that defines the components that the system builds into your configuration. The NAME variable usually specifies the system name. Chapter 5 describes this file.
/usr/sys/conf/NAME .list: The optional configuration file that stores information about the layered product subsystems and is used to automatically configure static subsystems. The NAME variable usually specifies the system name. Chapter 5 describes this file.
/usr/sys/conf/param.c: The text file that contains default values for some tunable system parameters used in building the system's kernel. Chapter 5 describes this file.

4.1.1 Using the /etc/inittab File

One of the first actions taken by the init program is to read the /etc/inittab file. The inittab file supplies the init program with instructions for creating and running initialization processes. The init program reads the inittab file each time init is invoked. The file typically contains instructions for the default initialization, the creation and control of processes at each run level, and the getty line process that controls the activation of terminal lines.

The Digital UNIX software provides you with a basic /etc/inittab file that contains line entries for the most common and necessary initialization processes. For example, the /etc/inittab file available with the distribution software would look similar to the following:

is:3:initdefault:
ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1
fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1
# Dynamic loading not supported in this release.
#kls:23:bootwait:/sbin/kloadsrv < /dev/console > /dev/console 2>&1
#cfg:23:wait:/sbin/cfgmgr -l < /dev/console > /dev/console 2>&1
update:23:wait:/sbin/update > /dev/console 2>&1
it:23:wait:/sbin/it < /dev/console > /dev/console 2>&1
kmk:3:bootwait:/sbin/kmknod > /dev/console 2>&1
s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
cons:1234:respawn:/usr/sbin/getty console console vt100
lat02:3:respawn:/usr/sbin/getty         /dev/tty02
lat03:3:respawn:/usr/sbin/getty         /dev/tty03

The inittab file is composed of an unlimited number of lines, each with four fields; each field is separated by a colon. The fields and syntax for entries in the inittab file are as follows:

Identifier: Runlevel: Action: Command

Identifier

This 14-character field uniquely identifies an object entry.

Runlevel

This 20-character field defines the run levels in which the object entry is to be processed. The Runlevel variable corresponds to a configuration of processes in a system. Each process spawned by the init command is assigned one or more run levels in which it is allowed to exist. The run levels are as follows:

`0`	Specifies the halt state
`s` or `S`	Specifies single-user mode
`2`	Specifies multiuser mode without network services
`3`	Specifies multiuser mode with network services

The Runlevel field can define multiple run levels for a process by specifying more than one run level character in any combination.

Action

This 20-character field tells init how to treat the specified process. The most common actions that init recognizes are as follows:

`respawn`	If the process does not exist or dies, `init` starts it. If the process currently exists, `init` does nothing and continues scanning the `inittab` file.
`wait`	When `init` enters a run level that matches the run level of the entry, it starts the process and waits for its termination. As long as `init` continues in this run level, it does not act on subsequent reads of the entry in the `inittab` file.
`bootwait`	When `init` first executes and reads the `inittab` file, it processes this line entry. The `init` program starts the process, waits for its termination and, when it dies, does not restart the process.
`initdefault`	A line with this action is processed when `init` is first invoked. The `init` program uses this line to determine which run level to enter. To do this, it takes the highest run level specified in the run-level field and uses that as its initial state. If the run-level field is empty, this is interpreted as 0s23, so `init` enters run level 3. If `init` does not find an `initdefault` line in the `inittab` file, it requests an initial run level from the operator.

Other action keywords are available and recognized by the init program. See the inittab(4) reference page for more information.

Command

This 1024-character field holds the sh command to be executed. The entry in the command field is prefixed with exec. Any legal sh syntax can appear in the command field.

You can insert comments in the inittab file by specifying a # (number sign) at the beginning of a line. You can also place a \ (line continuation character) at the end of a line.

If you intend to change or add entries to the /etc/inittab file, make certain that you are familiar with the function and contents of the associated files and run command scripts.

The following sections provide information that will help you to use the /etc/inittab file.

4.1.1.1 Specifying the Initialization Default Run Level

At boot time, the init program looks in the inittab file for the initdefault keyword to find the definition of the run level to enter. If there is no entry for initdefault, the system prompts you for a run level. In the previous inittab file example, the following line indicates that the run level for initdefault is set to 3, which is the multiuser with network services mode:

is:3:initdefault:

4.1.1.2 Specifying wait Run Levels

The init program looks in the inittab file for the wait entries. In the previous inittab file example, the following line contains a wait entry:

fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1

In this case, the init program invokes the /sbin/bcheckrc script for the fs entry. Processes associated with this entry execute at run levels 2 and 3. Input comes from the system console (/dev/console). System and process error messages are sent to the console (> /dev/console 2>&1).

The bcheckrc run command script contains procedures associated with file system checking and mounting. See the /sbin/bcheckrc file for details.

4.1.1.3 Specifying bootwait Run Levels

The init program looks in the inittab file for the bootwait entry. In the previous inittab file example, the following line contains a bootwait entry:

kmk:3:bootwait:/sbin/kmknod > /dev/console 2>&1

In this case, the init program invokes the /sbin/kmknod script for the kmk entry.

4.1.1.4 Specifying Console Run Levels

Before you or anyone else can log in to your system, the getty program for nonworksystems and the xdm program for worksystems must set up the process that runs the login and shell programs for each terminal and workstation, respectively. Because a large portion of your initial work is done at the system console, the /etc/inittab file contains an entry for setting up a getty process for the console. The xdm process is started with a run-level script in the /sbin/rc3.d directory.

In the previous example of the inittab file, the following line contains the entry for the system console:

cons:1234:respawn:/usr/sbin/getty console console vt100

The init program is instructed to invoke the getty program, which sets the terminal line attributes for the system console (/dev/console). The run-level field specifies that the getty process executes at run levels 1, 2, 3, and 4. The respawn keyword tells init to re-create the getty process if the active process terminates. If the process is active, init does not respawn the process; if it terminates, the process is re-created.

Note
In general, you should not modify the system console entry in the inittab file unless you want to limit the system console's access to different run levels. By placing limitations on the range of run levels for this terminal line, you risk disabling the system console if the system enters a run level that prohibits execution of the console's getty process.

4.1.1.5 Specifying Terminals and Terminal Run Levels

To enable user logins at each terminal supported by your system, you must maintain support for the terminal types available at your site and define the run level and getty process for each supported terminal type. Use the following database and file:

The /usr/lib/terminfo database (a symbolic link to /usr/share/lib/terminfo) defines the various terminal types.
Entries in the /etc/inittab file define the run level and getty process for the supported terminal types.

The Digital UNIX system supports a wide variety of terminal types. The terminfo database contains entries that describe each terminal type and its capabilities. The database is created by the tic program, which compiles the source files into data files. The terminfo source files typically consist of at least one device description that conforms to a particular format. See the terminfo(4) reference page for specific details on creating and compiling source files.

The /usr/lib/terminfo directory contains the source files, each of which has a .ti suffix, for example name.ti. After you compile the source files with the tic command, it places the output in a directory subordinate to /usr/lib/terminfo.

Various commands and programs rely on the files in these directories. Set your TERMINFO environment variable to the /usr/lib/terminfo directory to instruct programs that rely on the database for information to look there for relevant terminal information.

See the getty(8), gettydefs(4), and inittab(4) reference pages for information about defining terminal lines and managing terminal access.

4.1.1.6 Specifying Process Run Levels

Specific entries in the inittab file define the run command scripts that are to be executed when the system enters or changes to a particular run level. For example, the following inittab file entries specify the action to be taken by the init program at each of the available run levels:

ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1
s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1

These entries are associated with the rc directory structure and are discussed in detail in Section 4.1.2.

4.1.1.7 Securing a Terminal Line

The /etc/securettys file indicates to the system whether terminals or pseudoterminals can be used for root logins. To enable root logins on a terminal line, include the pathname in the /etc/securettys file. To enable root login on pseudoterminals, include the ptys keyword. You enable X displays for root login by including their display name, for example :0. By default, only the console and the X server line are set secure.

The following example of an /etc/securettys file shows root logins enabled on the console, on the X display, on two hard-wired or LAT lines, and on all pseudoterminals:

/dev/console
:0
/dev/tty00
/dev/tty01
ptys

4.1.2 Using the init and rc Directory Structure

The Digital UNIX system provides you with an initialization and run command directory structure. The structure has four main components: the init.d, rc0.d, rc2.d, and rc3.d directories. In addition, each of the rcn .d directories has a corresponding rcn run command script.

4.1.2.1 The init.d Directory

The /sbin/init.d directory contains the executable files associated with system initialization. For example, a listing of the directory contents would look similar to the following:

acct       inetd      motd       preserve    savecore   syslog
crashdc    kloadsrv   named      quota       sendmail   uucp
cron       kmod       nfs        recpasswd   settime    xdm
enlogin    lat        nfsmount   rmtmpfiles  sia        xntpd
gateway    loader     nis        route       snmpd
inet       lpd        paging     rwho        startlmf

4.1.2.2 The rc0.d Directory and rc0 Run Command Script

The /sbin/rc0 script contains run commands that enable a smooth shutdown and bring the system to either a halt state or single-user mode. As described previously, the inittab file contains entries that the init program reads and acts on when the system is shutting down to single-user mode (level s) or halting (level 0). For example:

ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1

Notice that in both cases, the rc0 script is the specified command. In addition to commands listed in the script itself, rc0 contains instructions to run commands found in the /sbin/rc0.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is being halted while others run if the system is being shut down and rebooted to single-user mode.

By convention, files in the /sbin/rc0.d directory begin with either the letter "K" or the letter "S" and are followed by a 2-digit number and a file name. For example, a long listing of the rc0.d directory contents would look similar to the following:

lrwxr-xr-x 1 root staff 17 Jan 04 10:31 K00enlogin -> ../init.d/enlogin
lrwxr-xr-x 1 root staff 13 Jan 04 10:44 K05lpd -> ../init.d/lpd
lrwxr-xr-x 1 root staff 13 Jan 04 10:51 K07lat -> ../init.d/lat
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K10inetd -> ../init.d/inetd
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K15snmpd -> ../init.d/snmpd
lrwxr-xr-x 1 root staff 13 Jan 04 10:31 K19xdm -> ../init.d/xdm
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K20xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root staff 14 Jan 04 10:31 K22cron -> ../init.d/cron
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 K25sendmail -> ../init.d/sendmail
lrwxr-xr-x 1 root staff 13 Jan 04 10:41 K30nfs -> ../init.d/nfs
lrwxr-xr-x 1 root staff 18 Jan 04 10:41 K35nfsmount -> ../init.d/nfsmount
lrwxr-xr-x 1 root staff 13 Jan 04 10:37 K38nis -> ../init.d/nis
lrwxr-xr-x 1 root staff 15 Jan 04 10:41 K40named -> ../init.d/named
lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K42rwho -> ../init.d/rwho
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K43route -> ../init.d/route
lrwxr-xr-x 1 root staff 17 Jan 04 10:37 K44gateway -> ../init.d/gateway
lrwxr-xr-x 1 root staff 16 Jan 04 10:31 K45syslog -> ../init.d/syslog
lrwxr-xr-x 1 root staff 14 Jan 04 10:52 K46uucp -> ../init.d/uucp
lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K50inet -> ../init.d/inet
lrwxr-xr-x 1 root staff 15 Jan 04 10:31 K52quota -> ../init.d/quota

In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." The numbering of commands in the /sbin/rc0.d directory is important since the numbers are sorted and the commands are run in ascending order.

See the rc0(8) reference page for additional information.

4.1.2.3 The rc2.d Directory and rc2 Run Command Script

The /sbin/rc2 script contains run commands that enable initialization of the system to a nonnetworked multiuser state, run level 2. As described previously, the inittab file contains entries that the init program reads and acts on when the system is booting or changing its state to run level 2. For example:

s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1

Notice that the rc2 script is the specified command. In addition to commands listed in the script itself, rc2 contains instructions to run commands found in the /sbin/rc2.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is booting, other commands run if the system is changing run levels.

By convention, files in the /sbin/rc2.d directory begin with either the letter "K" or the letter "S" and are followed by a 2-digit number and a file name. For example, a listing of the /sbin/rc2.d directory contents would look similar to the following:

lrwxr-xr-x 1 root staff 13 Jan 04 10:44 K00lpd -> ../init.d/lpd
lrwxr-xr-x 1 root staff 13 Jan 04 10:51 K03lat -> ../init.d/lat
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K05inetd -> ../init.d/inetd
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K10snmpd -> ../init.d/snmpd
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K15xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root staff 14 Jan 04 10:31 K20cron -> ../init.d/cron
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 K30sendmail -> ../init.d/sendmail
lrwxr-xr-x 1 root staff 13 Jan 04 10:41 K35nfs -> ../init.d/nfs
lrwxr-xr-x 1 root staff 18 Jan 04 10:41 K40nfsmount -> ../init.d/nfsmount
lrwxr-xr-x 1 root staff 13 Jan 04 10:37 K43nis -> ../init.d/nis
lrwxr-xr-x 1 root staff 15 Jan 04 10:41 K45named -> ../init.d/named
lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K47rwho -> ../init.d/rwho
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K48route -> ../init.d/route
lrwxr-xr-x 1 root staff 17 Jan 04 10:37 K49gateway -> ../init.d/gateway
lrwxr-xr-x 1 root staff 16 Jan 04 10:31 K50syslog -> ../init.d/syslog
lrwxr-xr-x 1 root staff 14 Jan 04 10:52 K51uucp -> ../init.d/uucp
lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K55inet -> ../init.d/inet
lrwxr-xr-x 1 root staff 15 Jan 04 10:31 K57quota -> ../init.d/quota
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S00savecore -> ../init.d/savecore
lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S05paging -> ../init.d/paging
lrwxr-xr-x 1 root staff 19 Jan 04 10:31 S10recpasswd -> ../init.d/recpasswd
lrwxr-xr-x 1 root staff 14 Jan 04 10:52 S15uucp -> ../init.d/uucp
lrwxr-xr-x 1 root staff 17 Jan 04 10:31 S25enlogin -> ../init.d/enlogin

In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." Commands that begin with the letter "K" run only when the system is changing run levels from a higher to a lower level. Commands that begin with the letter "S" run in all cases. The numbering of commands in the /sbin/rc2.d directory is important since the numbers are sorted and the commands are run in ascending order.

Refer to the rc2(8) reference page for more information.

4.1.2.4 The rc3.d Directory and rc3 Run Command Script

The /sbin/rc3 script contains run commands that enable initialization of the system to a networked multiuser state, run level 3. As described previously, the inittab file contains entries that the init program reads and acts on when the system is booting or changing its state to run level 3. For example:

s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1

Notice that the rc3 script is the specified command. In addition to commands listed in the script itself, rc3 contains instructions to run commands found in the /sbin/rc3.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is booting, other commands run if the system is changing run levels.

By convention, files in the /sbin/rc3.d directory begin with the letter "S" and are followed by a 2-digit number and a file name. For example, a long listing of the rc3.d directory contents would look similar to the following:

lrwxr-xr-x 1 root staff 14 Jan 04 10:37 S00inet -> ../init.d/inet
lrwxr-xr-x 1 root staff 15 Jan 04 10:31 S01quota -> ../init.d/quota
lrwxr-xr-x 1 root staff 14 Jan 04 10:52 S04uucp -> ../init.d/uucp
lrwxr-xr-x 1 root staff 17 Jan 04 10:31 S05settime -> ../init.d/settime
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S08startlmf -> ../init.d/startlmf
lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S10syslog -> ../init.d/syslog
lrwxr-xr-x 1 root staff 17 Jan 04 10:37 S11gateway -> ../init.d/gateway
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S12route -> ../init.d/route
lrwxr-xr-x 1 root staff 14 Jan 04 10:37 S13rwho -> ../init.d/rwho
lrwxr-xr-x 1 root staff 15 Jan 04 10:41 S15named -> ../init.d/named
lrwxr-xr-x 1 root staff 13 Jan 04 10:37 S18nis -> ../init.d/nis
lrwxr-xr-x 1 root staff 18 Jan 04 10:41 S20nfsmount -> ../init.d/nfsmount
lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S22loader -> ../init.d/loader
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S23kloadsrv -> ../init.d/kloadsrv
lrwxr-xr-x 1 root staff 14 Jan 04 10:31 S24kmod -> ../init.d/kmod
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S25preserve -> ../init.d/preserve
lrwxr-xr-x 1 root staff 13 Jan 04 10:31 S26sia -> ../init.d/sia
lrwxr-xr-x 1 root staff 20 Jan 04 10:31 S30rmtmpfiles -> ../init.d/rmtmpfiles
lrwxr-xr-x 1 root staff 13 Jan 04 10:41 S35nfs -> ../init.d/nfs
lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S40sendmail -> ../init.d/sendmail
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S45xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S50snmpd -> ../init.d/snmpd
lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S55inetd -> ../init.d/inetd
lrwxr-xr-x 1 root staff 14 Jan 04 10:31 S57cron -> ../init.d/cron
lrwxr-xr-x 1 root staff 13 Jan 04 10:30 S58lat -> ../init.d/lat
lrwxr-xr-x 1 root staff 14 Jan 04 10:30 S60motd -> ../init.d/motd
lrwxr-xr-x 1 root staff 13 Jan 04 10:44 S65lpd -> ../init.d/lpd
lrwxr-xr-x 1 root staff 14 Jan 04 10:42 S75acct -> ../init.d/acct
lrwxr-xr-x 1 root staff 17 Jan 04 10:30 S80crashdc -> ../init.d/crashdc
lrwxr-xr-x 1 root staff 13 Jan 04 10:30 S95xdm -> ../init.d/xdm

Usually, only commands that begin with the letter "S" are placed in the rc3.d directory. By default, run level 3 is the highest run level. The numbering of commands in the /sbin/rc3.d directory is important since the numbers are sorted and the commands are run in ascending order.

Refer to the rc3(8) reference page for more information.

4.1.3 Using the crontabs Directory

The crontab command submits a schedule of commands to the cron system clock daemon. The cron daemon runs shell commands according to the dates and times specified in the files in the /var/spool/cron/crontabs directory. Commands that you want to run on a regular schedule are in these files. Commands that you want to run only once are in the /var/spool/cron/atjobs/* files and are submitted with the at command.

The following example of an entry from a file in the /var/spool/cron/crontabs directory specifies that the runacct command runs at 2:00 a.m., Monday through Saturday, and output is sent to the /var/adm/acct/nite/fd2log file:

   [1]                    [2]                      [3]
0 2 * * 1-6 /usr/sbin/acct/runacct > /var/adm/acct/nite/fd2log&

Each entry has the following syntax:

--> Specifies the minutes past the hour, the hour, day of month, month, and day of week. Note that for the day of week, the value 0 (zero) indicates Sunday, the value 1 indicates Monday, and so on. You can specify a single value, more than one value separated by commas, or two values separated by a dash (-) to indicate a range of values. You can also specify an asterisk (*) to indicate no specific value. For example, if an asterisk (*) is specified for the hour, the command is run every hour.
--> Specifies the command to be executed at the specified time.
--> Specifies, optionally, arguments to the command.

To add a comment to a file, specify a # (number sign) at the beginning of the line.

The files in the /var/spool/cron/crontabs directory are named for system users, and the commands in the files are run under the authority of the user. For example, the commands in the adm file are run under adm authority.

To use the crontab command, you must be the user that matches the file name you want to act upon. For example, if you are user adm and you run the crontab command, the action is performed on the /var/spool/cron/crontabs/adm file.

To submit commands to the cron daemon to be run under adm authority:

Become user adm.
Enter the crontab command with the -l option to copy the /usr/spool/cron/crontabs/adm file to a temporary file in your home directory.
```
% crontab -l > temp_adm
```
Edit the temporary file and add the commands you want to run at a specified time.
Enter the crontab command and specify the temporary file to submit the commands to the cron daemon.
```
% crontab temp_adm
```

The /var/adm/cron/log file contains a history of the commands executed by the cron daemon. This file should be monitored to prevent it from becoming excessively large.

Refer to the crontab(1) reference page for more information.

4.2 Identifying and Managing National Language Support Directories and Files

Digital UNIX provides language-specific and country-specific information or support for programs.

The support components that concern you most directly as system administrator are the directories and files that reside at /usr/lib/nls.

An internationalized system presents information in a variety of ways. The word "locale" refers to the language, territory, and code set requirements that correspond to a particular part of the world. The system stores locale-specific data in two kinds of files:

Locale files, which contain month and day names, date formats, monetary and numeric formats, valid yes/no strings, character classification data, and collation sequences. These files reside in the /usr/lib/nls/loc directory.

Message catalogs, which contain translations of messages used by programs. These files reside in the /usr/lib/nls/msg/locale-name directory.

Table 4-1 lists the locales moved to the /usr/lib/nls/loc directory when you install the optional Single-Byte European Locales subset. Additional locales are installed by language variant subsets with special licensing requirements.

Table 4-1: Locale Support Files
Language/Territory	Locale Filename
Danish-Denmark	da_DK.ISO8859-1
Dutch-Netherlands	nl_NL.ISO8859-1
Dutch_Belgium	nl_BE.ISO8859-1
English_U.K	en_GB.ISO8859-1
English_U.S.A.	en_US.ISO8859-1
Finnish-Finland	fi_FI.ISO8859-1
French_Belgium	fr_BE.ISO8859-1
French_Canada	fr_CA.ISO8859-1
French_France	fr_FR.ISO8859-1
French_Switzerland	fr_CH.ISO8859-1
German_Belgium	de_BE.ISO8859-1
German_Germany	de_DE.ISO8859-1
German_Switzerland	de_CH.ISO8859-1
Greek-Greece	el_GR.ISO8859-7
Italian-Italy	it_IT.ISO8859-1
Norwegian-Norway	no_NO.ISO8859-1
Portuguese-Portugal	pt_PT.ISO8859-1
Spanish-Spain	es_ES.ISO8859-1
Swedish-Sweden	sv_SV.ISO8859-1
Turkish-Turkey	tr_TR.ISO8859-1

Note
The /usr/lib/nls/loc directory also contains environment tables (.en files), character tables (.8859* files), and DEC variants (@DEC files) that correspond to some of the files listed in Table 4-1. These tables and variants are provided only to ensure system compatibility for old programs and should not be used by new applications.

4.2.1 Setting Locale

The default system-wide locale for internationalization is the C locale. The default system-wide locale is the one that the setlocale function uses when a user does not set the internationalization environment variables, such as LANG, LC_COLLATE, and so on.

To change the system-wide default locale for Bourne and Korn shell users, edit the /etc/profile file and include the name of the locale you want to be the system-wide default. The setlocale function will then use the locale specified in this file. Those using the C shell can set a system-wide locale by editing the /etc/csh.login file and including the name of the locale you want to be the default system-wide locale.

You can set the native locale to any of the locales in the /usr/lib/nls/loc directory.

To set a locale, assign a locale name to one or more environment variables in the appropriate shell startup file. The simplest way is to assign a value to the LANG environment variable because it covers all components of a locale.

Note
The C locale mentioned in Table 4-1 is the system default. The C locale specifies U.S. English and uses the 7-bit ASCII codeset. The main difference between the C locale and the U.S. English locale (en_US.ISO8859-1) is that the latter has enhanced error messages.

The following example sets the locale to French for the C shell in which it is invoked and for all child processes of that shell:

% setenv LANG fr_FR.ISO8859-1

If you want another shell to have a different locale, you can reset the LANG environment variable in that particular shell. The following example sets the locale to French for the Korn and Bourne shells:

$ LANG=fr_FR.ISO8859-1

$ export LANG

Note that setting the LANG environment variable on the command line sets the locale for the current process only.

In most cases, assigning a value to the LANG environment variable is the only thing you need to do to set the locale. This is because when you set the locale with the LANG environment variable, the appropriate defaults are automatically set for the following functions:

Collation
Character classification
Date and time conventions
Numeric and monetary formats
Program messages
Yes/no prompts

In the unlikely event that you need to change the default behavior of any of the previous categories within a locale, you can set the variable that is associated with that category. See the following section for more information.

4.2.2 Modifying Locale Categories

When you set the locale with the LANG environment variable, defaults are automatically set for the collation sequence, character classification functions, date and time conventions, numeric and monetary formats, program messages, and the yes/no prompts appropriate for that locale. However, should you need to change any of the default categories, you can set the environment variables that are associated with one or more categories.

Table 4-2 describes the environment variables that influence locale categories.

Table 4-2: Locale Environment Variables
Environment Variable	Description
LC_ALL	Overrides the setting of all other internationalization environment variables, including LANG.
LC_COLLATE	Specifies the collating sequence to use when sorting names and when character ranges occur in patterns.
LC_CTYPE	Specifies the character classification information to use.
LC_NUMERIC	Specifies the numeric format.
LC_MONETARY	Specifies the monetary format.
LC_TIME	Specifies the date and time format.
LC_MESSAGES	Specifies the language in which system messages will appear. In addition, specifies the strings that indicate ``yes'' and ``no'' in yes/no prompts.

As with the LANG environment variable, you can assign all of the category variables locale names. For example, suppose that your company's main language is Spanish. You can set the locale with the LANG environment variable for Spanish, but set the numeric and monetary format for U.S. English. To do this for the C shell, you would make the following variable assignments:

% setenv LANG es_ES.ISO8859-1

% setenv LC_NUMERIC en_US.ISO8859-1

% setenv LC_MONETARY en_US.ISO8859-1

Locale names may include @modifiers to indicate versions of the locales that meet special requirements for different categories.

For example, a locale might exist in two versions to sort data two ways: in dictionary order and in telephone-book order. Suppose your site is in France, uses the default French locale, and the standard setup for this locale uses dictionary order. However, your site also needs to use a site-defined locale that collates data in telephone-book order. You might set your environment variables for the C shell as follows:

% setenv LANG fr_FR.ISO8859-1

% setenv LC_COLLATE fr_FR.ISO8859-1@phone

The explicit setting of LC_COLLATE overrides LANG's implicit setting of that portion of the locale.

4.2.3 Limitations of Locale Variables

The LANG and LC_* environment variables allow you to set the locale the way you want it, but they do not protect you from mistakes. There is nothing to protect you from setting LANG to a Swedish locale and LC_CTYPE to a Portuguese locale.

Also, there is no way to tie locale information to data. This means that the system has no way of knowing what locale you set when you created a file, and it does not prevent you from processing that data in inappropriate ways later. For example, suppose LANG was set to a German locale when you created file foo. Now suppose you reset LANG to a Spanish locale and then use the grep command for something in foo. The grep command will use Spanish rules on the German data in the file.

4.2.4 Setting Environment Variables for Message Catalogs and Locales

To define the location of message catalogs, set the NLSPATH environment variable. The default path is as follows:

NLSPATH=/usr/lib/nls/msg/%L/%N:

In this example, %L specifies the current locale name, and %N specifies the value of name of the message catalog.

There is also a LOCPATH environment variable that defines the search path for locales. The default path is as follows:

LOCPATH=/usr/lib/nls/loc:

4.3 Customizing Internationalization Features

Digital UNIX is an internationalized operating system. Your site's planners determine which elements of the operating system's internationalization features, commonly called worldwide support features, are required. The worldwide support features are optional subsets that you can select during installation. Your job as an administrator is to set up and maintain these features for:

Software developers who produce internationalized applications
Users who run internationalized applications on your system

The Digital UNIX product provides three sources of information about worldwide support:

For a list of optional software subsets that support internationalization, see the Digital UNIX Installation Guide.
For information about setting up and maintaining an operating system environment for programmers who write internationalized software, see the Digital UNIX manual Writing Software for the International Market.
To set up and maintain your system for users of internationalized applications, see the SysMan graphical interface and click on the Configuration icon and then the internationalization icon. From the internationalization window, you can select tasks to configure or modify several of the worldwide support capabilities on your system.

4.4 Customizing Your Time Zone

Information about configuring your system's time zone is in Chapter 5. This section describes how to administer local and worldwide time zone information on your system.

Time zone information is stored in files in the /etc/zoneinfo directory. The /etc/zoneinfo/localtime file is linked to a file in the /etc/zoneinfo directory and specifies the local time zone. These files are linked during system installation, but, as superuser, you can change your local time zone by relinking the /etc/zoneinfo/localtime file. For example, the following command changes the local time zone to Canada's Atlantic time zone:

# ln -sf /etc/zoneinfo/Canada/Atlantic /etc/zoneinfo/localtime

The /etc/zoneinfo/sources directory contains source files that specify the worldwide time zone and daylight savings time information that is used to generate the files in the /etc/zoneinfo directory. You can change the information in the source files and then use the zic command to generate a new file in the /etc/zoneinfo directory. Refer to the zic(8) reference page for more information.

You can also change the default time zone information by setting the TZ environment variable in your .login file or shell environment file. If you define the TZ environment variable, its value overrides the default time zone information specified by /etc/zoneinfo/localtime. By default, the TZ variable is not defined.

The TZ environment variable has the following syntax:

stdoffset [dst[offset] [,start[/time], end[/time]]]

You can also specify the following syntax:

stdoffset [dst | [offset] ]

The TZ environment variable syntaxes have the following parameters:

std and dst

Specifies the three or more characters that designate the standard (std) or daylight savings time (dst) zone.

Note
Daylight savings time is called daylight summer time in some locales.

The dst variable is not specified, daylight savings time time does not apply. You can specify any uppercase and lowercase letters. A leading colon (:), comma (,), hyphen (-), plus sign(+), and ASCII NUL are not allowed.

offset

Specifies the value to be added to the local time to arrive at GMT. The offset variable uses 24-hour time and has the following syntax:

hh [ :mm [ :ss ]]

If you do not specify the offset variable after the dst variable, daylight savings time is assumed to be 1 hour ahead of standard time. You can specify a minus sign (-) before the offset variable to indicate that the time zone is east of the prime meridian; west is the default, which you can specify with a plus sign (+).

start and end

Specifies when daylight savings time starts and ends. The start and end variable has the following syntaxes:

Jj
n

Mm.w.d

In the first syntax, the j variable specifies the Julian day, which is between 1 and 365. The extra day in a leap year (February 29) is not counted.

In the second syntax, the n variable specifies the zero-based Julian day, which is between zero (0) and 365. The extra day in a leap year is counted.

In the third syntax, the m variable specifies the month number (from 1 to 12), the w variable specifies the week number (from 1 to 5), and the d variable specifies the day of the week (from 0 to 6), where zero (0) specifies Sunday and six (6) specifies Saturday.

time

Specifies the time, in local time, when the change occurs to or from daylight savings time. The time variable uses 24-hour time and has the following syntax: hh [ :mm [ :ss ] ]

The default is 02:00:00.

The following example of the TZ environment variable specification specifies:

EST (eastern standard time) specifies the standard time, which is 5 hours behind GMT.
EDT (eastern daylight time) specifies the daylight savings time, which is 4 hours behind GMT.
EDT starts on the first Sunday in April and ends on the last Sunday in October; the change to and from daylight savings time occurs at 2:00, which is the default time.

EST5EDT4,M4.1.0,M10.5.0

You can also specify the following syntax:

:pathname

The pathname variable specifies the pathname of a file that is in the tzfile file format and that contains the time conversion information. For example:

:US/Eastern

Refer to the tzfile(4) reference page for more information on the file format.

If the pathname begins with a slash (/), it specifies an absolute pathname; otherwise, the pathname is relative to the /etc/zoneinfo directory. If the specified file is unavailable or corrupted, the system defaults to the offset stored in the kernel tz structure.

The time zone formats differ for SVID 2 and SVID 3. For SVID 2, /usr/sbin/timezone creates the /etc/svid2_tz file. The contents of the TZ and TZC variables are based on the information you supply when you run /usr/sbin/timezone.

For SVID 3, the /etc/svid3_tz file is created during the installation process. The contents of the TZ variable is based upon answers you supply to time zone-related questions at installation time.

Refer to the timezone(3) reference page for more information.

Refer to Chapter 5 for information about configuring a time zone for your system.

4.5 Customizing System Security

The system security tasks of the administrator range from the protection of physical components of the system and its environment to the implementation of an organization's security policies.

Two manuals in the Digital UNIX documentation set describe security-related tasks. Refer to the following documents for information about administering local system security:

The Technical Overview briefly describes the security components of the Digital UNIX operating system.
The Security manual is the principal source of security-related information for Digital UNIX users, administrators, and programmers dealing with the security components. Use this manual to administer security on an Digital UNIX operating system.

4.6 Customizing Performance Monitors

This section discusses how to set up and use some of the performance monitoring components of the Digital UNIX operating system:

Monitoring Performance History
Performance Monitor
Digital UNIX performance monitoring commands and scripts

4.6.1 Monitoring Performance History Utility

The Monitoring Performance History (MPH) utility gathers timely and accurate information on the reliability and availability of the Digital UNIX operating system and its hardware environment.

MPH is a suite of shell scripts that copy error log and crash dump information twice per week. The information is automatically copied to Digital for analysis via Internet Mail. After analysis, reports are generated and distributed to the users of this information, namely Software and Hardware Engineering, Manufacturing, and Digital Services. This data is internally secure to Digital and will be used exclusively for monitoring purposes.

The MPH process is automatic, requiring no human intervention and no training. The installation time is approximately 10 minutes.

This software will not impact or degrade your system's performance. MPH runs as a background task, using very negligible CPU resources and is invisible to the user. The disk space required for the collected data and the application is approximately 300 blocks per system. This could be slightly higher in the case of a high number of errors.

Before running MPH, review the following information:

The Software Development Environment subset (OSFPGMR) must be installed.
The MPH software kit is contained in the mandatory base software subset OSFHWBASE400. This subset is installed automatically during the operating system installation.
Disk space requirements for MPH is approximately 100 blocks.
If the operating system needs to be shut down for any reason, an orderly shutdown process must be followed. Otherwise, you will have to restart the MPH script.

To run MPH on your system, complete the following steps:

Enter the following command to run the MPH script:
```
# MPH_OSF_018.CSH
```
Enter the information requested by the script.

Running the MPH_OSF_018.CSH script does the following:

Creates an MPH directory. The default directory location is /var/mph.
Updates the system crontab files to execute the MPH files at the appropriate times. The binary error log extractor runs daily at 2:00 a.m. The data is mailed to Digital at 3:00 a.m. every Wednesday and Sunday.

4.6.2 Performance Monitor

The Performance Monitor is a real-time performance monitor that allows you to detect and correct performance problems. You can display graphs and counters to monitor dozens of different system values, including CPU performance, memory usage, disk transfers, file-system capacity, network efficiency, and buffer cache hit rates. In addition, thresholds can be set to alert you to, or correct, a problem when it occurs, and archives of data can be kept for high-speed playback or compression into charts, showing resource usage trends.

The Performance Monitor is an optional subset in the Digital UNIX software kit. For information about establishing and using the Performance Monitor, see the Performance Monitor User's Guide.

4.6.3 Performance Manager

Performance Manager is a real-time performance monitor that allows users to detect and correct performance problems. Graphs and charts can show hundreds of different system values, including CPU performance, memory usage, disk transfers, file- system capacity, and network efficiency. Thresholds can be set to alert you to correct a problem when it occurs, commands can be run on multiple nodes from the graphical user interface, and archives of data can be kept for high-speed playback or long-term trend analysis. See the Installation Guide for information about this product.

4.6.4 UNIX Commands and Scripts

Many Digital UNIX commands and scripts can be used to establish and use good system monitoring practices. For information about these commands and scripts, see the Digital UNIX System Tuning and Performance Management manual.

4.7 Customizing Power Management

Use the dxpower utility, the sysconfig command, and sysconfigdb database to manage power-saving features on hardware subsystems, such as processors and peripherals, that employ power managment capabilities. With these utilities, you enable power management modes and specify the amount of time to wait before shutting off each component in order to save power.

4.7.1 Using the dxpower Utility's Graphical User Interface

If you have CDE installed on your system, you can open the dxpower power management utility by performing the following steps:

Click on the Application Manager icon.
Double click on the System_Admin application group icon.
Double click on the DailyAdmin application group icon.
Double click on the Power Management icon.

If you are not using CDE, you can start the dxpower utility from the command line as follows:

# /usr/bin/X11/dxpower

When the dxpower utility runs, a power management window is displayed on your screen. The window provides check boxes that you use to select modes of operation, and scales you use to specify dwell times.

For more information about how to use the dxpower utility, start the application and then click on the Help button in the lower right-hand corner of the window.

4.7.2 Implementing Power Management from the Command Line

You can control power management attributes from the command line by using sysconfig commands to manage the sysconfigdb database. For example, you will need to use these commands if you are activating power management for a system from a remote terminal or from a local console terminal.

If you activate the power management tools from a console terminal where CDE is not running, only the graphics_powerdown and graphics_off_dwell attributes apply. Changing the graphics_standby_dwell and graphics_suspend_dwell attribute values has no effect. See Section 4.7.2.1 for descriptions of these attributes.

Caution
Do not attempt to use the sysconfig commands and dxpower simultaneously. If you do, you could encounter unpredictable behavior.

4.7.2.1 Changing the Power Management Values

To change the power management values that take effect every time you restart the kernel, you create a file in stanza file format. See stanza(4) for more information. The stanza-formatted file can contain the following power management attributes:

default_pwrmgr_state
The global power management state. Specify 1 to enable or 0 to disable this attribute.
cpu_slowdown
The current state of CPU slowdown. Specify 1 to enable or 0 to disable this attribute.
disk_dwell_time
The default dwell time, in minutes, for registered disks.
disk_spindown
The current state of disk spindown. Specify 1 to enable or 0 tor disable this attribute.
graphics_powerdown
The current state of graphics powerdown. Specify 1 to enable or 0 to disable this attribute.
graphics_standby_dwell
The default dwell time, in minutes, for standby Display power management Signaling (DPMS) mode. Specify a value of 0 to disable this attribute.
graphics_suspend_dwell
The default dwell time, in minutes, for suspend DPMS mode. Specify 0 to disable this attribute or specify a value greater than or equal to the value for graphics_standby_dwell.
graphics_off_dwell
The default dwell time, in minutes, for off DPMS mode. Specify 0 to disable this attribute or specify a value greater than or equal to the values for graphics_standby_dwell and graphics_suspend_dwell.

For example, you can create a stanza file called power_mgr.stanza that defines the following values for the attributes:

pwrmgr:
		default_pwrmgr_state=1
		cpu_slowdown=1
		disk_dwell_time=20
		disk_spindown=1
		graphics_powerdown=1
		graphics_standby_dwell=5
		graphics_suspend_dwell=10
		graphics_off_dwell=15

For the disk_dwell_time, graphics_standby_dwell, graphics_suspend_dwell, and graphics_off_dwell attributes, the specified values indicate the number of minutes to wait before powering down the idle hardware. In this case, the power management subsystem waits 20 minutes before disk spindown, and 5, 10, and 15 minutes before DPMS standby, suspend, and off modes, respectively. The remaining attributes, have a value of 1, which indicates that the function is enabled.

After you create and save the stanza file, enter the following command to update the /etc/sysconfigtab database:

# sysconfigdb -a -f power_mgr.stanza pwrmgr

See the sysconfigdb(8) reference page for more information.

4.7.2.2 Changing a Running Kernel or X Server

To change the values of attributes in the running kernel, use the sysconfig -r command. For example:

# sysconfig -r pwrmgr cpu_slowdown=0

You can change more than one attribute at a time, as shown in the following example:

# sysconfig -r pwrmgr graphics_powerdown=1 graphics_standby_dwell=10

See the sysconfig(8) reference page for more information.

See the dpms switches in the Xdec(1X) and xset(1X) reference pages for information about changing Display power management Signalling modes and values in the X Server.