LynxOS User's Guide

z

LynxOS System Administration

System Administration Tasks

When a LynxOS system is used heavily by several users either for developing software and/or running applications, it is necessary to perform the following system administration tasks to maintain performance level:

• Adding and removing system devices and terminals

• User support, including security issues

• Spooling system configuration

• System shutdown and reboot

• Disk space maintenance and backup

Using the setup Utility

The setup utility is used through the initial configuration and any subsequent reconfiguration. To run setup, log in to the LynxOS system as setup, then type setup at the command prompt. The setup utility allows users to perform the following tasks:

• Add a password for the setup and root users

• Set up symbolic links for floppy drives (x86 and certain PowerPCs)

• Enable multiple consoles (x86 and certain PowerPCs)

• Enable ttys for login

• Add/delete users to/from the system

• Enable virtual memory

• Set time, time zone and daylight savings support

• Enable Write-Through Cache

The setup utility is a self-documented, menu-driven program. Read all the instructions displayed by setup before making selections.

Managing User Privileges

Many of the programs described in this chapter are available only to users with root access. Root users are often called the superuser because they have more system privileges than other users. The root user has the user ID number 0.

After completing initial system setup, LynuxWorks recommends that a root password be created. Securing the root account protects the system from unwanted intrusion or use from unauthorized users.

Understanding the /etc Directory Contents

The files in the /etc directory are routinely used for system maintenance. The /etc files that need to be set up for each instance of LynxOS to run properly according to its configuration are described below.

/etc Directory Contents  

File	Description
fstab	Contains a list of devices with file systems usually mounted while the system is running. Each line contains five colon-separated fields (listed below) that display information about devices and their mountpoints:   device : mountdir : type : freq : passno The fstab file needs to be accessed by /bin/rc during mounting and file system checks. See the fstab file format man pages; see man pages for the mount and umount utilities for more information.
group	Contains information listed in the four colon-separated fields below, where group_name is the user group's name; * is a vestigial artifact of previous operating systems; GID is the user group's identification number; and users_names is the list of groups that have access to this group's files:   group_name : * : GID : users_names This file is used to add new user groups by inserting a line with the syntax shown above.
motd	Contains the messages of the day from the system administrator. These messages are automatically displayed upon user login.
mtab	Contains information about currently mounted file systems. mtab is not readable or editable by administrators; it is a system file maintained by the mount and umount utilities. The mtab file, if it does not already exist, is created by mount during the initial file system mounting. The file contains a record of mounted devices, but its existence is not critical for proper system operation. See the mtab man page for more information.
nodetab	Contains a list of standard nodes automatically created with the mknod -a command. Each line displays the information about nodes in the colon-separated fields listed below:   name : type : major : minor : perm For more information, see the nodetab and the mknod man pages.
passwd	Contains information describing each user known to the system. Each user is identified by an individual user ID that the passwd file maps to the user name. Each line displays information in the seven colon-separated fields listed below:   name : passwd : uid : gid : info : dir : shell For more information, see the passwd man page in Section 5 of the man pages. The passwd file must exist. It is used by several system programs to relate items of information about a user to each other. It is also consulted by the login program to verify a user name.
printcap	Contains information about the various printers available on the system. Users can set up either local or remote printers. The lpr and lpd commands use this file whenever a print job is queued. For more information on this file, see the printcap man page.
starttab	Contains information read by init at system boot time. The starttab file gives the default umask value; the program to use for the single-user shell at boot time; the name of the system initialization file (usually /bin/rc); and the default data, stack, and core limits for all processes. For more information, see the starttab man page. The init process is the only system process that reads the starttab file. If the starttab file does not exist, init uses its default values.
tconfig	Contains descriptions of serial port configurations; It serves the same purpose as /etc/gettytab on BSDbased systems. The tconfig file is referenced by stty, tset, and other programs to prepare a terminal for some special use. Each entry consists of one or more lines that assign values to various parameters. For more information, see the tconfig man page. The tconfig file is very important. Various utility programs (tset in particular) do not operate if the file cannot be found.
termcap	Contains descriptions of software features for various specific terminal devices. Each entry consists of one or more lines that assign values to various parameters. Terminal descriptions are read by the vi text editor, the shell, and other programs that must manipulate the terminal using software command sequences. The termcap file should exist, and should contain descriptions of all terminals likely to be used with the system.
ttys	Contains a list of serial ports to be recognized by init as valid for login. Each line displays information about its respective serial port or ATC virtual terminal in the five colon-separated fields listed below: device : flag : config : terminal : login For more information on the ttys file, see the ttys man page. The ttys file must exist for init to control multiuser operations.
utmp	Contains entries describing active login sessions. The file consists of records (not accessible for reading) containing the user name, host of origin, and login time for each active session. Each record corresponds to an entry in ttys. The utmp file must exist for the who utility to function. The file is created, if possible, by the login program if it has been removed.

