Introduction to Unix Administration

Objectivesto identify the basic concepts of Unix administrationContentshistory of Unixunix vendors and standardsworking as rootsystem administration shellsPracticalsevaluating an administration shellSummary

Unix

This chapter looks at the role of the system administrator with a Unix system. The origins and history of Unix is described to help put the role of the administrator into context. A description of the role of a system administration shell is also included.

Unix - Genealogy

1969

1972

1975

1978

1981

1983

1985

1987

1989

1991

1993

1995

1

25

500

100000

2800000

5000000

Date

Systems

SunOS

Unix System V.4 - SVR4

Unix 7th edition - non PDP

Unix 5/6th edition - C

Amdahl UTS

Unix - PDP/7

Unix 1st edition - PDP/11

BSD

SunOS 4

SCO Unix

XENIX

Unix System V.3

AIX 3.1

Solaris 2.0

Solaris 1.0

BSD 4.2

BSD 4.3

UnixWare 2.0

BSD 4.1

AIX 4.1

AIX

Unix System III

Unix System V

UnixWare 1.0

Unix SVR4.2

The genealogy of the Unix operating System and all its derivatives is complicated and cannot be represented on a single diagram. The slide shows a simplified view of the major milestones and important variants in the development of Unix.

Unix was first devised at AT&T Bell Laboratories in 1969 by Ken Thompson and Dennis Ritchie. It was to fulfil two initial purposes. Thompson had designed a hierarchical file system and wished to evaluate it; Ritchie had a space travel program which was expensive to run on the mainframe and had difficulty in controlling the simulated spaceship. An unused DEC PDP-7 became available and a single-user version of Unix was born. Soon, a system supporting two concurrent users was developed. At this point Brian Kernighan coined the name Unix as a pun on another multi-user operating system called Multics which he, and others, were attempting to design and develop.

In 1970/71Unix was ported to a new PDP-11 and official documentation was produced defining the 1st edition of the Unix operating system. In 1973 most of Unix was translated from assembler into C code, making the operating system more portable and maintainable. This was a revolutionary step forward in operating system development which were traditionally written in assembler and very machine specific. The machine independence of Unix has been a major factor in its success..

In 1976 Unix was made widely available outside of AT&T for a nominal fee. Many universities picked up copies of the source code. In particular Berkeley (California) added significant functionality to Unix to produce the most influential derivative called BSD. AT&Ts 7th edition of Unix was the first to be ported to a non-PDP-11 architecture and led to the removal of most machine dependencies in the code. BSD was ported to the DEC VAX in 1979 to become BSD3, then BSD4, of which BSD4.2 and BSD4.3 have formed the basis for several other derivatives, most notably SunOS from Sun Microsystems. AT&T amalgamated several versions of Unix together between 1977 and 1982 to create Unix System III. Unix System V took in several ideas from other variants such as BSD, and the last major release (SVR4) is an attempt to produce a definitive Unix standard.

During this time the number of Unix systems world-wide has grown from 25 in 1973 to an estimated 5 million by 1993/1994.

Major Unix Versions

AT&T System V currently release 4.2 (SVR4.2)most widely implemented version of UnixBerkeley Software Distribution (BSD)pure BSD systems usually found as free Unix on PCsOSF/1 derived from BSD with SVR4 additions

HPHP/UXSVR4 + OSF/1

ICLDRXSVR4

SNI/PyramidDC/OSxSVR4

Silicon Graphics IncIRIXSVR4

SCOUnixWareSVR4

Sun MicrosystemsSolaris 2SVR4

SCOSCO UnixSVR3.2

SequentDynix/PTXSVR3.2 + security

Sun MicrosystemsSunOS 4BSD

DECDigital UnixOSF/1 + SVR4

IBMAIXOSF/1 + SVR4

Unix comes in many flavours and under many different names (most end in X). Most systems are derived from two sources: AT&T System V or Berkeley BSD4. From a system administration point of view, the differences are readily apparent, but to most users there is no appreciable difference. Although the systems are very similar, the differences affect nearly all administration functions.

The proliferation of Unix vendors created during the 1980s had a choice of two Unix variants to base their operating system on: AT&T System V or BSD. Most vendors incorporated there own modifications to the basic system and often ported features from other versions of Unix. As a result, by the late 1980s there were many variations of Unix which, while fundamentally the same, had small but significant variations.

If 1989 AT&T and Sun Microsystems formed Unix International (UI) agreed to combine their operating systems into a single standard (SVR4) intending this to become the industry standard Unix. IBM, HP and DEC countered by forming the Open Software Foundation specifying their own Unix standard called OSF/1. OSF/1 would be compatible with SVR4 but would not be AT&T/Sun dependent. OSF/1 was mores strongly influenced by BSD Unix than by System V.

As a result there are two basic types of Unix: System V and BSD derived systems. The major difference, to an administrator, lies in how system startup and shutdown is controlled.

