Setup Procedures


The following is a set of the most basic procedures you need to do to get your system going. Some procedures you will probably only do once, such as defining the computer’s name and creating default profiles for your users. Others you will repeat over time, such as adding new users.

You should check the documentation that comes with your system to see if additional setup procedures are required.

Installing the Console Terminal

Before you can set up your UNIX system, you must set up the computer and its console terminal

The console is where you must do your initial setup, because it is the only terminal defined when the system is first started. For small systems, the console will be the screen and keyboard that come with the computer. For large systems, there may be a completely separate terminal that may produce paper printouts.

Some administrators like to have messages from the console printed on paper in order to maintain a paper audit trail of system activities. Important messages about the system’s activities and error conditions are directed to the console. For example, a running commentary is sent to the console as the system is started up. This commentary keeps the administrator informed as hardware diagnostics are run; as the file system is checked for errors; and as processes providing system services to printers, networks, and other devices are started up. This is commonly done for many administrative tasks. Notice that standard output and standard error for one of the commands in the earlier crontab example were sent to /dev/ console. Clearly, one could direct system messages to a file, rather than to a paper terminal. However, if the system goes down, or if the file system crashes, this file will not be available.

The instructions that come with your computer will tell you how to set up the computer and console.

Installation

Procedures for installing UNIX System application software, as well as the operating system itself, are different from one system to the next. It’s not possible to give specific, detailed advice about system installation in a book of this kind. You should consult the software installation instructions that come with your computer’s operating system to see how this is done. While each variant may have its own procedures, they enable you to install your software either through a menu interface or by using command-line instructions.

Installing Software Packages

It is easy to install new software packages on your UNIX system. Although there are slight differences in how each of the UNIX variants performs this task, the basic operations are the same. For instance, Red Hat Linux developed a tool called rpm (Red Hat Package Management) that enables you to install software packages. This package has been migrated to other Linux distributions as well. HP-UX has a software distributor based on the pkgadd routine, and Solaris also uses the pkgadd routine to install software packages.

The pkgadd command transfers the software package from disk, tape, or CD-ROM to install it on the system. You can do the installation directly from the distribution medium or copy the software to a spool directory first. A command of the format

 # pkgadd -d /dev/fd0 package1

will directly install package1 onto your system from a floppy disk defined as /dev/fd0. The command

 # pkgadd -d /cdrom/cdrom0/s0/Solaris_10

will prompt you for the name of the package you want to install, and it will then install it into your default directory

If you wish, you can copy the software into the spool directory to install some other time. The command

 # pkgadd -s /var/spool/pkg

will copy the software into the spool directory instead of installing it. When used without options, pkgadd looks in the default spool directory (typically /var/spool/pkg) and installs the package.

