Preface

The /usr/aset/masters directory contains several files used by the Automated Security Enhancement Tool (ASET). /usr/aset is the default operating directory for ASET. An alternative working directory can be specified by the administrators through the aset -d command or the ASETDIR environment variable. See aset(1M).

/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
/usr/aset/masters/uid_aliases
/usr/aset/masters/cklist.low
/usr/aset/masters/cklist.med
/usr/aset/masters/cklist.high

DESCRIPTION

These files are provided by default to meet the need of most environments. The administrators, however, can edit these files to meet their specific needs. The format and usage of these files are described below.

All the master files allow comments and blank lines to improve readability. Comment lines must start with a leading "#" character.

tune.low
tune.med
tune.high    These files are used by the tune task (see aset(1M)) to restrict the permis-

sion settings for system objects. Each file is used by ASET at the security level indicated by the suffix. Each entry in the files is of the form: pathname mode owner group type

where

pathname: is the full pathname

mode: is the permission setting

owner: is the owner of the object

group: is the group of the object

type: is the type of the object It can be symlink for a sym-

bolic link, directory for a directory, or file for every-

thing else.

Regular shell wildcard ("* ","?", ...) characters can be used in the pathname for multiple references. See sh(1). The mode is a five-digit number that represents the permission setting. Note that this setting represents a least restrictive value. If the current setting is already more restrictive than the specified value, ASET does not loosen the permission settings.

For example, if mode is 00777 ,the permission will not be changed, since it is always less restrictive than the current setting.

Names must be used for owner and group instead of numeric ID's. ? can be used as a "don't care" character in place of owner, group, and type to prevent ASET from changing the existing values of these parameters.

uid_alias

This file allows user ID's to be shared by multiple user accounts. Normally, ASET discourages such sharing for accountability reason and reports user ID's that are shared. The administrators can, however, define permissible sharing by adding entries to the file. Each entry is of the form:

For example, if sync and daemon share the user ID 1 ,the corresponding entry is:

uid: is the shared user id

alias?: is the user accounts sharing the user ID

                1=sync=daemon

audit.log - audit trail file

cklist.med
cklist.high

These files are used by the cklist task (see aset(1M)), and are created the first time the task is run at the low, medium, and high levels. When the cklist task is run, it compares the specified directory's contents with the appropriate cklist.level file and reports any discrepancies.

EXAMPLES

The following is an example of valid entries for the tune.low, tune.med, and tune.high files:

/bin       00777      root       staff      symlink
/etc       02755      root       staff      directory
/dev/sd*   00640      root       operator   file

NAME

SYNOPSIS

#include <bsm/audit.h>

#include <bsm/audit_record.h>

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

audit.log files are the depository for audit records stored locally or on an audit server. These files are kept in directories named in the file audit_control(4). They are named to reflect the time they are created and are, when possible, renamed to reflect the time they are closed as well. The name takes the form

        yyyymmddhhmmss.not_terminated.hostname
when open or if the auditd(1M) terminated ungracefully, and the form
        yyyymmddhhmmss. yyyymmddhhmmss. hostname

when properly closed. yyyy is the year, mm the month, dd day in the month, hh hour in the day, mm minute in the hour, and ss second in the minute. All fields are of fixed width.

The audit.log file begins with a standalone file token and typically ends with one also. The beginning file token records the pathname of the previous audit file, while the ending file token records the pathname of the next audit file. If the file name is NULL the appropriate path was unavailable.

The audit.log files contains audit records. Each audit record is made up of audit tokens. Each record contains a header token followed by various data tokens. Depending on the audit policy in place by auditon(2), optional other tokens such as trailers or sequences may be included.

The tokens are defined as follows:

The file token consists of:: token ID

char

seconds of time: u_int

milliseconds of time: u_int

file name length: short

file pathname: null terminated string

The header token consists of:: token ID

char

record byte count: u_long

version #                        char     (1)
event type                       u_short
event modifier                    u_short
seconds of time                  u_int
milliseconds of time             u_int

The trailer token consists of:: token ID

trailer magic number: u_short

record byte count: u_long

The arbitrary data token is defined:: token ID

how to print: char

basic unit: char

unit count: char

data items: depends on basic unit

The in_addr token consists of:: token ID

internet address: long

The ip token consists of:: token ID

version and ihl: char

type of service: char

length: short

id: u_short

offset: u_short

ttl: char

protocol: char

checksum: u_short

source address: long

destination address: long

The iport token consists of:: token ID

port address: short

The opaque token consists of:: token ID

size: short

data: char, size chars

The path token consists of:: token ID

path length: short

path: null terminated string

The process token consists of:: token ID

auid: u_long

euid: u_long

egid: u_long

ruid: u_long

rgid: u_long

pid: u_long

sid: u_long

terminal ID: u_long (port ID)

u_long (machine ID)

The return token consists of:: token ID

error number: char

return value: u_int

The subject token consists of:: token ID

auid: u_long

euid: u_long

egid: u_long

ruid: u_long

rgid: u_long

pid: u_long

sid: u_long

terminal ID: u_long (port ID)

u_long (machine ID)

The System V IPC token consists of:: token ID

object ID type: char

object ID: long

The text token consists of:: token ID

text length: short

text: null terminated string

The attribute token consists of:: token ID

mode: u_long

uid: u_long

gid: u_long

file system id: long

node id: long

device: u_long

The groups token consists of:: token ID

number: short

group list: long, size chars

The System V IPC permission token consists of:: token ID

uid: u_long

gid: u_long

cuid: u_long

cgid: u_long

mode: u_long

seq: u_long

key: long

The arg token consists of:: token ID

argument #: char

argument value: long

string length: short

text: null terminated string

The exec_args token consists of:: token ID

count: short

text: count null terminated string(s)

The exec_env token consists of:: token ID

count: short

text: count null terminated string(s)

The exit token consists of:: token ID

status: long

return value: long

The socket token consists of:: token ID

socket type: short

local port: short

local Internet address: long

remote port: short

remote Internet address: long

The seq token consists of:: token ID

audit_class - audit class definitions

sequence number: long

NOTES

Each token is generally written using the au_to (3)family of function calls.

audit_class(4)

NAME

SYNOPSIS

/etc/security/audit_class

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

/etc/security/audit_class is an ASCII system file that stores class definitions. Programs use the getauclassent(3) routines to access this information.

The fields for each class entry are separated by colons. Each class entry is a bitmap and is separated from each other by a newline.

Each entry in the audit_class file has the form:

mask: name: description

The fields are defined as follows:

mask: The class mask.

name: The class name.

description: The description of the class.

The classes are now user-configurable. Each class is represented as a bit in the class mask which is an unsigned integer. Thus, there are 32 different classes available, plus two meta-classes -- all and no.

all represents a conjunction of all allowed classes, and is provided as a shorthand method of specifying all classes.

no is the "invalid" class, and any event mapped solely to this class will not be audited. (Turning auditing on to the all meta class will NOT cause events mapped solely to the no class to be written to the audit trail.)

EXAMPLES

Here is a sample of a audit_class file:

0x00000000:no:invalid class
0x00000001:fr:file read
0x00000002:fw:file write
0x00000004:fa:file attribute access
0x00000008:fm:file attribute modify
0x00000010:fc:file create
0x00000020:fd:file delete
0x00000040:cl:file close
0xffffffff:all:all classes

FILES

/etc/security/audit_class

NOTES

It is possible to deliberately turn on the no class in the kernel, in which case the audit trail will be flooded with records for the audit event AUE_NULL.

audit_control(4)

NAME

audit_control - control information for system audit daemon

SYNOPSIS

/etc/security/audit_control

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

The audit_control file contains audit control information used by auditd(1M). Each line consists of a title and a string, separated by a colon. There are no restrictions on the order of lines in the file, although some lines must appear only once. A line beginning with `# ' is a comment.

Directory definition lines list the directories to be used when creating audit files, in the order in which they are to be used. The format of a directory line is:

dir: directory-name

directory-name is where the audit files will be created. Any valid writable directory can be specified.

The following configuration is recommended:

/etc/security/audit/server/files

where server is the name of a central machine, since audit files belonging to different servers are usually stored in separate subdirectories of a single audit directory. The naming convention normally has server be a directory on a server machine, and all clients mount /etc/security/audit/server at the same location in their local file systems. If the same server exports several different file systems for auditing, their server names will, of course, be different.

There are several other ways for audit data to be arranged: some sites may have needs more in line with storing each host's audit data in separate subdirectories. The audit structure used will depend on each individual site.

The audit threshold line specifies the percentage of free space that must be present in the file system containing the current audit file. The format of the threshold line is:

minfree: percentage

where percentage is indicates the amount of free space required. If free space falls below this threshold, the audit daemon auditd(1M) invokes the shell script audit_warn(1M). If no threshold is specified, the default is 0%.

The audit flags line specifies the default system audit value. This value is combined with the user audit value read from audit_user(4) to form the process audit state. The user audit value overrides the system audit value. The format of a flags line is:

flags:audit-flags

where audit-flags specifies which event classes are to be audited. The character string representation of audit-flags contains a series of flag names, each one identifying a single audit class, separated by commas. A name preceded by `-' means that the class should be audited for failure only; successful attempts are not audited. A name preceded by `+' means that the class should be audited for success only; failing attempts are not audited. Without a prefix, the name indicates that the class is to be audited for both successes and failures. The special string all indicates that all events should be audited; -all indicates that all failed attempts are to be audited, and +all all successful attempts. The prefixes ^, ^-, and ^+ turn off flags specified earlier in the string (^- and ^+ for failing and successful attempts, ^ for both). They are typically used to reset flags.

The non-attributable flags line is similar to the flags line, but this one contain the audit flags that define what classes of events are audited when an action cannot be attributed to a specific user. The format of a naflags line is:

naflags: audit-flags

The flags are separated by commas, with no spaces.

The following table lists the predefined audit classes:

short name      long name       short description
no              no_class        null value for turning off event preselection
fr              file_read        Read of data, open for reading, etc.
fw              file_write       Write of data, open for writing, etc.
fa              file_attr_acc    Access of object attributes: stat, pathconf, etc.
fm              file_attr_mod    Change of object attributes: chown, flock, etc.
fc              file_creation    Creation of object
fd              file_deletion    Deletion of object
cl              file_close       close(2) system call
pc              process         Process operations: fork, exec, exit, etc.
nt              network         Network events: bind, connect, accept, etc.
ip              ipc             System V IPC operations
na              non_attrib      non-attributable events
ad              administrative administrative actions: mount, exportfs, etc.
lo              login_logout    Login and logout events
ap              application     Application auditing
io              ioctl           ioctl(2) system call
ex              exec            exec(2) system call
ot              other           Everything else
all             all             All flags set

Note that the classes are configurable, see audit_class(4).

EXAMPLES

Here is a sample /etc/security/audit_control file for the machine eggplant:

dir: /etc/security/jedgar/eggplant
dir: /etc/security/jedgar.aux/eggplant
#
# Last-ditch audit file system when jedgar fills up.
#
dir: /etc/security/global/eggplant
minfree: 20
flags: lo,ad,-all,^-fm
naflags: lo,ad

This identifies server jedgar with two file systems normally used for audit data, another server global used only when jedgar fills up or breaks, and specifies that the warning script is run when the file systems are 80% filled. It also specifies that all logins, administrative operations are to be audited (whether or not they succeed), and that failures of all types except failures to access object attributes are to be audited.

FILES

/etc/security/audit_control