Creating Device Nodes

Under LynxOS, all peripheral devices are accessed through device nodes. Each device must have an associated device node file.

The standard LynxOS image comes with all required device nodes pre-installed on the file system, ready to use. However, if new devices are added to a system, or if a new file system is created on another disk or diskette as the root file system, it becomes necessary to create new device nodes. The mknod program creates device nodes for any character or block device, or named pipe (FIFO). The syntax for making a single character or block device node in the nodetab file is as follows:

# mknod name mode major minor

The italicized items are replaced by the following values:

• name is a LynxOS path name for the new device node. Device nodes can be created in any directory, but they are usually placed in /dev.

• mode represents the transfer interface mode with either the letter c for a character device, or the letter b for a block device.

• major and minor represent the major and minor numbers for the device (for detailed information see "Major and Minor Numbers"). Major and minor numbers are dependent upon the configuration of the operating system, as well as any devices and drivers that have been dynamically installed.

For example, to create a node for the second floppy disk that has a major number of 0 and a minor number of 16, use the following command syntax:

# mknod /dev/fd1 b 0 16

Whenever a root file system is created, device nodes need to be created within the root file system for various utilities to function properly.

To simplify the process of creating device nodes on a new root file system, it is advisable to save the /etc/nodetab file associated with the kernel files that are to be booted with this file system.

Device nodes are listed one per line using the syntax below:

name : type : major : minor : perm

The mknod program reads this file and creates all the device nodes described in it when invoked, as follows:

# mknod -a filename

With the optional filename following the -a switch, the given nodetab file is read instead of /etc/nodetab.

Note: The nodetab file is created in /sys/bsp* and copied to the /etc directory. In effect, there is no difference between the "nodetab" and the /etc/nodetab files.

LynxOS Device Node Naming Conventions

Like UNIX, LynxOS uses device nodes to access drivers for such devices as floppy disks, hard disks, RAM disks, CD-ROMs and tapes. By LynxOS convention, an individual device node for each device must reside in the /dev directory.

Additionally, LynuxWorks has designed a standardized naming convention for device nodes stored in /dev. Adherence to these conventions is required for proper identification by mkboot and kernel booting by preboot to take place.

This section describes the LynxOS device node naming conventions.

Note: While reading through this section, the following device support factors need to be considered: LynxOS supports the following devices on the following platforms: IDE devices on x86, PowerPC, except as noted below SCSI devices on x86 and PowerPC only, except as noted below LynxOS does not support the following devices on the following platforms: IDE tape drives on any platform

Floppy Device Naming Convention

LynxOS supports standard floppy disk drives for x86 and PowerPC.

LynxOS also supports TEAC SCSI floppy disk drives for PowerPC only.

Note: To correctly follow the LynxOS floppy device naming conventions, it is necessary to identify each floppy device type (standard or SCSI), and its data capacity in bytes.

A LynxOS device node name is a character string made up of several fields corresponding to data about the given device.

A device node name beginning with the letter r indicates that the associated device is handled by LynxOS through a character ("raw") interface.

Conversely, a LynxOS device node name not beginning with the letter r indicates that the associated device is handled by LynxOS through a block interface.

Note: There are two exceptions to the r and no-r device node naming convention stated above: RAM disk device node names have an rd prefix; the associated devices are handled by LynxOS through a block interface. No-rewind tape device names have an nrst (no-rewind SCSI tape drive) prefix; the associated devices are handled by LynxOS through a character ("raw") interface. For more information on devices, see Writing Device Drivers for LynxOS.

Standard Floppy Device Naming Convention

LynxOS supports standard floppy devices on all x86 and PowerPC systems.

The figure below shows the fields that make up the LynxOS standard floppy disk device name. The device node name must be a contiguous character string.

fd indicates that the floppy drive associated with the device node is a standard floppy drive. This is followed by a numeric_string indicating the floppy device's capacity in bytes (value supplied by user). This is followed by a period (.) and a single numeral from 0 - 3 indicating the user-selected floppy drive ID:

Floppy drive indicator	Device capacity (in bytes)	period	Floppy drive ID
fd	numeric_string	.	0-3

LynxOS Standard Floppy Device Naming Convention

On systems with only one standard floppy drive designated as the boot disk drive, the drive number must be 0.

