![[Return to Library]](BOOKSHELF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
This chapter describes how you can customize your system environment in the following areas:
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:
The following files contain information on kernel configuration:
![[Previous Section]](PREV.GIF)
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
| 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.
| 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.
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.
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:
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.
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.
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.
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 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.
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 3.1.2.
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
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.
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
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.
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.
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
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.
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.
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:
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:
%
crontab -l > temp_adm
%
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.
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:
Table 3-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.
| 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_SE.ISO8859-1 |
| Turkish-Turkey | tr_TR.ISO8859-9 |
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 3-1. These tables and variants are provided only to ensure system compatibility for old programs and should not be used by new applications.
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 3-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:
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.
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 3-2 describes the environment variables that influence locale categories.
| 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.
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.
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:
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:
The Digital UNIX product provides three sources of information about worldwide support:
Information about configuring your system's time zone is in Chapter 4. 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:
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.
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.
The default is 02:00:00.
The following example of the TZ environment variable specification specifies:
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 4 for information about configuring a time zone for your system.
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:
This section discusses how to set up and use some of the performance monitoring components of the Digital UNIX operating system:
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:
To run MPH on your system, complete the following steps:
#
MPH_OSF_018.CSH
Running the MPH_OSF_018.CSH script does the following:
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.
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.
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.
If you have CDE installed on your system, you can open the dxpower power management utility by performing the following steps:
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.
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 3.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.
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:
The global power management state. Specify 1 to enable or 0 to disable this attribute.
The current state of CPU slowdown. Specify 1 to enable or 0 to disable this attribute.
The default dwell time, in minutes, for registered disks.
The current state of disk spindown. Specify 1 to enable or 0 tor disable this attribute.
The current state of graphics powerdown. Specify 1 to enable or 0 to disable this attribute.
The default dwell time, in minutes, for standby Display power management Signaling (DPMS) mode. Specify a value of 0 to disable this attribute.
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.
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.
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.