/etc/security/audit_warn
/etc/security/audit/* /* /*
/etc/security/audit_user

NAME

audit_data - current information on audit daemon

SYNOPSIS

/etc/security/audit_data

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

The audit_data file contains information about the audit daemon. The file contains the process ID of the audit daemon, and the pathname of the current audit log file. The format of the file is:

<pid>:<pathname>

Where pid is the process ID for the audit daemon, and pathname is the full pathname for the current audit log file.

EXAMPLES

64:/etc/security/audit/server1/19930506081249.19930506230945.bongos

FILES

/etc/security/audit_data

NAME

audit_event - audit event definition and class mapping

SYNOPSIS

/etc/security/audit_event

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

/etc/security/audit_event is an ASCII system file that stores event definitions and specifies the event to class mappings. Programs use the getauevent (3)routines to access this information.

The fields for each event entry are separated by colons. Each event is separated from the next by a newline.

Each entry in the audit_event file has the form:

number: name: description: flags

The fields are defined as follows:

number: The event number.

name: The event name.

description: The description of the event.

flags: Flags specifying classes to which the event is mapped.

EXAMPLES

Here is a sample of the audit_event file entries:

7:AUE_EXEC:exec(2):pc,ex
79:AUE_OPEN_WTC:open(2) - write,creat,trunc:fc,fd,fw
6152:AUE_login:login - success or failure:lo
6153:AUE_logout:logout:lo
6154:AUE_telnet:login - through telnet:lo
6155:AUE_rlogin:login - through rlogin:lo

FILES

/etc/security/audit_event

NAME

audit_user - per-user auditing data file

SYNOPSIS

/etc/security/audit_user

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

audit_user is an access-restricted ASCII system file that stores per-user auditing preselection data. Programs use the getauusernam(3) routines to access this information.

The fields for each user entry are separated by colons. Each user is separated from the next by a newline. audit_user does not have general read permission.

Each entry in the audit_user file has the form:

username: always-audit-flags: never-audit-flags

The fields are defined as follows:

username: The user's login name.

always-audit-flags: Flags specifying event classes to always audit.

never-audit-flags: Flags specifying event classes to never audit.

EXAMPLES

Here is a sample audit_user file:

other:lo,ad:io,cl
fred:lo,ex,+fc,-fr,-fa:io,cl
ethyl:lo,ex,nt:io,cl

FILES

/etc/security/audit_user

/etc/passwd

NAME

bootparams - boot parameter data base

SYNOPSIS

/etc/bootparams

DESCRIPTION

The /etc/bootparams file contains a list of client entries that diskless clients use for booting. Diskless booting clients retrieve this information by issuing requests to a server running the rpc.bootparamd (1M)program. The /etc/bootparams file may be used in conjunction with or in place of other sources for the bootparams information. See nsswitch.conf(4).

For each client the file contains an entry with the client's name and a list of boot parameter values for that client. Each entry should have the form:

clientname: identifier-pathname-specifier ...

The first item of each entry is the host name of the diskless client. This is followed by one or more whitespace characters and a series of identifier-pathname-specifiers separated by whitespace characters.

Each identifier-pathname-specifier has the form:

identifier=server: pathname

where identifier is a key that is used by diskless clients to identify a file or filesystem, server is the name of the server that will provide the file or filesystem to the diskless client, and pathname is the path to the exported file or filesystem on the specified server. The equal sign ('=') and colon (':') characters are used in the indicated positions. There should not be any whitespace within an identifier-pathname-specifier.

An entry may be split across multiple lines of the file. The backslash ('\') character should be used as the last character of a line to signify that the entry continues on the next line. The line may only be split in places where whitespace is allowed in the entry.

The asterisk ('* ')character may be used as a "wildcard" in place of the client name in a single entry. That entry will apply to all clients for whom there is not an entry that specifically names them.

EXAMPLES

Here is an example of an entry in the /etc/bootparams file:

client1 root=server1:/export/client1/root \
     swap=server1:/export/client1/swap

FILES

/etc/bootparams

x86 only

rpld(1M)

NOTES

Solaris diskless clients use the identifiers "root", "swap", and "dump" to look up the pathnames for the root filesystem, a swap area, and a dump area, respectively. These are the only identifiers meaningful for SPARC diskless booting clients.

For x86 booting clients, the additional keyword identifiers "numbootfiles," "bootfile," and "bootaddr" are used (see rpld(1M)).

cdtoc(4)

NAME

cdtoc - CD-ROM table of contents file

DESCRIPTION

The table of contents file, .cdtoc, is an ASCII file that describes the contents of a CD-ROM or other software distribution media. It resides in the top-level directory of the file system on a slice of a CD-ROM. It is independent of file system format, that is, the file system on the slice can be either ufs or hsfs.

Each entry in the .cdtoc file is a line that establishes the value of a parameter in the following form:

PARAM=value

Blank lines and comments (lines preceded by a pound-sign, ``#'') are also allowed in the file. Parameters are grouped by product, with the beginning of a product defined by a line of the form:

PRODNAME=value

Each product is expected to consist of one or more software packages that are stored together in a subdirectory on the distribution media. There can be any number of products described within the file. There is no required order in which the parameters must be specified, except that the parameters must be grouped by product and the PRODNAME parameter must appear first in the list of parameters for each product specified. Each parameter is described below. All of the parameters are required for each product.

PRODNAME: The full name of the product. This must be unique within the .cdtoc file and is preferably unique across all possible products. This value may contain white space. The length of this value is limited to 256 ASCII characters; other restrictions may apply (see below).

PRODVERS: The version of the product. The value can contain any combination of letters, numbers, or other characters. This value may contain white space. The length of this value is limited to 256 ASCII characters; other restrictions may apply (see below).

PRODDIR: The name of the top-level directory containing the product. This name should be relative to the top-level directory of the distribution media, for example, Solaris_2.0. The number of path components in the name is limited only by the system's maximum path name length, which is 1024 ASCII characters. Any single component is limited to 256 ASCII characters. This value cannot contain white space.

The lengths of the values of PRODNAME and PRODVERS are further constrained by the fact that the initial install programs and swmtool(1M) concatenate these values to produce the full product name. swmtool concatenates the two values (inserting a space) to produce the name displayed in its software selection menu, for example, Solaris 2.0. For unbundled products the combined length of the values of PRODNAME and PRODVERS must not exceed 256 ASCII characters.

During installation of the bundled OS release, directories for diskless and dataless client usr and kvm file systems are created by constructing names derived from a concatenation of the values of PRODNAME, PRODVERS, and client architecture, for example,

/export/exec/kvm/Solaris_2.0_sparc.sun4c/usr/kvm. The length of the component containing the product name and version must not exceed 256 ASCII characters. Thus, for products corresponding to bundled OS releases (for example, Solaris 2.0), the values of PRODNAME and PRODVERS are effectively restricted to lengths much less than 256.

The initial installation programs, swm and swmtool, use the value of the PRODDIR macro in the .cdtoc file to indicate where packages can be found.

EXAMPLES

Here is a sample .cdtoc file:

#
# .cdtoc file -- Online product family CD
#
PRODNAME=Online DiskSuite
PRODVERS=2.0
PRODDIR=Online_DiskSuite_2.0
#
PRODNAME=Online Backup
PRODVERS=2.0
PRODDIR=Online_Backup_2.0

This example corresponds to the following directory layout on a CD-ROM partition:

        /.cdtoc
        /Online_DiskSuite_2.0
                ./SUNWmddr.c
                ./SUNWmddr.m
                ./SUNWmddu
        /Online_Backup_2.0
                ./SUNWhsm

The bundled release of Solaris 2.2 includes the following .cdtoc file:

PRODNAME=Solaris
PRODVERS=2.2
PRODDIR=Solaris_2.2

This file corresponds to the following directory layout on slice 0 of the Solaris 2.0 product CD:

/.cdtoc
/Solaris_2.2
        ./SUNWaccr
        ./SUNWaccu
        ./SUNWadmap
        .
        .
        .
        ./SUNWutool

NAME

asetmasters, tune.low, tune.med, tune.high, uid_aliases, cklist.low, cklist.med, cklist.high - ASET master files

SYNOPSIS

For example, if mode is 00777 ,the permission will not be changed, since it is always less restrictive than the current setting.

/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
/usr/aset/masters/uid_aliases
/usr/aset/masters/cklist.low
/usr/aset/masters/cklist.med
/usr/aset/masters/cklist.high

DESCRIPTION

All the master files allow comments and blank lines to improve readability. Comment lines must start with a leading "#" character.

tune.low
tune.med
tune.high    These files are used by the tune task (see aset(1M)) to restrict the permis-

sion settings for system objects. Each file is used by ASET at the security level indicated by the suffix. Each entry in the files is of the form: pathname mode owner group type

where

pathname: is the full pathname

mode: is the permission setting

owner: is the owner of the object

group: is the group of the object

type: is the type of the object It can be symlink for a sym-

bolic link, directory for a directory, or file for every-

thing else.

uid_alias

For example, if sync and daemon share the user ID 1 ,the corresponding entry is:

uid: is the shared user id

alias?: is the user accounts sharing the user ID

                1=sync=daemon

asetmasters, tune.low, tune.med, tune.high, uid_aliases, cklist.low, cklist.med, cklist.high - ASET master files

cklist.med
cklist.high

EXAMPLES

The following is an example of valid entries for the tune.low, tune.med, and tune.high files:

/bin       00777      root       staff      symlink
/etc       02755      root       staff      directory
/dev/sd*   00640      root       operator   file

NAME

SYNOPSIS

For example, if mode is 00777 ,the permission will not be changed, since it is always less restrictive than the current setting.

/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
/usr/aset/masters/uid_aliases
/usr/aset/masters/cklist.low
/usr/aset/masters/cklist.med
/usr/aset/masters/cklist.high

DESCRIPTION

All the master files allow comments and blank lines to improve readability. Comment lines must start with a leading "#" character.

tune.low
tune.med
tune.high    These files are used by the tune task (see aset(1M)) to restrict the permis-

sion settings for system objects. Each file is used by ASET at the security level indicated by the suffix. Each entry in the files is of the form: pathname mode owner group type

where

pathname: is the full pathname

mode: is the permission setting

owner: is the owner of the object

group: is the group of the object

type: is the type of the object It can be symlink for a sym-

bolic link, directory for a directory, or file for every-

thing else.

uid_alias

For example, if sync and daemon share the user ID 1 ,the corresponding entry is:

uid: is the shared user id

alias?: is the user accounts sharing the user ID

                1=sync=daemon

asetmasters, tune.low, tune.med, tune.high, uid_aliases, cklist.low, cklist.med, cklist.high - ASET master files

cklist.med
cklist.high

EXAMPLES

The following is an example of valid entries for the tune.low, tune.med, and tune.high files:

/bin       00777      root       staff      symlink
/etc       02755      root       staff      directory
/dev/sd*   00640      root       operator   file

NAME

SYNOPSIS

For example, if mode is 00777 ,the permission will not be changed, since it is always less restrictive than the current setting.

/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
/usr/aset/masters/uid_aliases
/usr/aset/masters/cklist.low
/usr/aset/masters/cklist.med
/usr/aset/masters/cklist.high

DESCRIPTION

All the master files allow comments and blank lines to improve readability. Comment lines must start with a leading "#" character.

tune.low
tune.med
tune.high    These files are used by the tune task (see aset(1M)) to restrict the permis-

sion settings for system objects. Each file is used by ASET at the security level indicated by the suffix. Each entry in the files is of the form: pathname mode owner group type

where

pathname: is the full pathname

mode: is the permission setting

owner: is the owner of the object

group: is the group of the object

type: is the type of the object It can be symlink for a sym-

bolic link, directory for a directory, or file for every-

thing else.

uid_alias

For example, if sync and daemon share the user ID 1 ,the corresponding entry is:

uid: is the shared user id

alias?: is the user accounts sharing the user ID

                1=sync=daemon

clustertoc - cluster table of contents description file

cklist.med
cklist.high

EXAMPLES

The following is an example of valid entries for the tune.low, tune.med, and tune.high files:

/bin       00777      root       staff      symlink
/etc       02755      root       staff      directory
/dev/sd*   00640      root       operator   file

NAME

DESCRIPTION

The cluster table of contents file, .clustertoc, is an ASCII file that describes a hierarchical view of a software product. A .clustertoc file is required for the base OS product. The file resides in the top-level directory containing the product.

The hierarchy described by .clustertoc can be of arbitrary depth, although the initial system installation programs assume that it has three levels. The hierarchy is described bottom-up, with the packages described in .packagetoc at the lowest layer. The next layer is the cluster layer which collects packages into functional units. The highest layer is the meta-cluster layer which collects packages and clusters together into typical configurations.

The hierarchy exists to facilitate the selection or deselection of software for installation at varying levels of granualarity. Interacting at the package level gives the finest level of control over what software is to be installed.

Each entry in the .clustertoc file is a line that establishes the value of a parameter in the following form:

PARAM=value

A line starting with a pound-sign, ``#'', is considered a comment and is ignored.

Parameters are grouped by cluster or meta-cluster. The start of a cluster description is defined by a line of the form:

CLUSTER=value

The start of a meta-cluster description is defined by a line of the form:

METACLUSTER=value

There is no order implied or assumed for specifying the parameters for a (meta-)cluster with the exception of the CLUSTER or METACLUSTER parameter, which must appear first and the END parameter which must appear last.

Each parameter is described below. All of the parameters are mandatory.

CLUSTER: The cluster identifier (for example, SUNWCacc). The identifier specified must be unique within the package and cluster identifier namespace defined by a product's .packagetoc and .clustertoc files. The identifiers used are subject to the same constraints as those for package identifiers. These constraints are (from pkginfo(4)):

``All characters in the abbreviation must be alphanumeric and the first may not be numeric. The abbreviation is limited to a maximum length of nine characters. install, new, and all are reserved abbreviations.''

A cluster must be described before another cluster or meta-cluster may refer to it.

METACLUSTER The metacluster identifier (for example, SUNWCprog). The identifier: specified must be unique within the package and cluster identifier namespace defined by a product's .packagetoc and .clustertoc files. The identifiers used are subject to the same constraints as those for package identifiers. These constraints are (from pkginfo(4)):

Meta-clusters cannot contain references to other meta-clusters.

NAME: The full name of the (meta-)cluster. The length of the name string supplied may not exceed 256 characters.

VENDOR: The name of the (meta-)cluster's vendor. The length of the vendor string supplied may not exceed 256 characters.

VERSION: The version of the (meta-)cluster. The length of the version string supplied may not exceed 256 characters.

DESC: An informative textual description of the (meta-)cluster's contents. The length of the description supplied may not exceed 256 characters. The text should contain no newlines.

SUNW_CSRMEMBER: Indicates that the package or cluster is a part of the (meta-) cluster currently being described. The value specified is the identifier of the package or cluster. There may be an arbitrary number of

SUNW_CSRMEMBER parameters per (meta-)cluster.

EXAMPLES

The following is an example of a cluster description in a .clustertoc file.

# ident "@(#)clustertoc.4 1.2 93/02/24"
CLUSTER=SUNWCacc
NAME=System Accounting
DESC=System accounting utilities
VENDOR=Sun Microsystems, Inc.
VERSION=7.2
SUNW_CSRMEMBER=SUNWaccr
SUNW_CSRMEMBER=SUNWaccu
END

The following is an example of a meta-cluster description in a .clustertoc file.

# required meta-cluster description for Solaris 2.0 FCS
METACLUSTER=SUNWCreq
NAME=Core System Support
DESC=A pre-defined software configuration consisting of the minimum
required software for a standalone, non-networked workstation.
VENDOR=Sun Microsystems, Inc.
VERSION=2.0
SUNW_CSRMEMBER=SUNWadmr
SUNW_CSRMEMBER=SUNWcar
SUNW_CSRMEMBER=SUNWCcs
SUNW_CSRMEMBER=SUNWCcg6
SUNW_CSRMEMBER=SUNWCdfb
SUNW_CSRMEMBER=SUNWkvm
SUNW_CSRMEMBER=SUNWCnis
SUNW_CSRMEMBER=SUNWowdv
SUNW_CSRMEMBER=SUNWter
END

NOTES

The current implementation of the initial system installation programs depend on the .clustertoc describing three required meta-clusters for the base OS product:

SUNWCall: contains all of the software packages in the OS distribution.

SUNWCuser: contains the typical software packages for an end-user of the OS distribution.

SUNWCreq: contains the bare-minimum packages required to boot and configure the OS to the point of running a multi-user shell.

compver(4)

NAME

compver - compatible versions file

DESCRIPTION

compver is an ASCII file used to specify previous versions of the associated package which are upward compatible. It is created by a package developer.

Each line of the file specifies a previous version of the associated package with which the current version is backward compatible.

Since some packages may require installation of a specific version of another software package, compatibility information is extremely crucial. Consider, for example, a package called "A" which requires version "1.0" of application "B" as a prerequisite for installation. If the customer installing "A" has a newer version of "B" (version 1.3), the compver file for "B" must indicate that "1.3" is compatible with version "1.0" in order for the customer to install package "A".

EXAMPLES

A sample compver file is shown below.

Version 1.3
Version 1.0

NOTES

The comparison of the version string disregards white space and tabs. It is performed on a word-by-word basis. Thus "Version 1.3" and "Version 1.3" would be considered the same.

NAME

DESCRIPTION

copyright is an ASCII file used to provide a copyright notice for a package. The text may be in any format. The full file contents (including comment lines) is displayed on the terminal at the time of package installation.

core(4)

NAME

core - core image file

DESCRIPTION

The operating system writes out a core image of a process when it is terminated due to the receipt of some signals. The core image is called core and is written in the process's working directory (provided it can be; normal access controls apply). A process with an effective user ID different from the real user ID will not produce a core image.

The core file contains all the process information pertinent to debugging: contents of hardware registers, process status and process data. The format of a core file is object file specific.

For ELF executable programs (see a.out (4)),the core file generated is also an ELF file, containing ELF program and file headers. The e_type field in the file header has type ET_CORE. The program header contains an entry for every loadable and writeable segment that was part of the process address space, including shared library segments. The contents of the segments themselves are also part of the core image.

The program header of an ELF core file also contains a NOTE segment. This segment may contain the following entries. Each has entry name "CORE" and presents the contents of a system structure:

prstatus_t

The entry containing this structure has a NOTE type of 1. This structure contains things of interest to a debugger from the operating system's u-area, such as the general registers, signal dispositions, state, reason for stopping, process ID and so forth. The prstatus_t structure is defined in <sys/procfs.h>.

prfpregset_t

This entry is present only if the process used the floating-point hardware. It has a NOTE type of 2 and contains the floating-point registers. The prfpregset_t structure is defined in <sys/procfs.h>.

prpsinfo_t

The entry containing this structure has a NOTE type of 3. It contains information of interest to the ps(1) command, such as process status, cpu usage, "nice" value, controlling terminal, user ID, process ID, the name of the executable and so forth. The prpsinfo_t structure is defined in <sys/procfs.h>.

The size of the core file created by a process may be controlled by the user (see getrlimit(2)).

NAME

default_fs, fs - specify the default file system type for local or remote file systems

DESCRIPTION

When file system administration commands have both specific and generic components (for example, fsck(1M)), the file system type must be specified. If it is not explicitly specified using the -F FSType command line option, the generic command looks in /etc/vfstab in order to determine the file system type, using the supplied raw or block device or mount point. If the file system type can not be determined by searching /etc/vfstab, the command will use the default file system type specified in either /etc/default/fs or /etc/dfs/dfstypes, depending on whether the file system is local or remote.

The default local file system type is specified in /etc/default/fs by a line of the form LOCAL=fstype (for example, LOCAL=ufs). The default remote file system type is determined by the first entry in the /etc/dfs/fstypes file.

File system administration commands will determine whether the file system is local or remote by examining the specified device name. If the device name starts with ``/'' (slash), it is considered to be local; otherwise it is remote.

The default file system types can be changed by editing the default files with a text editor.

FILES

/etc/vfstab: list of default parameters for each file system

/etc/default/fs: the default local file system type

/etc/dfs/fstypes the default remote file system type

NAME

depend - software dependencies file

DESCRIPTION

depend is an ASCII file used to specify information concerning software dependencies for a particular package. The file is created by a software developer.

Each entry in the depend file describes a single software package. The instance of the package is described after the entry line by giving the package architecture and/or version. The format of each entry and subsequent instance definition is:

type pkg name
        (arch)version
        (arch)version
        ...

The fields are:

type: Defines the dependency type. Must be one of the following characters:

P: Indicates a prerequisite for installation, for example, the referenced package or versions must be installed.

I: Implies that the existence of the indicated package or version is incompatible.

R: Indicates a reverse dependency. Instead of defining the

package's own dependencies, this designates that another package depends on this one. This type should be used only when an old package does not have a depend file but it relies on the newer package nonetheless. Therefore, the present package should not be removed if the designated old package is still on the system since, if it is removed, the old package will no longer work.

pkg: Indicates the package abbreviation.

name: Specifies the full package name.

(arch)version: Specifies a particular instance of the software. A version name cannot begin with a left parenthesis. The instance specifications, both arch and version, are completely optional but must each begin on a new line that begins with white space. A null version set equates to any version of the indicated package.

EXAMPLES

Here is a sample depend file:

#ident "@(#)pkg.compat:depend 1.1"
P nsu           Networking Support Utilities
P inet          Internet Utilities
P sys           System Header Files
P src_compat Source Compatibility Files

device.cfinfo(4)

NAME

device.cfinfo - devconfig configuration files

SYNOPSIS

device.cfinfo

AVAILABILITY

Here is the device configuration file logi.cfinfo for the LOGITECH bus mouse. The driver configuration file for this device is called logi.conf.

DESCRIPTION

device.cfinfo files pass information about device configuration to the devconfig(1M) program. They allow devconfig(1M) to provide the user with valid ranges for device attributes.

devconfig(1M) associates a device with its cfinfo file by name. For example, the device logi for the Logitec Bus Mouse has the devconfig(1M) configuration file logi.cfinfo associated with it in the DEVCONFIGHOME directory. DEVCONFIGHOME is /usr/lib/devconfig by default and may be set in the user's environment.

Below is a yaccish grammar of a cfinfo file:

cfinfo_file:         cfinfo_devspec EOF
                   ;

cfinfo_devspec:: cfinfo_spec_list SEMICOLON

cfinfo_spec_list:: cfinfo_spec |

                   cfinfo_spec_list cfinfo_spec
                   ;

cfinfo_spec:: comment |

                   attr_value_pair NEWLINE
                   ;

comment:: POUNDSIGN |

                   POUNDSIGN STRING
                   ;

attr_value_pair:: ATTR_NAME EQUALS STRING |

                   ATTR_OWNAME EQUALS STRING
                   ATTR_TITLE EQUALS STRING |
                   ATTR_CATEGORY EQUALS STRING |
                   ATTR_INSTANCE EQUALS STRING |
                   ATTR_CLASS EQUALS STRING |
                   ATTR_TYPE EQUALS STRING |
                   ATTR_REAL EQUALS STRING |
                   ATTR_AUTO EQUALS STRING |
                   NAME EQUALS value_spec_string
                   ;

value_spec_string: QUOTE value_spec QUOTE
                   ;

value_spec:: value_type COMMA value_list

value_type:: | /* EMPTY * /

                   TYPE_NUMERIC |
                   TYPE_STRING |
                   TYPE_VAR
                   ;

value_list:: integer_value_list |

                   string_value_list
                   ;

integer_value_list:: INTEGER |

                   INTEGER COLON INTEGER |
                   INTEGER COMMA integer_value_list
                   ;

string_value_list:: STRING |

                   STRING COMMA string_value_list
                   ;
ATTR_NAME            name           # device name specified in driver.conf
ATTR_CLASS           class          # device class specified in driver.conf
ATTR_TYPE            type           # device type specified in OWconfig
ATTR_OWNAME          __owname__     # device name specified in OWconfig
ATTR_TITLE           __title__      # device title displayed by devconfig
ATTR_CATEGORY        __category__   # device category
ATTR_INSTANCE        __instance__   # device unit
ATTR_REAL            __real__       # attributes to write to driver.conf
ATTR_AUTO            __auto__       # self-identifying device attribute
TYPE_NUMERIC         numeric        # precedes an integer value list
TYPE_STRING          string         # precedes a string values list
TYPE_VAR             var            # precedes a variable specification

The first value in a value_list is the default value picked by devconfig(1M) for the attribute. An attribute name of the form __name__ is used internally by devconfig(1M). Number ranges are specified as n1:n2. An internal attribute of the type var specifies a configurable portion of a real attribute. (See examples below.) Certain internal attributes have an expanded form when displayed. These attributes are listed in the file abbreviations in DEVCONFIGHOME. The file abbreviations also includes a list of name mappings for certain category names. If the __real__ attribute is present, only the attribute names it specifies are written to a driver.conf file. Otherwise all non-internal attributes are written.

EXAMPLES

name="logi"
                  __owname__="pointer:0"
                  __title__="Logitec bus mouse"

                  __category__="pointer"

class="sysbus"

type="LOGI-B"
buttons="var,__nbuttons__"
__nbuttons__="numeric,2:3"
dev="/dev/logi"

intr="numeric,1","var,__irq__"

__irq__="numeric,2:5"

__real__="name","class","intr"

;

The driver name for the LOGITECH Bus Mouse is logi. The device name in OWconfig (see the OpenWindows Reference Manual) is pointer:0. The device category is pointer; the device category is displayed as pointing devices however since there is a category mapping for pointer in the abbreviations file. The device class is sysbus as specified in the file /kernel/drv/classes. A device of class owin does not have a device driver associated with it. The device IPL is 1. The device IRQ is substituted by the variable __irq__ and has a range of 2 to 5. A name mapping for __irq__ exists in abbreviations and so __irq__ is displayed as Interrupt (IRQ):. The device attributes written to logi.conf are name , class and intr as specified by the __real__" entry.

The resulting entry in logi.conf is:

name="logi" class="sysbus" intr=1,2;

The resulting entry in OWconfig is:

type="LOGI-B" buttons=3 dev="/dev/logi" class="owin" name="pointer:0";

Here is an example of a self-identifying device.

name="lp"
                  __title__="Parallel printer port"
                  __category__="lp"

                  class="sysbus"

__auto__="string,true"

;

The driver for the parallel port automatically identifies it, and devconfig(1M) treats this device as self-identifying.

FILES

abbreviations

NAME

device_allocate - device_allocate file

SYNOPSIS

/etc/security/device_allocate

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

The device_allocate file contains mandatory access control information about each physical device. Each device is represented by a one line entry of the form:

device-name; device-type;reserved;reserved;alloc; device-exec

where

device-name: This is an arbitrary ASCII string naming the physical dev-

ice. This field contains no embedded white space or non-

printable characters.

device-type: This is an arbitrary ASCII string naming the generic device

type. This field identifies and groups together devices of

like type. This field contains no embedded white space or

non-printable characters.

reserved: This field is reserved for future use.

reserved: This field is reserved for future use.

alloc: This field contains an arbitrary string which controls

whether or not a device is allocatable. If the field contains

only an asterisk (* ),the device is not allocatable. Other-

wise, the device may be allocated and deallocated in the

normal fashion.

device-exec: This is the physical device's data purge program to be run

any time the device is acted on by allocate(1M). This is to

ensure that all usable data is purged from the physical

device before it is reused. This field contains the filename

of a program in /etc/security/lib or the full pathname of a

cleanup script provided by the system administrator.

The device_allocate file is an ASCII file that resides in the /etc/security directory.

Lines in device_allocate can end with a `\' to continue an entry on the next line.

Comments may also be included. A `# 'makes a comment of all further text until the next NEWLINE not immediately preceded by a `\'.

Leading and trailing blanks are allowed in any of the fields.

The device_allocate file must be created by the system administrator before device allocation is enabled.

The device_allocate file is owned by root, with a group of sys, and a mode of 0644.

EXAMPLES

Declare that physical device st0 is a type st. st is allocatable, and the script used to clean the device after running deallocate(1M) is named /etc/security/lib/st_clean.

                # scsi tape
        st0;\
                st;\
                reserved;\
                reserved;\
                alloc;\
                /etc/security/lib/st_clean;\

Declare that physical device fd0 is of type fd . fd is allocatable, and the script used to clean the device after running deallocate(1M) is named /etc/security/lib/fd_clean.

        # floppy drive
fd0;\
        fd;\
        reserved;\
        reserved;\
        alloc;\
        /etc/security/lib/fd_clean;\

Note that making a device allocatable means that you need to allocate and deallocate them to use them (with allocate(1M) and deallocate(1M)). If a device is allocatable, there will be an asterisk (* )in the alloc field, and one can use the device without allocating and deallocating it.

FILES

/etc/security/device_allocate: Contains list of allocatable devices

NAME

device_maps - device_maps file

SYNOPSIS

/etc/security/device_maps

AVAILABILITY

The functionality described in this man page is available only if the Basic Security Module (BSM) has been enabled. See bsmconv(1M) for more information.

DESCRIPTION

The device_maps file contains access control information about each physical device. Each device is represented by a one line entry of the form:

device-name : device-type : device-list :

where

device-name: This is an arbitrary ASCII string naming the physical dev-

ice. This field contains no embedded white space or non-

printable characters.

device-type: This is an arbitrary ASCII string naming the generic device

type. This field identifies and groups together devices of

like type. This field contains no embedded white space or

non-printable characters.

device-list: This is a list of the device special files associated with the

physical device. This field contains valid device special

file path names separated by white space.

The device_maps file is an ASCII file that resides in the /etc/security directory.

Lines in device_maps can end with a `\' to continue an entry on the next line.

Comments may also be included. A `# 'makes a comment of all further text until the next NEWLINE not immediately preceded by a `\'.

Leading and trailing blanks are allowed in any of the fields.

The device_maps file must be created by the system administrator before device allocation is enabled.

This file is owned by root, with a group of sys, and a mode of 0644.

EXAMPLES

# scsi tape

st1:\
        rmt:\
        /dev/rst21 /dev/nrst21 /dev/rst5 /dev/nrst5 /dev/rst13 \
        /dev/nrst13 /dev/rst29 /dev/nrst29 /dev/rmt/1l /dev/rmt/1m \
        /dev/rmt/1 /dev/rmt/1h /dev/rmt/1u /dev/rmt/1ln /dev/rmt/1mn \
        /dev/rmt/1n /dev/rmt/1hn /dev/rmt/1un /dev/rmt/1b /dev/rmt/1bn:\

FILES

/etc/security/device_maps

NAME

dfstab - file containing commands for sharing resources across a network

DESCRIPTION

dfstab resides in directory /etc/dfs and contains commands for sharing resources across a network. dfstab gives a system administrator a uniform method of controlling the automatic sharing of local resources.

Each line of the dfstab file consists of a share(1M) command. The dfstab file can be read by the shell to share all resources. System administrators can also prepare their own shell scripts to execute particular lines from dfstab.

The contents of dfstab are executed automatically when the system enters run-level 3.

NAME

dir_ufs, dir - format of ufs directories

SYNOPSIS

A directory consists of some number of blocks of DIRBLKSIZ bytes, where DIRBLKSIZ is chosen such that it can be transferred to disk in a single atomic operation (for example, 512 bytes on most machines).

#include <sys/types.h>
#include <sys/fs/ufs_fsdir.h>

DESCRIPTION

Each DIRBLKSIZ -byteblock contains some number of directory entry structures, which are of variable length. Each directory entry has a struct direct at the front of it, containing its inode number, the length of the entry, and the length of the name contained in the entry. These entries are followed by the name padded to a 4 byte boundary with null bytes. All names are guaranteed null-terminated. The maximum length of a name in a directory is MAXNAMLEN.

#define        DIRBLKSIZ                        DEV_BSIZE
#define        MAXNAMLEN                        256
struct direct {
     u_long d_ino;                             /* inode number of entry * /
     u_short d_reclen;                         /* length of this record * /
     u_short d_namlen;                         /* length of string in d_name * /
     char    d_name[MAXNAMLEN + 1];            /* name must be no longer than this * /
};

NAME

dir_ufs, dir - format of ufs directories

SYNOPSIS

dirent - file system independent directory entry

#include <sys/types.h>
#include <sys/fs/ufs_fsdir.h>

DESCRIPTION

#define        DIRBLKSIZ                        DEV_BSIZE
#define        MAXNAMLEN                        256
struct direct {
     u_long d_ino;                             /* inode number of entry * /
     u_short d_reclen;                         /* length of this record * /
     u_short d_namlen;                         /* length of string in d_name * /
     char    d_name[MAXNAMLEN + 1];            /* name must be no longer than this * /
};

NAME

SYNOPSIS

#include <dirent.h>

DESCRIPTION

Different file system types may have different directory entries. The dirent structure defines a file system independent directory entry, which contains information common to directory entries in different file system types. A set of these structures is returned by the getdents(2) system call.

The dirent structure is defined:

struct dirent {
    ino_t                      d_ino;
    off_t                      d_off;
    unsigned short             d_reclen;
    char                       d_name[1];
};

The d_ino is a number which is unique for each file in the file system. The field d_off is the byte offset of the next, non-empty directory entry in the actual file system directory. The field d_name is the beginning of the character array giving the name of the directory entry. This name is null terminated and may have at most MAXNAMLEN characters. This results in file system independent directory entries being variable length entities. The value of d_reclen is the record length of this entry. This length is defined to be the number of bytes between the current entry and the next one, so that the next structure will be suitably aligned.

NAME

driver.conf - driver configuration files

SYNOPSIS

driver.conf

DESCRIPTION

Driver configuration files pass information about device drivers and their configuration to the system. Most device drivers do not have to have configuration files. Drivers for devices that are self-identifying, such as the SBus devices on many systems, can usually obtain all the information they need from the FCode PROM on the SBus card using the DDI property interfaces. See ddi_prop_op(9F) for details.

The system associates a driver with its configuration file by name. For example, a driver in /usr/kernel/drv called wombat has the driver configuration file wombat.conf associated with it. By convention, the driver configuration file lives in the same directory as the driver.

The syntax of a single entry in a driver configuration file takes one of three forms:

name ="node name" parent="parent name" [property-name=value ...];

In this form, the parent name is a simple nexus driver name. Alternatively, the parent can be specified by the type of interface it presents to its children.

name ="node name" class="class name" [property-name=value ...];

For example, the driver for the SCSI host adapter may have different names on different platforms, but the target drivers can use class scsi to insulate themselves from these differences.

Entries of either form above correspond to a device information (devinfo) node in the kernel device tree. Each node has a name which is usually the name of the driver, and a parent name which is the name of the parent devinfo node it will be connected to. Any number of name-value pairs may be specified to create properties on the prototype devinfo node. These properties can be sized and retrieved using the DDI property interfaces (for example, ddi_getproplen(9F) and ddi_getprop(9F)). The prototype devinfo node specification must be terminated with a semicolon (; ).

The third form of an entry is simply a list of properties.

[property-name=value ...];

A property created in this way is treated as global to the driver. It can be overridden by a property with the same name on a particular devinfo node, either by creating one explicitly on the prototype node in the driver.conf file or by the driver.

Items are separated by any number of newlines, SPACE or TAB characters.

The configuration file may contain several entries to specify different device configurations and parent nodes. The system may call the driver for each possible prototype devinfo node, and it is generally the responsibility of the drivers probe(9E) routine to determine if the hardware described by the prototype devinfo node is really present.

Property names should obey the same naming convention as Open Boot PROM properties, in particular they should not contain at-sign (@), or slash (/) characters. Property values can be decimal integers or strings delimited by double quotes ("). Hexadecimal

integers can be constructed by prefixing the digits with 0x .

A comma separated list of integers can be used to construct properties whose value is an integer array. The value of such properties can be retrieved inside the driver using ddi_getlongprop(9F) or one of the related property interfaces.

Comments are specified by placing a # character at the beginning of the comment string, the comment string extends for the rest of the line.

EXAMPLES

Here is a configuration file called ACME,simple.conf for a VMEbus frame buffer called ACME,simple.

        #ident "@(#)ACME,simple.conf            1.3     93/09/09"

name="ACME,simple" class="vme"

reg=0x7d,0x400000,0x110600;

This example creates a prototype devinfo node called ACME,simple under all parent nodes of class vme. It specifies a property called reg that consists of an array of three integers. The reg property is interpreted by the parent node, see vme(4) for further details.

Here is a configuration file called ACME,example.conf for a pseudo device driver called ACME,example.

        #ident "@(#)ACME,example.conf           1.2     93/09/09"

name="ACME,example" parent="pseudo" instance=0

  debug-level=1;

name="ACME,example" parent="pseudo" instance=1;

whizzy-mode="on";

debug-level=3;

This example creates two devinfo nodes called ACME,example which will attach below the pseudo node in the kernel device tree. The instance property is only interpreted by the pseudo node, see pseudo(4) for further details. A property called debug-level will be created on the first devinfo node which will have the value 1. The example driver will be able to fetch the value of this property using ddi_getprop(9F).

Two global driver properties are created, whizzy-mode (which will have the string value "on") and debug-level (which will have the value 3). If the driver looks up the property whizzy-mode on either node, it will retrieve the value of the global whizzy-mode property ("on"). If the driver looks up the debug-level property on the first node, it will

retrieve the value of the debug-level property on that node (1). Looking up the same property on the second node will retrieve the value of the global debug-level property (3).

WARNINGS

To avoid namespace collisions between multiple driver vendors, it is strongly recommended that the name property of the driver should begin with a vendor-unique string. A reasonably compact and unique choice is the vendor over-the-counter stock symbol.

dumpdates(4)

NAME

ufsdump, dumpdates - incremental dump format

SYNOPSIS

#include <sys/types.h>

#include <sys/inode.h>
#include <protocols/dumprestore.h>

/etc/dumpdates

DESCRIPTION

Tapes used by ufsdump(1M) and ufsrestore(1M) contain:

a header record

two groups of bit map records

a group of records describing directories

a group of records describing files

The format of the header record and of the first record of each description as given in the include file <protocols/dumprestore.h> is:

#define TP_BSIZE                 1024
#define NTREC                    10
#define HIGHDENSITYTREC          32
#define CARTRIDGETREC            63
#define TP_NINDIR                (TP_BSIZE /2)
#define TP_NINOS                 (TP_NINDIR / sizeop (long))
#define LBLSIZE                  16
#define NAMELEN                  64

#define NFS_MAGIC: (int) 60012

#define CHECKSUM                (int) 84446

union u_data {

        char s_addrs[TP_NINDIR ];
        long s_inos[TP_NINOS ];

union u_spcl {

        char dummy[TP_BSIZE ];
        struct s_spcl {
               long            c_type;
               time_t          c_date;
               time_t          c_ddate;
               long            c_volume;
               daddr_t         c_tapea;
               ino_t           c_inumber;
               long            c_magic;
               long            c_checksum;
               struct dinode   c_dinode;
               long            c_count;
               union           u_data c_data;
               char            c_label[LBLSIZE ];

               long            c_level;
               char            c_filesys[NAMELEN ];
               char            c_dev[NAMELEN ];
               char            c_host[NAMELEN ];
               long            c_flags;
               long            c_firstrec;
               long            c_spare[32];
       } s_spcl;
} u_spcl;

#define spcl u_spcl.s_spcl

#define c_addr c_data.s_addrs
#define c_inos cdata.s_inos

#define TS_TAPE: 1

#define TS_INODE                 2
#define TS_ADDR                  4
#define TS_BITS                  3
#define TS_CLRI                  6
#define TS_END                   5
#define TS_EOM                   7

#define DR_NEWHEADER: 1

#define DR_INODEINFO             2
#define DR_REDUMP                4
#define DR_TRUELIC               8
#define DUMPOUTFMT               "%-24s %c %s"
#define DUMPINFMT                "%24s %c %[^ \n ] \n"

The constants are described as follows:

TP_BSIZE: Size of file blocks on the dump tapes. Note that TP_BSIZE must be a multiple of DEV_BSIZE .

NTREC: Default number of TP_BSIZE byte records in a physical tape block, changeable by the b option to ufsdump(1M).

HIGHDENSITYNTREC: Default number of TP_BSIZE byte records in a physical tape block on 6250 BPI or higher density tapes.

CARTRIDGETREC: Default number of TP_BSIZE records in a physical tape block on cartridge tapes.

TP_NINDIR: Number of indirect pointers in a TS_INODE or TS_ADDR record. It must be a power of 2.

TP_NINOS: The maximum number of volumes on a tape. Used for tape labeling in hsmdump and hsmrestore (available with Online:Backup 2.0 optional software package SUNWhsm).

LBLSIZE: The maximum size of a volume label. Used for tape labeling in hsmdump and hsmrestore (available with Online:Backup 2.0 optional software package SUNWhsm).

NAMELEN: The maximum size of a host's name.

NFS_MAGIC: All header records have this number in c_magic.

CHECKSUM: Header records checksum to this value.

The TS_ entries are used in the c_type field to indicate what sort of header this is. The types and their meanings are as follows:

TS_TAPE: Tape volume label.

TS_INODE: A file or directory follows. The c_dinode field is a copy of the disk inode and contains bits telling what sort of file this is.

TS_ADDR: A subrecord of a file description. See s_addrs below.

TS_BITS: A bit map follows. This bit map has a one bit for each inode that was dumped.

TS_CLRI: A bit map follows. This bit map contains a zero bit for all inodes that were empty on the file system when dumped.

TS_END: End of tape record.

TS_EOM: floppy EOM -- restore compat with old dump

The flags are described as follows:

DR_NEWHEADER: New format tape header.

DR_INFODEINFO: Header contains starting inode info.

DR_REDUMP: Dump contains recopies of active files.

DR_TRUEINC: Dump is a "true incremental".

DUMPOUTFMT Name, incon, and ctime (date) for printf.

DUMPINFMT: Inverse for scanf.

The fields of the header structure are as follows:

s_addrs: An array of bytes describing the blocks of the dumped file. A byte is zero if the block associated with that byte was not present on the file system; otherwise, the byte is non-zero. If the block was not present on the file lsystem, no block was dumped; the block will be stored as a hole in the file. If there is not sufficient space in this record to describe all the blocks in a file, TS_ADDR records will be scattered through the file, each one picking up where the last left off

s_inos: The starting inodes on tape.

c_type: The type of the record.

c_date: The date of the previous dump.

c_ddate: The date of this dump.

c_volume: The current volume number of the dump.

c_tapea: The logical block of this record.

c_inumber: The number of the inode being dumped if this is of type TS_INODE .

c_magic: This contains the value MAGIC above, truncated as needed.

c_checksum: This contains whatever value is needed to make the record sum to CHECKSUM .

c_dinode: This is a copy of the inode as it appears on the file system.

c_count: The count of bytes in s_addrs.

u_data c_data: The union of either u_data c_data The union of either s_addrs or s_inos.

c_label: Label for this dump.

c_level: Level of this dump.

c_filesys: Name of dumped file system.

c_dev: Name of dumped service.

c_host: Name of dumped host.

c_flags: Additional information.

c_firstrec: First record on volume.

c_spare: Reserved for future uses.

Each volume except the last ends with a tapemark (read as an end of file). The last volume ends with a TS_END record and then the tapemark.

The dump history is kept in the file /etc/dumpdates. It is an ASCII file with three fields separated by white space:

The name of the device on which the dumped file system resides.

The level number of the dump tape; see ufsdump(1M).

The date of the incremental dump in the format generated by ctime(3C).

DUMPOUTFMT is the format to use when using printf(3S) to write an entry to /etc/dumpdates; DUMPINFMT is the format to use when using scanf(3S) to read an entry from /etc/dumpdates.

NAME

sysbus, isa, eisa, mca - configuration files for ISA, EISA, and MCA bus device drivers

AVAILABILITY

integer elements of this property are used to construct the address part of the device name under /devices. If the device has memory-mapped addresses, the first integer should be 0 and the second integer should specify the physical address; if the device does not have memorymapped addresses, the first integer should specify a unique identifier and the second integer should be 0 . A recommended unique identifier is the ioaddr value; that is, specify the I/O address in both the ioaddr field and the first integer of the reg field. The third integer of each 3-tuple specifies the size, in bytes, of the mappable region.

DESCRIPTION

Solaris for x86 platforms support the ISA, EISA, and MCA buses as the system bus. Drivers for devices on these buses use driver configuration files to inform the system that the device hardware may be present (see driver.conf(4) for more information). The configuration file must specify the device I/O port addresses, any interrupt capabilities that the device may have, any DMA channels it may require, and any memory-mapped addresses it may occupy.

Configuration files for ISA, EISA, and MCA device drivers should identify the parent nexus driver implicitly using the class keyword. This removes the dependency on the name of the particular nexus driver involved since most drivers can operate device controllers attached to any of those buses. The ISA, EISA, and MCA nexus drivers all belong to class sysbus. See driver.conf(4) for further details of configuration file syntax.

All bus drivers of class sysbus recognize the following properties:

intr: An arbitrary-length array where each element of the array consists of a pair of integers. Each array element describes a possible interrupt that the device might generate.

The first integer of each pair specifies the device's relative priority. This is the priority that this device's interrupt handler will receive relative to the interrupt handlers of other drivers. The priority is an integer from 1 to 16 . Generally, disks are assigned a priority of 5 ,while mice and printers are lower, and serial communication devices are higher, typically 7 . 10 is reserved by the system and must not be used. Interrupts 11 and greater are high level interrupts and are generally not recommended (see ddi_intr_hilevel(9F)).

The second integer of each pair denotes the hardware interrupt request (IRQ) number.

The driver can refer to the elements of this array by index using ddi_add_intr(9F). The index into the array is passed as the inumber argument of ddi_add_intr( ).

Only devices that generate interrupts need to provide intr properties.

reg: An arbitrary-length array where each element of the array consists of a 3-tuple of integers. Each array element describes a contiguous memory address range associated with the device on the bus.

The first integer of the tuple is reserved.

The driver can refer to the elements of this array by index, and construct kernel mappings to these addresses using ddi_map_regs(9F). The index into the array is passed as the rnumber argument of ddi_map_regs( ).

All sysbus device drivers must provide reg properties. The first two

ioaddr: An integer that describes the I/O port base address for this device.

dmachan: An integer that specifies the DMA channel used by this device. Only devices that use a DMA channel need to provide dmachan properties.

EXAMPLES

Here are three sample entries from three different driver.conf files:

name="fdc" class="sysbus" intr=5,6 ioaddr=0x3f0 dmachan=2 reg=0x3f0,0,0;

name="logi" class="sysbus" intr=1,4 ioaddr=0x23c reg=0x23c,0,0;
name="sbpro" class="sysbus" ioaddr=0x220 intr=5,7 dmachan=1 reg=0x220,0,0;

NAME

environ, .environ, .pref, .variables - user-preference variables files for AT&T FACE

DESCRIPTION

The .environ, .pref, and .variables files contain variables that indicate user preferences for a variety of operations. The .environ and .variables files are located under the user's $HOME/pref directory. The .pref files are found under $HOME/FILECABINET, $HOME/WASTEBASKET, and any directory where preferences were set via the organize command. Names and descriptions for each variable are presented below. Variables are listed one per line and are of the form variable=value.

Variables found in .environ include:

LOGINWIN[1-4]: Windows that are opened when FACE is initialized

SORTMODE: Sort mode for file folder listings. Values include the following hexadecimal digits:

1: sorted alphabetically by name

2: files most recently modified first

800: sorted alphabetically by object type

The values above may be listed in reverse order by "ORing" the following value:

1000: list objects in reverse order. For example, a value of 1002 will produce a folder listing with files LEAST recently modified

displayed first. A value of 1001 would produce a "reverse"

alphabetical by name listing of the folder

DISPLAYMODE: Display mode for file folders. Values include the following hexadecimal digits:

0: file names only

4: file names and brief description

8: file names, description, plus additional information

WASTEPROMPT: Prompt before emptying wastebasket (yes/no)?

WASTEDAYS: Number of days before emptying wastebasket

PRINCMD[1-3] Print command defined to print files.

UMASK: Holds default permissions that files will be created with.

Variables found in .pref are the following:

SORTMODE: which has the same values as the SORTMODE variable described in .environ above.

DISPMODE
            which has the same values as the DISPLAYMODE variable described in
            .environ above.
Variables found in .variables include:
EDITOR      Default editor
PS1         shell prompt

FILES

$HOME/pref/.environ

$HOME/pref/.variables
$HOME/FILECABINET/.pref
$HOME/WASTEBASKET/.pref

ethers(4)

NAME

ethers - Ethernet address to hostname database or domain

DESCRIPTION

The ethers file is a local source of information about the (48 bit) Ethernet addresses of hosts on the Internet. The ethers file can be used in conjunction with or instead of other ethers sources, including the NIS maps ethers.byname and ethers.byaddr and the NIS+ table ethers. Programs use the ethers(3N) routines to access this information.

The ethers file has one line for each host on an Ethernet. The line has the following format:

Ethernet-address official-host-name

Items are separated by any number of SPACE and/or TAB characters. A `# 'indicates the beginning of a comment extending to the end of line.

The standard form for Ethernet addresses is " x : x : x : x : xwhere: : x "

x is a hexadecimal

number between 0 and ff, representing one byte. The address bytes are always in network order. Host names may contain any printable character other than SPACE, TAB, NEWLINE, or comment character.

FILES

/etc/ethers

NAME

logindevperm, fbtab - login-based device permissions

SYNOPSIS

/etc/logindevperm

DESCRIPTION

The /etc/logindevperm file contains information that is used by login(1) and ttymon(1M) to change the owner, group, and permissions of devices upon logging into or out of a console device. By default, this file contains lines for the keyboard, mouse, audio, and frame buffer devices.

The owner of the devices listed in /etc/logindevperm is set to the owner of the console by login(1). The group of the devices is set to the owner's group specified in /etc/passwd. The permissions are set as specified in /etc/logindevperm.

Fields are separated by TAB and/or SPACE characters. Blank lines and comments can appear anywhere in the file; comments start with a hashmark, ` # ', and continue to the end of the line.

The first field specifies the name of a console device (for example, /dev/console). The second field specifies the permissions to which the devices in the device_list field (third field) will be set. A device_list is a colon-separated list of device names. A device entry that is a directory name and ends with "/* "specifies all entries in the directory (except "." and ".."). For example, "/dev/fbs/* "specifies all frame buffer devices.

Once the devices are owned by the user, their permissions and ownership can be changed using chmod(1) and chown(1), as with any other user-owned file.

Upon logout the owner and group of these devices will be reset by ttymon(1M) to owner root and root's group as specified in /etc/passwd (typically other). The permissions are set as specified in the /etc/logindevperm file.

FILES

/etc/passwd: File that contains user group information.

NOTES

/etc/logindevperm provides a superset of the functionality provided by /etc/fbtab in SunOS 4.x releases.

fd(4)

NAME

fd - file descriptor files

DESCRIPTION

These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2, and so on, refer to files accessible through file descriptors. If file descriptor n is open, these two system calls have the same effect:

fd = open("/dev/fd/n",mode);
fd = dup(n);

On these files creat(2) is equivalent to open, and mode is ignored. As with dup, subsequent reads or writes on fd fail unless the original file descriptor allows the operations.

For convenience in referring to standard input, standard output, and standard error, an additional set of names is provided: /dev/stdin is a synonym for /dev/fd/0, /dev/stdout for /dev/fd/1, and /dev/stderr for /dev/fd/2.

DIAGNOSTICS

open(2) returns -1 and EBADF if the associated file descriptor is not open.

filehdr(4)

NAME

filehdr - file header for common object files

SYNOPSIS

#include <filehdr.h>

DESCRIPTION

Every common object file begins with a 20-byte header. The following C struct declaration is used:

struct filehdr
{
 unsigned short f_magic ;   /** magic number ** /
 unsigned short f_nscns ;   /** number of sections ** /
 long            f_timdat ; /** time & date stamp ** /
 long            f_symptr ; /** file ptr to symtab ** /
 long            f_nsyms ; /** number of symtab entries ** /
 unsigned short f_opthdr ; /** sizeof(opt and header) ** /
 unsigned short f_flags ;    /** flags ** /
};

f_symptr is the byte offset into the file at which the symbol table can be found. Its value can be used as the offset in fseek(3S) to position an I/O stream to the symbol table. The UNIX system optional header is 28 bytes. The valid magic numbers are given below:

#define I386MAGIC          0514    /** i386 Computer ** /
#define WE32MAGIC          0560    /** 3B2, 3B5, and 3B15 computers ** /
#define N3BMAGIC           0550    /** 3B20 computer ** /
#define NTVMAGIC           0551    /** 3B20 computer ** /

#define VAXWRMAGIC 0570: /** VAX writable text segments ** /

#define VAXROMAGIC 0575            /** VAX read only sharable
                                    text segments ** /

The value in f_timdat is obtained from the time(2) system call. Flag bits currently defined are:

#define F_RELFLG        0000001    /** relocation entries stripped ** /
#define F_EXEC          0000002    /** file is executable ** /
#define F_LNNO          0000004    /** line numbers stripped ** /
#define F_LSYMS         0000010    /** local symbols stripped ** /
#define F_AR16WR        0000200    /** 16-bit DEC host ** /
#define F_AR32WR        0000400    /** 32-bit DEC host ** /
#define F_AR32W         0001000    /** non-DEC host ** /
#define F_BM32ID        0160000    /** WE32000 family ID field ** /

#define F_BM32B         0020000    /** file contains WE 32100 code ** /
#define F_BM32MAU 0040000          /** file reqs MAU to execute ** /
#define F_BM32RST       0010000    /** this object file contains restore
                                    work around [3B5/3B2 only] ** /

NAME

format.dat - disk drive configuration for the format command.

DESCRIPTION

format.dat enables you to use your specific disk drives with format(1M). On Solaris 2.3 and later systems, format will automatically configure and label SCSI drives, so that they need not be defined in format.dat . Three things can be defined in the data file:

search paths

disk types

partition tables.

Syntax

The following syntax rules apply to the data file:

The pound # sign is the comment character. Any text on a line after a pound sign is not interpreted by format.

Each definition in the format.dat file appears on a signle logical line. If the definition is more than one line long, all but the last line of the definition must end with a backslash (\).

A definition consists of a series of assignments that have an identifier on the left side and one or more values on the right side. The assignment operator is the equal sign (=). Assignments within a definition must be separated by a colon (:).

White space is ignored by format(1M). If you want an assigned value to contain white space, enclose the entire value in double quotes ("). This will cause the white space within quotes to be preserved as part of the assignment value.

Some assignments can have multiple values on the right hand side. Separate values by a comma (,).

File Formats..format.dat ( 4 ) Keywords

The data file contains disk definitions that are read in by format(1M) when it starts up. Each definition starts with one of the following keywords: search_path, disk_type, and partition.

search_path: 4.x: Tells format which disks it should search for when it starts up. The list in the default data file contains all the disks in the GENERIC configuration file. If your system has disks that are not in the GENERIC configuration file, add them to the search_path definition in your data file. The data file can contain only one search_path definition. However, this single definition lets you specify all the disks you have in your system.

x: By default, format(1M) understands all the logical devices that are of the form /dev/rdsk/cntndnsn; hence search_path is not normally defined on a 5.x system.

disk_type: Defines the controller and disk model. Each disk_type definition contains information concerning the physical geometry of the disk. The default data file contains definitions for the controllers and disks that the Solaris operating system supports. You need to add a new disk_type only if you have an unsupported disk. You can add as many disk_type

definitions to the data file as you want.

The following controller types are supported by format(1M): XY450: Xylogics 450 controller (SMD)

XD7053: Xylogics 7053 controller (SMD)

MD21: SCSI, but using ESDI devices (aka shoebox)

SCSI: True SCSI (CCS or SCSI-2)

ISP-80: IPI panther controller

Note: The disk_type and partition definition entries must have "ctlr = MD21" for scsi disk devices for 4.1.1 release. But for 4.1.2, 4.1.3 and 5.x releases, the entries should say "ctlr = SCSI".

The keyword itself is assigned the name of the disk type. This name appears in the disk's label and is used to identify the disk type whenever format(1M) is run. Enclose the name in double quotes to preserve any white space in the name.

Below are lists of identifiers for supported controllers. Note that an asterisk ('* ')indicates the identifier is mandatory for that controller -- it is not part of the keyword name.

The following identifiers are assigned values in all disk_type definitions:

acyl*: alternate cylinders

asect: alternate sectors per track

atrks: alternate tracks

fmt_time: formatting time per cylinder

ncyl*: number of logical cylinders

nhead*: number of logical heads

nsect*: number of logical sectors per track

pcyl*: number of physical cylinders

phead: number of physical heads

psect: number of physical sectors per track

rpm*: drive RPM

These identifiers are for SCSI and MD-21 Controllers

read_retries: page 1 byte 3 (read retries)

write_retries: page 1 byte 8 (write retries)

cyl_skew: page 3 bytes 18-19 (cylinder skew)

trk_skew: page 3 bytes 16-17 (track skew)

trks_zone: page 3 bytes 2-3 (tracks per zone)

cache: page 38 byte 2 (cache parameter)

prefetch: page 38 byte 3 (prefetch parameter)

max_prefetch: page 38 byte 4 (minimum prefetch)

min_prefetch: page 38 byte 6 (maximum prefetch)

Note: The Page 38 values are device-specific. Refer the user to the particular disk's manual for these values.

For SCSI disks, the following geometry specifiers may cause a mode select on the byte(s) indicated:

asect: page 3 bytes 4-5 (alternate sectors per zone)

atrks: page 3 bytes 8-9 (alt. tracks per logical unit)

phead: page 4 byte 5 (number of heads)

psect: page 3 bytes 10-11 (sectors per track)

And these identifiers are for SMD Controllers Only

bps*: bytes per sector (SMD)

bpt*: bytes per track (SMD)

Note: under SunOS 5.x, bpt is only required for SMD disks. Under SunOS 4.x, bpt was required for all disk types, even though it was only used for SMD disks.

And this identifier is for XY450 SMD Controllers Only

drive_type*: drive type (SMD) (just call this "xy450 drive type")

partition: Defines a partition table for a specific disk type. The partition table contains the partitioning information, plus a name that lets you refer to it in format(1M). The default data file contains default parition definitions for several kinds of disk drives. Add a partition definition if you repartitioned any of the disks on your system. Add as many partition definitions to the data file as you need.

Partition naming conventions differ in SunOS 4.x and in SunOS 5.x.

x: the partitions are named as a ,b, c, d, e ,f, g, h.
x: the partitions are referred to by numbers 0 ,1 ,2 ,3 ,4 ,5 ,6 ,7 .

EXAMPLES

Following is a sample disk_type and partition definition in format.dat file for SUN0535 disk device.

disk_type = "SUN0535" \
        : ctlr = SCSI : fmt_time = 4 \
        : ncyl = 1866 : acyl = 2 : pcyl = 2500 : nhead = 7 : nsect = 80 \
        : rpm = 5400

partition = "SUN0535" \

        : disk = "SUN0535" : ctlr = SCSI \
        : 0 = 0, 64400 : 1 = 115, 103600 : 2 = 0, 1044960 : 6 = 300, 876960

FILES

/etc/format.dat: default data file if format -x is not specified, nor is

there a format.dat file in the current directory.

File Formats..format.dat ( 4 ) SEE ALSO

format(1M)

Peripherals Administration

forward(4)

NAME

aliases, addresses, forward - addresses and aliases for sendmail

SYNOPSIS

/etc/mail/aliases

/etc/mail/aliases.dir
/etc/mail/aliases.pag
~/.forward

DESCRIPTION

These files contain mail addresses or aliases, recognized by sendmail(1M) for the local host:

/etc/passwd: Mail addresses (usernames) of local users.

/etc/aliases: Aliases for the local host, in ASCII format. This file can be edited to add, update, or delete local mail aliases.

/etc/aliases. { dir , pag}: The aliasing information from /etc/aliases, in binary, dbm format for use by sendmail(1M). The program newaliases(1), which is

invoked automatically by sendmail(1M), maintains these files.

/.forward: Addresses to which a user's mail is forwarded (see Automatic Forwarding, below).

In addition, the YP name services aliases map mail.aliases contains addresses and aliases available for use across the network.

Addresses

As distributed, sendmail(1M) supports the following types of addresses:

Local Usernames

username

Each local username is listed in the local host's /etc/passwd file.

Local Filenames

pathname

Messages addressed to the absolute pathname of a file are appended to that file.

Commands

|command

If the first character of the address is a vertical bar, ( | ), sendmail(1M) pipes the message to the standard input of the command the bar precedes.

DARPA-standard

username@domain

Addresses

.COM: Commercial organizations.

.EDU: Educational organizations.

.GOV: Government organizations.

.MIL: Military organizations.

For example, the full address of John Smith could be:

js@jsmachine.Podunk-U.EDU

if he uses the machine named jsmachine at Podunk University.

uucp Addresses

. . . [host!]host!username

These are sometimes mistakenly referred to as ``Usenet'' addresses. uucp(1C) provides links to numerous sites throughout the world for the remote copying of files.

Other site-specific forms of addressing can be added by customizing the sendmail.cf configuration file. See sendmail(1M) for details. Standard addresses are recommended.

Aliases Local Aliases

/etc/aliases is formatted as a series of lines of the form

aliasname : address,[address ]

Lines beginning with white space are treated as continuation lines for the preceding alias. Lines beginning with # are comments.

Special Aliases

An alias of the form:

owner-aliasname : address

directs error-messages resulting from mail to aliasname to address ,instead of back to the person who sent the message.

An alias of the form:

aliasname ::include:pathname

with colons as shown, adds the recipients listed in the file pathname to the aliasname alias. This allows a private list to be maintained separately from the aliases file.

YP Domain Aliases

jsmith:js@jsmachine

For example, the alias:

        jsmith:root

sends mail on a YP client to root@podunk-u if the name of the YP domain is podunk-u.

Automatic Forwarding

When an alias (or address) is resolved to the name of a user on the local host, .. sendmail(1M) checks for a: /.forward file, owned by the intended recipient, in that user's

home directory, and with universal read access. This file can contain one or more addresses or aliases as described above, each of which is sent a copy of the user's mail.

A backslash before a username inhibits further aliasing. For instance, to invoke the vaca-.. tion program, user js creates a: /.forward file that contains the line:

\js, "|/usr/ucb/vacation js"

so that one copy of the message is sent to the user, and another is piped into the vacation program.

FILES

/etc/passwd

/etc/mail/aliases
/etc/mail/sendmail.cf
..
 /.forward

NOTES

Because of restrictions in dbm(3B), a single alias cannot contain more than about 1000 characters. Nested aliases can be used to circumvent this limit.

fs(4)

NAME

default_fs, fs - specify the default file system type for local or remote file systems

DESCRIPTION

The default file system types can be changed by editing the default files with a text editor.

FILES

/etc/vfstab: list of default parameters for each file system

/etc/default/fs: the default local file system type

/etc/dfs/fstypes the default remote file system type

NAME

fs_ufs, inode_ufs, inode - format of a ufs file system volume

SYNOPSIS

Standard ufs file system storage volumes have a common format for certain vital information. Every volume is divided into a certain number of blocks. The block size is a parameter of the file system. Sectors 0 to 15 contain primary and secondary bootstrapping programs.

#include <sys/types.h>
#include <sys/fs/ufs_fs.h>
#include <sys/fs/ufs_inode.h>

DESCRIPTION

The actual file system begins at sector 16 with the super-block. The layout of the superblock is defined by the header <sys/fs/ufs_fs.h>.

Each disk drive contains some number of file systems. A file system consists of a number of cylinder groups. Each cylinder group has inodes and data.

A file system is described by its super-block, and by the information in the cylinder group blocks. The super-block is critical data and is replicated before each cylinder group block to protect against catastrophic loss. This is done at file system creation time and the critical super-block data does not change, so the copies need not be referenced.

fs_clean indicates the state of the file system. The FSCLEAN state indicates an undamaged, cleanly unmounted file system. The FSACTIVE state indicates a mounted file system that has been updated. The FSSTABLE state indicates an idle mounted file system. It is not necessary to run fsck on any unmounted file systems with a state of FSCLEAN or FSSTABLE. mount (2)will return ENOSPC if a ufs file system with a state of FSACTIVE is being mounted for read-write.

To provide additional safeguard, fs_clean could be trusted only if fs_state contains a value equal to FSOKAY - fs_time, where FSOKAY is a constant integer. Otherwise, fs_clean is treated as though it contains the value of FSACTIVE.

Addresses stored in inodes are capable of addressing fragments of "blocks." File system blocks of at most, size MAXBSIZE can be optionally broken into 2, 4, or 8 pieces, each of which is addressable; these pieces may be DEV_BSIZE or some multiple of a DEV_BSIZE unit.

Large files consist exclusively of large data blocks. To avoid undue wasted disk space, the last data block of a small file is allocated only as many fragments of a large block as are necessary. The file system format retains only a single pointer to such a fragment, which is a piece of a single large block that has been divided. The size of such a fragment is determinable from information in the inode, using the blksize(fs, ip, lbn) macro.

The file system records space availability at the fragment level; aligned fragments are examined to determine block availability.

The root inode is the root of the file system. Inode 0 cannot be used for normal purposes and historically, bad blocks were linked to inode 1. Thus the root inode is 2 (inode 1 is no longer used for this purpose; however numerous dump tapes make this assumption, so we are stuck with it). The lost+found directory is given the next available inode when it is initially created by mkfs(1M).

fs_minfree gives the minimum acceptable percentage of file system blocks which may be free. If the freelist drops below this level only the super-user may continue to allocate blocks. fs_minfree may be set to 0 if no reserve of free blocks is deemed necessary, however severe performance degradations will be observed if the file system is run at greater than 90% full; thus the default value of fs_minfree is 10%.

Empirically the best trade-off between block fragmentation and overall disk utilization at a loading of 90% comes with a fragmentation of 8; thus the default fragment size is an eighth of the block size.

fs_optim specifies whether the file system should try to minimize the time spent allocating blocks, or if it should attempt to minimize the space fragmentation on the disk. If the value of fs_minfree is less than 10%, then the file system defaults to optimizing for space to avoid running out of full sized blocks. If the value of fs_minfree is greater than or equal to 10%, fragmentation is unlikely to be problematical, and the file system defaults to optimizing for time.

Cylinder group related limits: Each cylinder keeps track of the availability of blocks at different rotational positions, so that sequential blocks can be laid out with minimum rotational latency. fs_nrpos is the number of rotational positions which are distinguished. With the default fs_nrpos of 8, the resolution of the summary information is 2ms for a typical 3600 rpm drive.

fs_rotdelay gives the minimum number of milliseconds to initiate another disk transfer on the same cylinder. It is used in determining the rotationally optimal layout for disk blocks within a file; the default value for fs_rotdelay varies from drive to drive (see tunefs(1M)).

fs_maxcontig gives the maximum number of blocks, belonging to one file, that will be allocated contiguously before inserting a rotational delay.

Each file system has a statically allocated number of inodes. An inode is allocated for each NBPI bytes of disk space. The inode allocation strategy is extremely conservative.

MINBSIZE is the smallest allowable block size. With a MINBSIZE of 4096 it is possible to create files of size 2^32 with only two levels of indirection. MINBSIZE must be large enough to hold a cylinder group block, thus changes to (struct cg) must keep its size within MINBSIZE. Note: super-blocks are never more than size SBSIZE.

The path name on which the file system is mounted is maintained in fs_fsmnt. MAXMNTLEN defines the amount of space allocated in the super-block for this name.

The limit on the amount of summary information per file system is defined by MAXCSBUFS. It is currently parameterized for a maximum of two million cylinders.

Per cylinder group information is summarized in blocks allocated from the first cylinder group's data blocks. These blocks are read in from fs_csaddr (size fs_cssize) in addition to the super-block.

Note: sizeof (struct csum) must be a power of two in order for the fs_cs macro to work.

The inode is the focus of all file activity in the file system. There is a unique inode allocated for each active file, each current directory, each mounted-on file, text file, and the root. An inode is "named" by its device/i-number pair. For further information, see the header <sys/fs/ufs_inode.h>.

NAME

fspec - format specification in text files

DESCRIPTION

It is sometimes convenient to maintain text files on the system with non-standard tabs, (tabs that are not set at every eighth column). Such files must generally be converted to a standard format, frequently by replacing all tabs with the appropriate number of spaces, before they can be processed by system commands. A format specification occurring in the first line of a text file specifies how tabs are to be expanded in the remainder of the file.

A format specification consists of a sequence of parameters separated by blanks and surrounded by the brackets <: and :>. Each parameter consists of a keyletter, possibly followed immediately by a value. The following parameters are recognized:

ttabs: The t parameter specifies the tab settings for the file. The value of tabs must be one of the following:

A list of column numbers separated by commas,

indicating tabs set at the specified columns

A '--' followed immediately by an integer

n, indicating tabs at intervals of n columns

A '--' followed by the name of a ``canned'' tab specification

Standard tabs are specified by t--8 ,or equivalently, t1,9,17,25, etc. The canned tabs that are recognized are defined by the tabs(1) command.

ssize: The s parameter specifies a maximum line size. The value of size must be an integer. Size checking is performed after tabs have been expanded, but before the margin is prepended.

mmargin The m parameter specifies a number of spaces to be prepended to each line.: The value of margin must be an integer.

d: The d parameter takes no value. Its presence indicates that the line containing the format specification is to be deleted from the converted file.

e: The e parameter takes no value. Its presence indicates that the current format is to prevail only until another format specification is encountered in the file.

Default values, which are assumed for parameters not supplied, are t--8 and m0. If the s parameter is not specified, no size checking is performed. If the first line of a file does not contain a format specification, the above defaults are assumed for the entire file. The following is an example of a line containing a format specification:

* <:t5,10,15 s72:> *

If a format specification can be disguised as a comment, it is not necessary to code the d parameter.

NAME

fstypes - file that registers distributed file system packages

DESCRIPTION

fstypes resides in directory /etc/dfs and lists distributed file system utilities packages installed on the system. For each installed distributed file system type, there is a line that begins with the file system type name (for example, ``nfs''), followed by white space and descriptive text.

The file system indicated in the first line of the file is the default file system; when Distributed File System (DFS) Administration commands are entered without the option -F fstypes, the system takes the file system type from the first line of the fstypes file.

The default file system can be changed by editing the fstypes file with any supported text editor.

NAME

group - group file

DESCRIPTION

The group file is a local source of group information. The group file can be used in conjunction with other group sources, including the NIS maps group.byname and group.bygid and the NIS+ table group. Programs use the getgrnam(3C) routines to access this information.

The group file contains a one-line entry for each group recognized by the system, of the form:

        groupname: password: gid: user-list
groupname             The name of the group.
gid                   The group's unique numerical ID within the system.
user-list             A comma-separated list of users allowed in the group.

If the password field is empty, no password is demanded. During user identification and authentication, the supplementary group access list is initialized sequentially from information in this file. If a user is in more groups than the system is configured for, {NGROUPS_MAX}, a warning will be given and subsequent group specifications will be ignored.

Malformed entries cause routines that read this file to halt, in which case group assignments specified further along are never made. To prevent this from happening, use grpck(1B) to check the /etc/group database from time to time.

Previous releases used a group entry beginning with a `+' (plus sign) or `--' (minus sign) to selectively incorporate entries from NIS maps for group. If still required, this is supported by specifying group:compat in nsswitch.conf(4). The ``compat'' source may not be supported in future releases. The preferred sources are, ``files'' followed by ``nisplus''. This has the effect of incorporating the entire contents of the NIS+ group table after the group file.

EXAMPLES

Here is a sample group file:

root::0:root
stooges:q.mJzTnu8icF.:10:larry,moe,curly

and the sample group entry from nsswitch.conf:

group: files nisplus

With these entries, the group stooges will have members larry, moe, and curly, and all groups listed in the NIS+ group table are effectively incorporated after the entry for stooges.

If the group file was:

root::0:root
stooges:q.mJzTnu8icF.:10:larry,moe,curly
+:

and the group entry from nsswitch.conf:

group: compat

all the groups listed in the NIS group.bygid and group.byname maps would be effectively incorporated after the entry for stooges.

NAME

holidays - prime/nonprime table for the accounting system

SYNOPSIS

/etc/acct/holidays

DESCRIPTION

The /etc/acct/holidays file describes which hours are considered prime time and which days are holidays. Holidays and weekends are considered non-prime time hours. /etc/acct/holidays is used by the accounting system.

All lines beginning with an "** "are comments.

The /etc/acct/holidays file consists of two sections. The first non-comment line defines the current year and the start time of prime and non-prime time hours, in the form:

current_year: prime_start

non_prime_start

The remaining non-comment lines define the holidays in the form:

month/day: company_holiday

Of these two fields, only the month/day is actually used by the accounting system programs.

The /etc/acct/holidays file must be updated each year.

EXAMPLES

The following is an example of the /etc/acct/holidays file:

* Prime/Nonprime Table for the accounting system

* Curr Prime Non-Prime
* Year Start    Start
*
 1991  0830    1800
*
* only the first column (month/day) is significant.
*
* month/day     Company
*               Holiday
*
1/1             New Years Day
5/30            Memorial Day
7/4             Indep. Day
9/5             Labor Day
11/24           Thanksgiving Day
11/25           day after Thanksgiving
12/25           Christmas
12/26           day after Christmas

NAME

hosts - host name database

SYNOPSIS

/etc/inet/hosts

/etc/hosts

DESCRIPTION

The hosts file is a local database that associates the names of hosts with their Internet Protocol (IP) addresses. The hosts file can be used in conjunction with, or instead of, other hosts databases, including the Domain Name System (DNS), the NIS hosts map and the NIS+ hosts table. Programs use library interfaces to access information in the hosts file.

The hosts file has one entry for each IP address of each host. If a host has more than one IP address, it will have one entry for each. The format of each line is:

IP-address: official-host-name

nicknames . . .

Items are separated by any number of SPACE and/or TAB characters. The first item on a line is the host's IP address. The second entry is the host's official name. Subsequent entries on the same line are alternative names for the same machine, or "nicknames." Nicknames are optional. A `# 'indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file.

Network addresses are written in the conventional "decimal dot" notation and interpreted using the inet_addr routine from the Internet address manipulation library, inet(3N). Host names may contain any printable character other than a field delimiter, NEWLINE, or comment character. It is recommended that host names not contain `.' (dot).

EXAMPLES

Here is a typical line from the hosts file:

9.1.20 gaia
# John Smith

NOTES

/etc/inet/hosts is the official SVR4 name of the hosts file. The symbolic link /etc/hosts exists for BSD compatibility.

hosts.equiv(4)

NAME

hosts.equiv, .rhosts - trusted remote hosts and users

DESCRIPTION

The /etc/hosts.equiv and .rhosts files provide the ``remote authentication'' database for rlogin(1), rsh(1), rcp(1), and rcmd(3N). The files specify remote hosts and users that are considered trusted. Trusted users are allowed to access the local system without supplying a password. The library routine ruserok( ) (see rcmd(3N)) performs the authentication procedure for programs by using the /etc/hosts.equiv and .rhosts files. The /etc/hosts.equiv file applies to the entire system, while individual users can maintain their own .rhosts files in their home directories.

These files bypass the standard password-based user authentication mechanism. To maintain system security, care must be taken in creating and maintaining these files.

The remote authentication procedure determines whether a user from a remote host should be allowed to access the local system with the identity of a local user. This procedure first checks the /etc/hosts.equiv file and then checks the .rhosts file in the home directory of the local user who is requesting access. Entries in these files can be of two forms. Positive entries allow access, while negative entries deny access. The authentication succeeds when a matching positive entry is found. The procedure fails when the first matching negative entry is found, or if no matching entries are found in either file. Thus, the order of entries is important; If the files contain positive and negative entries, the entry that appears first will prevail. The rsh(1) and rcp(1) programs fail if the remote authentication procedure fails. The rlogin program falls back to the standard passwordbased login procedure if the remote authentication fails.

Both files are formatted as a list of one-line entries. Each entry has the form:

hostname [username]

Negative entries are differentiated from positive entries by a `-' character preceding either the hostname or username field.

Positive Entries

If the form:

hostname

is used, then users from the named host are trusted. That is, they may access the system with the same user name as they have on the remote system. This form may be used in both the /etc/hosts.equiv and .rhosts files.

If the line is in the form:

hostname username

then the named user from the named host can access the system. This form may be used in individual .rhosts files to allow remote users to access the system as a different local user. If this form is used in the /etc/hosts.equiv file, the named remote user will be allowed to access the system as any local user.

netgroup(4) can be used in either the hostname or username fields to match a number of hosts or users in one entry. The form:

+@netgroup

allows access from all hosts in the named netgroup. When used in the username field, netgroups allow a group of remote users to access the system as a particular local user. The form:

hostname +@netgroup

allows all of the users in the named netgroup from the named host to access the system as the local user. The form:

+@netgroup1 +@netgroup2

allows the users in netgroup2 from the hosts in netgroup1 to access the system as the local user.

The special character `+' can be used in place of either hostname or username to match any host or user. For example, the entry

will allow a user from any remote host to access the system with the same username. The entry

+ username

will allow the named user from any remote host to access the system. The entry

hostname +

will allow any user from the named host to access the system as the local user.

Negative Entries

Negative entries are preceded by a `/-' sign. The form:

-hostname

will disallow all access from the named host. The form:

-@netgroup

means that access is explicitly disallowed from all hosts in the named netgroup. The form:

hostname -username

disallows access by the named user only from the named host, while the form:

+ -@netgroup

will disallow access by all of the users in the named netgroup from all hosts.

FILES

/etc/hosts.equiv

~/.rhosts

NOTES

Hostnames in /etc/hosts.equiv and .rhosts files must be the official name of the host, not one of its nicknames.

Root access is handled as a special case. Only the .rhosts file is checked when access is being attempted for root. To help maintain system security, the /etc/hosts.equiv file is not checked.

As a security feature, the .rhosts file must be owned by the user who is attempting access.

Positive entries in /etc/hosts.equiv that include a username field (either an individual named user, a netgroup, or `+' sign) should be used with extreme caution. Because /etc/hosts.equiv applies system-wide, these entries allow one, or a group of, remote users to access the system as any local user. This can be a security hole.

inetd.conf(4)

NAME

inetd.conf - Internet servers database

SYNOPSIS

/etc/inet/inetd.conf

/etc/inetd.conf

DESCRIPTION

The inetd.conf file contains the list of servers that inetd(1M) invokes when it receives an Internet request over a socket. Each server entry is composed of a single line of the form:

service-name endpoint-type protocol wait-status uid server-program server-arguments

Fields are separated by either SPACE or TAB characters. A `# '(number sign) indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search this file.

service-name: The name of a valid service listed in the services file. For RPC services, the value of the service-name field consists of the RPC service name or program number, followed by a '/' (slash) and either a version number or a range of version numbers (for example, rstatd/2-4).

endpoint-type: Can be one of:

stream: for a stream socket,

dgram: for a datagram socket,

raw: for a raw socket,

seqpacket: for a sequenced packet socket

tli: for all tli endpoints

protocol: Must be a recognized protocol listed in the file /etc/inet/protocols. For RPC services, the field consists of the string rpc followed by a '/' (slash) and either a '* '(asterisk), one or more nettypes, one or more netids, or a combination of nettypes and netids. Whatever the value, it is first treated as a nettype. If it is not a valid nettype, then it is treated as a netid. For example, rpc/* for an RPC service using all the transports supported by the system (the list can be found in the /etc/netconfig file), equivalent to saying rpc/visible rpc/ticots for an RPC service using the Connection-Oriented Transport Service.

wait-status: nowait for all but "single-threaded" datagram servers -- servers which do not release the socket until a timeout occurs. These must have the status wait. Do not configure udp services as nowait. This will cause a race condition where the inetd program selects on the socket and the server program reads from the socket. Many server programs will be forked and performance will be severly compromised.

uid: The user ID under which the server should run. This allows

servers to run with access privileges other than those for root.

server-program: Either the pathname of a server program to be invoked by inetd to

perform the requested service, or the value internal if inetd itself provides the service.

server-arguments: If a server must be invoked with command line arguments, the entire command line (including argument 0) must appear in this field (which consists of all remaining words in the entry). If the server expects inetd to pass it the address of its peer (for compatibility with 4.2 BSDexecutable daemons), then the first argument to the command should be specified as `%A'. No more than five arguments are allowed in this field.

FILES

/etc/netconfig: network configuration file

/etc/inet/protocols: Internet protocols

/etc/inet/services: Internet network services

NOTES

/etc/inet/inetd.conf is the official SVR4 name of the inetd.conf file. The symbolic link /etc/inetd.conf exists for BSD compatibility.

init.d(4)

NAME

init.d - initialization and termination scripts for changing init states

SYNOPSIS

/etc/init.d

DESCRIPTION

/etc/init.d is a directory containing initialization and termination scripts for changing init states. These scripts are linked when appropriate to files in the rc?.d directories, where `?' is a single character corresponding to the init state. See init(1M) for definitions of the states.

File names in rc?.d directories are of the form [SK]nn<init.d filename> ,where S means start this job, K means kill this job, and nn is the relative sequence number for killing or starting the job. When entering a state (init S,0,2,3,etc.) the rc[S0-6] script executes those scripts in /etc/rc[S0-6].d that are prefixed with K followed by those scripts prefixed with S. When executing each script in one of the /etc/rc[S0-6] directories, the /sbin/rc[S0-6] script passes a single argument. It passes the argument 'stop' for scripts prefixed with K and the argument 'start' for scripts prefixed with S. There is no harm in applying the same sequence number to multiple scripts. In this case the order of execution is deterministic but unspecified.

Guidelines for selecting sequence numbers are provided in README files located in the directory associated with that target state. For example, /etc/rc[S0-6].d/README. Absence of a README file indicates that there are currently no established guidelines.

EXAMPLES

When changing to init state 2 (multi-user mode, network resources not exported), /sbin/rc2 is initiated by the init process. The following steps are performed by /sbin/rc2.

In the directory /etc/rc2.d are files used to stop processes that should not be running in state 2. The filenames are prefixed with K. Each K file in the directory is executed (by /sbin/rc2) in alpha-numeric order when the system enters init state 2. See example below.
Also in the rc2.d directory are files used to start processes that should be running in state 2. As in the Step 1, each S file is executed.
Assume the file /etc/netdaemon is a script that will initiate networking daemons when given the argument argument 'stop'. It is linked to
/etc/rc2.d/S68netdaemon, and to /etc/rc0.d/K67netdaemon. The file is executed by /etc/rc2.d/S68netdaemon start when init state 2 is entered and by /etc/rc0.d/S67netdaemon stop when shutting the system down.

NOTES

/sbin/rc2 has references to the obsolescent rc.d directory. These references are for compatibility with old INSTALL scripts. New INSTALL scripts should use the init.d directory for related executables. The same is true for the shutdown.d directory.

inittab(4)

NAME

inittab - script for init

DESCRIPTION

The file /etc/inittab controls process dispatching by init. The processes most typically dispatched by init are daemons.

The inittab file is composed of entries that are position dependent and have the following format:

id: rstate: action: process

Each entry is delimited by a newline; however, a backslash (\) preceding a newline indicates a continuation of the entry. Up to 512 characters for each entry are permitted. Comments may be inserted in the process field using the convention for comments described in sh(1). There are no limits (other than maximum entry size) imposed on the number of entries in the inittab file. The entry fields are:

id: One or two characters used to uniquely identify an entry.

rstate: Define the run level in which this entry is to be processed. Run-levels effectively correspond to a configuration of processes in the system. That is, each process spawned by init is assigned a run level(s) in which it is allowed to exist. The run levels are represented by a number ranging from 0 through 6 . For example, if the system is in run level 1 ,only those entries having a 1 in the rstate field are processed.

When init is requested to change run levels, all processes that do not have an entry in the rstate field for the target run level are sent the warning signal SIGTERM and allowed a 5-second grace period before being forcibly terminated by the kill signal SIGKILL . The rstate field can define multiple run levels for a process by selecting more than one run level in any combination from 0 through 6 . If no run level is specified, then the process is assumed to be valid at all run levels 0 through 6 .

There are three other values, a ,b and c, which can appear in the rstate field, even though they are not true run levels. Entries which have these characters in the rstate field are processed only when an init or telinit process requests them to be run (regardless of the current run level of the system). See init(1M). These differ from run levels in that init can never enter run level a ,b or c. Also, a request for the execution of any of these processes does not change the current run level. Furthermore, a process started by an a ,b or c command is not killed when init changes levels. They are killed only if their line in inittab is marked off in the action field, their line is deleted entirely from inittab, or init goes into single-user state.

action: Key words in this field tell init how to treat the process specified in the process field. The actions recognized by init are as follows:

respawn: If the process does not exist, then start the process; do not wait for its termination (continue scanning the inittab file), and when the process dies, restart the process. If the process currently exists, do nothing and continue scanning the inittab file.

wait: When init enters the run level that matches the entry's rstate, start the process and wait for its termination. All subsequent reads of the inittab file while init is in the same run level cause init to ignore this entry.

once: When init enters a run level that matches the entry's rstate, start the process, do not wait for its termination. When it dies, do not restart the process. If init enters a new run level and the process is still running from a previous run level change, the program is not restarted.

boot: The entry is to be processed only at init's boot-time read of the inittab file. init is to start the process and not wait for its termination; when it dies, it does not restart the process. In order for this instruction to be meaningful, the rstate should be the default or it must match init's run level at boot time. This action is useful for an initialization function following a hardware reboot of the system.

bootwait: The entry is to be processed the first time init goes from single-user to multi-user state after the system is booted. (If initdefault is set to 2 ,the process runs right after the boot.) init starts the process, waits for its termination and, when it dies, does not restart the process.

powerfail: Execute the process associated with this entry only when init receives a power fail signal, SIGPWR (see signal(3C)).

powerwait Execute the process associated with this entry only when init: receives a power fail signal, SIGPWR ,and wait until it terminates before continuing any processing of inittab.

off: If the process associated with this entry is currently running, send the warning signal SIGTERM and wait 5 seconds before forcibly terminating the process with the kill signal SIGKILL . If the process is nonexistent, ignore the entry.

ondemand This instruction is really a synonym for the respawn action. It is: functionally identical to respawn but is given a different keyword in order to divorce its association with run levels. This instruction is used only with the a ,b or c values described in the rstate field.

initdefault An entry with this action is scanned only when init is initially: invoked. init uses this entry to determine which run level to enter initially. It does this by taking the highest run level specified in the rstate field and using that as its initial state. If the rstate field is empty, this is interpreted as 0123456 and init will enter run level 6 . This will cause the system to loop (it will go to firmware and reboot continuously). Additionally, if init does not find an initdefault entry in inittab, it requests an initial run level from the user at reboot time.

sysinit: Entries of this type are executed before init tries to access the console (that is, before the Console Login: prompt). It is expected that this entry will be used only to initialize devices that init might try to ask the run level question. These entries are executed and init waits for their completion before continuing.

process: Specify a command to be executed. The entire process field is prefixed with exec and passed to a forked sh as sh -c .exec command.. For this reason, any legal sh syntax can appear in the process field.

NAME

fs_ufs, inode_ufs, inode - format of a ufs file system volume

SYNOPSIS

The actual file system begins at sector 16 with the super-block. The layout of the superblock is defined by the header <sys/fs/ufs_fs.h>.

#include <sys/types.h>
#include <sys/fs/ufs_fs.h>
#include <sys/fs/ufs_inode.h>

DESCRIPTION

Each disk drive contains some number of file systems. A file system consists of a number of cylinder groups. Each cylinder group has inodes and data.

The file system records space availability at the fragment level; aligned fragments are examined to determine block availability.

fs_maxcontig gives the maximum number of blocks, belonging to one file, that will be allocated contiguously before inserting a rotational delay.

Each file system has a statically allocated number of inodes. An inode is allocated for each NBPI bytes of disk space. The inode allocation strategy is extremely conservative.

The path name on which the file system is mounted is maintained in fs_fsmnt. MAXMNTLEN defines the amount of space allocated in the super-block for this name.

The limit on the amount of summary information per file system is defined by MAXCSBUFS. It is currently parameterized for a maximum of two million cylinders.

Note: sizeof (struct csum) must be a power of two in order for the fs_cs macro to work.

NAME

fs_ufs, inode_ufs, inode - format of a ufs file system volume

SYNOPSIS

The actual file system begins at sector 16 with the super-block. The layout of the superblock is defined by the header <sys/fs/ufs_fs.h>.

#include <sys/types.h>
#include <sys/fs/ufs_fs.h>
#include <sys/fs/ufs_inode.h>

DESCRIPTION

Each disk drive contains some number of file systems. A file system consists of a number of cylinder groups. Each cylinder group has inodes and data.

The file system records space availability at the fragment level; aligned fragments are examined to determine block availability.

fs_maxcontig gives the maximum number of blocks, belonging to one file, that will be allocated contiguously before inserting a rotational delay.

Each file system has a statically allocated number of inodes. An inode is allocated for each NBPI bytes of disk space. The inode allocation strategy is extremely conservative.

The path name on which the file system is mounted is maintained in fs_fsmnt. MAXMNTLEN defines the amount of space allocated in the super-block for this name.

The limit on the amount of summary information per file system is defined by MAXCSBUFS. It is currently parameterized for a maximum of two million cylinders.

Note: sizeof (struct csum) must be a power of two in order for the fs_cs macro to work.

NAME

sysbus, isa, eisa, mca - configuration files for ISA, EISA, and MCA bus device drivers

AVAILABILITY

Here are three sample entries from three different driver.conf files:

DESCRIPTION

All bus drivers of class sysbus recognize the following properties:

intr: An arbitrary-length array where each element of the array consists of a pair of integers. Each array element describes a possible interrupt that the device might generate.

The second integer of each pair denotes the hardware interrupt request (IRQ) number.

The driver can refer to the elements of this array by index using ddi_add_intr(9F). The index into the array is passed as the inumber argument of ddi_add_intr( ).

Only devices that generate interrupts need to provide intr properties.

reg: An arbitrary-length array where each element of the array consists of a 3-tuple of integers. Each array element describes a contiguous memory address range associated with the device on the bus.

The first integer of the tuple is reserved.

All sysbus device drivers must provide reg properties. The first two

ioaddr: An integer that describes the I/O port base address for this device.

dmachan: An integer that specifies the DMA channel used by this device. Only devices that use a DMA channel need to provide dmachan properties.

EXAMPLES

name="fdc" class="sysbus" intr=5,6 ioaddr=0x3f0 dmachan=2 reg=0x3f0,0,0;

name="logi" class="sysbus" intr=1,4 ioaddr=0x23c reg=0x23c,0,0;
name="sbpro" class="sysbus" ioaddr=0x220 intr=5,7 dmachan=1 reg=0x220,0,0;

NAME

issue - issue identification file

DESCRIPTION

The file /etc/issue contains the issue or project identification to be printed as a login prompt. issue is an ASCII file that is read by program getty and then written to any terminal spawned or respawned from the lines file.

FILES

/etc/issue

NAME

keytables - keyboard table descriptions for loadkeys and dumpkeys

AVAILABILITY

SPARC

DESCRIPTION

These files are used by loadkeys(1) to modify the translation tables used by the keyboard streams module and generated by (see loadkeys(1)) from those translation tables.

Any line in the file beginning with # is a comment, and is ignored. # is treated specially only at the beginning of a line.

Other lines specify the values to load into the tables for a particular keystation. The format is either:

key number list_of_entries

swap number1 with number2

key number1 same as number2

or a blank line, which is ignored.

key number list_of_entries

sets the entries for keystation number from the list given. An entry in that list is of the form

tablename code

where tablename is the name of a particular translation table, or all. The translation tables are:

base: entry when no shifts are active

shift: entry when "Shift" key is down

caps: entry when "Caps Lock" is in effect

ctrl: entry when "Control" is down

altg: entry when "Alt Graph" is down

numl: entry when "Num Lock" is in effect

up: entry when a key goes up

All tables other than up refer to the action generated when a key goes down. Entries in the up table are used only for shift keys, since the shift in question goes away when the key goes up, except for keys such as "Caps Lock" or "Num Lock"; the keyboard streams module makes the key look as if it were a latching key.

A table name of all indicates that the entry for all tables should be set to the specified value, with the following exception: for entries with a value other than hole ,the entry for the numl table should be set to nonl, and the entry for the up table should be set to nop.

The code specifies the effect of the key in question when the specified shift key is down. A code consists of either:

A character, which indicates that the key should generate the given character. The character can either be a single character, a single character preceded by ^ which refers to a "control character" (for instance, ^c is control-C), or a C-style character constant enclosed in single quote characters ('), which can be expressed with C-style escape sequences such as \r for RETURN or \000 for the null character. Note that the single character may be any character in an 8-bit character set, such as ISO 8859/1.

A string, consisting of a list of characters enclosed in double quote characters ("). Note that the use of the double quote character means that a code of double quote must be enclosed in single quotes.

One of the following expressions:

shiftkeys+leftshift

the key is to be the left-hand "Shift" key

shiftkeys+rightshift

the key is to be the right-hand "Shift" key

shiftkeys+leftctrl

the key is to be the left-hand "Control" key

shiftkeys+rightctrl

the key is to be the right-hand "Control" key

shiftkeys+alt

the key is to be the "Alt" shift key

shiftkeys+altgraph

the key is to be the "Alt Graph" shift key

shiftkeys+capslock

the key is to be the "Caps Lock" key

shiftkeys+shiftlock

the key is to be the "Shift Lock" key

shiftkeys+numlock

the key is to be the "Num Lock" key

buckybits+systembit

the key is to be the "Stop" key in SunView; this is normally the L1 key, or the SETUP key on the VT100 keyboard

buckybits+metabit

the key is to be the "meta" key. That is, the "Left" or "Right" key on a Sun-2 or Sun-3 keyboard or the "diamond" key on a Sun-4 keyboard

compose

the key is to be the "Compose" key

ctrlq: on the "VT100" keyboard, the key is to transmit the control-Q character (this would be the entry for the "Q" key in the ctrl table)

ctrls: on the "VT100" keyboard, the key is to transmit the control-S character (this would be the entry for the "S" key in the ctrl table)

noscroll

on the "VT100" keyboard, the key is to be the "No Scroll" key

string+uparrow

the key is to be the "up arrow" key

string+downarrow

the key is to be the "down arrow" key

string+leftarrow

the key is to be the "left arrow" key

string+rightarrow

the key is to be the "right arrow" key

string+homearrow

the key is to be the "home" key

fa_acute

the key is to be the acute accent "floating accent" key

fa_cedilla

the key is to be the cedilla "floating accent" key

fa_cflex

the key is to be the circumflex "floating accent" key

fa_grave

the key is to be the grave accent "floating accent" key

fa_tilde

the key is to be the tilde "floating accent" key

fa_umlaut

the key is to be the umlaut "floating accent" key

nonl: this is used only in the Num Lock table; the key is not to be affected by the state of Num Lock

pad0: the key is to be the "0" key on the numeric keypad

pad1: the key is to be the "1" key on the numeric keypad

pad2: the key is to be the "2" key on the numeric keypad

pad3: the key is to be the "3" key on the numeric keypad

pad4: the key is to be the "4" key on the numeric keypad

pad5: the key is to be the "5" key on the numeric keypad

pad6: the key is to be the "6" key on the numeric keypad

pad7: the key is to be the "7" key on the numeric keypad

pad8: the key is to be the "8" key on the numeric keypad

pad9: the key is to be the "9" key on the numeric keypad

paddot the key is to be the "." key on the numeric keypad

padenter

the key is to be the "Enter" key on the numeric keypad

padplus

the key is to be the "+" key on the numeric keypad

padminus

the key is to be the "-" key on the numeric keypad

padstar

the key is to be the "* "key on the numeric keypad

padslash

the key is to be the "/" key on the numeric keypad

padequal

the key is to be the "=" key on the numeric keypad

padsep the key is to be the "," (separator) key on the numeric keypad

lf(n): the key is to be the left-hand function key n

rf(n): the key is to be the right-hand function key n

tf(n): the key is to be the top function key n

bf(n): the key is to be the "bottom" function key n

nop: the key is to do nothing

error: this code indicates an internal error; to be used only for keystation 126, and must be used there

idle: this code indicates that the keyboard is idle (that is, has no keys down); to be used only for all entries other than the numl and up table entries for keystation 127, and must be used there

oops: this key exists, but its action is not defined; it has the same effect as nop

reset: this code indicates that the keyboard has just been reset; to be used only for the up table entry for keystation 127, and must be used there.

swap number1 with number2
        exchanges the entries for keystations number1 and number2.

key number1 same as number2

sets the entries for keystation number1 to be the same as those for keystation number2. If the file does not specify entries for keystation number2, the entries currently in the translation table are used; if the file does specify entries for keystation number2, those entries are used.

EXAMPLES

The following entry sets keystation 15 to be a "hole" (that is, an entry indicating that there is no keystation 15); sets keystation 30 to do nothing when Alt Graph is down, generate "!" when Shift is down, and generate "1" under all other circumstances; and sets keystation 76 to be the left-hand Control key.

key 15: all hole

key 30: base 1 shift ! caps 1 ctrl 1 altg nop

key 76: all shiftkeys+leftctrl up shiftkeys+leftctrl

The following entry exchanges the Delete and Back Space keys on the Type 4 keyboard:

swap 43 with 66

Keystation 43 is normally the Back Space key, and keystation 66 is normally the Delete key.

The following entry disables the Caps Lock key on the Type 3 and U.S. Type 4 keyboards:

key 119 all nop

The following specifies the standard translation tables for the U.S. Type 4 keyboard:

key 0: all hole

key 1: all buckybits+systembit up buckybits+systembit

key 2: all hole

key 3: all lf(2)

key 4: all hole

key 5: all tf(1)

key 6: all tf(2)

key 7: all tf(10)

key 8: all tf(3)

key 9: all tf(11)

key 10: all tf(4)

key 11: all tf(12)

key 12: all tf(5)

key 13: all shiftkeys+altgraph up shiftkeys+altgraph

key 14: all tf(6)

key 15: all hole

key 16: all tf(7)

key 17: all tf(8)

key 18: all tf(9)

key 19: all shiftkeys+alt up shiftkeys+alt

key 20: all hole

key 21: all rf(1)

key 22: all rf(2)

key 23: all rf(3)

key 24: all hole

key 25: all lf(3)

key 26: all lf(4)

key 27: all hole

key 28: all hole

key 29: all ^[

key 30: base 1 shift ! caps 1 ctrl 1 altg nop

key 31: base 2 shift @ caps 2 ctrl ^@ altg nop

key 32: base 3 shift # caps 3 ctrl 3 altg nop

key 33: base 4 shift $ caps 4 ctrl 4 altg nop

key 34: base 5 shift % caps 5 ctrl 5 altg nop

key 35: base 6 shift ^ caps 6 ctrl ^^ altg nop

key 36: base 7 shift & caps 7 ctrl 7 altg nop

key 37: base 8 shift * caps 8 ctrl 8 altg nop

key 38: base 9 shift ( caps 9 ctrl 9 altg nop

key 39: base 0 shift ) caps 0 ctrl 0 altg nop

key 40: base - shift _ caps - ctrl ^_ altg nop

key 41: base = shift + caps = ctrl = altg nop

key 42: base ` shift ~ caps ` ctrl ^^ altg nop

key 43: all '\b'

key 44: all hole

key 45: all rf(4) numl padequal

key 46: all rf(5) numl padslash

key 47: all rf(6) numl padstar

key 48: all bf(13)

key 49: all lf(5)

key 50: all bf(10) numl padequal

key 51: all lf(6)

key 52: all hole

key 53: all '\t'

key 54: base q shift Q caps Q ctrl ^Q altg nop

key 55: base w shift W caps W ctrl ^W altg nop

key 56: base e shift E caps E ctrl ^E altg nop

key 57: base r shift R caps R ctrl ^R altg nop

key 58: base t shift T caps T ctrl ^T altg nop

key 59: base y shift Y caps Y ctrl ^Y altg nop

key 60: base u shift U caps U ctrl ^U altg nop

key 61: base i shift I caps I ctrl '\t' altg nop

key 62: base o shift O caps O ctrl ^O altg nop

key 63: base p shift P caps P ctrl ^P altg nop

key 64: base [ shift { caps [ ctrl ^[ altg nop

key 65: base ] shift } caps ] ctrl ^] altg nop

key 66: all '\177'

key 67: all compose

key 68: all rf(7) numl pad7

key 69: all rf(8) numl pad8

key 70: all rf(9) numl pad9

key 71: all bf(15) numl padminus

key 72: all lf(7)

key 73: all lf(8)

key 74: all hole

key 75: all hole

key 76: all shiftkeys+leftctrl up shiftkeys+leftctrl

key 77: base a shift A caps A ctrl ^A altg nop

key 78: base s shift S caps S ctrl ^S altg nop

key 79: base d shift D caps D ctrl ^D altg nop

key 80: base f shift F caps F ctrl ^F altg nop

key 81: base g shift G caps G ctrl ^G altg nop

key 82: base h shift H caps H ctrl '\b' altg nop

key 83: base j shift J caps J ctrl '\n' altg nop

key 84: base k shift K caps K ctrl '\v' altg nop

key 85: base l shift L caps L ctrl ^L altg nop

key 86: base ; shift : caps ; ctrl ; altg nop

key 87: base '\'' shift '"' caps '\'' ctrl '\'' altg nop

key 88: base '\\' shift | caps '\\' ctrl ^\ altg nop

key 89: all '\r'

key 90: all bf(11) numl padenter

key 91: all rf(10) numl pad4

key 92: all rf(11) numl pad5

key 93: all rf(12) numl pad6

key 94: all bf(8) numl pad0

key 95: all lf(9)

key 96: all hole

key 97: all lf(10)

key 98: all shiftkeys+numlock

key 99: all shiftkeys+leftshift up shiftkeys+leftshift

key 100 base z shift Z caps Z ctrl ^Z altg nop

key 101 base x shift X caps X ctrl ^X altg nop

key 102 base c shift C caps C ctrl ^C altg nop

key 103 base v shift V caps V ctrl ^V altg nop

key 104 base b shift B caps B ctrl ^B altg nop

key 105 base n shift N caps N ctrl ^N altg nop

key 106 base m shift M caps M ctrl '\r' altg nop

key 107 base , shift < caps , ctrl , altg nop

key 108 base . shift > caps . ctrl . altg nop

key 109 base / shift ? caps / ctrl ^_ altg nop

key 110 all shiftkeys+rightshift up shiftkeys+rightshift

key 111 all '\n'

key 112 all rf(13) numl pad1

key 113 all rf(14) numl pad2

key 114 all rf(15) numl pad3

key 119 all shiftkeys+capslock

key 120 all buckybits+metabit up buckybits+metabit

key 121 base ' ' shift ' ' caps ' ' ctrl ^@ altg ' '

key 122 all buckybits+metabit up buckybits+metabit

key 123 all hole

key 124 all hole

key 125 all bf(14) numl padplus

key 126 all error numl error up hole

key 127 all idle numl idle up reset

NAME

krb.conf - Kerberos configuration file

SYNOPSIS

/etc/krb.conf

DESCRIPTION

krb.conf contains configuration information describing the Kerberos realm and the Kerberos key distribution center (KDC) servers for known realms.

krb.conf contains the name of the local realm in the first line, followed by lines indicating realm/host entries. The first token is a realm name, and the second is the hostname of a host running a KDC for that realm. There can be multiple lines for a given realm; the servers are tried in order until an active one is found. The words admin server following the hostname indicate that the host also provides an administrative database server. For example:

ATHENA.MIT.EDU
ATHENA.MIT.EDU kerberos-1.mit.edu admin server
ATHENA.MIT.EDU kerberos-2.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu admin server

The Kerberos configuration information can also be supplied using the krb.conf NIS map. If /etc/krb.conf is not found (or the requested information is not found in it), and the system is running NIS, then the information will be obtained from the NIS map. If neither the file nor the NIS map are found, then the Kerberos library will use the domainname (as returned by domainname (1M))as the Kerberos realm, and the host kerberos as the location of the KDC. There is no default for the admin server.

Note that every time krb.conf is modified, kerbd(1M) needs to be restarted.

BUGS

There is no NIS+ support yet for the krb.conf map.

krb.realms(4)

NAME

krb.realms - host to Kerberos realm translation file

SYNOPSIS

/etc/krb.realms

DESCRIPTION

krb.realms provides a translation from a hostname to the Kerberos realm name for the services provided by that host.

Each line of the translation file is in one of the following forms:

host_name kerberos_realm
domain_name kerberos_realm

domain_name should be of the form .XXX.YYY, for example, .LCS.MIT.EDU.

If a hostname exactly matches the host_name field in a line of the first form, the corresponding kerberos_realm is used as the realm of the host. If a hostname does not match any host_name in the file, but its domain exactly matches the domain_name field in a line of the second form, the corresponding kerberos_realm is used as the realm of the host.

If no translation entry applies, the host's realm is considered to be the hostname's domain portion converted to upper case.

BUGS

There is no NIS or NIS+ support for this information.

limits(4)

NAME

limits - header for implementation-specific constants

SYNOPSIS

#include <limits.h>

DESCRIPTION

The header <limits.h> is a list of minimal magnitude limitations imposed by a specific implementation of the operating system.

ARG_MAX          1048320               /** max length of arguments to exec ** /
CHAR_BIT         8                     /** max # of bits in a "char" ** /
CHAR_MAX         255                   /** max value of a "char" ** /
CHAR_MIN         0                     /** min value of a "char" ** /
CHILD_MAX        25                    /** max # of processes per user id ** /
CLK_TCK          _sysconf(3)           /** clock ticks per second ** /
DBL_DIG          15                    /** digits of precision of a "double" ** /
DBL_MAX          1.7976931348623157E+308/** max decimal value of a "double"** /
DBL_MIN          2.2250738585072014E-308/** min decimal value of a "double"** /
FCHR_MAX         1048576               /** historical default file size limit in bytes ** /
FLT_DIG          6                     /** digits of precision of a "float" ** /
FLT_MAX          3.40282347e+38F       /** max decimal value of a "float" ** /
FLT_MIN          1.17549435E-38F       /** min decimal value of a "float" ** /
INT_MAX          2147483647            /** max value of an "int" ** /
INT_MIN          (-2147483647-1)       /** min value of an "int" ** /
LINK_MAX         1000                  /** max # of links to a single file ** /
LOGNAME_MAX      8                     /** max # of characters in a login name ** /
LONG_BIT         32                    /** # of bits in a "long" ** /
LONG_MAX         2147483647            /** max value of a "long int" ** /
LONG_MIN         (-2147483647-1)       /** min value of a "long int" ** /
MAX_CANON        256                   /** max bytes in a line for canonical
                                       processing ** /
MAX_INPUT        512                   /** max size of a char input buffer ** /
MB_LEN_MAX       5                     /** max # of bytes in a multibyte
                                       character ** /
NAME_MAX         14                    /** max # of characters in a file name ** /
NGROUPS_MAX      16                    /** max # of groups for a user ** /
NL_ARGMAX        9                     /** max value of "digit" in calls to the
                                       NLS printf() and scanf() ** /
NL_LANGMAX       14                    /** max # of bytes in a LANG name ** /
NL_MSGMAX        32767                 /** max message number ** /
NL_NMAX          1                     /** max # of bytes in N-to-1 mapping
                                       characters ** /
NL_SETMAX        255                   /** max set number ** /
NL_TEXTMAX       255                   /** max # of bytes in a message string ** /
NZERO            20                    /** default process priority ** /
OPEN_MAX         20                    /** max # of files a process can have
                                       open ** /
PASS_MAX         8                     /** max # of characters in a password ** /
PATH_MAX         1024                  /** max # of characters in a path name ** /
PID_MAX          30000                 /** max value for a process ID ** /

PIPE_BUF         5120                  /** max # bytes atomic in write to a pipe ** /
PIPE_MAX         5120                  /** max # bytes written to a pipe
                                       in a write ** /
SCHAR_MAX        127                   /** max value of a "signed char" ** /
SCHAR_MIN        (-128)                /** min value of a "signed char" ** /
SHRT_MAX         32767                 /** max value of a "short int" ** /
SHRT_MIN         (-32768)              /** min value of a "short int" ** /
STD_BLK          1024                  /** # bytes in a physical I/O block ** /
SYS_NMLN         257                   /** 4.0 size of utsname elements ** /
                                       /** also defined in sys/utsname.h ** /
SYSPID_MAX       1                     /** max pid of system processes ** /
TMP_MAX          17576                 /** max # of unique names generated
                                       by tmpnam ** /
UCHAR_MAX        255                   /** max value of an "unsigned char" ** /
UID_MAX          60000                 /** max value for a user or group ID ** /
UINT_MAX         4294967295            /** max value of an "unsigned int" ** /
ULONG_MAX        4294967295            /** max value of an "unsigned long int" ** /
USHRT_MAX        65535                 /** max value of an "unsigned short int" ** /
USI_MAX          4294967295            /** max decimal value of an "unsigned" ** /
WORD_BIT         32                    /** # of bits in a "word" or "int" ** /

The following POSIX definitions are the most restrictive values to be used by a POSIX conformance application. Conforming implementations shall provide values at least this large.

_POSIX_ARG_MAX         4096  /** max length of arguments to exec ** /
_POSIX_CHILD_MAX       6     /** max # of processes per user ID ** /
_POSIX_LINK_MAX        8     /** max # of links to a single file ** /
_POSIX_MAX_CANON       255   /** max # of bytes in a line of input ** /
_POSIX_MAX_INPUT       255   /** max # of bytes in terminal
                             input queue ** /
_POSIX_NAME_MAX        14    /** # of bytes in a filename ** /
_POSIX_NGROUPS_MAX      0    /** max # of groups in a process ** /
_POSIX_OPEN_MAX        16    /** max # of files a process can have open ** /
_POSIX_PATH_MAX        255   /** max # of characters in a pathname ** /
_POSIX_PIPE_BUF        512   /** max # of bytes atomic in write
                             to a pipe ** /

loadfont(4)

NAME

loadfont - format of a font file used as input to the loadfont utility

AVAILABILITY

As mentioned above, this section, if it exists, must be terminated by ENDPROPERTIES .

DESCRIPTION

This section describes the format of files that can be used to change the font used by the console when using the loadfont(1) utility with the -f option.

The format is compatible with the Binary Distribution Format version 2.1 as developed by Adobe Systems, Inc.; however, certain restrictions apply. Video cards, when used with the Solaris for x86 system in text mode, only accept constant width and constant height fonts in certain sizes.

The loadfont utility also requires that there is a description of all 256 characters of the codeset used specified in the fontfile. Certain attributes are not used by loadfont but are maintained for compatibility purposes.

File Format

A loadfont input file is a plain ASCII file containing only printable characters (octal 40 through 176) and a carriage return at the end of each line.

The information about a particular font should be contained in a single file. The file begins with information on the font in general, followed by the information and bitmaps for the individual characters. The file should contain bitmaps for all 256 characters, and each character should be of the same size.

A font bitmap description file has the following general form, where each item is contained on a separate line of text in the file. Items on a line are separated by spaces:

One or more lines beginning with the word COMMENT . These lines can be used to add comments to the file and will be ignored by the loadfont program.

The word STARTFONT followed by the version number 2.1.

The word FONT followed by the full name of the font. The name may continue all the way to the end of the line, and may contain spaces.

The word SIZE followed by the point size of the characters, the x resolution, and the y resolution of the font. This line is not used by loadfont but it needs to be there for compatibility purposes.

The word FONTBOUNDINGBOX followed by the width in x, height in y, and the x and y displacement of the lower left-hand corner from the origin. Again, this line is not used by loadfont but it must be there for compatibility purposes.

Optionally, the word STARTPROPERTIES followed by the number of properties that follow. If present, the number needs to match the number of lines following this one before the occurrence of a line beginning with ENDPROPERTIES These lines consist of a word for the property name followed by either an integer or string surrounded by double quotes. Properties named FONT_ASCENT FONT_DESCENT and DEFAULT_CHAR are typically present in BDF files to define the logical font-ascent and font-descent and the default-char for the font.

The word CHARS followed by the number of characters that follow. This number should always be 256 .

This terminates the part of the loadfont input file describing features of the font in general. The rest of the file contains descriptions of the individual characters. They consist of the following parts:

The word STARTCHAR followed by up to 14 characters (no blanks) describing the character. This can either be something like C0041, which indicates the hex value of the character or uppercaseA, which describes the character.

The word ENCODING followed by a positive integer representing value by which this character is represented internally in the codeset for which this font is used. The integer needs to be specified in decimal.

The word SWIDTH followed by the scalable width in x and y of character. Scalable widths are in units of 1/1000th of the size of the character. The y value should always be 0 ;the x value is typically 666 for the type of characters used with loadfont. The values are not checked by the loadfont utility, but this line needs to be there for compatibility purposes.

The word DWIDTH followed by two numbers, which in a BDF file would mean the width in x and y of the character in device units. The y value is always zero. The x value is typically 8. loadfont checks only for the presence of the DWIDTH keyword.

The word BBX followed by the width in x, height in y and x and y displacement of the lower left-hand corner from the origin of the character.

Most fonts used by video cards will not use the bottom 4 rows of pixels, which basically means a vertical (y) displacement of -4. The only width allowed by loadfont is 8; heights supported are 8, 14, and 16. All BBX lines of the subsequent characters should list the same height and width as the first one (because only fixed size fonts are supported).

The optional word ATTRIBUTES followed by the attributes as 4 hex-encoded characters. The loadfont utility will accept this line, if present, but there is no meaning attached to it.

The word BITMAP ,which indicates the beginning of the bitmap representation of the character. This line should be followed by height number of lines (height as specified in the BBX line) representing a hex-encoded bitmap of the character, one byte per line.

The word ENDCHAR indicating the end of the bitmap for this character.

After all the bitmaps, the end of the file is indicated by the ENDFONT keyword.

Example

The following example lists the beginning of the loadfont input file for an 8 by 16 font, supporting the IBM 437 codeset, as well as the bitmap representation of the character uppercase A.

STARTFONT 2.1
FONT 8x16
SIZE 16 75 75
FONTBOUNDINGBOX 8 16 0 -4
STARTPROPERTIES 3
FONT_DESCENT 4
FONT_ASCENT 12
DEFAULT_CHAR 0
ENDPROPERTIES
CHARS 256
STARTCHAR C0000
ENCODING 0
. . .

Bitmap for uppercase A character:

STARTCHAR C0041
ENCODING 65
SWIDTH 666 0
DWIDTH 8 0
BBX 8 16 0 -4
BITMAP
00
00
10
38
6c
c6
c6
fe
c6
c6
c6
c6
00
00
00
00
ENDCHAR

FILES

/usr/share/lib/* .bdf

NAME

logindevperm, fbtab - login-based device permissions

SYNOPSIS

/etc/logindevperm

DESCRIPTION

Fields are separated by TAB and/or SPACE characters. Blank lines and comments can appear anywhere in the file; comments start with a hashmark, ` # ', and continue to the end of the line.

Once the devices are owned by the user, their permissions and ownership can be changed using chmod(1) and chown(1), as with any other user-owned file.

FILES

/etc/passwd: File that contains user group information.

NOTES

/etc/logindevperm provides a superset of the functionality provided by /etc/fbtab in SunOS 4.x releases.

loginlog(4)

NAME

loginlog - log of failed login attempts

DESCRIPTION

After five unsuccessful login attempts, all the attempts are logged in the file /var/adm/loginlog. This file contains one record for each failed attempt. Each record contains the login name, tty specification, and time.

This is an ASCII file. Each field within each entry is separated from the next by a colon. Each entry is separated from the next by a new-line.

By default, loginlog does not exist, so no logging is done. To enable logging, the log file must be created with read and write permission for owner only. Owner must be root and group must be sys.

FILES

/var/adm/loginlog

NAME

magic - file command's magic number file

SYNOPSIS

/etc/magic

DESCRIPTION

The file(1) command identifies the type of a file using, among other tests, a test for whether the file begins with a certain magic number. The /etc/magic file specifies what magic numbers are to be tested for, what message to print if a particular magic number is found, and additional information to extract from the file.

Each line of the file specifies a test to be performed. A test compares the data starting at a particular offset in the file with a 1-byte, 2-byte, or 4-byte numeric value or a string. If the test succeeds, a message is printed. The line consists of the following fields:

        offset  type    value   message
offset     A number specifying the offset, in bytes, into the file of the data which is to be
           tested.
type       The type of the data to be tested. The possible values are:
           byte    A one-byte value.
           short   A two-byte value.
           long    A four-byte value.
           string A string of bytes.

The types byte ,short, and long may optionally be followed by a mask specifier of the form &number. If a mask specifier is given, the value is AND'ed with the number before any comparisons are done. The number is specified in C form. For instance, 13 is decimal, 013 is octal, and 0x13 is hexadecimal.

value: The value to be compared with the value from the file. If the type is numeric, this value is specified in C form. If it is a string, it is specified as a C string with the usual escapes permitted (for instance, \n for NEWLINE).

Numeric values may be preceded by a character indicating the operation to be performed. It may be `=', to specify that the value from the file must equal the specified value, `<', to specify that the value from the file must be less than the specified value, `>', to specify that the value from the file must be greater than the specified value, `&', to specify that all the bits in the specified value must be set in the value from the file, `^', to specify that at least one of the bits in the specified value must not be set in the value from the file, or x to specify that any value will match. If the character is omitted, it is assumed to be `='.

For string values, the byte string from the file must match the specified byte string. The byte string from the file which is matched is the same length as the specified byte string.

message: The message to be printed if the comparison succeeds. If the string contains a printf(3S) format specification, the value from the file (with any specified masking performed) is printed using the message as the format string.

Some file formats contain additional information which is to be printed along with the file type. A line which begins with the character `>' indicates additional tests and messages to be printed. If the test on the line preceding the first line with a `>' succeeds, the tests specified in all the subsequent lines beginning with `>' are performed, and the messages printed if the tests succeed. The next line which does not begin with a `>' terminates this.

FILES

/etc/magic

BUGS

There should be more than one level of subtests, with the level indicated by the number of `>' at the beginning of the line.

mca(4)

NAME

sysbus, isa, eisa, mca - configuration files for ISA, EISA, and MCA bus device drivers

AVAILABILITY