On systems with more than one standard floppy drive, one of which is designated as the boot disk drive, any drive number from 0 - 3 can be used for any of the floppy drives.

On systems with more than one standard floppy drive, none of which has been designated as the boot disk drive, any drive number from 0 - 3 can be used for any of the floppy drives.

Note: For MS-DOS, drive number 0 corresponds to drive A: and drive number 1 to drive B:.

Using the conventions illustrated above, the device node associated with a block, 3.5 inch, high-density (1.44 MB) standard floppy disk drive designated as drive 0,
is fd1440.0.

Similarly, the LynxOS node associated with the character interface for a 3.5 inch high-density (1.44 MB) standard floppy disk drive designated as drive 0,
is rfd1440.0.

SCSI Floppy Device Naming Convention

LynxOS supports TEAC SCSI floppy devices for PowerPC systems only.

The figure below shows the fields that make up the LynxOS SCSI floppy device name. The device node must be a contiguous character string when entered by users.

fdscsi indicates that the floppy disk associated with the device node is a SCSI disk. This is followed by a numeric_string indicating the floppy device's capacity in bytes (value to be supplied by the user). This is followed by a period (.) and a single numeral from 0 - 3 indicating the user-selected floppy drive ID number:

SCSI floppy drive indicator	Media capacity (in bytes)	period	Floppy drive ID
fdscsi	numeric_string	.	0-3

LynxOS SCSI Floppy Device Naming Convention

On systems with only one SCSI floppy drive designated as the boot disk drive, the drive number must be 0.

On systems with more than one SCSI floppy disk drive, one of which has been designated as the boot disk drive, any drive number from 0 - 3 can be used for any of the floppy drives.

On systems with more than one SCSI floppy drive, none of which has been designated as the boot disk drive, any drive number from 0 - 3 can be used for any of the floppy drives.

Using the conventions illustrated in the figure above, the LynxOS device node associated with the block interface to a 3.5 inch, high-density (1.44 MB) SCSI floppy drive designated as drive 0, is fdscsi1440.0.

Similarly, the LynxOS node associated with the character ("raw") interface to a 3.5 inch, high-density (1.44 MB) SCSI floppy drive designated as drive 0,
is rfdscsi1440.0.

Hard Disk Device Naming Convention

LynxOS supports IDE hard disk devices for x86 and PowerPC.

LynxOS also supports SCSI hard disk devices for x86 and PowerPC only.

Note: To correctly follow the LynxOS hard disk device naming convention, it is necessary to identify the hard disk type (IDE or SCSI).

IDE Hard Disk Device Naming Convention

LynxOS supports IDE hard disk devices for x86 and PowerPC.

A LynxOS device name is a contiguous character string made up of several fields that correspond to relevant data about the associated device.

The following figure details the fields that make up the LynxOS IDE hard disk device name.

The prefix ide indicates that the hard disk associated with the device node is an IDE device. A period follows the IDE hard disk indicator.

LynxOS supports up to two IDE channels on a single system, with two device positions on each of these channels, for a total of four IDE drives.

The hard drive ID follows the period. For the x86 architecture, the four IDE hard disk drives have the following IDs:

• 0--primary master

• 1--primary slave

• 2--secondary master

• 3--secondary slave

The partition ID number follows the hard disk ID. LynxOS supports up to 15 partitions per IDE disk, with each partition assigned an ID of a - o.

Note: On systems with partitioned hard disks, LynxOS treats each partition as a separate device. Each partition requires a separate device node with a partition ID and a hard disk ID.

The figure below details the LynxOS IDE hard disk device naming convention:

IDE disk identifier	Period	Hard disk ID	Partition ID
ide	.	0-3	a-o

LynxOS IDE Hard Disk Drive Naming Convention

On systems with only one IDE hard disk that has been designated as the boot disk drive, the drive number must be 0.

On systems with more than one IDE hard disk, one of which has been designated as the boot disk drive, any number from 0 - 3 can be used for any IDE disk.

On systems with more than one IDE hard disk, none of which has been designated as the boot disk drive, any number from 0 - 3 can be used for any IDE disk.

Using the conventions above, the LynxOS device node associated with the block interface to a primary master IDE device is ide.0.

Similarly, the LynxOS device node associated with the character interface to a primary master IDE device is ride.0.

The device node associated with the block interface to a partition a on a primary master block IDE device is ide.0a.

The device node associated with the character interface to partition a on a primary master IDE device is ride.0a.

SCSI Hard Disk Device Naming Convention