UI is now defunct and AT&T and Sun have now joined OSF.

Unix Standards

Unix has been standardisedSVR4, OSF/1, POSIX, spec1170standards concentrate on kernel functionality and APIadministration not covered by standardsAdministration is similar for all Unix systemscommand names can vary from one variant to anothercommand options can varysome systems provide better support for administrators than othersUnix administration is developing standardsDistributed Computing Environment (DCE)Domain Name Services (DNS)Common Desktop Environment (CDE)

Note that POSIX is often mistaken for a Unix system; this is not the case. POSIX is an interface definition for systems to conform to. Most modern Unix systems are POSIX compliant or can be configured to be POSIX compliant.

Scope of this Course

To cover basic administrative functionsdescribe underlying concepts and utilitiesFeatures described in a vendor independent mannerconcentrate on SVR4reference to other systems where appropriateCover common areas of administration in detailusers, processes, files & backupsnetworking, terminals & printersIntroduce less common administrationinstalling the system and softwareaccounting & performance monitoringUseful commands are briefly describeduse the on-line manual pages for full information

Discussion - Administration Roles

What are the typical jobs performed by a Unix System Administrator in the following categories?

Operations

Administration

Technical Support

?

?

?

The system administrator looks after the system. This covers everything from day-to-day tasks, such as backups and changing printer or toner cartridges, to administrative tasks. Larger sites differentiate between daily operations tasks and less frequent administrative tasks. They employ operators to do backups and look after printers, and administrators to deal with user-oriented functions.

More complex matters, such as software installation and system upgrades, are often classed as technical support. In many small sites, the system administrator is expected to do everything from complex technical problem solving downwards.

The system administrator is responsible for ensuring that the Unix system provides a reasonable service to its users. This involves a variety of activities, the most important of which are illustrated in the slide. Briefly, these are:

Adding new users to the system, configuring their home directories and basic privileges.

Installing any new software: applications, new versions of the operating system or bug fixes.

Monitoring the usage of the filestore, ensuring that no one is using too much disk space and that all backups are carried out properly.

Responding to problems from users, attempting to track down bugs and liaising with suppliers as appropriate.

Installing new hardware components.

Ensuring the smooth operation of any network services, such as electronic mail or remote access to other machines.

General Responsibilities

Identify your role and responsibilitiescan you delegate some of your work?Find out about your systemwhen was it purchaseddo you have hardware maintenance, if not why not?do you have OS maintenance, if not why not?What hardware does your system have?What software is installed?is all the software necessaryWho uses your system?

