![[Return to Library]](BOOKSHLF.GIF)
![[TOC]](TOC.GIF)
![[PREV]](REW.GIF)
![[NEXT]](FF.GIF)
![[INDEX]](INDEX.GIF)
![[Help]](HELP.GIF)
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
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:
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:
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
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.
The bcheckrc run command script contains procedures
associated with file system checking and mounting. See the /sbin/bcheckrc file for details.
In the previous example of the inittab file, the
following line contains the entry for the system console:
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.
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
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
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:
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:
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
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:
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
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:
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
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:
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:
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
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 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.
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.init(8)
reference page for a description of the program and its behavior.
rcmgr(8) reference page
and the Network Administration manual for more information. getty(8) reference page for more information.gettydefs(4)
reference page for more information. at(1) reference page for
more information.
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.
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
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.
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).
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.
cons:1234:respawn:/usr/sbin/getty console console vt100
Note
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:
terminfo(4) reference
page for specific details on creating and compiling source files.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.
/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
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
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
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
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
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
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.
[1] [2] [3]
0 2 * * 1-6 /usr/sbin/acct/runacct > /var/adm/acct/nite/fd2log&
% crontab -l > temp_adm
% crontab temp_adm
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 /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. Note
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.
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.
Table 4-2 describes the environment variables
that influence locale categories.
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.Note
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.
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.
% 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@phoneThe explicit setting of LC_COLLATE overrides LANG's implicit setting of that portion of the 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.
There is also a LOCPATH environment variable that defines the search
path for locales. The default path is as follows:
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:
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
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:
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 (+).
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:
: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:
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
Refer to Chapter 5 for information about configuring
a time zone for your system.
Two manuals in the Digital UNIX documentation set describe security-related
tasks. Refer to the following documents for information about administering
local system security:
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:
Running the MPH_OSF_018.CSH script does the following:
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.
If you are not using CDE, you can start the dxpower
utility from the command line as follows:
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.
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.
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.
After you create and save the stanza file, enter
the following command to update the /etc/sysconfigtab database:
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.
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.
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:
The Digital UNIX product provides three sources of information
about worldwide support:
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.
# ln -sf /etc/zoneinfo/Canada/Atlantic /etc/zoneinfo/localtime
zic(8) reference page
for more information.
Note
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.hh [ :mm [ :ss ]]
Jj
n
Mm.w.d
EST5EDT4,M4.1.0,M10.5.0
You can
also specify the following syntax:
:US/Eastern
Refer to the tzfile(4) reference page for more information
on the file format.timezone(3) reference page for more information.
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.
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:
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_OSF_018.CSH
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.
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:
# /usr/bin/X11/dxpower
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.Caution
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:
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.
# sysconfigdb -a -f power_mgr.stanza pwrmgr
See the sysconfigdb(8) reference page for more information.