LynxOS supports SCSI hard disk devices for x86 and PowerPC only.

A LynxOS device node is a contiguous character string made up of several fields that correspond to relevant data about the associated device.

The following figure details the various fields that make up the LynxOS SCSI disk name.

In the LynxOS SCSI device naming conventions, the prefix sd indicates that the device node is associated with a SCSI device. The SCSI controller ID follows the sd prefix, which is then followed by a period (.).

LynxOS supports up to a total of 16 SCSI devices: 4 devices per each of 2 channels on narrow SCSI architecture; 8 devices per each of 2 channels on wide SCSI architecture. A device ID of 0 - 7 for narrow, or 0 - 15 for wide SCSI architecture needs to be assigned by the user. The device ID follows the period.

LynxOS supports up to 15 partitions per hard disk; a partition ID of a - o identifies a partition on the SCSI disk.

Note: LynxOS treats each partition as a separate device. Each partitions requires a separate special device file with a partition ID and a controller ID.

The figure below details the LynxOS SCSI drive naming conventions:

SCSI disk identifier	controller ID	period	Device ID	Partition ID
sd	alpha_num_string	.	0-7 0-15	a-o

LynxOS SCSI Hard Disk Device Naming Convention

Using the conventions above, for the block interface to a SCSI hard disk connected to an Adaptec 1542 controller, designated as drive number 0, the LynxOS device node is sd1542.0.

For the character interface to a SCSI hard disk, connected to an Adaptec 1542 controller, designated as drive number 0, the LynxOS device node is rsd1542.0.

For the block interface to partition a on a SCSI hard disk, connected to an Adaptec 1542 controller designated as drive number 0, the LynxOS device node is sd1542.0a.

For the character interface to a partition a on a SCSI hard disk, connected to an Adaptec 1542 controller, designated as drive number 0, the LynxOS device node is rsd1542.0a.

Note: For x86 systems, if the SCSI hard disk is the only drive (no CD-ROM, tape, RAM disk), or the SCSI disk is designated as the boot disk drive, then the hard disk BIOS configuration must be set to Not Installed.

Examples of LynxOS Hard Disk and Partition Device Nodes

The following table below shows examples of LynxOS hard disk and partition device nodes:

Hard Disk and Hard Disk Partition Device Node Names  

Hard Disk Type	Character ("raw") or Block	Controller Name	Hard Disk ID	Partition ID	Hard Disk or Partition Device Node
IDE	Block	N/A	0	a	ide.0a
IDE	Character ("raw")	N/A	0	a	ride.0a
SCSI	Block	Adaptec 1542	0	None	sd1542.0
SCSI	Character ("raw")	Adaptec 1542	0	None	rsd1542.0
SCSI	Block	Adaptec 2940	1	c	sd2940.1c
SCSI	Character ("raw")	Adaptec 2940	1	c	rsd2940.1c
SCSI	Block	NCR	6	a	sdncr.6a
SCSI	Character ("raw")	NCR	6	a	rsdncr.6a

Hard Disk Device Node Naming Exceptions

Iomega Jaz and Zip drives have a unique electronic copy protection mechanism. The iomega utility is used to manipulate the privileges on these devices. Other than the privilege modification tool, Zip and Jaz drives behave as direct-access SCSI devices; see the iomega man page for more information.

CD-ROM Device Naming Convention

LynxOS supports IDE CD-ROM devices for x86 and PowerPC.

LynxOS also supports SCSI CD-ROM devices for x86 and PowerPC only.

Note: To correctly follow the LynxOS CD-ROM device node naming convention, it is necessary to identify the CD-ROM type (IDE or SCSI).

The subsections that follow detail the LynxOS device node naming conventions for IDE and SCSI CD-ROM devices.

IDE CD-ROM Drive Device Node Naming Conventions

LynxOS supports IDE CD-ROM devices for x86 and PowerPC.

A LynxOS device name is a contiguous character string made up of several fields that correspond to relevant data about the associated device.

The following figure details the various fields that make up the LynxOS IDE CD-ROM device name.

The prefix ide indicates that the hard disk drive associated with the device node is an IDE device. A period follows the CD-ROM indicator.

The CD-ROM ID follows the period. LynxOS supports up to two IDE channels on a single system, with two device positions on each channel, for a total of four IDE CD-ROM drives per system, requiring a CD-ROM ID of 0 - 3.

IDE CD-ROM indicator	period	CD-ROM ID
ide	.	0-3

LynxOS IDE CD-ROM Device Naming Convention

On systems with only one IDE CD-ROM drive that has been designated as the boot drive, the drive number must be 0.