Identify your role as a system administrator. Find out what your manager expects and find out what your users expect (they probably won't agree with each other).

Clarify any vague areas of responsibility. Find out if you can off-load work to less well-qualified staff. Changing printer paper and toner cartridges is not very difficult compared to configuring Unix file systems, so delegate if possible.

You should have hardware maintenance for your system. An engineer should call once every 1 to 3 months (depends on the system) to perform preventative maintenance (PM). PM is like a car service, since the engineer checks that the system is functioning correctly, cleans fans, circuit boards, tape heads and so on. A hardware maintenance contract also includes quick help for solving problems when they occur, and usually covers replacement hardware costs and labour.

Is the system going to be upgraded at any time? Can you ask for more hardware? Perhaps a new DAT backup tape drive will save time (and money in the long run) when compared to your existing cartridge tape system.

Will you be able to ask for more memory or disks if the number of users increases?

Software maintenance provides new versions of the operating system (or third party system) and usually includes a help line in the supplier's support office for problem solving. Software maintenance is highly recommended, as many third party software systems will only work with the latest version of the operating system.

4.unknown

System Logbook

Keep a logbook for each systemRecord activities such assystem crashesmaintenance, hardware problemssystem upgradessoftware installationsKeep as paper copy, not an on-line copy

A system log book is an indispensable tool for the administrator. The log book is used to record all the events, trivial and important, which involve the system. The log book is a good place to store system details such as model numbers, installed hardware and software and those all important serial numbers.

Preventative Maintenance reports and other bits of paper can be kept with the log book providing a single point of reference for all information associated with the system.

Working As Root

Nearly all Unix administration must be done as user rootthis superuser account (user id 0) has unrestricted access to the systemAdministration should be done by one person at a timecheck that no one else is logged in as rootif someone else is working as root, find out what they are doingIn a secure room, keep the console logged in as rootuseful for getting out of trouble if system starts to hangdo all administration from the consoledisable root logins on other terminal lines for security

WARNING

root can irrevocably damage the system

take care when working as root

Most system administration functions are carried out using the root account. Root has unrestricted access to all system functions. Some additional system accounts are used to administer subsystems. Use these accounts to ensure that file ownership and permissions are correct for the subsystem.

On larger systems, administration may be done by several people. It is imperative that multiple administrators co-ordinate their activities. It is possible for one person to undo or corrupt work done by another.

If the machines are in a restricted access area (like a computer room), keep the system console logged in as root at all times. In the event of drastic problems, it may not be possible to log into the system; with the console logged in as root there is a chance that remedial action can be taken. Some administrators disable root logins on other terminals to prevent multiple root users working on the system. This may be a good idea, but if the console locks up, there will be no way of working as root, so always leave at least one other terminal with root access permissions.

The su Command

The set user (su) command changes to another userruns a new shell for the new userexit from the new shell to resume original user's shellsu changes your effective user id (and group id)most commands use effective uid/gid for access controlreal uid/gid not changedbe aware that some commands always use real uid/gidRoot can use su without providing a passwordother users must supply a password

$ su - root

password:

work as root, with root's environment

The su command is used by the system administrator to become another user temporarily . A new shell is invoked with the user and group ids of the specified login name.

If the - option is given, the shell executes the login profiles to set up the environment as though the new user had logged in as normal. Without the - option, the current environment is used for the new shell.

The su command logs all attempts to become a new user.

The login command can also be used to become another user. In this case, the existing login shell is replaced by a new login shell for the named user (i.e.. cannot return to existing user).

Running Commands with su

su can be used to run a command as another userUse the -c option to specify a "command string"useful for including in shell scriptssu defaults are in /root/.bash_profileit it usual for root to have a separate su pathsu attempts are logged in /var/log/messagesPermission file: /etc/sudoers tell who is allowed to suPermission file is edited with command visudo

# /bin/su - printer -c cleanup

run the printer cleanup script

# more /root/.bash_profile

The su command can be given options for the login program. For most accounts, the login program is the shell, and the -c option can be used to specify a command to execute (the next parameter given in double quotes).

Many modern Unix systems with extra security features can disallow the su command on a per user basis (either from or to individual accounts).

SVR4-compliant systems also allow commands to list environmental definitions in files reflecting command name, under /etc/default directory. The su's default path is defined in its controlling file, /etc/default/su.

Other Unix systems also have similar control files, but older Unix systems have configuration information hard-coded into the su program itself.

Note that it is usual for the su to root to reset the path to a default root path normally excluding the current directory (for security reasons).

To avoid Trojan horse programs, you should always execute su using its full pathname (/bin/su) when changing to the root user.

The /etc/default is not implemented under AIX. Some defaults are established by the command itself, some are picked

up from /etc/environment file or from files under /etc/security directory.

SuSE /etc/sudoers edited by visudo. Usally anybody can do su to root and other users in system. This file can limit su access to root in various ways, most common is to use a group wheel or similar.

AIX

Exercise - Using su

What do the following commands do and which ones require a password?

$ su

# su - henry

$ su -

# su - root -c poweroff

# exit

$ su root -c "rm /tmp/.lock321"

For your future reference the answers are sometimes included at the end of this chapter. If not, consult the manual pages or teacher for answer

Traditional Administration

Traditionally, Unix administration requires a good knowledge of the Unix operating systemAdministrators work directly with configuration files and special programsAdministrators develop or borrow extra programs and scripts to support standard utilitiesDifficult for novice administrators even to get started...

As Unix was developed by programmers for programmers, a certain level of knowledge about the system was assumed. Administrators were usually extremely knowledgeable and worked directly with low-level files and programs.

This approach has slowly changed over recent years, and better administration interfaces are being provided.

Administration Shells

System manufacturers often provide menu driven administration interfacessome are better than otherssome only work under X-WindowsAdmin shells are not as comprehensive as one would likeUnix administrators still need to know about underlying commands smit on AIX is awarded to be the most friendly and comprehensive front end to administration

LinuxWebMinhttp

SuSEYaSTtty & X

AIXSMITtty & X

Digital Unixsetuptty

HP/UXSAMX

IRIXCadminX

SCO Unixsysadmshtty

Solaris 2admintoolX

SVR4sysadmtty

tty = shell based text interface

X = X-Windows graphical enviroment GUI

http = Web based (Webmin/Usermin is very popular and smart to use)

Administration shells have been introduced to make Unix more acceptable to the commercial marketplace. The shells simplify the administration of most functions, so that relatively novice users can administer a Unix system.

The shells break down when something goes wrong, and the novice user will usually need help to correct the problems.

Lately Admin-Wizards has emerged both for tty and X.

SuSE common admin shells are yast and yast2 for tty and X. To setup X SaX2 is used. In other linuxes we have xf86config de devil one.

Summary

Unix administration is similar but not identical for all systemsUnix administrators tend to learn a lot about how Unix worksNearly all administration is undertaken as the superuser (root)Administration shells such as sysadm or SMIT can simplify Unix for novice administratorsUse the su command to run a shell as another userWhen you know one Unix system you can easly learn all other dialects.SuSE uses yast and yast2 for most common admin work.