If you are a Linux user, a lot of software packages may be installed over the Internet by going directly to the download page on the site offering the software (such as http://www.tucows.com). If you use Red Hat, you can use the Update Agent called up2date to check for newer versions of software packages currently loaded on your machine, download them, and even install them automatically, as well as download and install new software packages.

On other Linux distributions that use the rpm manager, the yum tool allows you to update software packages that are known in the yum repository (either /etc/yum.repos.d or /etc/yum/repos.d by default) according to the configuration file /etc/yum.conf.

Most Linux distributions can use an older tool developed by the Debian Project called apt-get, which is part of the apt (Advanced Package Tool) suite of tools. apt-get is a command-line tool that allows a user to update, install, and remove software packages known to a list defined in /etc/apt/sources.list according to the configuration file /etc/apt.conf.

Distributions based on Debian Linux can also use the Synaptic Package Manager synaptic, which is a graphical implementation of apt to install, upgrade, and remove software packages using a user-friendly GUI based on Gtk+ (part of the GIMP toolkit for creating graphical user interfaces).

Installation Defaults

Most UNIX-based systems will contain an installation defaults file generally referred to as admin. admin defines default actions to be taken in installing a software package. There are no standard naming conventions for this file, but typically the default admin file is /var/ sadm/install/admin/default. If you wish to change the default installation parameters, copy the current admin file to a new filename, and edit this new file-never edit the admin file itself. Table 13–1 shows the installation parameters that can be defined. If a parameter does not have a value, pkgadd asks the installer how to proceed.

Table 13–1: Software Installation Parameters

Parameter

Function

basedir

Indicates the base directory in which software packages should be installed. May refer to a shell variable $PKGINST to indicate that basedir depends on the package.

mail

Lists users to whom mail should be sent after installation of the package.

runlevel

Is current run level correct for installation?

conflict

What should be done if installation overwrites earlier file? “do not check” or “quit if file conflict is detected” are two options.

setuid

Check for programs that will have setuid or setgid enabled. “do not check,” “quit if setuid or setgid detected,” or “don’t change uid and gid bits” are several options.

action

Determine if scripts provided by package developers might have a security impact.

partial

Check to see if package is already partially installed.

instance

What should be done if earlier instance of package exists-quit, overwrite, or create new unique instance?

idepend

Choose whether or not to abort installation if other packages depend on the one to be installed.

rdepend

Choose whether or not to abort installation if other packages depend on the one to be removed.

space

Resolve disk space requirements, e.g., abort if disk space requirements cannot be met.

Here you see a conservative set of admin installation defaults:

 basedir=default runlevel=quit conflict=quit setuid=quit action=quit partial=quitinstance=unique idepend=quit rdepend=quit space=quit

This set minimizes the effects of any package installation on the rest of the system and quits the installation if any potential problem is detected.

Powering Up

Once the computer and console are set up and the initial software is installed, you can power up the system following the instructions in your system’s documentation.

If the system comes up successfully, you should see a series of diagnostic messages, followed by the “Console Login:” prompt. After that, you should type the word root to log in as the system’s superuser. You will not have to enter a password if one was not assigned yet, but you have to press ENTER after the “Password:” prompt. For instance,

 Console Login: root Password:

You should then set a root password as soon as possible, to avoid security problems-unless you can guarantee that you will be the only user on the machine.

The Superuser

Most administration must be done as superuser, using the root login. The superuser is the most powerful user on the system. It is as superuser that you will have complete control of the system’s resources. You can start and shut down the system, open and close access to any file or directory, delete or change any part of the system, and generally change the system’s configuration.

Becoming the Superuser

You have two ways to become the superuser. You can log in to the console as root. If you are at another terminal and attempt to log in as root, you’ll be denied access. If you’re not at the console and you need to have superuser privileges, you can first log in as a regular user and then use the su command to get root privileges, as shown here:

 $ /bin/su - Password: #

After you log in as root, you will have superuser privileges. The-(dash) on the command line tells the su command that you want to change the shell environment to the superuser’s environment. So, for example, the home directory would be set to / and the path variable would be set to include the directories where administrative commands are located. (You can return to the original user’s privileges and environment by keying CTRL-D.)

Linux administrators should understand how LILO (the Linux Loader) can be used to boot Linux from a floppy, thus giving whoever performs the boot procedure superuser (root) privileges. In order to avoid unwanted root access to your system, it’s a good idea not to leave these types of floppies around.

The root Prompt

Note that this is the shell prompt for root:

 #

You will see the # prompt throughout this section instead of the $ or other user shell prompts, such as %, shown for other users in the rest of the book.

Maintaining the Superuser Login

Because the capabilities of the superuser are so great, you should exercise extreme caution when you are the superuser. It’s a good idea to adopt a few simple rules when administering your system as superuser:

  • Keep the root prompt equal to the # character. This will help you remember when you have total power over the system.

  • Restrict access to superuser capabilities to those who really need it. Don’t give the root password out to anyone who doesn’t need total control of the whole system.

  • Change the root password often. Keeping the same password for long periods of time makes the system more vulnerable.

  • Do not do any work on the system except system administration when you are logged in as root or superuser. Even if you are the only user on your system, don’t make root your usual login. A typing mistake by a normal user may have little impact; the same mistake by root could demolish the whole system.

  • Make the root environment different from your normal environment. You want to make yourself aware of when you have root privileges. Make your root environment very different from your normal user environment. Don’t use the same or similar .profile as a user and as root. Minimize the use of aliases in your root login. Make the PATH variable for root as short as practical; don’t include your user directories in your root PATH.

Besides the superuser, other special administrative logins have other, more limited uses. These users are described later in this chapter.

Setting Date/Time

You must set the current date and time on your system. To set the date and time to July 15, 2006, 11:17 P.M., do the following:

 # date 1215231706 Sat Jul 15 23:17:00 EST 2006

This breaks down to July (12) 15 (15), 11:17 P.M. (2317), 2006 (06).

Whenever you want to see the current date and time, type date with no options.

Setting the Time Zone

You can set the time zone you are in by modifying the /etc/TIMEZONE file. In this file, the TZ environment variable is set as follows:

 TZ=EST5EDT export TZ

The preceding entry says that the time zone is eastern standard time (EST), this time zone is five hours from GMT (5), and the name of the time zone when and if daylight saving time is used is eastern daylight time (EDT). The system will automatically switch between standard and daylight saving time when appropriate. Note that /etc/TIMEZONE is not available in Red Hat Linux. See http://www.linuxsa.org.au/tips/time.html for details on how to set the time zone. On Solaris /etc/TIMEZONE is a symlink (symbolic link) to /etc/default/init.

Setting System Names

You need to assign a system name and a communications node name to your system. It is most important to assign names to your system if it is going to communicate with other systems.

The system name, by convention, is used to identify the type of operating system you are running (though no particular syntax is required). The communications node name, on the other hand, is used to identify your computer. For example, networking applications such as mail (see Chapter 8) and uucp use the node name when sending mail or doing file transfers. Internet applications also use the node name, referring to it as the hostname of the system.

Here is an example of how to set your computer’s system name to UNIX1 and its node name to trigger in UNIX variants other than Linux:

 # setuname -s UNIX1 -n trigger

You can type uname -a to see the results of the setuname command.

In Linux, Solaris, and AIX, the equivalent command to set or display the system name is hostname:

 # hostname trigger

will set the system host name from whatever it is currently to trigger. hostname without an argument will print the current system host name.

Using Administrative Logins

Administrative logins are assigned by the system before the system is delivered. However, these logins have no passwords. In order to avoid security breaches through these logins, you must define a password for each when you set up your system.

The reason for having special administrative logins is to allow limited special capabilities to some users and application programs, without giving them full root user privileges. For example, the uucp login can do administrative activities for Basic Networking Utilities. A uucp administrator could then set up files that let the system communicate with remote systems, without giving that user permission to use other confidential administrative commands or files (see the companion web site for more information on uucp).

To assign a password to the sysadm administrative login, type this:

 # passwd sysadm New Password: Re-enter new password:

You will be asked to enter the password twice. (For security reasons, the password will not be echoed as you type it.) You should then repeat this procedure, replacing sysadm with each of the special user names listed here, and any other special user names that you may have on your system:

root

Login has complete control of the operating system; very important to assign a password and protect it.

sys

Owns some system files.

adm

Owns many system logging and accounting files in the /var/adm directory.

uucp

Used to administer Basic Networking Utilities.

daemon

Owns some process that runs in the background and waits for events to occur (daemon processes).

lp

Used to administer the lp system.

sysadm

Used to access the sysadm command.

Another way to secure these special user logins is to set the shell for the account to /bin/false in the /etc/passwd file.

Startup and Shutdown (Changing System States)

The UNIX System has several different modes of operation called system states. These system states make it possible for you, as an administrator, to limit the activity on your system when you perform certain administrative tasks.

For example, if you are adding a communications board to your computer, you would change to system state 0 (power-down state) and the system will be powered off. Or if you want to run hardware diagnostics, you can change to system state 5 (firmware state) and the UNIX operating system will stop, but you will be able to run diagnostic programs at the firmware level. However, note that this only applies to non-Intel-based UNIX systems.

The two types of running system states are single-user states (1, s, or S) and mult-user states (2 and 3). When you bring up your system in single-user state, only the root file system (/) is accessible (mounted) and only the console terminal can access the system. When you bring up the system in multiuser state, usually all other file systems on your computer are mounted. Processes are started that allow general users to log in. (State 3, Network File System state, is a multiuser state that also starts NFS and mounts file systems across the network from other systems. See Chapters 15 and 17 for more information on NFS.)

By default, your system will go into multiuser state (2) when it is started up. In general, going to higher-numbered system states (e.g., from 1 to 2, or 2 to 3) starts processes and mounts file systems, making more services available. Going to lower-numbered system states, conversely tends to make fewer services available.

You may want your system to come up in another state or, more likely, you may need to change states to do different kinds of administration while the system is running.

To change the default system state, you must edit the /etc/inittab file and edit the initdef ault line. Here is an example of an initdefault entry that brings the system up in state 3, the Network File System (NFS) state:

 is:3:initdefault:

The next time the system is started, all multiuser processes will be started, plus NFS services will be started. Coming up in NFS state (3) is appropriate if you are sharing files across a network using NFS (see Chapter 17 for details). Windows NT/2000/XP administrators use their own versions of NFS in setting up shared folders and shared devices for Windows users.

You can also use single-user state(s) if, for example, you want to check the system after it is booted and before other users can access it. Most often, however, computer systems are set to come up in multiuser state (2).

When your system is up and running, you may decide you want to change the current state. If, for example, you are in single-user mode and want to change to multiuser mode, type the following:

 # init 2

All level 2 multiuser processes will be started, and users will be able to log in.

Startup Directories

UNIX uses daemon information (see Chapter 11) in some key directories to help in the startup process. The directories are init.d and the rcX.d directories (where X is a number that equates to a state level, described later). These directories are stored in the /etc/rc.d directory on Linux distributions, the /sbin directory on HP-UX, and in the /etc directory on Solaris.

The init.d directory contains daemons that will always be started up on initialization (system start). These scripts set up accounting, start cron, manage system resources, and set up environments not handled by entries in the /etc/inittab file.

The rcX.d directories contain specific scripts that are run depending on the run level at which the system is initialized. For example, if the run level at initialization is set to 3 (multiuser mode), scripts in the /etc/rc3.d directory will be executed at initialization. These scripts can either start or kill processes, or perform a combination of both. The numbering scheme tells the system in what order to perform the scripts in the directory For example, the contents of an /etc/rc2.d directory may look something like this:

 ls /etc/rc2.d K20spc K76 snmpdx S74syslog S74xntpd

The scripts beginning with the letter K are kill scripts and are processed before any S, or startup, scripts. In addition, the scripts are processed in numerical order within a type. Therefore, the scripts listed in the example will be processed in the order in which they appear.

By convention, most of the K series scripts are in the directory /etc/rc1.d, with fewer in /etc/rc2.d. The directory /etc/rc2.d contains a combination of K and S scripts. The directory /etc/rc3.d usually contains just S scripts.

System State Summary

Here is a list of the numbers representing possible system states and their meanings:

0

Shutdown state Machine brought down to a point where you can reboot or power off. Used if you need to change hardware or move the machine.

1

Administrative state Multiuser file systems are available, but multiuser processes are not. Use this state to start the OS and have the full file system available to you only (from the console).

s or S

Single-user state All multiuser file systems are unmounted, multiuser processes are killed, and the system can only be accessed through the console. Use this state if you want all other users off the system and only the root (/) file system available.

2

Multi-user state File systems are mounted and multiuser services are started. Normal mode of operation.

3

Network File System state Used to start Network File System (NFS), connect your computer to an NFS network, mount remote resources, and offer your resources automatically. (NFS state is also a multiuser state.)

4

User-defined state Not defined by the system.

5

Firmware state Used to run special firmware commands and programs, for example, making a floppy key or booting the system from different boot files.

6

Stop and reboot state Stop the operating system and then reboot to the state defined in the initdefault entry in the inittab file.

a, b, c

Psuedo-states Process those inittab file entries assigned the a, b, or c system state. These are pseudo-states that may be used to run certain commands without changing the current system state.

Q

Reexamine the inittab file for the current run level Use this if you have added or changed some entries in the inittab file that you want to start without otherwise changing the current state.

The shutdown Command

You can shut down your machine using the init command; however, it is more common to use the shutdown command. shutdown can be used not only to power down the computer, but also to go to a lower state. The benefit of using shutdown is that it lets you assign a grace period so that your users will have some warning before the shutdown actually begins. UNIX administrators should be careful to always power down using shutdown. Just as Windows users know that you can’t just turn off the power, UNIX administrators should understand that files, devices, and even processes can be left in damaged or even unrepairable states if the machine is just turned off.

For example, you can leave multiuser state (2) and go to single-user state (S) if you want to have the system running but want all other users off the system. Or you could go down from state 2 to firmware state (5) if you want to run hardware diagnostics.

The following example of the Solaris 10 shutdown command,

 # shutdown -g 60 -I 6 "System is powering down for maintenance. Please log off."

tells the system to shut down after waiting for a grace period of one minute (-g 60), and to stop the UNIX system and reboot immediately to the level defined by initdefault in the inittab file (-i 6). It also sends a message to the users telling the reason for the shutdown.

Other UNIX variants have similar command syntaxes. For example, Linux allows the use of a variable for the time to shutdown of “now,” meaning start the shutdown immediately. Check the built-in Help feature or the man page for your system to see which options are correct for your variant.

Managing User Logins

UNIX is a multiuser system, and access to the system and permissions within the system is restricted to people who have been assigned logins and passwords. The system administrator has the responsibility of maintaining the user logins. This includes defining the default user environment, adding users, aging passwords, changing passwords, and removing user logins. You must be the superuser to perform any of these functions.

Display Default User Environment

Before you add users to your system, you should display default user addition information. These defaults will show you information that will be used automatically when you add a user to your system (unless you specifically override it). For example,

 # useradd -D group=other, 1  basedir=/home  skel=/etc/skel shell=/bin/sh   inactive=0  expire=0

In the preceding example, typing the command useradd -D shows you that the next time you add a user, it will be assigned to the group other, with a group ID of 1; its home directory will be placed under the /home directory; useful user files and directories (such as a user’s .profile file and rje directory) will be picked up from the /etc/skel directory and be put into the user’s home directory; and the shell used when the user logs in will be /bin/sh (/bin/bash for Linux users). No value is set for the number of days a login must be inactive before being turned on, and the login will not expire on a specific date. Note that users are added in AIX by using the SMIT interface (see the example earlier in this chapter).

Changing Default User Environment

You can change the default user environment values by typing useradd -D along with any of the following options: -g (group), -b (base directory), -f (inactive), or -e (expire). For example,

 # useradd -D -g test -b /usr2/home -f 100 -e 10/15/06

After you run this command, by default, any user you add will be assigned to the group test. The user will have a home directory of its login name under the /usr2/home directory, the account will be deactivated if the user does not log in for 100 days, and if still active, the login will expire on October 15, 2006.

Here are just two of the reasons you may want to change useradd defaults:

  • The file system containing /home is getting full, so you may want to add future users’ home directories to another file system.

  • You may decide that, to maintain security, all logins will expire, either after a certain number of days of inactivity or on a particular date.

Default profile Files

After a user logs in and as part of starting up the user’s shell, two profile files are executed. The first is the system profile /etc/profile, which is run by every user, and the second is the .profile in the user’s home directory, which is only run by the user who owns it.

The intent of these two files is to set up the environment each user will need to use the system. As an administrator, you are only responsible for delivering profiles that will provide the user with a workable environment the first time the user logs in. The user should then tailor the .profile file to the user’s own needs (see the description of .profile in Chapter 4).

Before a logged-in user gets a shell prompt to start working, robust profiles will usually display messages about the system (message of the day). They will also set up a $PATH so that the user can access basic UNIX System programs, tell the user if there is mail, make sure the user’s terminal type is defined, and set the user’s shell prompt.

You can edit the /etc/profile and the /etc/skel/.profile files to add some of the items shown in the examples that follow or to add other items that make the user’s environment more useful.

The .profile in the /etc/skel directory is copied to a user’s home directory when the user is first added. By setting up a skeleton .profile, you can avoid the problem many first-time UNIX System users have of scrambling for a usable .profile. Once your users have working profiles, you should instruct them to exercise caution in editing their own .profile files to avoid corrupting their own environment by mistake. Some administrators go to the extent of setting up separate files that contain common environment variables (see Chapter 4) to avoid this.

Example/etc/profile

Here is a typical /etc/profile (note that the # on a line is followed by a comment describing the entry):

 PATH=/bin:/usr/bin LOGNAME='logname'            #  Set LOGNAME to the user's name if [ "$LOGNAME" = root ] then      PATH=/sbin:/usr/sbin:/usr/bin:/etc # Set root path      PATH=$PATH:/letc:/usr/lbin else      PATH=$PATH::/usr/lbin:/usr/add-on/local/bin # Path for others      trap ""1 2 3      news -s # Report how many news items are unread by user      trap ""1 2 3 fi trap "" 1 2 3 export LOGNAME   # Make user's logname available to user's shell . /etc/TIMEZONE  # Make local time zone available to user's shell export PATH       # Make the PATH available to user's shell trap "" 1 2 3   # Let user to break out of Message-Of-The-Day cat -s /etc/motd trap "" 1 2 3 if mail -e      # Check if there's mail in the user's mailbox   then      echo "you have mail" # If so, print "you have mail"   fi umask 022          # Define default permissions assigned to files                    # the user creates

Note that Red Hat Linux uses /etc/localtime to store the time. See the web page at http://www.linuxsa.org.au/tips/time.html for more details on setting and viewing the time zone.

Example .profile

Here is a typical user’s .profile:

 stty echoe echo icanon ixon stty erase '^h'           # Set backspace character to erase PS1="'uuname -l':$ "      # Set shell prompt to "system name:$: " HOME=/home/$LOGNAME       # Define the HOME variable PATH=$PATH:$HOME/bin:/bin:/usr/bin:/usr/localbin  # Set PATH TERM=vt100                # Set the terminal definition MAIL=/var/mail/$LOGNAME   # Set variables for user's mailbox MAILPATH=/var/mail/$LOGNAME echo "terminal? \c"        # Ask user for the terminal being used read TERM                  # set TERM to terminal name entered export PS1 HOME PATH TERM  # Export variables to the shell. # Prompt user to see news echo "\nDo you want to read the current news items [y]?\c" read ans case $ans in  [Nn] [Oo]) ; ;  [Yy] [Ee] [Ss]) news | /usr/bin/pg -s -e;;  *)              news | /usr/bin/pg -s -e;; esac unset ans umask 022                    # Set the user's umask value

Adding a User

There are a few ways to add users to your UNIX system. One is to use the menu interface for your system and follow the prompts. This method requires a minimum knowledge of all of the defaults in setting up a user-the user’s group ID, home directory default mailbox, etc. The other way to add a user is to use a command-line interface. Many system administrators prefer this method over the menu interface, as it affords you more control. We will discuss the command-line utilities here.

Most UNIX variants use the useradd command to identify a new user to the system and allow the new user to access the system. This command protects you from having to edit the /etc/passwd and /etc/shadow files manually It also simplifies the process of adding a user by using the useradd defaults described earlier. The following is an example of how to add a user with the user name of abc:

 # useradd -m abc

This will define the new user abc using information from the default user environment described previously. The -m option will create a home directory for the user in /home/abc (you may have to change ownership of the directory from root by using chown).

useradd Options

To set different information for the user, you could use any of the following options instead of the default information:

-u uid

This sets the user ID of the new user. The uid defaults to the next available number above the highest number currently assigned on the system. If you are adding a user who has a login on another computer you are administering, you may want to assign the user the same UID from the other computer, instead of taking the default. If you ever share files across a network (see the description of NFS in Chapter 17), having the same UID will ensure that a user will have the same access permissions across the computers.

-o

Use this option with -u to assign a UID that is not unique. You may want to do this if you want several different users to have the same file access permissions, but different names and home directories.

-g group

This sets an existing group’s ID number or group name. The defaults when the system is delivered are 1 (group ID) and other (group name).

-d dir

This sets the home directory of the new users. The default, when the system is delivered, is /home/username.

-s shell

This sets the full pathname of the user’s login shell. The default shell, when the system is delivered, is /sbin/sh.

-c comment

Use this to set any comment you want to add to the user’s /etc/password file entry.

-k skel_dir

This sets the directory containing skeleton information (such as .profile) to be copied into a new user’s home directory. The default skeleton directory, when the system is delivered, is/etc/skel.

-e expire

This sets the date on which a login expires. Useful for creating temporary logins, the default expiration, when the system is delivered, is 0 (no expiration).

-f inactive

This sets the number of days a login can be inactive before it is declared invalid. The default, as the system is delivered, is 0 (do not invalidate).

User Passwords

A new login is locked until a password is added for it. You add initial passwords for every regular user just as you do for administrative users:

 # passwd username 

You will then be asked to type an initial password. You should use this password the first time you log in, and then change it to one known only to you (for security reasons). Chapter 2 covers some of the requirements placed on valid passwords in UNIX and provides some suggestions for how to select a password and what to avoid when creating one.

As an administrator, you assign users their initial passwords. If you can’t ask what password a user wants, it’s best to assign a temporary password and force the user to change it. One way to do this is to assign a password (e.g., the user’s initials followed by the user’s ID number), and to activate the login at the end of the day with password aging set to force an immediate password change. Thus, the first time the new user logs in, the system asks for a new password. A command sequence to do this would look like this:

 # useradd -m abc # passwd abc Enter password for login: New Password: # passwd -f abc

The useradd command adds the user’s login and home directory the first passwd command sets the user’s password to whatever is assigned by the system administrator, and the second passwd -f forces the user to change passwords at the next login by forcing the expiration of the password for abc.

Lost Passwords

Passwords are not recorded by the UNIX system. The password entries in /etc/passwd or in /etc/shadow do not contain the user’s password. Nor is there any easy way to determine a password if it is forgotten or lost. You will, from time to time, receive calls from users who have forgotten their password. If you are sure that the caller is, in fact, the owner of the login, you have two ways to restore his or her privileges. One way is to use the command sequence

 # passwd abc Enter password for login: New Password: # passwd -f abc

which will allow you to enter a new password for the user abc and require that it be changed the first time abc logs in. An alternative is to use the sequence

 # passwd -d abc

This deletes the password entry for abc. The next time abc logs in, he or she will not be prompted for a password. If the /etc/default/login file contains the field “PASSREQ=YES”, then a password is required for all users. The use of the -d option will remove the password for the user, but that user will be required to specify a password on the next login attempt. The first approach is slightly more secure, since only a user who knows the assigned password can log in; with the second approach, anyone who calls is allowed to log in and specify a new password.

If root deletes a password for a user with the passwd -d command and password aging is in effect for that user, the user will not be allowed to add a new password until the NULL password has been in use for the minimum number of days specified by aging. This is true even if PASSREQ in /etc/login/default is set to YES. This results in a user without a password. It is recommended that the -f option be used whenever the -d (delete) option is used. This will force a user to change the password at the next login.

Caution 

Root can replace a lost password for any user, except root itself. In other words, if you forget or lose your superuser password, you are in serious trouble. Procedures for recovering from this vary from system to system, but in general they require you to partially or totally reinstall the UNIX system on your computer. At a minimum, this will result in resetting many administrative defaults, and creating a great deal of administration work.

Aging User Passwords

Passwords are an important key to UNIX user security. As mentioned in Chapter 2, UNIX enforces several rules regarding password format and length. You, as system administrator, can also force users to regularly change their passwords by implementing password aging.

You use the passwd command to specify the minimum and the maximum number of days a password can be in effect. Aging prevents a user from using the same password for long periods, and it prevents the user, when forced to change, from changing back, by enforcing a minimum duration. For example,

 # passwd -x30 -n7 minnie

will require minnie to change her password every 30 days, and to keep the password for at least one week.

In establishing password aging, variables in /etc/default/passwd set the defaults for aging. The passwd command can be used to change these defaults on a per-user basis:

  • MAXWEEKS = number, where number is the maximum number of weeks that a password can be in effect

  • MINWEEKS = number, where number defines the minimum number of weeks a password has to be in effect before it can be changed

  • WARNWEEKS = number, where number is the number of weeks before the password expires that the user will be warned

Blocking User Access

You can block a user from having access to your system in a number of ways. You can use this command to lock a login so that the user is denied access:

 # passwd -1 abc

If user abc is to gain access to her account and its files, the superuser will have to run passwd again for this login.

You can limit or block a user’s access by changing the user’s shell. For example, the command

 # usermod -s /usr/bin/rsh abc

will modify the user’s login definition on the system and change abc’s shell to the restricted shell, which limits the user’s access to certain commands and files. If you set the default shell to some other command, such as this, for example,

 # usermod -s /bin/true abc

then abc will be logged off immediately after every login attempt. UNIX will go through the login process, exec /bin/true in place of the shell, and when true immediately completes, log out the user.

Hard Delete of a User

If you no longer want a user and his files to be on your system, you can use the userdel command:

 # userdel -r abc

The preceding example will remove the user abc from the system and delete abc’s home directory (-r). Once you remove a user, any other files owned by that user that are still on the system will still be owned by that user’s user ID number. If you did an ls -1 on such files, the user ID would be listed in place of the user’s name.

Soft Delete of a User

The userdel command eliminates a user from the /etc/passwd and /etc/shadow files and deletes the user’s home directory You may not want to be so abrupt. Often users share files in a project, and other users may need to be able to recover material in abc’s directory The following procedure is useful to block any further access to the system by a user while allowing others to access shared files:

 # passwd -l abc

Find any other users who are in the same group as abc, and send them mail informing them that abc’s login is being closed:

 # grep abc /etc/group abc::568:abc, lsb, oca, gxl # mailx lsb oca gxl Subject: abc login Cc: I will be deleting the home directory of abc. If you have need for any of those files please let me know. Fondly, your SysAdmin

Make the user’s home directory permissions 000 so that the directory is inaccessible to everyone but root as read-only root can still access the directory to change back the permissions (see Chapter 3 for more details on setting octal permission modes). To do this, type

 # chmod 000 /home/abc

Arrange an at command to delete the user’s home directory in one month, by typing:

 # at now + 1 month 2>/dev/console <<%% rm -r /home/abc %%

Adding a Group

Creating groups can be useful in cases where you want a number of users to have permissions to a particular set of files or directories.

For example, you may want to assign users who are writing manuals to a group called docs and give them permission to a directory containing documents, or assign users who are testing software programs to a group called test that has access to some special testing programs. See Chapter 3 for a description of how to set group access permissions. Windows NT administrators are also familiar with the concept of groups and group permissions for programs and files, since the NT environment borrowed this useful capability from UNIX.

To add a group called test to your system, type the following:

 # groupadd test

The command will add the name “test” to the /etc/group file, and the system will assign a group ID number.

Once a group is created, you can assign users to that group. To assign a new user to an existing group, use useradd. For example,

 # useradd -g project -G test bcd

will add the new user, bcd, to the system with project as the primary (default) group, and test as the secondary group.

For existing users, you use the usermod command. For example,

 #usermod -g project -G test abc

will do the same for existing user abc.

Deleting a Group

If you find you no longer need a group you previously added, you can delete it this way:

 # groupdel test

The command will delete the name “test” from the /etc/group file. Note that if you want to change a group name, you can use the groupmod command:

 # groupmod -n TryNot test

This will change the group’s name from test to TryNot.

Setting Up Terminals and Printers

You need to identify to the UNIX System the terminals, printers, or other hardware peripherals connected to your computer.

Ports

Each physical hardware port (the place where you connect the cable from the hardware to your computer) is usually represented by a file under the /dev directory It is through this file, called a device special file or simply a device, that the hardware is accessible from the operating system. Usually these devices are created for you automatically when you install a hardware board and its associated software.

Configuration

Once hardware is connected, you usually need to configure it into the operating system. The procedure for configuring hardware can involve a complex series of steps that could include editing configuration files manually, starting and stopping port monitors, and adding and enabling the specific services provided by the hardware.

It is strongly recommended that you configure peripheral hardware through your system’s menu interfaces unless you are very familiar with the environments under which these devices operate. The following examples show a basic terminal and printer setup.

Adding a Terminal

After you have connected a terminal to a particular port on your computer (see your computer’s documentation for details on ports and cables), you must tell the system to listen for login requests from that port. Traditionally, this has been done by adding an entry to the /etc/inittab file, like this:

 ct:234:respawn:/usr/lib/saf/ttymon -g -m Idterm -d /dev/contty -1 contty

The preceding entry is identified by the two-letter entry name ct. This entry says, in system states 2, 3, or 4, start up the command /usr/lib/saf/ttymon as a stand-alone process for the “contty” port (/dev/contty). Then push the “Idterm” module onto the device (to add some additional services) and get the definitions needed for the terminal port from an entry named “contty” in the /etc/ttydefs file. respawn means that if the process dies, and you are still in states 2, 3, or 4, the process will be restarted.

The entry in the /etc/ttydefs file for “contty” that is used in the preceding entry looks like

 contty:9600 hupcl opost onlcr erase ^h:9600 sane ixany tab3 erase ^h::contty

and says that for the entry “contty,” the initial and final flags for the terminal are set to the following values:

  • Initial flags   9600 hupcl opost onlcr erase ^h

  • Final flags   9600 sane ixany tab3 erase ^h

The meanings of the flags are as follows:

9600

9600 (baud) is the line speed

erase ^h

The erase character is set to ^h

hupcl

Hang up on the last close

ixany

Enable any character to restart the output

onler

Map newline to RETURN/NEWLINE on output

opost

Post-process output

sane

Set all modes to traditionally reasonable values

tab3

Expand horizontal tab to 3 spaces

You could add a separate entry to the /etc/inittab file for each port on your computer that is connected to a terminal. This would cause a separate process to be run for each terminal on the system. However, the recommended way to start up processes to monitor ports is to use the Service Access Facility (see Chapter 14). This facility enables you to have a single process monitor several ports at once, and it also gives you greater flexibility in providing other services for ports.

Adding a Printer to Your System

Printing documents is an important part of any UNIX system. System V-based systems use the lp command set, while Berkeley-based systems use the lpr command set. Since the command structures are the same, we will describe the lp command set here.

When the Line Printer (lp) Utilities are installed, a shell script is usually set up to start the lp scheduler when your system enters a multiuser state. When you add a printer, you need to stop the lp scheduler, identify the printer, restart the scheduler, say that the printer is ready to accept jobs, and enable the printer.

In the following example, a simple dot-matrix printer will be added and connected to port 11 (/dev/term/11) to get it running. Note that this is a simple example. The lp utilities are powerful tools that let you configure a variety of printers, change printer attributes, and connect printers to networks and remote computers. Once you have connected the printer to the port on your computer, you should make sure the port has the correct permissions, user ownership (lp), and group ownership (bin) for printing. Use the following:

 # chown lp /dev/term/11 # chgrp bin /dev/term/11 # chmod 600 /dev/term/11 # ls -1 /dev/term/11 crw-------1 lp   bin     1,     0 Oct 27 13:39 /dev/term/11

To shut down the lp scheduler, type this:

 # /usr/sbin/lpshut Print services stopped.

To identify the printer to the lp system, type this:

 # lpadmin -p duke -i /usr/lib/lp/model/standard -l/dev/term/11

This will set the printer’s name to duke, use the /usr/lib/lp/model/standard file for the definition of the interface to the printer, and identify port 11 (/dev/term/11) as the port it is connected to. Restart the lp scheduler by typing this:

 # /usr/lib/lpsched Print services started.

Allow the printer to accept lp requests by typing this:

 # accept duke Destination "duke" now accepting requests.

Then enable the printer by typing this:

 # enable duke Printer "duke" now enabled.

The printer should now be available for printing. You can check it by printing a text file as follows:

 # lp -dduke testfile

This command will direct the contents of file testfile to the printer (duke).

Using CUPS to Administer Printers

Since so many UNIX variants exist today, it is difficult to develop printer drivers to support all of the different UNIX printing systems. For this reason, CUPS (Common UNIX Printing System) was developed by a company called Easy Software Products. It provides a common printing system interface, based on the Internet Printing Protocol (IPP). CUPS defines how to manage jobs and set printer options, but also adds some security features for printing over the Internet. Once CUPS is installed on your system, it provides a complete printer management environment that includes the lp and lpr subsystems and all of their commands.

CUPS is available under the GNU Public License for Linux, Mac OS, and other UNIX variants. More information about CUPS can be found at www.cups.org.




UNIX. The Complete Reference
UNIX: The Complete Reference, Second Edition (Complete Reference Series)
ISBN: 0072263369
EAN: 2147483647
Year: 2006
Pages: 316

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net