On systems with more than one IDE CD-ROM drive, one of which has been designated as the boot drive, any drive number from 0 - 3 can be used for any of the IDE CD-ROM drives.

On systems with more than one IDE CD-ROM drive, none of which has been designated as the boot drive, any drive number from 0 - 3 can be used for any of the IDE CD-ROM drives.

Using the conventions above, the device node associated with the block interface to an IDE CD-ROM designated as drive number 0 is ide.0.

The device node name associated with the character interface to an IDE CD-ROM designated as drive number 0 is ride.0.

SCSI CD-ROM Device Naming Convention

LynxOS supports SCSI CD-ROM drive devices for x86 and PowerPC only.

A LynxOS device node is a contiguous character string made up of several fields that correspond to relevant data about the associated device.

The following figure details the various fields that make up the LynxOS SCSI CD-ROM device node.

The prefix sd indicates that the CD-ROM drive with which the device node is associated is a SCSI device. This is followed by the CD-ROM controller ID, followed in turn by a period.

The CD-ROM device ID follows the period. LynxOS supports up to a total of 16 SCSI CD-ROM devices: 4 devices per each of 2 channels on narrow SCSI architecture; 8 devices per each of 2 channels on wide SCSI architecture. A device ID of 0 - 7 for narrow, or 0 - 15 for wide SCSI architecture needs to be assigned by the user.

SCSI CD-ROM indicator	Controller ID	period	Device ID
sd	alpha_num_string	.	0-7 0-15

LynxOS SCSI CD-ROM Device Node Naming Convention

Using the conventions above, for a block SCSI CD-ROM drive connected to an Adaptec 1542 controller designated as drive 0, the device node is sd1542.0.

For a character SCSI CD-ROM drive connected to an Adaptec 1542 controller designated as drive 0, the device node is rsd1542.0.

Examples of LynxOS CD-ROM Device Nodes

The table below shows example CD-ROM device nodes:

Examples of CD-ROM Drive Device Node Names  

CD-ROM Drive Type	Character ("raw") or Block	Controller Name	CD-ROM Drive ID	CD-ROM Device Node
IDE	Block	n/a	0	ide.0
IDE	Character ("raw")	n/a	0	ride.0
SCSI	Block	Adaptec 1542	0	sd1542.0
SCSI	Character ("raw")	Adaptec 1542	0	rsd1542.0
SCSI	Block	Adaptec 2940	1	sd2940.1
SCSI	Character ("raw")	Adaptec 2940	1	rsd2940.1
SCSI	Block	NCR	6	sdncr.6
SCSI	Character ("raw")	NCR	6	rsdncr.6

Tape Device Naming Conventions

LynxOS supports SCSI tape devices for x86 and PowerPC only.

LynxOS does not support IDE tape devices.

A LynxOS device node is a contiguous character string made up of several fields that correspond to relevant data about the associated device.

Tape drives can be either "rewind-on-open" or "no-rewind-on-open." Accordingly, device nodes begin with either of the following identifier prefixes:

• rst--rewind SCSI tape drive

• nrst--no-rewind SCSI tape drive

A tape drive controller ID follows the rst or nrst prefix, followed by a period.

A SCSI tape drive ID follows the period. LynxOS supports up to a total of 16 SCSI tape devices: 4 devices per each of 2 channels on narrow SCSI architecture; 8 devices per each of 2 channels on wide SCSI architecture. A device ID of 0 - 7 for narrow, or 0 - 15 for wide SCSI architecture must be assigned by the user.

The following figure details the various fields that make up the LynxOS SCSI tape device name:

no/rewind SCSI tape drive	Controller ID	period	Device ID
nrst rst	alpha_num_string	.	0-7 0-15

LynxOS SCSI Tape Drive Naming Convention

Using the conventions above, the device node associated with a rewind-on-open SCSI tape drive connected to an Adaptec 1542 SCSI controller is rst1542.0.

The device node associated with a no-rewind-on-open tape drive connected to an Adaptec 1542 SCSI controller is nrst1542.0.

RAM Disk Naming Convention

LynxOS supports RAM disk virtual disk drives.

A RAM disk is space in memory that simulates a disk drive, i.e., creates a "virtual" disk drive.

The prefix rd indicates that the device with which the device node is associated is a RAM disk. The prefix is followed by a period.

LynxOS supports up to 16 RAM disks, each capable of containing up to 4 partitions. To accommodate this number, the following scheme is used:

• After the period, a single character numeric ID from 0 - 15

• After the numeric ID, a single character alphabetic ID from a - d

The figure below details the LynxOS RAM disk naming convention:

RAM disk type indicator	Period	Numeric ID	Alphabetic ID
rd	.	0-15	a-d

LynxOS RAM Disk Device Node Naming Convention

Using the conventions above, the device node associated with the block interface to a RAM disk with numeric and alphabetic designations of 0 and a, respectively, is rd.0a.

The device node associated with the character interface to a RAM disk with numeric and alphabetic designations of 0 and a, respectively, is rrd.0a.

Major and Minor Numbers

Although users and applications use a device name to refer to a device, internally, LynxOS uses a unique numeric identifier for each device that it supports. This identification consists of a major and a minor number. Major and minor numbers are used by the kernel to identify a device. Major numbers represent a general device type. Minor numbers represent a specific class or subset of a device. The major and minor numbers of devices on any given system depend on how LynxOS is configured. To view the major and minor numbers of the devices on any system, use the command ls l /dev. A listing of the /dev directory shows the major and minor numbers of each device node. These are located in column three below as two numbers separated by a comma (,).

$ ls -l /dev

brw-rw-rw- 1 root 2,13 Apr 7 17:15 fd1440.1

brw------- 1 root 1,0 Apr 7 17:15 ide.0

brw------- 1 root 0,32 Apr 7 17:15 sd0b

brw------- 1 root 3,0 Apr 7 17:15 sd1542.0

brw------- 1 root 3,16 Apr 7 17:15 sd1542.0a

In the example above, /dev/fd1440.1's major number is 2 and its minor number is 13.

For additional information on major and minor numbers, see the Chapter "Booting LynxOS" in the LynxOS Installation Guide.

Managing Terminals

When using a LynxOS computer for software development, terminals are an important resource. The LynxOS utilities provide several methods to simplify and organize the job of installing new or different terminals, or adding extra serial communication lines.

Most of the work necessary to manage the terminals on a system involves updating the files in the /etc directory.

Enabling Ports for Login

Serial ports on a LynxOS system can be set up to be used by terminals and other RS-232 devices, such as printers or modems. Only some of the serial ports should be recognized by init as being available for interactive use. On these ports, init maintains an active process, usually login. Serial ports can be listed in the /etc/ttys file. Each line of this file describes a single port as follows:

device : flag : config : terminal : login

The device field names a node for a serial port. The port is enabled for login (actually, enabled for consideration by init) if the flag is non-zero. The config and terminal fields select a configuration and terminal type from the files /etc/tconfig and /etc/termcap.

Note: It is convenient to include all serial ports in this file, even those unlikely to ever be connected to an interactive terminal. As long as the flag field for these ports is 0, they are not used by init.

For each port enabled in /etc/ttys, init starts a program named by the login field of the description line for the port. The standard input, standard output, and standard error file descriptors (0, 1, and 2) are connected to the port. For interactive software development, the login program is /bin/login, although any program can be substituted (for example, a simpler version of login that ignores passwords).

init monitors the activity of all the child processes it creates.When any of these child processes terminates, init creates another child process to take its place. Pseudo-tty devices used by network and window-management software are also listed in the /etc/ttys file. They are always disabled. The entries in the file are used to bypass login and provide terminal type information when login is started by a network daemon.

Describing Terminals

Before using a text editor or running utilities, Users must understand the actual terminal device being used before editing files or running utilities. LynxOS stores terminal characteristics and capabilities in the /etc/termcap database file.

Each different make or model of terminal used on a system should be included in the database. The details of a terminal description are rather involved; therefore, a list of only common terminal capabilities is associated with corresponding strings and numeric values. For more information on terminal descriptions, see the termcap file format reference pages.

The terminal type can be specified in a relatively static manner as the terminal field in the /etc/ttys description of the port. If the terminal type for the port varies, as it could on a modem port, the terminal field should be dialup or unknown.

The value of this field is placed in the environment by login as the value of the TERM environment variable. The TERM variable can be examined and possibly changed by the shell initialization scripts. It is ultimately used by the editor or other programs to determine the terminal type.

Serial Port Configurations

The serial port driver, called the tty driver, controls the details of input and output through a serial port. The following characteristics can be controlled:

• Baud rate

• Input character echoing

• Character mapping of certain characters to driversupported editing and process management functions

All communication with the driver (as with all drivers) is through the ioctl system call. Because there are so many tty driver features, a program might have to call ioctl several times to configure the serial port for its needs. The LynxOS library routine ttyconfig simplifies this process by allowing the details of the configuration to be kept in the /etc/tconfig file.

Using ttyconfig, a program simply requests a configuration by name, and the ioctl calls are performed automatically. At least one entry, called default, should be in the /etc/tconfig file. Others may be added, or the file can be forever ignored. However, because login, stty, and tset use the information, the file should exist. For more information on creating configuration entries, see the ttyconfig man page.

User Accounts

Typically, each user on a LynxOS system has a unique account. At a minimum, each user account needs the following information set up:

• An entry in the /etc/passwd file

• A directory controlled by the user

The user directory is called the home directory of that user. LynuxWorks recommends that system administrators establish file protections such that only the superuser can perform the work of creating accounts (See "File Permissions").

There are two unique attributes of a user:

• User name

• User ID number

Generally, the user name is some adaptation of a person's name. The user ID number is an arbitrarily chosen integer between 0 and 65534; it is rarely manipulated or even seen. However, because file ownership is recorded in terms of user ID, different users must have distinct user ID numbers

Note: User ID number 0 is reserved for the superuser.

Root and Setup Accounts

The LynxOS setup system administration utility enables the creation of root (superuser) and setup accounts. To invoke this utility, log in to the LynxOS system as setup.

System administrators can create setup and root accounts for the LynxOS machine with the setup utility. Typically, setup and root accounts are reserved for special usage (for example, to manipulate all other user accounts and data), and require superuser privilege.

LynuxWorks recommends that the setup and root accounts have their own separate passwords. To give the setup account a password, enter yes at the following prompt:

# Do you want to give the setup account a password?

When ready, enter the password; the characters are not echoed on the screen. This is to ensure that passwords remain secret. The system asks that the password be reentered for integrity.

If the password entered is too short, the system prompts for a longer, less obvious password. The password-length safety mechanism can be overridden, allowing entry of a shorter password, by repeatedly entering the desired, shorter password; after two such efforts, the system accepts the shorter password.

Using the adduser Utility

The system administrator can add user accounts to the system with the adduser utility. This utility is automatically invoked by the setup utility. The adduser utility creates the following information:

• An entry in the /etc/passwd file

• A home directory

To add a user to the system, enter yes at this prompt:

# Do you want to add a user to the system?

For each user added, supply the following information:

• User Name

• User ID Number (the default is the first available number)

• User's Group ID Number (the default group ID is 2, the staff group ID)

The user can create a new group by modifying the /etc/group file.

• Comment

Typically, the full name of the user is entered in the Comment field.

• User's Home Directory

This is the user's initial working directory when logging in to the system; it is owned by the user.

• User's Login Shell

The login shell is the interface between the user and the LynxOS kernel. LynxOS does not copy the login or shell configuration files to the user's home directory. The system administrator needs to copy these files. The following lists the five LynxOS shells that can be chosen as default login shells:

LynxOS Login Shells  

Shell	Definition
/bin/csh	A hard link to /bin/tcsh
/bin/tcsh	Enhanced Berkeley C shell
/bin/sh	A hard link to /bin/bash
/bin/bash	Free Software Foundation Korncompatible shell
/bin/dlsh	LynuxWorks proprietary shell

The following example shows the entry for a user named Bob Jones:

bob::17:3:Bob Jones:/usr/bob:/bin/bash

In the example, Bob's user name is bob, his ID is 17, his group ID is 3, his home directory is /usr/bob, his default shell is the bash shell. In this example, the account password remains to be set in the second field, delimited by the two colons (::). If the password was set, the second field would contain an encrypted, but printable, string.

Using the deluser Utility

System administrators can delete user accounts from the system with the deluser utility. The setup utility automatically invokes deluser, used to delete the following items:

• Specified user's entry from the /etc/passwd file

• The user's home directory and subdirectories, if specified

The first prompt displayed when deluser is run is as follows:

Do you want to delete a user from the system?

To remove a user, enter yes.

Note: The first time setup is run, the prompt above does not appear. Before removing the user's home directory, make sure to back up all files that may be needed in the future.

Understanding Security Issues

In order to protect data from unwanted removal or inadvertent tampering, LynxOS provides a means to protect files and programs. Security on a LynxOS system is based on access permissions, allowing a user to read, write, or execute a file.

File Permissions

LynxOS uses standard UNIX file permission commands and bit settings to protect files. Every file or directory contains a set of permissions that define access privileges to the file/directory owner, members of the owning group, and any others. Each of these categories (owner, group, and other), contain permissions that allow (or deny) read access, write access, or execution access. The owner & group associated with a file are displayed with the ls -l command. Typically the Owner is the creator of the file (or the last user to touch it.) The Group is the associated group ID of the owner. Anyone who is a part of the group has the listed permission settings. Anyone who is not the owner, nor a member of the group falls into the Other category.

To display the permissions of a file or directory, use the ls-l command. The permissions are displayed in the leftmost columns:

Listing File Permissions

bash$ ls -l drwxrwxr-x 4  tim    pubs   4096  Oct 29 11:55 my_project -rwxr-xr-x 1  paul   eng    11900 Nov 2  15:39 a.out -rw-r--r-- 1  paul   eng    215   Nov 1  17:28 cypher.c Permissions       Owner    Group

The read (r), write (w), and execute (x) bits are displayed for the owner, group, and other categories. Also, the file (or directory) owner and associated group is displayed. The leading d or - character indicate whether it is a file (-) or a directory (d). The following table provides the permissions breakdown from the example above:

File Permission Settings

Directory/ File	Owner Permissions	Group Permissions	Other Permissions	Filename
d	rwx	rwx	r-x	my_project
-	rwx	r-x	r-x	a.out
-	rw-	r--	r--	cypher.c

Users have access to the file or directory if a particular bit is set. For example, on the cypher.c file, a user in the Other category would have read-only permission because the write and execute bits are not set (r--).

Changing Permissions with chmod

The permissions of a file can be changed with the chmod command:

# chmod mode file

Where mode are the octal values of the permission settings and file is the file to change. For example,

# chmod 760 cypher.c

To change the mode of the file, users must know the octal values of the permission settings they want to use. In the above example, the mode 760 represents the permission settings for the owner (7), group(6) and other(0). These octals are calculated by adding the various permission settings together. The read, write and execute bits are represented by the following values:

• r=4

• w=2

• x=1

• -=0

To determine the octal value of the permissions for a file, add the appropriate values together:

File Permission Octal Values

Permissions	Octal Value	Calculation
---	0	0+0+0
--x	1	0+0+1
-w-	2	0+2+0
-wx	3	0+2+1
r--	4	4+0+0
r-x	5	4+0+1
rw-	6	4+2+0
rwx	7	4+2+1

To change the permissions of a file to rwxrw----, use the chmod command, the appropriate octals for each user setting, and the filename:

# chmod 760 cypher.c

The chmod man page contains additional descriptions and options.

Default Permissions

When a file is created, the effective user ID number of the creating process is assigned to the file. The group ID number is inherited from the directory where the file is created.

The mode of the new file is derived by combining the current umask of the process with the mode requested by the process when it is called open. The umask is a number, when expressed in binary, tells which access bits of a requested mode are to be disabled.

For example, if a process attempts to create a file with mode 0666 octal (110110110 in binary) and the umask is currently 0022 octal, then the file is given mode 0644, as shown below:

Example umask Requested Number Result  

Requested	1	1	0	1	1	0	1	1	0
umask	0	0	0	0	1	0	0	1	0
Result	1	1	0	1	0	0	1	0	0

Changing Effective User ID

Sometimes, applications must access files that would normally be protected from access by the user ID under which the application is running. For example, a program that maintains a simple database might allow all users to add records to it, even though the data files are protected against access with ordinary utility programs.

In addition to the basic protection code bits, the mode of an executable file contains flags that can be used to set the effective user and group ID numbers upon execution. With this facility, a program can be configured so that while it is running the effective user or group ID, which is used to determine access privileges, is changed to that of the owner of any protected data.

The set-user-ID and set-group-ID flags are referred to by the constants S_ISUID and S_ISGID as defined in the include file sys/stat.h. To set or clear these bits, enter the following commands:

# chmod u+s file
# chmod g+s file

Note: Programs owned by user ID 0, which have the set-user-ID flag enabled, assume most superuser privileges while running. Such programs must be carefully written to prevent unwanted side effects or security violations.

Process Protection

Processes are also protected against interference from processes running under different user ID numbers. Only the owner of a process and the superuser can send signals to, or set the priority of that process.

When a process begins, it is assigned the user ID of the parent process. When a program is loaded, the user ID of the process changes if the S_ISUID bit of the program is set. Although a process is protected from direct interference by other processes, it is possible, nevertheless, for a non-privileged process to set its priority high enough to monopolize the processor.

In the context of a real-time application, this feature is expected of a real-time operating system. However, in a development environment, one user could monopolize system resources. The setpriority system call allows the root user to set the maximum priority of all non-root users. Thus, users who do not have root access cannot set their priority above that value.

LynuxWorks, Inc. 855 Branham Lane East San Jose, CA 95138 http://www.lynuxworks.com 1.800.255.5969