AIX RS/6000
System and
Administration Guide
James W. DeRoest
McGraw-Hill, Inc.
New York San Francisco Washington, D.C. Auckland Bogota
Caracas Lisbon London Madrid Mexico City Milan
Montreal New Delhi San Juan Singapore
Sydney Tokyo Toronto
Library of Congress Cataloging-in-Publication Data
DeRoest, James W.
AIX RS/6000 : system and administration guide I James W. DeRoest.
cm. - (J. Ranade workstation series)
Includes bibliographical references and index.
ISBN 0-07-036439-7
1. Operating systems (Computers) 2. AIX (Computer file) 3. IBM
RS/6000 Workstation. I. Title. II. Series.
QA76.76.063D472 1994
005.4'4--- dc20
Copyright© 1995, by McGraw-Hill, Inc. All rights reserved. Printed in the
United States of America. Except as permitted under the United States
Copyright Act of 1976, no part of this publication may be reproduced or distrib­
uted in any form or by any means, or stored in a database or retrieval system,
without the prior written permission of the publisher.
1 2 3 4 5 6 7 8 9 0
9 0 9 8 7 6 5 4
ISBN 0-07-036439-7
The sponsoring editor for this book was Jerry Papke, the editing supervisor was
Joseph Bertuna, and the production supervisor was Pamela A Pelton. It was set in
Century Schoolbook by McGraw-Hill's Professional Book Group composition unit.
Printed and bound by R. R. Donnelley & Sons Company.
Illustrations and screen images for InfoExplorer and Xl 1 SMIT are
reproduced with permission by IBM Corp.
Information containe d in this work has been obtained by
McGraw-Hill, Inc., from sources believed to be reliable. However,
neither McGraw-Hill nor its authors guarantees the accuracy or
completeness of any information published herein, and neither
McGraw-Hill nor its authors shall be responsible for any errors,
omissions , or damages arising out of use of this information.
This work is published with the understanding that McGraw­
Hill and its authors are supplying information, but are not
attempting to render engineering or other professional services.
If such services are required, the assistance of an appropriate
professional should be sought.
This book is dedicated to my wife Meleece. She
has given me five wonderful daughters
and the support it takes to
live with them!
C ontents
Part 1
System Administration Tasks and Tools
Chapter 1 . Introduction
1 .1 System Administration
1 .2 RISC Architecture
1 .2.1 Multlchlp POWER
1 .2.2 PowerPC
1 .3 AIX and UNIX
1 .4 AIX and OSF
1 .5 System Administration Activities
1 .5.1 System administration tasks and tools
1 .5.2 System installation
1 .5.3 System configuration
1 .5.4 Network management
1 .5.5 Services and resources
1 .5.6 Users and security
1 .5.7 System recovery and tuning
1 .5.8 Distributed systems
Chapter 2. lnfoExplorer
2.1 AIX Help
2.2 lnfoExplorer Overview
2.3 lnfoExplorer lnstatllation
2.3.1 lnfoExplorer on CD-ROM
2.3.2 lnfoExplorer on fixed disk
2.3.3 lnfoExplorer over NFS
2.4 Using lnfoExplorer
2.4.1 Hypertext links
2.4.2 Searching
2.4.3 History and bookmarks
2.4.4 Note facility
2.4.5 Output
2.5 lnfoExplorer and man
2.5.1 Extracting man pages
2.5.2 man page format
Chapter 3. System Management Interface Tool-SMIT
3.1 SMIT Overview
3.2 Using SMIT
3.2.1 SMIT display
3.2.2 SMIT keys
3.2.3 SMIT help and messages
3.2.4 SMIT log file
3.2.5 SMIT script file
3.2.6 SMIT fast paths
3.3 Customizing SMIT
3.4 Distributed Management Environment
3.5 lnfoExplorer Keywords
3.6 Qwiklnfo
Part 2
System Installation and Operation
AIX Installation and Maintenance
4.1 Installing AIX
4.1 .1 Installation and maintenance planning
4.1 .2 Apply and commit
4.1 .3 Fiie system expansion
4.1 .4 System state
4.1 .5 Installing preloaded systems
4.1 .6 Upgrading existing AIX systems
4.1 .7 Installing from distribution media
4.2 Installing Applications
4.2.1 Non-LPP products
4.3 Applying Maintenance
4.4 Postinstallation and Maintenance Tasks
4.4.1 Review install/update status
4.4.2 Restoring your environment
4.4.3 Create new bootable media and backups
4.5 Distributed Systems
4.5.1 NFS installation support
4.5.2 Creating a reference system
4.5.3 Network install server
4.5.4 Accessing the network install server
4.6 Diskless Installation
4.6.1 Configuring an install server
4.6.2 Adding diskless clients
4.7 lnfoExplorer Keywords
4.8 Qwiklnfo
Chapter 5. System Boot and Shutdown
5.1 AIX Boot Process
5.2 Booting the System
5.2.1 Stand-alone boot
5.3 Creating Bootable Media
5.3.1 Configuring the boot l ist
5.3.2 Installing a boot Image
5.3.3 Creating stand-alone boot diskettes
5.4 Boot Sequence of Events
5.4.1 Key mode switch position
5.5 ROS lnltiallzation
5.5.1 Built-In self-test (BIST)
5.5.2 Power-on self-test (POST)
5.5.3 Initial sequence controller test
5.5.4 Core sequence controller test
5.5.5 IPL controller load boot Image
5.6 Boot Kernel Configuration
5.6.1 Phase 1
5.6.2 Phase 2
5.6.3 Phase 3
5.6.4 Runtime
5.7 Stopping the System
5.8 Troubleshooting
5.9 lnfoExplorer Keywords
5.1 0 Qwiklnfo
Part 3
System Configuration and Customization
Chapter 6. Devices Configuration and the Object Data Manager
6.1 AIX Dynamic Device Configuration
6.2 ODM Overview
6.3 ODM Components
6.3.1 ODM database
6.3.2 Objects and object classes
6.3.3 Command and library interface
6.4 ODM Editor
6.5 Configuration Tables and the ODM
6.6 Device Configuration
6.7 Predefined and Customized Devices
6.8 Device States
6.9 Boot Devices
6.1 o Small Computer System Interface
6.1 0.1 SCSl-1 and SCSl-2
6.1 0.2 Cables and adapters
6.1 0.3 Single-ended and differential SCSI
6.1 0.4 SCSI addressing
6.1 1 Updating the Product Topology Diskette
6.1 2 lnfoExplorer Keywords
6.1 3 Qwiklnfo
Chapter 7. Tapes
7.1 Tape Characteristics
7.1 .1 Physical characteristics
7.1 .2 Data format
7.1 .3 Block size
7.1 .4 Device names
7.1 .5 Tape positioning
7.1 .6 Permissions
7.2 Tape Tools
7.3 Public Domain Tape Tools
7.4 IBM Tape Devices and Characteristics
7.5 lnfoExplorer Keywords
7.6 Qwiklnfo
Chapter 8. Disks and File Systems
8.1 Disk Evolution
8.2 Disk Hardware
8.3 Disk Installation
8.4 Logical Volume Manager
8.5 Configuring Volume Groups
8.5.1 Quorum
8.5.2 Root volume group-rootvg
8.6 Configuring Logical Volumes
8.6.1 Logical volume types
8.6.2 Logical volume size
8.6.3 lnterdisk policy
8.6.4 lntradisk policy
8.6.5 Adding a logical volume
8.6.6 Mirrors
8.7 File Systems
8.7.1 Virtual file system
8.7.2 Journaled file system configuration
8.7.3 Mounting file systems
8.7.4 AIX root tree
8.8 Paging Space
8.9 Volume Maintenance
8.9.1 Moving file systems
8.9.2 Moving volume groups
8.9.3 Resizing file systems
8.1 O Troubleshooting
8.1 1 lnfoExplorer Keywords
8.1 2 Qwiklnfo
Chapter 9. Terminals and Modems
9.1 Terminal Types
9.2 Serial TTY Support
9.2.1 Cabli ng
9.2.2 Modem/DCE wiring
9.2.3 TTY/DTE wiring
9.2.4 Serial cable length
9.2.5 Port addressing
9.3 AIX TTY Definition
9.3.1 Line speed
9.3.2 Data format
9.3.3 Terminal type
9.3.4 Control characters
9.3.5 Line discipline
9.3.6 Logi n state
1 00
1 00
1 01
1 03
1 03
1 03
1 04
1 05
1 06
1 08
1 09
1 09
1 21
1 21
1 23
1 23
1 23
1 24
1 25
1 26
1 26
1 29
1 29
1 29
1 29
1 30
1 31
1 32
1 32
1 33
1 33
1 35
1 35
1 37
1 37
1 37
9.4 Modem Support
9.4.1 Signals
9.4.2 Problems
9.5 High-Function Terminals
9.5.1 Keyboard
9.5.2 Display
9.5.3 Display fonts
9.5.4 Display palette
9.5.5 Dials and lighted function keys
9.5.6 Speaker volume
9.5.7 Virtual terminals
9.6 Console
9.6.1 Console problems
9.7 Pseudo-TTY Devices
9.8 DOS TTY Defin ition
9.9 lnfoExplorer Keywords
9.1 0 Qwiklnfo
Chapter 1 0. Printers
1 0.1 Printin g Overview
1 0.2 Print Devices
1 0.2.1 Testing the device and driver
1 0.3 Print Queues and Queue Devices
1 0.3.1 Local and remote queues
1 0.3.2 Backend programs
1 0.3.3 Postscript printing
1 0.3.4 Custom backends
1 0.3.5 BSD and SYSV support
1 0.3.6 Customizing banner pages
1 0.4 Virtual Printers
1 0.5 Testing and Modifying Printer Configuration
1 0.6 qdaemon and /etc/qconfig
1 0.7 lpd Daemon
1 0.8 Administering Jobs and Queues
1 0.8.1 Starting and stopping queues and printers
1 0.8.2 Listing print jobs
1 0.8.3 Changing priority
1 0.8.4 Removing print jobs
1 0.9 ASCII Terminal Printers
1 0.9.1 Pass-through mode
1 0.9.2 lned prtty
1 0. 1 0 X Station Printers
1 0.1 1 OSF Palladium
1 0. 1 2 lnfoExplorer Keywords
1 0. 1 3 Qwiklnfo
Part 4
1 39
1 39
1 40
1 41
1 41
1 43
1 44
1 44
1 44
1 45
1 45
1 45
1 46
1 46
1 47
1 48
1 48
1 51
1 51
1 53
1 55
1 57
1 57
1 58
1 60
1 61
1 61
1 61
1 62
1 63
1 63
1 65
1 65
1 66
1 67
1 67
1 68
1 68
1 68
1 69
1 69
1 70
1 72
1 72
Network Configuration and Customization
Chapter 1 1 . TCP/IP
1 1 .1 Internet History
1 1 .1 .1 OSI model
1 1 .1 .2 ARPANET
1 75
1 75
1 75
1 76
1 1 .1 .3 NSFNET
1 1 .1 .4 CREN
1 1 .1 .5 Future Net-ATM
1 1 .2 TCPnP Suite
1 1 .3 Plannlng
1 1 .4 Hardware Components
1 1 .4.1 RISC System/6000 Micro Channel
1 1 .4.2 Ethernet
1 1 .4.3 Token ring
1 1 .4.4 Fiber Distributed Data Interface (FDDI)
1 1 .4.5 SLIP/PPP
1 1 .4.6 Serial optical channel converter (SOCC)
1 1 .4.7 High-Performance Parallel Interface (HIPPI)
1 1 .4.8 Fiber Channel Standard (FCS)
1 1 .4.9 Asynchronous Transfer Mode (ATM)
1 1 .5 TCPnP Software Configuration
1 1 .6 Addressing
1 1 .6.1 Hardware address
1 1 .6.2 IP address
1 1 .6.3 Domain address
1 1 .6.4 Host tables
1 1 .6.5 Domain name service
1 1 .7 Network Routing
1 1 .7.1 Static routes
1 1 .7.2 Dynamic routes
1 1 .7.3 Subnets
1 1 .7.4 Interface configuration
1 1 .8 System Resource Controller
1 1 .8.1 TCPnP subsystem
1 1 .8.2 Master daemon-inetd
1 1 .8.3 Other network daemons
1 1 .8.4 Start-up configuration
1 1 .9 SLIP and PPP
1 1 .1 O Anonymous FTP
1 1 .1 1 Security
1 1 .1 1 .1 Network Trusted Computing Base
1 1 .1 1 .2 Traditional security measures
1 1 .1 1 .3 Security information
1 1 .1 2 Network Management
1 1 . 1 2.1 AIX SNMP and NetView/6000
1 1 .1 3 Troubleshooting
1 1 .1 3.1 Sniffers
1 1 .1 3.2 AIX iptrace
1 1 .1 3.3 Interface status
1 1 .1 3.4 Reachability
1 1 .1 3.5 Server applications
1 1 . 1 3.6 Name service
1 1 .1 3.7 mbuf allocation
1 1 .1 4 lnfoExplorer Keywords
1 1 .1 5 Qwiklnfo
Chapter 1 2. UUCP
1 2.1 UUCP Overview
1 2.2 Using UUCP
1 2.2.1 UUCP addressing
1 76
1 77
1 77
1 77
1 78
1 79
1 79
1 79
1 82
1 83
1 85
1 86
1 86
1 87
1 87
1 87
1 87
1 88
1 88
1 89
1 90
1 90
1 94
1 95
1 96
1 96
1 97
1 98
1 98
1 98
21 0
21 0
21 0
21 1
21 1
21 5
21 5
21 5
21 6
1 2.3 UUCP Configuration
1 2.3.1 UUCP login ID
1 2.3.2 Host name
1 2.3.3 Directories and permissions
1 2.3.4 Configuration tables
1 2.4 UUCP Daemons
1 2.5 Housekeeping and Logs
1 2.6 Hardware
1 2.7 U UCP Commands
1 2.8 Troubleshooting
1 2.9 lnfoExplorer Keywords
1 2. 1 0 Qwiklnfo
Chapter 1 3. Network File System
1 3.1 Virtual File System
1 3.2 Network File System
1 3.3 Starting NFS
1 3.4 NFS Server
1 3.4.1 NFS server daemons
1 3.4.2 Exporting server file systems
1 3.5 NFS Clients
1 3.5.1 Importing file systems
1 3.6 Secure NFS
1 3.6.1 Yellow Pages
1 3.6.2 VP name space
1 3.6.3 VP file classes
1 3.6.4 VP servers and clients
1 3.6.5 Public key authentication
1 3.6.6 Starting VP (NIS) services
1 3.6.7 Automounter
1 3.7 Troubleshooting
1 3.8 Highly Available NFS Servers
1 3.8.1 High Availability Network File System/6000
1 3.8.2 Configuring HANFS
1 3.8.3 High Availability Cluster Multiprocessor/6000
1 3.9 High-speed NFS
1 3.9.1 Prestoserv
1 3.9.2 7051 network dataserver
1 3. 1 0 Andrew File System
1 3.1 1 OSF Distributed File System
1 3.1 1 .1 DCE local file system
1 3.1 2 lnfoExplorer Keywords
1 3. 1 3 Qwiklnfo
Chapter 1 4. Network Computing System
1 4.1
1 4.2
1 4.3
1 4.4
1 4.5
1 4.6
1 4.7
NCS Overview
NCS Remote Procedure Call
Network Interface Definition Language
Location Broker
Configuring NCS
Resource License Manager
Using RLM
21 6
21 6
21 7
21 7
21 8
1 4.8
1 4.9
lnfoExplorer Keywords
Chapter 1 5. System Network Architecture
1 5.1 Introduction to SNA
1 5.2 SNA Overview
1 5.3 AIX SNA Services/6000
15.3.1 Physical interface
15.3.2 Defining the network
15.3.3 Starting and stopping services
1 5.4 SNA Security
1 5.5 Network Management
1 5.6 Troubleshooting
1 5.7 lnfoExplorer Keywords
1 5.8 Qwiklnfo
Part 5
System Services and Resources
Chapter 1 6. Process Management
1 6.1 Process Overview
1 6.2 Process Attributes
1 6.2.1 Displaying process attributes
1 6.2.2 Process identifiers
1 6.2.3 Effective and real UID and GID
1 6.2.4 Controlling terminal
1 6.2.5 Resource utilization and priority
1 6.2.6 Process state
1 6.3 Parent-Child Inheritance
1 6.4 Controlling Processes
1 6.4.1 Rules of thumb
1 6.4.2 Ignoring hangup
1 6.5 Scheduled Processes-cron
1 6.5.1 crontab
1 6.5.2 Ad hoc jobs
1 6.5.3 Managing cron activities
1 6.6 System Resource Control ler
1 6.6.1 SRC components
1 6.7 lnfoExplorer Keywords
1 6.8 Qwi klnfo
Chapter 1 7. Electronic Mail
1 7.1 Mail System Overview
1 7.1 .1 Mail user agents
1 7.1 .2 Mail transport agents
1 7.1.3 Addressing and headers
1 7.1 .4 How mail is sent
1 7.2 Sendmail Configuration
1 7.2.1
1 7.2.2 sendma i l nl
1 7.2.3 Aliases
1 7 .2.4 Mail logs
1 7.3 Starting and Stopping sendmail
1 7.4 Debugging
1 7.5 Managing Mail Queues
1 7.6 OSIMF/6000
1 7.6.1 Starting and stopping the gateway
1 7.7 lnfoExplorer Keywords
1 7.8 Qwiklnfo
Chapter 1 8. News
1 8.1
1 8.2
1 8.3
1 8.4
1 8.5
1 8.6
1 8.7
Read All About It
News Resources
News Server
News Readers
News Groups
News Software Sites
Chapter 1 9. DOS Services
1 9.1 DOS Under AIX
1 9.2 DOS Tools
1 9.3 Intel Emulation
1 9.4 Personal Computer Simulator/6000
1 9.4.1 Installing DOS on pcsim
1 9.4.2 Multiuser pcsim
1 9.4.3 Running pcsim
1 9.4.4 pcsim features
1 9.4.5 pcsim AIX communication
1 9.5 Binary Interfaces
1 9.5.1 Microkernel personalities
1 9.6 Remote DOS Services
1 9.6.1 PC NFS
1 9.6.2 DOS server for AADU
1 9.7 lnfoExplorer Keywords
1 9.8 Qwiklnfo
Chapter 20. X1 1 Administration
20.1 Windows on the World
20.2 AIXwindows Overview
20.3 X Windows Administration
20.4 Product Locations
20.5 Start-up Defaults
20.6 Fonts
20.7 Window Managers-Take Your Pick
20.7.1 Window manager configuration
20.7.2 Motif Window Manager
20.7.3 OPEN LOOK Window Manager
20.7.4 Tab Window Manager
20.7.5 A Window Manager for X
20.8 Tools and Tips
20.9 IBM Xstatlon Administration
31 0
31 0
31 1
31 2
31 2
31 3
31 4
31 4
31 5
31 5
31 5
31 6
31 6
31 7
31 7
31 8
31 9
20.1 0 Xstation Hardware
20.1 0.1 Configuration and boot
20.1 1 AIX Xstation Manager/6000 Configuration
20. 1 2 X Windows Display Manager-xdm
20. 1 3 lnfoExplorer Keywords
20.1 4 Qwiklnfo
Part 6
Users and Security
Chapter 21 . Managing the User Environment
2 1 . 1 User Administration Policy
21 .2 Physical Resources
21 .2.1 User file systems
21 .3 UID Space and Groups
21 .3.1 /etc/group and /etc/security/group
2 1 .4 Resource Limits
21 .4.1 /etc/security/limits
2 1 .5 User Account Access Rights
2 1 .6 User Account Environment
21 .6.1 /etc/environment and /etc/profile
21 .6.2 /etc/security/environ
21 .6.3 /etc/security/login . cfg
21 .7 Managing User Accounts
21 .7.1 Adding a user account
21 .7.2 Updating user accounts
21 .7.3 Removing user accounts
21 .7.4 Restricting access
21 .8 Password Files
21 .8.1 /etc/passwd
21 .8.2 /etc/security/passwd
21 .8.3 /etc/security/user
21 .9 lnfoExplorer Keywords
21 .10 Qwiklnfo
Chapter 22. Auditing and Security
22.1 Security Overview
22.2 Defining a Security Policy
22.3 Passwords
22.3.1 Shadow password files
22.3.2 Password restrictions
22.3.3 Resetting users' passwords
22.3.4 Superuser access
22.3.5 Auditing passwords
22.3.6 Converting password files from other sources
22.4 Trusted Computing Base
22.4.1 tcbck command
22.4.2 Ietc I security I sysck . cfg
22.4.3 Trusted communication path
22.5 Access Control
22.5.1 Access control lists
22.6 Authentication Methods
22.6.1 Authentication tables
22.6.2 Smart card authentication
22.6.3 Kerberos-trusted third party
22.7 Network Security
22.8 System Auditing
22.8.1 Audit logging
22.8.2 Event types
22.8.3 Audit configuration
22.9 Security Tools and Information
22.9.1 virscan
22.9.2 COPS
22.9.3 Information sources
22.1 O lnfoExplorer Keywords
22.1 1 Qwlklnfo
Chapter 23. System Accounting
23.1 Accounting Overview
23.2 Data Collection
23.2.1 Connect time
23.2.2 Process resource usage
23.2.3 Command usage
23.2.4 Disk usage
23.2.5 Print usage
23.2.6 Accounting files
23.3 Accounting Configuration
23.3.1 Setup collection files
23.3.2 Identifying shifts
23.3.3 Disk accounting-/etc/filesystems
23.3.4 Print accounting-/etc/qconfig
23.3.5 Report directories
23.3.6 crontab entries
23.3.7 Work unit fees
23.4 Accounting Commands
23.4.1 Starting and stopping accounting
23.4.2 Displaying statistics
23.4.3 Summary reports
23.5 Periodic House Cleaning
23.6 lnfoExplorer Keywords
23.7 Qwiklnfo
Part 7
System Tuning and Recovery
Chapter 24. Backup and Copy Utilities
24.1 System Backups
24.2 Backup Strategies
24.2.1 What and when
24.2.2 Mounted or unmounted
24.2.3 Sizing
24.2.4 Full and Incremental dumps
24.2.5 Backup schedules and rotation
24.2.6 Disaster recovery and validation
24.2.7 Backup media
24.3 Backing Up a File System
24.4 Restoring Flies and File Systems
24.5 Other Dump Utilities
24.6 Operating System Dumps
24.7 Network Backups
24.8 The Whole Nine Yards
24.9 lnfoExplorer Keywords
24.10 Qwiklnfo
Chapter 25. System Monitoring and Tuning
25.1 Know Your Workload
25.2 AIX Operating System Characteristics
25.2.1 CPU scheduling
25.2.2 Virtual memory management
25.2.3 Disk 1/0
25.2.4 Network performance
25.3 AIX Monitoring and Tuning Tools
25.3.1 Traditional UNIX tools
25.3.2 AIX 3.2 tools
25.3.3 Performance Tool Box/6000 and Performance Alde/6000
25.3.4 AIX Capacity Planner-BEST/1 for UNIX
25.3.5 Public domain monitor package
25.4 Additional Help and Documentation
25.5 lnfoExplorer Keywords
25.6 Qwiklnfo
Chapter 26. Problem Analysis and Recovery
26.1 When Things Go Bump in the Night
26.2 Backups and Bootable Media
26.3 LED Status
26.4 System Logs
26.5 AIX Kernel Structure
26.6 Using crash
26.7 Hardware Diagnostics
26.8 Calling for Help
26.9 lnfoExplorer Keywords
26.10 Qwiklnfo
41 0
41 0
41 1
Part 8
Distributed Systems
Chapter 27. Clustering
27.1 Cluster Overview
27.2 Single System Image
27.2.1 Cluster domain name
27.2.2 Common file system
27.2.3 Management
27.2.4 Resources
27.3 Cluster Batch Queuing
27.3.1 Multiple device queuing system
27.3.2 Network queuing system
27.3.3 Monsanto CERN/NQS
27.3.4 NQSExec
41 5
41 5
41 5
41 6
41 7
41 8
41 8
41 9
41 9
27.3.5 Other NQS-based batch systems
27.3.6 Distributed job manager
27.3.7 Distributed network queuing system
27.3.8 Distributed queuing system-Codine
27.3.9 Condor
27.3.1 0 LoadLeveler
27 .3.1 1 Load-sharing facility-Utopia
27.3.1 2 There's still more
27.3.1 3 POSIX 1 003.1 5 Batch Standard
27.4 Cluster Futures
Chapter 28. Network Archiving
28.1 Storage Management
28.2 IEEE Mass Storage Reference Model
28.2.1 Components
28.2.2 Development history
28.3 Unltree Central File Manager
28.3.1 Fiie system view
28.3.2 Client access
28.3.3 Media architecture
41 9
41 9
41 9
Appendix A.
e-mail Lists and ftp Sites
Appendix B.
Sample Code
AIX RS I 6000: System and Administration Guide describes the admin­
istration and management activities required to install, configure, and
operate the AIX Operating System on IBM RISC System/6000 plat­
forms. The text covers many of the tasks common to most UNIX
implementations, yet also focuses on the areas where AIX provides dif­
ferent or enhanced functionality. Areas where AIX command personal­
ities represent either or both of its BSD and SYSV counterparts are
Why an AIX Administration Text?
Until very recently, the only information available concerning adminis­
tering AIX systems resided in the AIX documentation set. Because the
AIX manuals are delivered as softcopy with the base product, few sites
ordered the hardcopy versions of the manual set. While softcopy manu­
als work very well for ad hoc queries, they are difficult to read over
long periods of time. It's also very inconvenient to pick up your RS/6000
and carry it home to bone up on the operating system after dinner.
The IBM Technical Support Centers have done an excellent job of
filling in some of the information gaps with their topical Red Books.
Periodicals like AIXtra and RS IMagazine have provided an avenue for
disseminating information on vendor products and technologies. Self­
support networks like the NetNews comp. unix . aix news group have
helped to relate product experiences among the user base. What has
been lacking is a text that consolidates the data from all these
resources for new and experienced system administrators. AIX
RS I 6000: System and Administration Guide is intended to provide this
first stepping stone to AIX and RS/6000 management information.
Who Should Read This Book
The text is intended as a base reference for both new and experienced
AIX system administrators. The subject matter is partitioned by func­
tion to facilitate quick access. A keywords section at the end of most
chapters provides pointers into the detailed documentation presented
in the IBM hardcopy manuals and InfoExplorer information bases.
The book culminates with a discussion of the emerging clustering
and mass storage archiving technologies . These chapters include
examples of these technologies and information on obtaining repre­
sentative implementations.
Moving Target
Over the last year, while writing this book, at least three releases of
AIX have been announced. Now at the time of this writing, AIX V4 is
rumored to be in beta testing. Each release has brought new function to
the system. Add to this all the product changes and announcements
from both IBM and third-party vendors, and you begin to see the dilem­
ma I find myself in when trying to snapshot the AIX operating system
for this text. I have tried to add the new features and information to the
existing work as they have been made available. Unfortunately, at
some point it was required to close out a chapter. The work includes
AIX up to the 3.2.5 release. Future reprints will incorporate the latest
version of AIX, as well as new product offerings like DCE.
Like everything in the UNIX world, this text represents the work and
experiences of a group of programmers, developers, and administrators
whose names are too numerous to mention here. I would like to thank
all those who regularly share their experiences and frustrations with
the rest of us via the AIX-related news groups and electronic mail dis­
cussions. It has been my pleasure to work with many of the IBM AIX
development team members and marketing personnel over the years. I
can't say enough about the hard work and dedication these folks have
done in providing us, the users, with a first-rate technical workstation
and operating system. It has been a long and bumpy road from the
days ofVM/IX, IX/370, PC RT AIX & AOS, AIX/370, AIX/PS2, PAIX to
AIX/ESA, and AIX V3. I would also like to thank my colleagues from
the Open Systems Group of SHARE, Inc. and the staff at RS I Magazine
for their continuing support. Many thanks to Martin Timmerman at
the University of Waterloo for reviewing the work and keeping me hon­
est in the presentation. Finally, I want to thank my wife Meleece, who
is always my first reader and my dearest reader.
James W. DeRoest
System Administration
Tasks and Tools
I ntrod u ction
1 .1
System Administration
The UNIX operating system hasn't achieved the "drop it in and forget
it" simplicity that makes MS-DOS so popular with the masses. Until
recently, UNIX primarily inhabited the dusty halls of research insti­
tutions and universities. In these environments UNIX was used as a
programmer's tool which could be built upon to meet the needs of the
research community. It didn't have to be easy, it just had to be low
cost and provide standard common interfaces to support research col­
laboration and tool building. It is the open, standards-based face of
UNIX that has brought it to the forefront of the movement toward
open systems.
The proliferation of low-cost RISC processors has brought UNIX
onto the desktop. The open systems and right-sizing movements have
brought UNIX into the commercial glass house. The time has come
for UNIX to get a haircut, put on a suit, and go head to head with the
legacy operating systems, from desktop to big iron. Vendors and stan­
dards groups are scrambling to define and implement UNIX system
management and administration tools to satisfy the needs of this
diverse user base. Are they succeeding?
We are beginning to see some of the first offerings in the realm of
UNIX system management. Many of these tools are taking a good
deal of heat from the traditional UNIX system administrator crowd
because of the new approaches and protocols being employed to man­
age stand-alone and distributed UNIX environments. Whether this is
good or bad remains to be seen. The Open Software Foundation (OSF)
licensed their Distributed Management Environment (DME) technolo­
gy in late 1993 . While we wait for the standards to become shrink­
wrapped reality, we can test-drive the current vendor solutions and
vote on them with our hard-earned cash.
System Administration Tasks and Tools
Since you are reading this book, we can safely assume there is still
some work to be done. The wealth of services and resources provided
also makes it quite complex. Like any multiuser operating system,
UNIX requires special care to ensure that resources are distributed
equitably among the user base and that these resources are secured
from intrusion or failure. Our job as system administrators is to guaran­
tee that these requirements are being met. How do we do it? Read on!
Before we roll up our sleeves and begin hacking on system tables, it
might be helpful to those unfamiliar with UNIX history to see how we
got to this wonderful piece of software called AIX. The following is an
approximate genealogy of UNIX development milestones.
A Brief History o f UNIX
UNIX is born on the DEC PDP-7
ACM publishes Thompson and Ritchie's paper on UNIX
Bell Labs licenses UNIX to universities
SCO and Interactive Systems founded
BSD 1.0
UNIX Version 7
BSD 2.0
Berkeley ARPAnet Contract
BSD 3.0
BSD 4.0
SUN founded
AT&T System III
SUN becomes Sun Microsystems
AT&T System V
BSD 4.2
Hewlett-Packard HP-UX
AT&T System V.2
X/Open Founded
POSIX Founded
AT&T SYSV.3, Streams, RFS
BSD 4.3
AT&T SYSV .3.1
IBM IX/ 370
BSD 4.3 Tahoe
IBM AIX/ 370 and AIX/PS2
OSF Founded
OSF Motif
UNIX International Founded
Internet Worm on Nov 2
Sun SPARCstation
BSD 4.3Reno
OSF/ 1
1 .2
Apple, IBM, Motorola Venture
Sun Solaris 1.0
BSD 4.4
IBM Scalable POWER Parallel SP/1
RISC Architecture
The first Reduced Instruction Set Computer (RISC) was developed in
1975 at IBM T. J. Watson Research Center and called the 801 archi­
tecture. The IBM PC RT was based on 80 1 work. Although the 801
used a reduced number of instructions, it executed only one instruc­
tion per clock cycle. To improve performance, the 801 group started
thinking about executing more than one instruction per cycle. This
resulted in a second-generation RISC architecture that was dubbed
AMERICA. The AMERICA architecture was taken on by the IBM
Austin development lab in 1986. Austin development evolved the
AMERICA architecture into what we know today as the Performance
Optimized With Enhanced RISC (POWER) architecture used in the
RISC System/6000.
1 .2.1
Multichip POWER
The POWER architecture uses independent functional units in a
superscalar implementation to issue and execute multiple instruc­
tions per clock cycle. Separate branch, integer, and floating-point
units are fed via a four-word-wide path from the instruction cache,
enabling the dispatch of four instructions per clock cycle. The next
phase of multichip POWER architecture development will incorporate
additional integer and floating-point units, increasing the number of
instructions dispatched to six per clock cycle.
1 .2.2
Back in 1991, IBM, Apple, and Motorola formed a joint development
venture that would incorporate the POWER architecture into a sin­
gle-chip design. This new architecture would come to be known as the
PowerPC architecture. The PowerPC was designed to be a RISC
implementation that could be used in low-cost personal computers, as
well as combined in groups for multiprocessor implementations. The
group simplified the POWER architecture, improving clock cycle
times and the superscalar implementation. In the higher-end chips,
64-bit extensions were incorporated. All models of the chip are multi­
processor-enabled. The PowerPC chip uses three execution units to
deliver three instructions per cycle. It is compatible at the application
binary interface level with multichip POWER implementations.
At the low end, the Power PC model 601 is destined for personal
System Administration Tasks and Tools
TABLE 1 .1
RISC System/6000 Specifications
66 (601)
29. 1
48. 1
48. 1
46. 1
701 1/
48. 1
38. 1
101. 1
134. 6
46. 1
42. 1
38. 1
1 17.0
*Based on SPEC 92' benchmarks.
computers and technical workstations. The model 604 is intended for
midrange systems. A low-power version of the 604 called the 603 is
slated for the notebook market. At the high end, the model 620 is
designed for numerically intensive and multiprocessor architectures.
1 .3
Is AIX UNIX? It's certainly different in many respects from what
might be coined "legacy UNIX systems." What defines UNIX? Most
vendor UNIX offerings, including AIX, pass the SVID tests and are
POSIX compliant. Does this make them UNIX? Most of the differ­
ences found in AIX are related to system administration. As you
might expect, this crowd is the most vocal when it comes to complain­
ing or praising UNIX evolution. AIX offers a very solid mixture of
BSD and SYSV features. Users from either environment will find it
easy to make themselves at home. The measure of an operating sys­
tem should be whether or not it provides an environment and tool set
that assists rather than hinders your ability to do meaningful work.
AIX holds up very well under this definition.
As far as where UNIX is going, one can only hope that the vendor
community is serious about maintaining a common UNIX look and feel.
The Common Open Software Environment (COSE) alliance started by
HP, Sun, IBM, SCO, USL, and Univel is a step in the right direction.
1 .4
AIX V3 commands and libraries were accepted by the OSF as the
basis for their Application Environment Specification for the OSF/1
operating system. This is good news for the AIX user community in
that they can expect to find the face of AIX on OSF/1 offerings from
many vendors. Applications developed on AIX should port easily to
the OSF/1 environment (grain of salt here).
1 .5
System Administration Activities
What do system administrators do? They're faster than a speeding
bullet and leap tall buildings in a single bound! Seriously, UNIX sys­
tem management involves a diverse set of tasks that cover the gamut
from installation and configuration to end-user support. In large envi­
ronments, administrative tasks are managed by a group of adminis­
trators. Whether you are one or many, each administrator needs a
general understanding of administration tasks as a whole.
The text is organized to logically reflect AIX administration themes
and components, facilitating rapid location of the subject matter.
Chapters comprise detailed subject descriptions, examples, and dia­
grams . Where appropriate, both system management interface tool
(SMIT) and command line options are presented. Command examples
are flagged with the shell prompt character "#" to distinguish them
from other bullets and to remind the user that most configuration
activities are performed with superuser privileges.
# command
Each chapter culminates with an InfoExplorer topic list for obtain­
ing further information.
System Administration Tasks and Tools
This text is intended as a pointer to the more specific information
provided in the AIX hard-copy and InfoExplorer documents, as well
as to provide some insights based on practical experience with the
hardware and operating system.
1 .5.1
System administration tasks and tools
This section overviews system administration responsibilities and
identifies the base reference and management tools. Characteristics
of the AIX help system, InfoExplorer, are described. Attention is
devoted to using and tailoring the AIX System Management Interface
Tool (SMIT), which can be used to manage most aspects of the AIX
operating system.
1 .5.2
System installation
Before you can administer a system, it must be installed. Steps
required to install and apply service to AIX in diskfull and diskless
environments are discussed. An overview of the RS/6000 architecture
and boot process follows.
1 .5.3
System configuration
Once the operating system is installed, it must be customized. This
section describes the Object Data Manager (ODM) and how it is used
to store and manage configuration data. The steps involved to add
disks, printers, terminals, and tape devices to the RS/6000 and AIX
are detailed.
1 .5.4
Network management
This section discusses how to make your system accessible from a
number of network architectures and topologies, as well as what tools
and protocols are required to centrally manage a network of machines.
1 .5.5
Services and resources
Now that you have a machine and a network connection, how are you
going to make use of it? How do you control resource utilization? This
section considers such questions and examines configuring services like
electronic mail, Network News, MS-DOS support, and X Windows.
1 .5.6
Users and security
A great deal of system administrator time and energy is devoted to
managing user accounts. This section outlines ways to streamline
account management, reporting, and maintaining system security.
1 .5. 7
System recovery and tuning
What do you do when things go bump in the night? Backup strategies
and policies are explained. How do you keep your RS/6000 running hot?
System monitoring tools and problem analysis techniques are reviewed.
1 .5.8
Distributed systems
This section looks at tools and techniques that can be employed to
build a farm of networked RS/6000s functioning as a loosely coupled
multiprocessor. Strategies for providing batch, parallel, and archive
services in a clustered environment are described.
l nfo Expl o rer
AIX Help
Help! It's often the first thing uttered by a new AIX system adminis­
trator. You've invoked man to access help for a particular command. If
you're lucky, a man page will be displayed, but it may be followed by
two or three more! Being intrigued rather than put off, you type man
man and discover the existence of an information marvel called Info­
Explorer (info). You're still feeling adventurous, so you type info and
press return. Just when you thought it was safe to go into the water!
One of the first hurdles for new AIX users is mastering the help
system. Confusion over documentation location and access mecha­
nisms is the primary problem. The AIX lnfoExplorer hypertext docu­
mentation system provides a very powerful help search-and-retrieval
tool; however, it requires a bit of a learning curve before you get com­
fortable using the help system. It's too bad that you need so much
help to learn help!
lnfoExplorer Overview
lnfoExplorer provides an extensive GUI for perusing on-line docu­
mentation. It is at its friendliest when used from an Xll display, but
it may also be used from ASCII tty and pty connections. The docu­
mentation information bases include AIX and RS/6000 manual text
and graphics , reference index, glossary, product-related help files,
and add-on databases like the AIX Technical Library of HOWTO and
closed APAR documents . Hypertext links are used as fast p aths
between related documents, files, and programs. A public and private
note facility supports annotation of documents. The user interface can
be individually tailored to specify entry points, search criteria, and
printing options. History trails and bookmarks further facilitate mov­
ing between documents.
System Administration Tasks and Tools
lnfoExplorer Installation
InfoExplorer software is delivered as a part of Classic AIX. The exe­
cutables, fonts, i spath data and the NLS information bases are
located in / u s r / lpp / i n f o (see Table 2. 1). NLS information bases
may reside either on CD-ROM or fixed disk. Locating the information
bases on fixed disk will provide a snappier response, but requires an
additional 250 MB of disk space.
In multilanguage environments, more than one NLS information
base set may be installed. Access to a given NLS information base is
defined by the $LANG environment variable. Separate information
bases are provided for each product. A product information base may
provide an updated version of the / us r / lpp / info / data / i spaths
file. The i spaths file contains the hypertext paths and links used to
cross-reference data in the information bases. Care must be taken to
make certain you are using the correct i spa ths file for the informa­
tion bases installed on your system.
lnfoExplorer on CD-ROM
If disk space is at a premium, access the InfoExplorer information
bases from the distribution CD-ROM. Note that the CD-ROM distribu­
tion of lnfoExplorer information bases is a bit different than that of
preinstalled versions on disk. Mount the InfoExplorer distribution CD­
ROM as a cdr f s file system. Copy the i spaths. ful l data file from
the CD-ROM onto the fixed disk as / u s r / lpp / info / data / i spaths .
# mount -v cdr f s -r / dev/ cdO / u s r / lpp / in f o / $LANG
# cd / u s r / lpp / in f o / $ LANG
# cp i spaths . fu l l i spaths
To have the InfoExplorer CD-ROM file system mounted at boot
time, add an entry for the cdr f s file system to / e tc / f i l esys tems .
lnfoExplorer CD-ROM
/usr / lpp / in f o / En_US :
TABLE 2 . 1
/ dev/ cdO
cdr f s
lnfoExplorer Paths
/usr/ lpp / info /bin
/usr/ lpp / info / data
/usr / lpp / info / X l l fonts
/usr/ lpp / info /notes
/usr/ lpp / info /$LANG
$HOME / info
$HOME / info /notes
Executables for Xll and AS C II displays
i spaths files describing paths and links
InfoExp fonts
Public notes
Information databases (CD-ROM mount point)
Private notes
For higher availability, copy selected information bases to fixed disk.
These information bases will be available should the CD-ROM cdr f s
file system not b e mounted.
lnfoExplorer on fixed disk
If you have disk space to spare, InfoExplorer response will be much
better if the information bases are stored on fixed disk. To copy select­
ed information bases from CD-ROM to the fixed disk, mount the
InfoExplorer distribution CD-ROM as a cdr f s file system on the tem­
porary mount point /mnt . Copy the selected information bases from
the CD-ROM to the corresponding / u s r / lpp / in f o / $LANG/ <name>
directories. Unmount the CD-ROM cdr f s file system when copying
has been completed.
# mount -v cdr f s -r / dev/ cdO /mnt
# ls -al /mnt / $LANG
c opy des ired databases ( Examp l e nav , aix , etc )
# cp /mnt / $ LANG /nav/ * / u s r / lpp / info / $LANG/ nav
# cp / mnt / $LANG / aix/ * / us r / lpp / info / $LANG / a ix
# umount /mnt
If you decide to remove an information base from disk at a later
date, use the rm - r command to erase the information base subdirec­
tory from the / u s r / lpp / in f o / $LANG directory.
# rm -r / u s r / lpp / info / $ LANG/pascal
Remove pascal help
lnfoExplorer over NFS
If you want to share InfoExplorer information bases in a networked
environment, export the / u s r / lpp / i n f o / $ LANG directory using
NFS. Interactive response over NFS to information bases residing on
the servers hard disk is a bit better than local CD-ROM response.
You may wish to export selected information bases rather than the
whole set. Add the information base directories to the NFS server's
/ et c / export s file and an / e t c / f i l esys terns mount entry on each
NFS Server / et c / expo r t s InfoExplorer Example:
/ u s r / lpp / in f o / En_US -ro , access = dai sy . ferris . com
NFS Client I e t c I f i l e sys t erns InfoExplorer Example:
/ u s r / lpp / in f o / En_US :
System Administration Tasks and Tools
/usr / lpp / i n f o / En_us
rigel . ferri s . com
nf s
ro,bg,so f t,intr
Using lnfoExplorer
To start an InfoExplorer session, invoke the info command in Xll
based environments, or info -a for ASCII devices. lnfoExplorer will
display the default task selection window and an InfoExplorer overview
window for first-time users. The initial entry-point window may be cus­
tomized after you become familiar with the system. Use the cus t omi z e
menu bar field to set defaults and preferences. The default menu but- .
tons allow you to select InfoExplorer Top i c & Task Index, L i s t o f
Commands, L i s t o f Books , Programm ing Re ference, His tory, L i s t
o f Bookmarks , L i s t o f No t e s , Path, o r Search. InfoExplorer look
and feel has changed somewhat in AIX. 3.2.5, as compared with earlier
AIX. releases. These differences are minor, thus the information provid­
ed will be applicable to earlier versions. (See Figs. 2. 1 and 2.2.)
fl irtf o
fl i n f o - a
Start Xll interface
Start ASCII interface
Alternate information bases, like the AIX Technical Library, are
selected using info 1 <name> .
fl info -1 techl ib
Select techlib information base
In the Xll environment, menu options and hot links are selected
using the mouse point-and-click interface. Scroll bars are used when
text or option sets will not fit on one screen. Option boxes are provid­
ed to quickly set notes and bookmarks or move back and fo rth
through the screen path.
Accessing InfoExplorer from an ASCII device requires the use of
keys to negotiate your way around the system.
Hypertext links
Along with menu selections, InfoExplorer allows you to jump between
related documents , glossary definitions , and data file s , and also
enables you to invoke commands through the use of hypertext links.
Hypertext links are identified within displayed text through high­
lighting. To activate a link, point and click the mouse button on the
highlighted text from an Xll session, or tab to the highlighted text
and press the enter key in an ASCII session. Movement between links
will be recorded in your session history file.
With lnfoExplorer, you can access software and hardware information in an
online information base consisting of articles connected by hypertext llnl<s. A
hypertext link is a one-way path from one piece of information to another.
Items in lnfoExplorer text that appear In boxes are hypertext links. To follow a
link to more information about lnfoExplorer, move your mouse pointer inside
one of the following boxes and click the left mouse button:
!Basic lnfoExplorer Window Operations!
linfoExplorer Help!
!New lnfoExplorer Features!
!copyright and Trademark Information!
Comment Forml
If you are using the Hypertext lntbrmatlon Base library for AIX, see (8ypertextl
bnformation Base Library ContentHn AIX/6000 Vetsion 3.2 and RISC System/6000
Documentation ate1111ew for Information about what each Info Explorer clatanase
Basic lnfoExplorer Window Operations
lnfoExplorer has two basic types of screens, the madlng screen and the navigation
screen. The article you are looking at right now appears In a reading screen. Reading screens
contain conceptual, procedural, or reference information. Navigation screens display
information designed to help you access documentation. When you start
Figure 2.1
lnfoExplorer, the
InfoExplorer motif display.
The InfoExplorer search facility helps you find information when you
aren't quite certain what you are looking for. Simple and compound
text searching are supported with wildcard matching. A simple
search involves a single short text string as a search argument (see
Fig. 2 . 3 ) . Compound searching (Fig. 2 . 4 ) supports boolean search
semantics and defining the scope of the search within the document.
You may also limit the information bases included in the search to
System Administration Tasks and Tools
. Hi s tory
info Navigat i on
Top i c
Top i c & Task Index
About the Top i c & Task Index
Us ing
Programm i ng
Prob l em So lving
Answers to Cus t omer Ques t i ons
L i c ensed Program Spec i f icat i ons
( LPS )
README F i les
To s end a comment t o IBM ,
Figure 2.2
see InfoExplorer Reader ' s Commen t .
InfoExplorer ASCII display.
lnfoExplorer ASCII Key Mapping
Left arrow
Right arrow
Up arrow
Down arrow
Page down
Page up
Toggle reading and navigation
Move to next hypertext link
Move to previous hypertext link
Refresh screen
Move cursor one character left
Move cursor one character right
Move cursor one character up
Move cursor one character down
Move cursor 20 characters left
Move cursor 20 characters right
Activate menu bar
Close menu bar and move to text
Cycle through options in a ring
Activate a link or selection
Exi t
Figure 2.3
Example simple search menu.
Figure 2.4
Example compound search menu.
System Administration Tasks and Tools
improve response. Quick searches may be invoked from the command
line using the info -h option.
# info -h < s earchkey>
History and bookmarks
To facilitate moving around in an InfoExplorer session, InfoExplorer
records the document and display path in a history file. New path infor­
mation is appended to the file as you move about in the system. At any
time, you may jump forward or backward by selecting the pa th option.
History files may be saved, restored, and shared with other users.
Selected information may be marked for later reference using the
Bookmark facility. Bookmarks are stored in the $HOME / info directo­
ry and may be shared with other users by copying the bookmark files
to the user's $ HOME / info directory.
Note facility
Just like writing in the margins of hard-copy manuals, InfoExplorer
supports an annotation facility. Individual users may tag information
base text with private notes. Notes are stored in $HOME / inf o / no t e s .
The note format may be customized to individual tastes.
Private notes may added or collected from public notes by the system
administrator. Public notes can be grouped together and made available to
the entire user base by using the /usr I lpp/ info /bin/mergenote com­
mand. Public notes are stored in the /usr/ lpp / info /notes directory.
# /usr/ lpp / info/bin/mergenot e <no t e l i s t >
Text from InfoExplorer information bases may be printed or cut and
pasted into other documents. Users may customize default print
options by defining any valid command and filter stream using shell
1/0 redirection. Three print selections are supported: simple printer,
pretty print, and artwork printer.
tro f f -Tp s c
enq -P <PrinterName>
Postscript stream
lnfoExplorer and man
The man command has access to information stored in InfoExplorer
databases . When invoked, man will first search / u s r / man / c a t ?
directories, then / u s r /man/ man ? , and finally InfoExplorer data. man
and c atman map man page sections 1, 2, and 8 to lnfoExplorer com­
mands documents; sections 2 and 3 to InfoExplorer subroutines docu­
ments; and sections 4, 5, and 7 to InfoExplorer files documents. You
will need to periodically execute c atrnan - w to keep the database for
the apropos and wha t i s commands up to date.
Extracting man pages
A script is provided in the / us r / lpp /bos / bs dadrn readme file that
can be used to extract the man sections stored in InfoExplorer and
store them as flat files in the appropriate / u s r /man / cat ? subdirec­
tories. There is nothing fancy about the script. Basically it runs the
man command on each file and redirects the output to a temp file. The
temp file is then moved to / u s r /rnan / ca t ? .
man page format
From time to time you may need to add your own custom man page
information. This could be a help file explaining charging policies,
backup support, locally developed software, etc. It's a good idea to
keep local man pages separate from vendor-supplied help. This keeps
it from getting stepped on during installation, maintenance, and
upgrade activities. Commonly used location paths for local man pages
are / u s r /rnan / rnanl or / u s r / l o c a l / rnan /rnan ? . The $ MANPATH
environment variable can be set in / e t c / envi ronment to include
your local man page path. Users may also use $ MANPATH to support
their own man directories.
Local man Page Repos i to r i e s
/ u s r / man /manl
/ u s r / local / man/man?
/ u s r / local / c a t / c a t ?
When creating new man pages, you can use an existing man page as
a template. Try to stay within a common style so that your users know
what to expect. Each man page should include a NAME section identify­
ing the topic or command, a SYNOPS I S describing the command and
argument options and format, a DESCRI PTION section that describes
the topic, an OPTIONS section that details parameter and value infor­
mation, and a section on known BUGS . At the end of the man page, a
SEE ALSO section should indicate related information and an optional
AUTHOR section should identify the author name and address.
Example man Page Style:
mycommand ( l )
mycommand - Does j us t what I want to do .
mycommand [ wi l l l wont ] work
System Administration Tasks and Tools
mycommand i s always used as a l a s t resort . It can be expected
ei ther to work or fai l . mycommand contains no surp r i s e s at a l l .
wi l l
Completes the work a t hand .
Take a vaca t i on .
mycommand is always error free !
myprogram ( l } , myshe l l ( l }
Me . Who did you think it was !
You can include nro f f man tags in the man page to control display
format (see Table 2.3). After the tags are included, you can test them
using nro f f .
# nro f f -man mycommand . l
Example man Page with Tags:
. TH mycommand l
mycommand \ - Does j u s t what I want to do .
mycommand [ wi l l l wont ] work
. B mycommand
i s always used as a l a s t resort . It can
be expected e i ther to work or f a i l .
• B
contains no surpri s e s at a l l .
. TP 3
Comp l e t e s
t h e work a t
hand .
. TP 3
Take a vaca t i on .
Sample nroff man Tags
. TH <name> <num>
. SH < s e c t i on>
. B < text >
. I <test>
. PP
. TP <num>
man page name and section number
Identifies a subsection
Bold or highlighted text
Italics text
Block out a paragraph
Indent paragraph <num> spaces
except first line
. B myconunand
is always error free !
myprogram ( l ) , myshel l ( l )
. B Me .
Who did you think it was !
Remember to run the ca tman -w command periodically to keep the
aprop o s and wha t i s data up to date. You might want to add it to
roots c rontab .
The IBM Austin Information Design and Development group would
like your feedback and comments concerning AIX documentation and
the InfoExplorer help system and other AIX publications . An
lnfoExplorer Readers Comment Form is included as part of the sys­
tem and is accessible from the Top ic & Task Index. Follow the
instructions on the form and return it to the address indicated. You
can also e-mail comments to them at the following Internet address:
/ us r / lpp / i n f o
InfoExplorer product
/ u s r / lpp /man / $LANG
Hypertext database direc­
tory (disk, CD-ROM,
mount -v cdr f s -r / dev/ cdO /u s r / lpp / in f o / $LANG
Mount info CD-ROM
Motif interface
info - a
TTY interface
man Pages:
AIX man page location and search order:
/ u s r /man / c a t ?
Formatted text
/ us r /man / man?
nroff format
/ us r / lpp / inf o / $ LANG
catman -w
Update whatis database for apropos command
/ u s r / lpp /bos / bsdadm
Contains sample script to convert InfoExplorer hyper­
text to man text
System Management
I nterface Too l-SM IT
UNIX has a bad reputation when it comes to system management.
Most of the traditional UNIX management tools are the products of
necessity, built by frustrated system programmers. Historically, UNIX
development efforts have focused on designing the building blocks that
support this "roll-your-own" methodology-Perl being a case in point.
In production enterprises, UNIX must conform to the management
policies and practices that are the hallmarks of big iron operating sys­
tems. Ad hoc tool development is not acceptable in many of these
environments. A new breed of UNIX management tools is required
that will provide centralized control over distributed heterogeneous
resources. The tools should also interoperate with the existing legacy
tool sets. The Open Software Foundation is ready to license its
Distributed Management Environment (DME), however, real shrink­
wrapped DME tools remain products of the future.
Rather than wait, many vendors have begun testing the waters with
their own UNIX management tools. In general, most of these tools
integrate graphical interfaces with traditional UNIX commands to
streamline system installation, configuration, and management tasks.
3. 1
SMIT Overview
AIX provides a central administration and management tool called
the system management interface tool (SMIT) . SMIT is a complete
administrator's toolbox that may be used to perform system manage­
ment activities such as software installation and maintenance, device
configuration, administration of user accounts, system backups, and
diagnosis of problems. SMIT uses a menu-driven interface that
streamlines and simplifies the complexity of many system manage­
ment activities . SMIT does not inhibit or replace command line access
to system management; rather, it uses these same commands under
the cover of the menu-driven interface. Not all possible command and
System Administration Tasks and Tools
argument combinations are available under SMIT. Command and
parameter selection is based on the most common use to complete a
given management task.
For novice administrators, SMIT simplifies system management
through the use of task-oriented dialogs. New users can zero in on a
particular task by stepping through SMIT's submenu hierarchy.
Menu options for a specific task are identified with descriptive field
titles and contextual help. Error-checking routines validate argument
type and range.
The advanced administrator may find that SMIT provides a faster
interface to many management tasks. The SMIT script facility may
be used to assist in creating complex administration scripts.
The choice is yours whether or not you elect to use SMIT to manage
AIX AE you gain experience with SMIT and the AIX environment,
you may find that you prefer to use SMIT for some management
activities and the command line for others. Whether you love it or
hate it, SMIT is here to stay. As they say, SMIT happens!
Using SMIT
SMIT is started by executing the smi t command from the command
line. By default, SMIT will enter the top-level system management
menu (see Fig. 3 . 1). To enter SMIT at a particular task submenu,
supply the SMIT fast-path name as an argument.
# smi t
Start SMIT at top-level menu
# smi t user
Start SMIT at the user admin submenu
SMIT allows you to take a test drive utilizing all of its features with­
out making changes to the operating system. Invoke SMIT with the x
to kick the tires and get a feel for how it operates. SMIT will log the
commands it would have executed in the $HOME / smi t . s c r ipt file.
# smi t
You can also use the F6 key within SMIT to display the AIX com­
mand and arguments it will invoke before committing the update.
SMIT display
SMIT provides both an ASCII and a Motif based user interface. The
Motif interface is invoked by default on an Xll managed display and
employs a point-and-click feel. The Motif display (Fig. 3.2) enhances
the operating environment through the use of buttons, slider bars,
and submenu panels. The SMIT ASCII interface (Fig. 3.3) is invoked
using the smi t ty or smi t c commands.
# smi t user
# smi tty user
# smi t
SMIT Xll interface
SMIT ASCII interface
SMIT ASCII interface
System Management Interface Tool-SMIT
Sys t em Management
Move cursor to des ired i tem and press Enter .
Ins t a l l a t i on and Maintenance
Phys ical & Logical S torage
Securi ty & Users
Diskless Works tation Management
Commun i c a t i ons App l i c a t ions and Services
( Print Jobs )
Problem Determina t i on
Performance & Resource Schedul ing
Sys t em Environment s
Proces ses & Subsystems
Appl ications
Us ing SMIT ( information only )
F l = Help
F 9 = Shel l
Figure 3.1
F 2 = Re f resh
FlO = Ex i t
F 3 = Canc e l
Enter = D o
F8 = Image
System Management Interface Tool.
Each SMIT panel is divided into three parts. At the top of the panel
the task title and instructions appear. The middle of the screen con­
tains menu selections or input fields. Location in the set of fields is
indicated by [ TOP ] , [ MORE... # ] , and [ BOTTOM ] . At the bottom of each
panel, the set of valid function keys is listed in four columns. SMIT
flags input field types and selection lists through the use of field mark
characters (see Table 3 . 1 ) and buttons displayed to the far left and
right of the input fields.
SMIT keys
To navigate between fields and options in a SMIT panel, use the TAB
and Arrow keys, or the mouse. Input field values may be typed from
the keyboard or, in some cases, selected from a list. The Enter key
invokes and commits the selection or task. SMIT also provides a set of
function keys to display additional information, access the shell, or
exit (see Table 3.2).
SMIT help and messages
SMIT help can be invoked from any menu by pressing the Fl key. The
help and message text is located in /usr I lpp /msg I $LANG / smi t . cat
catalog. Note that the message catalog is a National Language (NLS)
System Administration Tasks and Tools
Figure 3.2
SMIT Xll display.
catalog, and is thus dependent on the setting of the $ LANG environ­
ment variable. An invalid or missing $LANG specification will result in
missing or garbled help and message information.
1 8 0 0 - 0 4 0 cannot open S o f t Copy help information
databas e . Help i s not ava i labl e f o r thi s
SMIT s e s s ion . You may cont inue from here or
you can check the $ LANG envi ronment variable
s e t ting o r use local problem report ing
procedure s . For the current s e t t ing o f
" / us r/ lpp / info / C / ai x / a i x . key " ,
" / usr / lpp / info / C / a ix/aix . rom " ,
" / usr / lpp / info / C / sys . sys " .
( " /us r / lpp / in f o / C / aixmin/ aixmin . key" )
( " /usr / lpp / inf o / C / aixmin/ aixmin . rom " )
( " /usr / lpp / in f o / C / sys . sys " )
System Management Interface Tool-SMIT
Create User
Type or s e l e c t values in entry f i e l ds .
Press Enter AFTER making a l l des i red changes .
[ Entry F i elds ]
[ TOP ]
* User NAME
User I D
LOGIN u s e r ?
Group SET
SU groups
HOME direc tory
I n i t i a l PROGRAM
Another user can SU to user?
User can RLOGIN?
F l = Help
F S = Undo
F9 = Shel l
Figure 3.3
F3 = Cancel
F7 = Edi t
Enter = Do
F 2 = Re f resh
F 6 = Comnand
F l O = Exi t
F4 = L i s t
F8 = Image
SMIT ASCII interface.
SMIT Dialog Symbols
Arrow button
List button
t rue
t rue
Entry is required
Numeric field
Hexadecimal field
File name field
List available
Field delimiters
Fixed set of options
List of choices
(ASCII display only)
(ASCII display only)
(Motif display only)
(Motif display only)
SMIT Function Keys
Refresh screen
Display selection list
Undo entry-reset to default
Display command and args
Edit or select
Display fast-path name
Shell escape
Move between options
System Administration Tasks and Tools
SMIT log file
SMIT creates an audit log of each SMIT session in the user's $ HOME
directory named smi t . l og. The log file indicates the SMIT submenu
path traversed during the session by object class ID, panel sequence
number, title, and the fast-path name. Each new SMIT session is
appended to the existing log file. Care must be taken to monitor the
size of the log file over time. The location of the log file may be set
using the smi t - 1 <PathName> option. The level of logging verbosi­
ty may be increased using smi t -vt.
# smi t -1 / tmp / smi t . log -vt
Use /tmp to hold log file
SMIT Log Example-Adding a 9-Track Tape Drive
[ Sep 07 1 9 9 3 , 1 3 : 2 9 : 3 6 ]
S tart ing SMIT
( Menu screen selec ted as Fas t Path ,
id = "_ROOT_" ,
id_seq__num = • o • ,
next_id = " top_menu • ,
t i t l e = • sys t em Management • . )
( Menu screen selected ,
Fas tPath = " top_menu • ,
id_seq__num = • o • ,
next_id = • top_menu • ,
t i t l e = • system Management " . )
( Menu s creen selec ted ,
Fas tPath = " dev• ,
id_seq__num = • 0 2 0 • ,
next_id = " dev • ,
t i t l e = " Devices • . )
( Menu screen selected ,
FastPath = • tape • ,
id_seq__num = • o s o • ,
next_id = • tape • ,
t i t l e = " Tape Dr ive • . l
( Selector screen selected,
FastPath = "maktpe " ,
i d = •maktpe • ,
next_id = "maktpe_ • ,
t i t l e = "Add a Tape Drive • . )
( Selector sc reen s e l e c t ed ,
FastPath = •maktpe • ,
i d = •maktpe_9 trk_s c s i • ,
next_id = "maktpe_9 trk_s c s i_hdr " ,
t i t l e = "Add a Tape Drive • . )
( Dialogue screen selec ted ,
FastPath = "maktpe • ,
id = •maktpe_9 trk_s c s i_hdr " ,
t i t l e = "Add a Tape Drive • . )
[ Sep 0 7 1 9 9 3 , 1 3 : 2 9 : 5 0 ]
Command_to_Execute f o l l ows bel ow :
>> mkdev -c tape - t ' 9 trk ' -s • s c s i '
[ Sep 0 7 1 9 9 3 , 13 : 2 9 : 5 2 ]
Exi t ing SMIT
-p ' s c s i l '
-w ' 1 0 '
SMIT script file
Along with the log file, SMIT appends the AIX commands invoked
during the session to a local $ HOME / smi t . s cript file. The script file
System Management Interface Tool-SMIT
information can be used to create complex management scripts or
review the commands invoked during a previous session. For exam­
ple, you might use SMIT to configure the first of a set of 64 TTY
devices. Then edit the $ HOME / smi t . s c ript file and duplicate the
mkdev command 62 times for the remaining devices, changing each
device name and attributes as required. The script file can be execut­
ed from the command line to complete the definition of the remaining
devices. Use the smi t - s < PathName> option to create a script file
in a location other than your home directory.
# smi t -s / tmp / smi t . script
Create a script file in /tmp
SMIT Script Example-Adding a 9-track Tape Drive
# [ Sep 07 1 9 9 3 , 1 3 : 2 9 : 5 0 ]
mkdev -c tape - t ' 9 trk ' -s
' sc s i '
-p ' sc s i l '
-w ' 1 0 '
SMIT fast paths
SMIT allows you to bypass menu levels and enter a task directly
through the use of a fast-path name. A fast-path name is an identifier
for a particular SMIT panel (see Table 3.3). Fast-path names are
recorded as part of the $ HOME / smi t . l o g information. The fast-path
name is included as an argument to the smi t command to enter a
task panel directly.
# smi t nfs
Access SMIT NFS management
Remembering all the fast-path names and management commands
can be a real bear. Fortunately, the AIX developers implemented an
easy-to-remember rule for remembering the fast-path and command
names . A set of four prefixes, l s , mk, ch, and rm are appended to a
root task name to l i s t , make, change , and remove operating sys­
tem obj ects. For example, to make a CD-ROM device, the fast-path or
command name is mkc drom. This doesn't work all the time, but it's
better than nothing!
j fs
sinstal lp
spo o l er
sys tem
Common SMIT Fast-Path Names
Devices management
Journaled file system management
Logical volume manager management
NFS management
Software installs and maintenance
Print queue management
System management
TCP/IP management
User administration
System Administration Tasks and Tools
Fast path and command algorithm
dev, user, fs, vg, pv, tty, cdrom, diskette, tape, etc.
ls, ch, rm
Customizing SMIT
SMIT consists of a hierarchical set of menu panels, an NLS message
catalog, command interface, and a logging and scripting facility.
These components are integrated to provide a seamless interface for
managing the operating system and system resources.
Three types of SMIT display panels are used to manage the dialog
between the user and management tasks: menu, selector, and Dialog.
Menu panels display management task selections . Selector panels
present a range of values of which one or more is to be selected before
proceeding with the management task. Dialog panels provide input
fields for specifying command arguments and values. (See Table 3.4.)
SMIT panel s , command link descriptions, option defaults , and
attributes are stored as objects in the ODM database. SMIT obj ect
classes (see Table 3.5) reside in the /usr / l ib / obj repos directory.
Symbolic links are used to provide access from the default ODM data­
base path, I e t c I obj rep o s .
SMIT obj ect classes may be manipulated using ODM commands
just like any ODM obj ect (see Chap. 6). After becoming experienced
with the ODM and SMIT architectures, you may use ODM commands
to customize SMIT. SMIT object class names and obj ect identifiers
are listed in the SMIT log file when SMIT is invoked with the verbose
trace, -vt option.
# smi t -vt
SMIT verbose tracing
To display an object class description associated with a SMIT object,
identify the object class, identifier, and number from the log. Then use
the odmshow or odmget commands to list the object description.
# odmshow sm_menu_opt
SMIT Panel Types
Display SMIT menu object class
List of task options
Request additional input before proceeding
Request values for command arguments and options
SMIT Object Classes
.. dr
Menu titles and options
Selector titles, attributes, and links to other screens
Dialog titles, base command, links
Defaults, input types, selector/dialog attributes
System Management Interface Tool-SMIT
odmget can be used to retrieve an existing entry for modification or
as a template for a new object. After updating the definition, delete
the old entry with odmde l e t e and add the new object using odmadd .
This is not something I would recommend unless you are very famil­
iar with the ODM and SMIT. Always back up the existing object class
information before making any modifications.
Distributed Management Environment
The Open Software Foundation has defined a management standard
for dis tribute d systems c a l l e d the Distri b u ted Ma nage ment
Environment (DME). DME supplies a uniform and consistent set of
tools and services which may be used to manage both stand-alone and
distributed heterogeneous systems, applications, and networks.
DME combines a select set of vendor management technologies into
a consistent framework based on a three-tier model. The lowest tier
supports single-host management activities. The second level pro­
vides cell naming and security management in distributed environ­
ments. The top level encompasses enterprisewide management via
Motif based GUI interfaces. DME routines communicate with man­
aged objects using DCE, SNMP, and OSI CMIP.
DME Technology Selections
Data Engine, System Resource Controller
MIT Project Athena
Palladium Print Services
WizDOM Object Oriented Framework
Network Logger
Open View Network Management Server
Software Distribution/Installation Utils
Network License Manager
Groupe Bull
Consolidated Management API
PC Ally and Client Lib for Net License Server
PC Agent and Event Components
The DME Request For Technology (RFT) was first issued in July
1990. After evaluation by OSF's Munich Development Office, a selec­
tion was made in September 199 1 . The selected technologies have
gone through a period of integration and testing, during which time
code snapshots have been made available to interested parties. DME
Network Management Option version 1.0 is generally available from
the OSF to all interested parties.
lnfoExplorer Keywords
smi t ty
System Administration Tasks and Tools
srni t . l og
srni t . s c r i p t
odrng e t
odrnde l e t e
Motif Interface
smi t
smi t -C ,
smi t ty
TTY Interface
smi t -X
Inhibit updates, test-drive SMIT
F 6 key
Display command to be executed by SMIT
smi t < f a s t -path-name>
Display SMIT submenu
$HOME / smi t . log
SMIT transaction log
$HOME / smi t . s cript
SMIT command log
/ e tc / obj repos / sm_xxxxxx
SMIT ODM panel database
/us r / l ib / obj repo s / sm_xxxxxx
SMIT ODM panel database
System Installati on
and Operation
AIX I nstal lation and
Mai ntenance
Installing AIX
One thing that IBM is well known for is documentation. It's a close
bet whether the installation and maintenance documentation you
receive with each RISC System/6000 weighs more than the hardware.
Although I have mixed feelings about the information provided in
some of the IBM documentation, the IBM AIX Version 3.2 for RISC
System / 6000 Installation Guide is a first-rate document. It's easy to
follow, helps get the job done, and exercises your upper body each
time you pick it up.
Another thing IBM is known for is changing the maintenance pro­
cedures with each new release. Each time you install AIX, I recom­
mend that you follow the installation guide carefully (even when you
feel like you can do it in your sleep). I can tell you from experience
that cutting corners can have catastrophic results. Follow the install
path that fits your environment and you'll keep surprises at a mini­
mum. Rather than duplicate the information in the install document,
I'll concentrate on condensing the install process down to the general
tasks. I'll also make a few suggestions to help keep your existing envi­
ronment isolated from the install and maintenance process.
While writing this text, the AIX maintenance procedures have
changed three times. I recommend staying as close to the current
release as is comfortable. I will concentrate on installation and main­
tenance function at the AIX 3.2.5 level, since it is the last one I have
personally used. Most of the SMIT panels are similar to those used in
earlier releases. The fast-path names have changed in 3.2.5. If you
are running an older release of AIX, read this text while looking
through a glass of water. If you're still uneasy, start at the top and
proceed through the SMIT software maintenance submenus until you
find what you're looking for.
4.1 .1
System Installation and Operation
Installation and maintenance planning
Installing a brand new operating system or application is like paint­
ing on clean canvas. You're not encumbered with preserving or work­
ing within any existing paradigm. You have the freedom to plan your
environment from scratch. Planning is the key word here. Operating
system and product file system configuration should not waste disk
space. Implement a configuration that facilitates future product
upgrades and maintenance tasks. Reserve disk space for non-roo tvg
volume groups to hold your user and local product file systems. If you
are installing multiple machines , consider installing one system as a
reference system, which can then be cloned from a network install
server. Eliminate duplicate file system requirements for diskless
client shared product object trees (SPOT). Make use of the worksheets
provided in the planning section of the installation guide. The plan­
ning sheets make a good reference set when you need to review your
installation plan at some time in the future.
4.1 . 1 . 1
Installation considerations
Installation media
Additional maintenance
BOS disk space
Product disk space
Paging space
/ tmp space
Separate volume group for local user and product file systems
Reference system and install server
Network parameters
SPOT support for diskless clients
Preservation of configuration and data on existing systems
Before jumping in with both feet, read any product-related readme
file s . Contact IBM support representatives concerning the latest
maintenance level and preventative service planning (PSP) informa­
tion for the release level being installed. Before you contact an IBM
service representative or IBM software manufacturing, make sure
you have your AIX version and release numbers, your service modifi­
cation level, machine serial number, model number, and your cus­
tomer number. To identify the version and release numbers for an
existing system use the uname command. AIX 3.2.4 provided a new
command for identifying the operating system level: o s l eve l . The
"<>" characters indicate whether you are "<" at a lower level, ">" at a
higher level, or "<>" equal to the displayed level.
AIX Installation and Maintenance
II uname -v -r
2 3
Note that uname will give the release level first, regardless of the
argument order. Thus, "2 3" indicates V3 R2.
II uname -m
Display machine id
xxyyyyyynuns s
00 for RS/6000
Model identifier
Submodel identifier
II o s l evel
AIX 3.2.5 product level
<>3 2 5 0
Your system maintenance level can be inferred from bas . obj his­
tory. Use the l s lpp -h command to display the maintenance history
and state.
11 l s lpp -h bes . obj
Short listing
S tatus
Fix Id
Path : /usr/ l ib / obj repos
bes . obj
0 3 . 0 2 . 0 0 0 0 . 0 0 0 0 COMPLETE
Ac t i on
User Name
16 : 00 : 00
Path : / e tc / obj repos
bes . obj
03 . 02 . 0 0 0 0 . 0000
16 : 00 : 00
II l s lpp -a -h bes . obj
Fix Id
Path : /usr / l ib / obj repos
bes . obj
03 . 02 . 0 0 0 0 . 0000
U4 0 1 8 6 4 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0 0 0 0 . 0 0 0 0
U4 0 1 9 62 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 6 3 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0 0 0 0 . 0 0 0 0
U4 0 1 9 6 8 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
0 3 . 02 . 0 0 0 0 . 0 0 0 0
U4 0 1 9 6 9 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 7 0 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 7 2 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 7 7 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 7 9 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 1 9 8 0 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
0 3 . 02 . 0 0 0 0 . 0 0 0 0
U4 0 1 9 8 6 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
0 3 . 02 . 0 0 0 0 . 0 0 0 0
U4 0 2 0 2 7 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0 0 0 0 . 0 0 0 0
Verbose listing
Ac t i on
0 9 / 04/92
0 9 / 04/92
0 9 / 04/92
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04/92
0 9 / 04 / 92
0 9 / 04 / 9 2
16 : 00 : 00
13 : 00 : 00
12 : 50 : 0 0
10 : 3 1 : 46
09 : 49 : 40
10 : 31 : 47
09 : 49 : 55
17 : 55 : 46
15 : 07 : 2 0
17 : 55 : 46
15 : 0 6 : 42
17 : 55 : 47
15 : 10 : 2 0
10 : 3 1 : 47
09 : 50 : 10
13 : 2 6 : 34
13 : 2 5 : 0 6
17 : 55 : 46
15 : 07 : 57
12 : 59 : 59
12 : 43 : 57
13 : 00 : 00
12 : 45 : 17
13 : 00 : 00
12 : 49 : 18
!l:o�r Name
System Installation and Operation
U4 0 2 0 4 3 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 2 0 4 4 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 2 0 9 3 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 2 0 9 8 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 2 0 9 9 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
U4 0 2 1 0 1 0 3 . 0 2 . 0 0 0 0 . 0 0 0 0
03 . 02 . 0000 . 0000
1 1 / 2 4 / 92
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 9 2
0 9 / 04 / 92
0 9 / 04 / 92
10 : 3 1 : 43
09 : 46 : 37
13 : 00 : 01
12 : 52 : 0 6
17 : 5 5 : 59
15 : 55 : 50
17 : 5 5 : 4 8
15 : 11 : 46
17 : 5 6 : 18
17 : 09 : 50
17 : 56 : 54
1 6 : 42 : 2 6
A quick snapshot of maintenance history can be obtained using the
- L option to l s lpp .
# l s lpp -L bes . obj
Process ing . . . . . Please Wai t .
bes . obj 3 . 2 . 0 . 0
3 2 5 0 bo s Maintenance Leve l
Vital User Inf orma t i on
Device Drivers
Character Stream Edi t ing U t i l i t i e s
Device D i agno s t i c s
U4 9 1 1 2 3
U42 3 5 1 5
U4 2 3 5 3 5
U4 2 3 6 4 3
U42 3 7 6 1
Look for the following fix numbers in the output stream. It will give
you an indication of the modification level of your system.
U41 1 7 1 1
3 . 2 . 3 Extended
U401864 only
3.2.0 else 3.2.1
In the United States, you can order software updates from IBM
Software Manufacturing:
IBM Software Manufacturing
For specific problem fixes, contact IBM Support:
IBM Support
1-800-237-55 1 1
IBM AIX/6000 support offers a number o f options fo r specialist assis­
tance for installation, problem solving, and tuning. For general infor­
mation contact AIX support at:
AIX Installation and Maintenance
AIX/6000 Support Family
IBM Corporation
P.O. Box 9000
Roanoke TX 76262-9989
FAX: (817) 962-6723
You can review the problem and service database yourself if you
have access to IBMLink. If you don't have access to IBMLink, IBM
provides periodic snapshots of the IBMLink question and service
databases on CD-ROM; order AIX Technical Library I 6000 CDROM.
IBMLink may be accessed via the Internet:
t e l n e t IBML ink . advant i s . c om
If you have access to the Internet or Usenet news, reference the
c omp . unix . aix discussion and archives. The best information comes
from peers who are using AIX in various production environments.
IBM support personnel and developers also watch these groups and
may lend assistance.
4.1 .2
Apply and commit
To commit or not to commit-that is the question.
Before installing new software or maintenance on an existing system,
you need to have a backout strategy in the event that problems occur
during or after the installation. The AIX default is used to add new soft­
ware and maintenance to the system using the APPLY option. This
option keeps a history file and a backup copy of each object replaced by
the software update. If you are not happy with the update, you can
REJECT it and restore the previous version. When using SMIT to install
software updates, use the default COMMIT s o f tware ? no option.
# ins t a l lp - qa -d / ins t . images -X a l l
# ins t a l lp - rB -X a l l
APPLY updates
REJECT updates
Once satisfied with the update, you can COMMIT the update to
remove the backup copy of the previous version:
# ins t a l lp -c -g -X a l l
COMMIT updates
The caveat of installing using the APPLY option is that additional
disk space is required in / u s r / lpp to hold the old version. This addi­
tional space is also difficult to reclaim once the new software is com­
mitted. If you don't have the disk space to spare, you may elect to
System Installation and Operation
install the update with COMMIT. This option will save on disk space,
but does not provide a simple backout mechanism. Make a full dump
of your root file systems prior to installing with COMMIT. In the
event of a problem, you can restore the backup.
# ins tallp - qa -d / in s t . images -c -N a l l
Install with COMMIT
In the event that you must back out a committed lpp, there is a script
originally provided by IBM Support that can be used to remove the
update and associated links.
4.1 .3
File system expansion
To ensure that sufficient file system space is available, you can elect
to have file system size automatically increased during the installa­
tion. Unfortunately, this process tends to overallocate file system
space, the result being wasted disk space at the end of the installa­
tion. Automatic file system expansion can also cause the installation
to abort if the requested increment in logical partitions is not avail­
abl e . In most cas e s , you will be better off calculating the space
r e quire d for the up d ate and allocating the s p ace manually.
Remember, you cannot easily shrink a file system once it is overallo­
# ins t a l lp -qa -d / in s t . images -X a l l
# ins t a l lp -qa -d / in s t . images a l l
4.1 .4
No autoexpansion
System state
When installing a new product release or maintenance, limit the
activity on your system. For some products, this may only involve
restricting access to the application being updated and stopping any
related subsystems and subservers. Use the s tops r c command to
shut down subsystems and subservers.
# s t opsrc -g tcpip
Stop tcpip subsystem
For operating system updates or when updating a group of prod­
ucts, it is easier to reduce system activity by shutting down to main­
tenance mode. This will stop all subsystems and restrict access to the
system other than from the system console.
# te li n i t M
Shut down to maintenance mode
You can temporarily inhibit login access by creating a / etc / no l o ­
gin file. The t sm l o g i n command will display the contents o f the
/ et c / no l ogin file at each login attempt and then exit.
A IX Installation and Maintenance
Example / e tc / no login
Login access is temporari ly inhibi ted due to sys tem maintenance
a c t ivi ties . Please try agai n later .
4.1 .5
Installing preloaded systems
If you are installing a brand new RISC System/6000, parts of the
basic operating system (BOS) and product run-time environments are
preinstalled on the system. Note that the preinstalled system does
not represent the full product or maintenance set. You must complete
the installation of the remaining products and maintenance before
configuring the system for use. Preloaded software is located in the
/ u s r / sys / in s t . image s directory.
4.1 .5.1
Preloaded install steps
0. Complete installation planning.
1. Power up the system with the key switch in the NORMAL position.
2. Log in as r o o t and set the TERM environment variable for your
terminal type.
II echo TERM
Display current setting
II export TERM = < type>
Set new terminal type
3. Check and set NLS language LANG environment variable.
II echo LANG
Query language setting
II export LANG = <NLSl ang>
Set new NLS language
4. Review the BOS readme file.
II more / u s r / lpp /bos / README
5. Install preloaded software and maintenance. Use SMIT fast path
s instal lp or the ins tal lp command. It's a good idea to copy any
additional maintenance into the preloaded software directory /usr­
/ sys I ins t . images and install software and updates as a unit.
6. Complete postinstallation tasks described in Sec. 4.4
4.1 .6
Upgrading existing AIX systems
Installing an upgrade or maintenance to an existing AIX system is
much easier if you have kept your user file systems and local product
data on non-roo tvg volume groups. Before installing the upgrade or
maintenance, these volume groups may be exported, protecting them
System Installation and Operation
from update problems . Once the update is complete , they can be
# exportvg <VGname>
Install upgrade
# importvg <VGname>
You may wish to save some configuration files-for example, pass­
word files, auditing configuration, printing qconf ig , network tables,
etc. If you know the installation date of your last upgrade, you can
use the f ind command to walk the roo tvg file systems and log file
names modified since the last upgrade date. Edit the log file and
remove any unnecessary file names. The log file can be easily convert­
ed to a script to copy the desired configuration files to a safe location
or backup medium.
# find / e t c -mi t ime <Ndays> -print > save-config
# f ind /usr / l ib -mi t ime <Ndays> -print > > s ave - c onf i g
AIX installation procedures provide a preservation install option
which does not destroy all of the roo tvg file systems. Only the / u s r ,
I tmp , I var , and I file systems are overwritten. There is a set of
upgrade utilities for AIX V3. l sites which preserve some configura­
tion files for later restoration on the AIX V3. 2 system. Beware that
there is a problem with preservation installs if you change the logical
device names of the default paging volumes.
Before initiating a preservation install, record location, layout, and
space on e ach of the physical volumes to be used by the install
process. Begin by displaying the physical volume names.
# ipl_varyon -i
For each physical volume display the location information.
# l s dev -C -1 hdi skO
hdi skO Ava i lable 0 0 - 0 8 - 0 0 - 0 0 6 7 0 MB SCSI Disk Drive
Use df and l svg to total the used and free space making up the root
file systems and the root volume group.
# df -v I / us r / tmp /var
AIX lnstallatlon and Maintenance
F i l !illi!Yli!t§!l
/ dev/hd4
/ dev/hd2
/ dev/hd3
/ dev/ hd9var
TQ!;al �
� �
3 02 5 1 6
17438 107490
2 60509
/ tmp
/ var
# l svg roo tvg
4.1 .7
a c t ive / c ompl et e
read/wr i t e
PP S I Z E :
0 0 0 0 1 5 0 8 fc e 8 0 4 2 7
4 megabyt e ( s )
5 7 4 ( 2 2 9 6 megabytes )
6 0 ( 2 4 0 megabytes )
5 1 4 ( 2 0 5 6 megabytes )
Installing from distribution media
Three types of BOS installation procedures are available for diskfull
workstations: new installation, preservation installation, and com­
plete overwrite installation. A new installation assumes you are
installing to clean disks. The latter two options assume an existing
system and allow you to retain nonroot file systems (preservation) or
wipe clean the existing installation (overwrite).
4.1 .7.1
Media install steps
0. Complete installation planning.
1. Power up the system from the bootable media with the key switch
in the SERVICE position. If you are booting from diskettes, the
LED display will prompt c 0 7 for each boot and display diskette. A
status of c 0 3 indicates the wrong diskette was inserted, and a
status of c 0 5 indicates a diskette error.
2. Select the device to be used as the console. The LED display reads
c 3 1 and a message is displayed on each attached tty or hft device
prompting for selection of the system console. If you are booting
from diskettes, you are prompted to insert the install I maint
Insert BOS Ins t a l l /Maint Di skette and Press Enter
3. Select Install AIX from the Installation and Maintenance menu
>>> 1 Install AIX
2 Install a system that was created . . .
3 Install this system for use with a / u s r . . .
4 Start a limited function maintenance . . .
System Installation and Operation
4. At this point, you must commit to proceeding with either the
preservation install or the overwrite install. The same menu
options will be presented in either case, with the exception that
menus for the preservation install assume existing volume groups
will be used.
1 Preservation install
2 Complete overwrite install
5. Verify that the correct disks or volume group will be used for the
install. In the case of a preservation install, use the volume group
identifier that you recorded on the planning worksheet to select
the volume group to be used for installation.
1 LOCALE (language)
1 LOCAL (language)
2 INPUT Installation Device
2 INPUT Installation Device
»>4 STARTUP (boot) Device
6. Select the LOCAL language and INPUT installation device.
Installation media include diskette, tape, CD-ROM, and network
device types.
7. Install BOS.
Base operating system installation . . .
99 Return to previous menu
0 Continue with install
8. Once installation is complete, remove the install media, switch
the key to NORMAL, and reboot the system.
AIX base operating system installation is complete
1 Make sure your installation media () has been removed from
the input device
2 Turn the system key to the NORMAL position
3 Press the ENTER key to restart (reboot) the system
9. Log in as root and review BOS readme file.
# more / u s r / lpp /bos / README
AIX lnstallatlon and Maintenance
10. Install remaining software and maintenance. Use SMIT fast path
s ins tal lp or the ins t a l lp command. It's a good idea to copy
any additional maintenance into the preloaded software directory
I u s r I sys I ins t . images and install software and updates as a
1 1 . Complete post installation tasks described in Sec. 4.4.
Installing Applications
Installing program products in backup format can be managed using
the SMIT ins t a l l fast path or by using the ins t a l lp command.
# installp - qa -d / inst . images -X a l l
APPLY updates
Products and maintenance will usually be installed into the
licensed program product (LPP) directory, / u s r / lpp . A separate
subdirectory is created for each product.
# l s - a F / u s r / lpp
j ls /
ncs /
nfs /
pci /
p c s im/
pcs immEn_US /
tcpip /
t ty/
txt fmt /
vdi /
x3 2 7 0 /
x3 2 7 0 . sav/
x_s t_mgrmEn_US /
bseiEn_U S /
bs l /
bsmEn_US /
bspi En_US /
b s s i En_US /
c obolcmp/
c obo l r t e /
c o lormaps /
cpp /
diagno s t i c s /
font s /
gai /
han f s /
info /
infoxl /
. I
. .I
Xl l /
X 1 1_3 d /
X l l dev/
X l ldeviEn_US /
X l l fn t /
X l lmEn_US /
bos /
bosadt /
bos ext l /
bosext 2 /
bosins t /
bosne t /
bosperf /
xdt 3 /
xlc /
xlccmp /
xl f /
x l f cmp /
xl f cmp iEn_US /
xl f cmpmEn_US /
x l f r t emEn_US/
x l f r t emsg/
xlp /
xlpcmp /
xlpcmpiEn_U S /
xlpcmpmEn_U S /
xlprt e /
xlprtemEn_U S /
xlprtems g /
The contents of the installation media may be reviewed by selecting
L i s t Al l S o f tware on Instal l a t i on Medi a from the SMIT
ins tal l menu or executing ins tal lp with the - 1 option.
# i ns t a l lp -q -d / inst . images -1
Option name
Q content
xlfrtemEn_us . ms g
# AIX XL FORTRAN Run Time Environment/6000 Messages -
N usr
xlfcmpmEn_US . ms g
# AIX XL FORTRAN Compiler/6000 Messages
N usr
xlfcmp . obj
# AIX XL FORTRAN Compiler/6000
N usr,root
xlfrte . obj
# AIX XL FORTRAN Run Time Environment/6000
N usr
U.S. English
System Installation and Operation
In the event that one or more of the applications will be installed on
multiple machines, you might want to copy the contents of the install
media to disk for use with an install server. Select C opy S o f tware
to Hard D i s k f o r F u t u r e I n s t a l l a t i o n from the SMIT
i n s t a l l_upda t e menu (see Fig. 4 . 1 ) , and refer to Sec. 4 . 5 . 3 for
details on configuring and using an install server. You may also use
the b f f create command to copy the software update to disk.
# b f f create -qv -d ' / dev/ rmt O ' - t ' / inst . image s '
# smi t instal l_updat e
' -X ' a l l
To install ALL software and maintenance on the media, invoke
SMIT with the ins t a l l_a l l fast-path name. You will be prompted
for the media type and installation will proceed using default options.
If you want to select other update options or install a subset of the
updates on the media, start SMIT using the ins t a l l_late s t fast
path. Use the F4 key to list the products available on the media.
Individual entries may be tagged using F7. (Refer to Fig. 4.2.)
# smi t instal l_late s t
In the previous section on installation planning, the pros and cons
of installing with COMMIT and automatically extending the file sys­
tem were discussed. The same arguments relate to product and main­
tenance updates. If you have extra disk space to play with, electing
not to COMMIT and allowing file system extension will make the
install smoother.
During the installation and update process, progress information is
displayed by SMIT and ins tal lp . SMIT will log this information to
the s m i t . l o g file . You may wish to redirect output from the
ins tal lp to a file if it was invoked from the command line. Once the
install has completed, verify the status of the update (see Sec. 4.4 for
details on product and maintenance installation status).
Instal l / Update S o f tware
Move cursor to des i red i tem and press Enter .
Insta l l / Update S e l e c table S o f tware ( Cus tom Instal l )
Ins tall ALL S o f tware Updates on Ins ta l l a t i on Media
Copy S o f tware t o Hard Disk for Future Installation
C l ean Up After a Fai led Installation
List Al l S o f tware on Ins t a l l a t i on Media
L i s t All Probl ems F ixed by S o f tware on Installation Media
F l = Help
F 9 = She l l
Figure 4.1
F2 = Re fresh
F l O = Exi t
SMIT install update panel.
F3 = Canc e l
Enter = D o
F B = Image
AIX Installation and Maintenance
Ins t a l l S o f tware Produ c t s at Lat e s t Avai lable Level
Type or s e l e c t values in entry f i elds .
Press Enter AFTER making a l l des ired changes .
* INPUT devi c e I directory for s o f tware
* SOFTWARE t o ins t a l l
Automa t i ca l l y ins t a l l PREREQU I S ITE s o f twar e ?
COMMIT s o f tware ?
SAVE replaced f i l e s ?
VERIFY S o f tware ?
EXTEND f i l e sys tems i f space needed?
REMOVE input f i l e a f t e r i ns t a l l a t i on ?
OVERWRITE exi s ting ver s i on?
ALTERNATE save directo ry
F l = Help
F5 = Reset
F9 = She l l
Figure 4.2
F 2 = Re f resh
F 6 = Command
F l O = Exi t
F3 = Cancel
F7 = Ed i t
Enter = Do
[ Entry Fi elds ]
/ in s t . images
F4 = L i s t
FS = Image
SMIT selective install panel.
Non-LPP products
It's a good idea to keep local, public domain, and vendor products sep­
arate from BOS directories. This will ensure that they will not be
clobbered by BOS upgrades and installations. A common practice is to
create a local product file system called / u s r I l o c a l . Within
/ u s r / l o c a l , create subdirectories bin , l ib , e t c , and s r c . You
can add these directories to the default command PATH and create
symbolic links from BOS directories if required.
Applying Maintenance
The first and foremost rule of system maintenance is: If it isn't bro­
ken, don't fix it! If only it was that easy! The AIX. operating system
and product set is made up of a large number of subsystems. Each
subsystem contains hundreds or thousands of components. In this
not-so-perfect world, problems will crop up in many of these objects.
You have to decide which bugs will be tolerated and which ones must
be fixed. Each new fix set that is applied to the system or subsystem
will include a new set of gremlins. The trick is to find a maintenance
level that provides stability for your environment and is within cur­
rent maintenance levels supported by the vendor.
All the operating system and applications vendors are doing their
best to drive product error rates down. This is a very difficult task,
which is complicated in shared library environments. Think of the
number of commands and subsystems that depend on l ibc . a ! IBM
has addressed the problems encountered with the old selective fix
strategy in AIX. 3.2.4+ by packaging fixes by subsystem. In the selec-
System Installation and Operation
tive fix environment it was difficult to collect all the prerequisite
(prereq) and corequisite (coreq) fixes that represented a particular
system snapshot. A prereq or c oreq often involves a component not
related to the problem being addressed. The unrelated component
often requires other fixes. Components were duplicated many times
in the fix set. You ended up with a 50-megabyte fix tape to fix a small
problem in c sh.
AIX 3.2.4+ comes with a new maintenance strategy that packages
prereq and c oreq fixes by subsystem. A subsystem is a set of func­
tionally related software components. The new strategy is called the
preventative maintenance package (PMP). Each PMP represents a
tested subsystem snapshot that includes all maintenance since the
previous PMP. PMPs will be provided at a frequency of three or four
times a year.
Preventative Maintenance Packages
Subsystem selective fix
Correct specific subsystem problem
Selective enhancement
Provides new subsystem function
Maintenance level
Contains all fixes since last release
AIX 3.2.4+ also provides a new instal lp option, - t <PathName> ,
that allows you to save files replaced by maintenance into the directo­
ry path of your choice. This feature saves on disk space requirements
in /usr.
The rules for installing maintenance are the same as described in
the previous section on installing program products. For distributed
environments, you may wish to copy the maintenance set to disk for
access from an install server. You might also choose to build a refer­
ence system image accessible from an install server (see Sec. 4.5.3 for
In many cases, maintenance updates involve the installation of a
new ins tal lp command set before proceeding with the installation.
Read the maintenance documentation carefully before beginning the
update. A short description of each fix on the media may be displayed
by selecting "List All Problems Fixed by Software on Installation
Media" from the SMIT s ins tal lp menu or using the instal lp -A
# ins tallp -qA -d / dev / rmtO a l l
Display fix information
Fix i n f ormat ion
f i l es res tored : 1
usr / share f ix informat ion for
x_st_mgr . obj 1 . 4 . 0 . 0 . U4 1 2 0 3 2
IX3 1 8 7 4 x_s tJ11gr Create supersede PTF so
f i les res tored : 1
u s r / share fix informat i on for
X_StJllg r . obj 1 . 3 . 0 . 0 . U4 0 6 2 0 6
and TW locales can instal l .
AIX Installation and Maintenance
IX2 8 8 0 6 X S t a t ion Manager changes t o support ko_KR and zh_TW locales .
X S ta t i on Manager changes to support ko_KR and zh_TW locales .
Follow the procedure outlined in Sec. 4.3 when installing system
Postinstallation and Maintenance Tasks
With the installation or maintenance process complete, there is still a
bit of tidying up to be done before making the system available for use.
A new installation requires that you set default system and environ­
ment variables. If you installed over an existing system, you will need to
restore the previous environment. Product updates or maintenance will
require testing before committing or rejecting the update. Finally, cre­
ate new stand-alone media and take a fresh backup of the new system.
A clean snapshot can be used as a reference point for installing addi­
tional machines or as a fallback should problems arise in the future.
Review Install/update status
Review the status of software product and maintenance updates using
L i s t Al l App l i ed but Not C ommi t t ed S o f tware from the
SMIT s instal lp menu or by invoking l s lpp from the command line.
# l s lpp -h bes . obj
Display lpp history
User Name
Path : /usr / l ib / obj repos
bes . obj
0 3 . 0 2 . 0 0 0 0 . 0 0 0 0 COMPLETE
12 / 3 1 / 6 9
16 : 00 : 00
Path : / e tc / obj repos
hos . obj
03 . 02 . 0 0 0 0 . 0 0 0 0
16 : 00 : 00
# l s lpp -pB U4 1 1 2 2 7
Path :
bes . obj
U4 1 1 2 2 7
Path : / e tc / obj repos
hos . obj
U4 1 1 2 2 7
Display fix status
Prerequi s i tes
/ obj repos
* i f req bosadt . l ib . obj p = U4 1 1 2 1 2
*prereq bos . obj v = 0 3 r = 0 2 m = 0 0 0 0
* i f req bosadt . l ib . obj p = U4 1 1 2 1 2
*prereq bos . obj v = 0 3 r = 0 2 m = 0 0 0 0
/ l ib
LPP software can be in one of the following states:
Software was applied successfully but has not been com­
Software has been applied and committed.
System Installation and Operation
Software has not been installed but is available on instal­
lation media.
Software installation was not successful. Reinstall the
Software has not been succes sfully applie d . Run
CLEANUP and reinstall.
COMMIT did not complete successfully.
REJECT failed for the software product.
In the event of problems with the update, invoke CLEANUP and
reinstall. LPP cleanup can be executed from the C l ean Up After
Fai l ed Ins t a l l a t i on option on the SMIT s ins t a l lp menu or via
the ins t a l lp -c option. Installations using SMIT or the ins t a l lp
command will normally perform any clean up automatically in the
event of a failure.
# ins tallp
<Produc tName>
Clean up failed install
Restoring your environment
Setting default system environments is a final step for the installation
paths described thus far (see Fig. 4.3). This involves setting or vali­
dating the default language , time zone, console type, number of
licensed users, and number of virtual terminals. IBM has kindly pro­
vided a SMIT fast path that addresses each of these variables. With
root permissions invoke SMIT s tartup :
# smi t startup
In a networked environment, you will need to set your network inter­
face address and characteristics (see Part 4, "Network Configuration
and Customization").
Set the root account password. The default installation does not
provide a password for root. Need I say more?
Sys tem Environment s
Move cursor to des i red i t em and press Enter .
As s i gn
the Cons o l e
Number o f Virtual Terminal s a t Next Sys tem Res tart
I Show Date , Time , and T ime Zone
I Show Charac teri s t i c s o f Opera t ing Sys tem
Language Environment
Number of L i c ensed Users
Fl = Help
F9 = She l l
Figure 4.3
F2 = Re f resh
FlO = Ex i t
F3 = Cance l
Enter = D o
SMIT system configuration panel.
FB = Image
AIX Installation and Maintenance
Restore any configuration tables from the previous system, and
reimport any volume groups exported as part of the preliminary
installation planning.
# importvg <VGname>
Create new bootable media and backups
Next make sure you have multiple copies of stand-alone bootable
media that reflect the new systems install and maintenance level.
Notice I said multiple copies. . I must admit that I have been bitten
more than once by having only a single copy of some crucial bit of
data. Let's start with the BOSboot diskettes. If you carefully read the
AIX Installation Guide, there is a chapter on creating stand-alone
boot diskettes. This procedure is version-dependent, so make sure you
have the right documentation in hand. Following the procedures in
the install guide, you will create a set of diskettes that contain a
small bootable kernel, device drivers for your console display type,
and the AIX. installation/maintenance shell.
# format
Format a diskette
# bosboo t - a -d fdO
Boot diskette
# mkdi spdskt
Display diskette
# mkextdskt
Display extension diskette
# mkins tdskt
BOS instalVmaint diskette
Unless you're the gambling type, test the diskettes you have creat­
ed. It will bring you peace of mind and familiarize you with the stand­
alone boot procedure.
Stand-alone boot procedure
1. Insert the boot diskette/tape and power on/reset.
2. At LED c 0 7 insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select S tart a l imi ted func t i on maintenance she l l from
the menu.
6. Access and mount the root volume group: getro o t f s hdi skO .
Now is a good opportunity to move the / u s r / sys / ins t . image s
directory into a separate file system, for example, I inst . images . The
/ u s r file system is not a good target for present or future installation
and maintenance activities. The ins t . images subdirectory requires
constant resizing to accommodate new install and maintenance
System Installation and Operation
images. Create a new JFS file system called I ins t . imag e s , and
move the current contents of / u s r / sys / in s t . images into the new
directory. If you want to continue using the / u sr / sys / in s t . image s
path, use i t a s the mount point for the new installation and mainte­
nance file system.
Create a vanilla bootable image of the new roo tvg on tape using
the mksysb command. The tape can be used to recover from a disk
failure or it can be used to install additional machines. Begin by
using the mks z f i l e command to create a I . f s . s i z e file. This file
contains d e scriptive information about the file systems in the
roo tvg. Edit this file so that it contains only those file systems you
wish to include in your reference set. Execute mksysb to create the
bootable image. When booting from the stand-alone tape, the AIX
install/maint shell is executed which will guide you through the
restoration process.
# mks z f i l e
Create rootvg description
# mksysb / dev/ rmtO
Boot tape and rootvg image
Once you are satisfied with the new configuration, backup every­
thing. The extra time is worth the peace of mind. I suggest making
both mksysb and backup full dumps of the new system state.
Distributed Systems
If installing or updating a single system isn't problem enough, think
about repeating the process over and over again in a multisystem
environment! In many cases, these systems represent both diskfull
and diskless configurations.
NFS installation support
In networked environments, copy product and maintenance images to
a file system, I ins t . images. NFS exports this file system to each of
the remote sites. This method requires repeating the installation
process on each machine. It provides the capability of individually tai­
loring the update on each system.
Creating a reference system
To minimize the amount of time and work required to update multi­
ple diskfull systems, create a single reference system image that can
be cloned on each machine.
1. Update and tailor one system that represents your base configura­
2. Invoke mks z f i l e to create a I . f s . s i z e table.
AIX Installation and Maintenance
3. Edit the I . f i l e . s i z e table such that it contains only those file
systems you want to include in your reference system image.
4. Invoke mksysb to create a bootable reference image. In nonnet­
worked environments, direct mksysb output to portable media. If
network access is available, direct the output image to a file sys­
tem, I ins t . images .
5. Create a network install server in networked environments with
NFS and TCP/IP support.
Network install server
A network install server can be used to serve BOS, maintenance, and
mksysb backup images to remote sites on TCP-based networks. Each
remote machine connects to the install server from the stand-alone
install/maintenance system. To create a network install server, com­
plete the following steps:
1. Create an ADC account named netins t .
# smi t mkuser
2. Copy i n s t server code to $ HOME / n e t i n s t from / u s r / lpp
/bos ins t .
cd /usr/ lpp/bosinst
f ind bin db scripts -print
chmod -R 500 *
chown -R netins t . s t a f f *
cpio - dumpv /home /netinst
3. Create a file system to hold product, maintenance, and mksysb
backup images with mount point I ins t . images .
# smi t crj f s
4. Install the product, maintenance, and mksysb backup images in
/ in s t . image s .
5. Set access permissions for objects in I ins t . image s .
# f ind
$ f ind
- type d -print
- type f -print
xargs chmod 7 5 5
xargs chmod 4 4 4
6. Create and maintain a cho i c e s file that lists the image names
available from the server.
# cd /home /netins t / db
$ echo ' / ins t . images / <path> / * ' > > cho i c e s
7. Add the install server port to / et c / s ervi c e s .
System Installation and Operation
ins t s rv 1 2 3 4 / tcp
8. Add the install server to I etc I inetd . conf .
ins t s rv s t ream tcp nowa i t netinst / u /netinst /bin/ ins t s rv
9. NFS export / ins t . image s to each remote site.
II smi t mkn f s exp
Accessing the network install server
To install images from the network install server, shut down the
remote machine and reboot from the stand-alone boot media.
Stand-alone boot procedure
1. Insert the boot diskette/tape and power on/reset.
2. At LED c 0 7 insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select Ins tal l a sys t em tha t wa s created wi th the
SMIT " Backup the Sys t em" func t i on or the "mksysb "
command from the menu.
6. Select the network interface type and IP numbers of the local
machine and the install server.
7. After the cho i c e s information is displayed, select the image to be
installed and start the installation.
Installation will proceed by creating the roo tvg file systems ; then
tar the image contents to the local file systems. The network BOS
install process takes about 20 minutes over Ethernet.
Diskless Installation
Diskless workstations are systems configured with local cpu, memory,
and external peripherals, but, as the name implies, no local disk. Disk
support for kernel images, paging space, and file systems is provided
by a network server. The network server must be configured with the
Diskless Workstation Management software. This software is standard
on AIX 3.2, or it may be installed on non-AIX servers. The network
server provides a boot image and tailored copies of the /usr file system
called shared product object trees (SPOTs) for each diskless client.
SPOTs, identified by a client group name, reside in the / export / root
directory and are created using the rnkspot command.
AIX Installation and Maintenance
Diskless Works t a t i on Management
Move cursor to des i red i t em and press Enter .
S tart Daemons on Server
Manage Shared Produ c t Obj e c t Trees
Install /Maintain S o f tware
Manage S o f tware Inventory
Manage C l i ents
F l = Help
F 9 = She l l
Figure 4.4
F2 = Refresh
FlO = Exi t
{ S POTs )
F3 = Cancel
Enter = Do
F B = Image
SMIT diskless workstation panel.
To access a boot image and associated SPOT, a diskless worksta­
tion sends a bootp request to the network SPOT server (see Fig. 4.4).
Once the server receives the bootp packet and the client address is
established, the server downloads a copy of the boot image to the
client using t f tp . The diskless client boots the copied image and
mounts the SPOT file system from the server, using NF s .
AIX supports three types of diskless clients:
Remote file systems, paging, and dump. Bootstrap ROM for
network boot.
Remote file systems. Local paging and dump. Bootstrap ROM
for network boot. Better performance than di s k l e s s config­
remote /usr
file system.
To tailor a SPOT server and manage diskless clients, invoke the
SMIT di skl e s s fast path.
# smi t di skless
Configuring an install server
To create a server for diskless clients complete the following steps:
1 . For non-AIX servers, install the diskless workstation code from the
bos . obj installation image. The following example assumes that
the bos . obj image has been copied from the installation media to
the I ins t . images directory.
# tar -xvf / inst . images /bas . obj
. / us r / l ib / dwm
Tailor the /usr / l ib / dwm/dwm_platform file to match the archi­
tecture p arameters associated with the non-AIX s erver. See
/ u s r / lpp /bos / README . di skl e s s for more information. Non-AIX
servers require that one diskless client be identified as a superclient.
The superclient will be used to install optional software products.
System Installation and Operation
2. Verify that b o o t p d a n d t f t p d s ervi c e s are d e fi n e d i n
/ e t c / inetd . c on f and / et c / s ervi c e s .
/ et c / inetd . conf :
t f tp
wai t
wai t
/ e t c /bootpd bootpd
/ e tc / t f tpd t f tpd -n
/ e t c / servi ces :
# bootp server port
# bootp c l i ent port
6 7 /udp
6 8 /udp
6 9 /udp
boo tps
t f tp
3 . Verify the existence of the / et c / bootptab file. This file is used to
locate boot images for bootp requests.
4. Create non-roo tvg file systems for the diskless clients using the
following mount points. You can save some disk space by using the
servers / u s r for the client SPOT. Planning worksheets for file sys­
tem size calculations are provided in AIX for RISC System I 6000-
Installation Guide.
/ export / root
Size + ( 4
/ expor t / home
num users on all clients
num clients)
/ expor t / dump
/ export / swap
Total client RAM
/ export / exec
/ expor t / share
/ t f tpbo o t
Mount and verify the file system sizes after they have been cre­
5. Create a SPOT from either the server's / u s r file system or from
the AIX 3.2 distribution media. Use the mkspot command or the
Add a S POT option from the SMIT di skl e s s menus.
# mkspo t
A /usr -v < SPOTName>
# mkspot - f / dev/ rmt 0 . 5 < SPOTName>
User servers /usr
AIX 3.2 install media
You can list the SPOT configuration after it is created by invok­
ing the l s spot command.
# l s sp o t -L < S POTName>
6. Customize common configuration files in the SPOT that will be
used by the diskless clients.
/ export / exec / < SPOTName> / u s r / lpp / bo s / ins t_root / resolv . conf
/ export / exec / < SPOTName > / u s r / lpp /bos / ins t_root / syslog . conf
AIX Installation and Maintenance
/ expor t / exec / < S POTName> /usr / lpp /bos / in s t_roo t / rc . local
/ expor t / exec / <S POTName> / u s r / lpp / bo s / ins t_roo t / . pro f i l e
7. Initialize NFS services on the server if not already running.
# s tartsrc -g n f s
8. Add diskless clients.
Adding dlskless clients
Each diskless client must be identified to the server. To add a disk­
less client, use the SMIT mkdc l i en t fast path or the mkdc l i ent
command (see Fig. 4.5).
# mkdc l ient - a - E< SPOTName> - A<HardwareAddre s s > -v < C l i entName>
# smi t mkdc l i en t
A list of configuration parameters and resources for each diskless
client can be displayed using the l sdc l i ent command.
# l s dc l i ent -L < C l i entName>
Add a Diskless C l i ent
Type or select values in entry f i elds .
Press Enter AFTER making a l l des i red changes .
*CLIENT name
S POT name
[ Entry F i e lds ]
[ l isa . dom . org ]
*HARDWARE address of c l i ent machine
ROOT parent direc tory
HOME parent direc tory
DUMP parent directory
PAGING parent direc tory
PAGING s i z e in blocks
MICROCODE direc tory
TIME z one
INSTALLATION f i l e s directory
DETAILED mes s ages during c l i ent creation?
[ 1 0 0 0 5a2 1 5 c 3 a ]
[ / export / roo t ]
[ / expor t / home ]
[ / export / dump ]
[ / expor t / swap )
( 6553 6 ]
[ / export / exec / S POTl /usr>
[ / export / exec / S POTl / usr>
F l = Help
F 5 = Undo
F9 = She l l
Figure 4.5
F 2 = Re f resh
F6 = Command
F l O = Ex i t
SMIT diskless client panel.
F3 = Cancel
F7 = Ed i t
Enter = D o
F4 = Li s t
F 8 = Image
System Installation and Operation
If maintenance or software updates are applied to the root server,
synchronize the updates with the diskless clients using the SMIT
di skles s_ins tupdt fast path.
# smi t diskless_ins tupdt
l nfoExplorer Keywords
rnks z f i l e
o s l eve l
f ind
roo tvg
mks p o t
bas . obj
l svg
boo tp
l s lpp
t f tp
ins tal lp
diskl e s s
b f fcreate
rnkdi spdskt
l s spo t
s t opsrc
rnkdc l i ent
s tart s re
rnkins tdskt
l sdc l i ent
t e l ini t
t srnlogin
Software install I maintenance information and support:
Software support
1-800-237-55 11
Problem support
E-mail problem support
Requires script contact:
Internet telnet IBMLink
Maintenance level and history:
AIX 3 . 2 . 4 1 version and release level
o s l evel
unarne -v -r
Display version and release level
l s lpp
List maint history
-h <produ c t >
Backup roo tvg :
mks z f i l e
Create .fs.size file for mksysb
mksysb / dev/ rmt O
Backup rootvg to tape
AIX Installation and Maintenance
Maintenance installation:
smi t instal l_update
Base install panel
smi t ins t a ll_late s t
Selective install panel
smi t instal l_a l l
Install ALL products
b f f create
- qv
- d <media> - f <disk-path>
Copy maint to disk
ins t a l lp -qa -d <media-path> -X a l l
APPLY updates
ins tallp - r B -d -X a l l
REJECT updates
ins t a l lp - c -g -X a l l
COMMIT updates
ins tallp
CLEANUP failed install
Diskless workstations system product object tree (SPOT):
mkspo t / l s spot
Manage SPOT
System Boot
and S h utdown
AIX Boot Process
E ach time you power up an RS/6000, a complex series of system
checkout and initialization tasks are executed. The only outward sign
of this activity is the play of numbers across the three-digit LED dis­
play on the front panel. This system start-up process is what you
might be familiar with on other UNIX systems as bootstrapping.
Bootstrapping the system involves a hardware initialization phase,
followed by AIX kernel initialization. IBM refers to the hardware
p h a s e as read o n ly storage i n i t i a l p rogram load ( R O S IPL ) .
Sometimes it i s referred to a s ROS init.
You may find that the terms "IPL" and "boot" are often used inter­
changeably in many of the IBM document s . Since IPL conjures
images of 370/390 MVS or VM architectures and boot is more com­
mon in UNIX circles, I'll tend to use boot in the remainder of the
chapter. Old habits are hard to break!
Whatever you call it, it's important that the system administrator
be familiar with the sequence of events that is taking place under the
system unit cover at boot time. Understanding the system start-up
flow of control will assist in diagnosing hardware and configuration
problems when they occur. (Notice that I said "when they occur"! )
Booting the System
AIX on the RS/6000 may be started in one of three ways.
Boot from a local disk. System initialized with run­
time kernel. Key mode switch in NORMAL position. Normal mode
of operation.
Normal boot.
Similar to normal boot, but the system is brought
up with a single-user maintenance/install or diagnostic mode kernel.
The system is booted from local disk, tape, or diskettes. Key mode
Stand-alone boot.
System Installation and Operation
switch in SERVICE position. Used when installing software or per­
forming maintenance or diagnostics. (See Sec. 5.2.1.)
Boot information and kernel provided by network­
based file server. ROS broadcasts a boot REQUEST packet to locate
a bootp server. The REPLY packet from the server indicates how
to load the boot image from the server. The boot kernel and file sys­
tem are copied from the server via TFTP. (See Sec. 4.6.)
Network boot.
Once the boot kernel and file system are loaded, generally the same
steps are followed in all three modes to initialize a run-time AIX kernel.
Assuming that the system is configured correctly, normal and net­
work boot proceed with bringing AIX up to multiuser mode after
power-on without additional intervention. The boot sequence of
events is outlined in Sec. 5.4 and in detail later in the chapter.
Stand-alone boot
In the event of a system problem or when required for AIX installa­
tion or maintenance, you may need to start the system in stand-alone
mode. In stand-alone mode, the system is running the boot kernel and
provides minimal access to the volume groups and file systems on
disk. Booting the system in stand-alone mode will assist you in recov­
ering corrupted system configuration files and file systems.
5.2.1 .1
Stand-alone boot procedure
1. Insert a diskette/tape containing a boot image and power on the
2. At LED c 0 7 , insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select Ma intenance option from the menu.
6. Select S t andal one Maintenanc e She l l option from the menu.
7. Access the root volume group: getroo t f s hdi skO .
Creating Bootable Media
In order to boot AIX , a boot image or bootstrap kernel must be avail­
able on one or more boot devices specified by boot lists stored in non­
volatile system RAM. ROS boot code will attempt to access each
device in the list until a valid boot device is found from which to load
the boot image.
The boot device characteristics and the location and size of the boot
image on the device are described by a boot record. The boot record
may be added to the beginning of the boot image, or, in the case of a
System Boot and Shutdown
disk device, the boot record is written to the first sector of the disk.
The boot image and file system may or may not be compressed to save
space and access speed.
Configuring the boot list
At system start-up, the ROS boot code will attempt to access boot
devi c e s from a list of boot devi c e s stored in nonvolatile RAM
(NVRAM). The boot list can be tailored or recovered by invoking the
boot l i s t command or from the RS/6000 diagnostic diskettes.
Examples :
# boo t l i s t - m normal hdi skO f d O rmt O
# boo t l i s t -m ent O gateway = 1 2 8 . 9 5 . 1 3 5 . 1 0 0 \
bserver = 1 2 8 . 9 5 . 1 3 2 . 1 \
c l i ent = 1 2 8 . 9 5 . 1 3 5 . 1 0 fdO
Separate lists are maintained for normal boot, service boot, and previ­
ous boot. Valid boot device types are listed in Table 5 . 1 .
Device drivers fo r e ach of thes e device type s are available in
NVRAM. New device drivers may be loaded using the nvl oad com­
mand for custom boot configurations.
Installing a boot image
A boot image consists of a stripped kernel and skeleton root file sys­
tem tailored for the boot device and boot type (normal, service, or
both). The kernel is stripped of symbols to reduce its resident size.
The boot file system contains the device configuration tables, driver
routines, and commands that will be required to gain access to the
systems devices and file systems. To create a boot image for a particu­
lar boot device, use the bosboot command. The boot image type is
specified by the [-M normal,serv,both] flag.
# bosboot -a - d -M both / dev/ hdiskO
Disk image
# bosboot - s
Compressed network
-M both - d / dev/ ne twork
Just in case bosboot fails when creating a new boot image on the
default boot device hdi s k O , DON'T attempt to reboot the system. It's
quite likely that the old boot image is corrupted, and it's no fun
hdi skXX
t okXX
Boot Device Types
Token ring
System Installation and Operation
rebuilding a system from scratch. Attempt to determine the reason
for the failure. Get it corrected and try again.
Creating stand-alone boot diskettes
It should go without saying that a local boot device be configured as
part of your standard boot list for maintenance purposes. This device
will be used to boot the stand-alone media created in Sec. 4.4. 3 .
Remember to keep multiple copies of the stand-alone boot media that
reflect your AIX maintenance level. See Sec. 5.8, "Troubleshooting,"
for the stand-alone boot procedure.
Boot Sequence of Events
In a nutshell, when the power switch is toggled to the ON ( 1 ) position,
the system start-up begins by self-checking and initializing hardware.
Once hardware has been reset, a boot device is located and a boot ker­
nel and file system is loaded into memory. Peripheral devices and
adapters are identified and enabled. Virtual memory support and the
process scheduler are initialized. The root volume group is varied
online and the root file systems checked and mounted. Run-time init
is dispatched to complete system configuration, check and mount
remaining file systems, and start the service daemons. Login process­
ing is enabled and the system is up and ready for use. Sounds simple!
In the following sections we will dissect each of the boot stages and
explore them in more detail. (See Fig. 5 . 1 . ) I'll list the steps per­
formed at each stage in the boot process and the three-digit LED code
that is associated with each major step being performed. You can use
the LED indicators as road signs to assist you in following the boot
process in real time. Being able to identify boot stages from the LED
information will give you a better feel for when to start getting wor­
ried during system power-up!
The orchestration of steps conducted at boot time depends on the
hardware state, key mode switch setting, available boot devices, and
the system reset count retained in memory from the previous run.
Key mode switch position
There are three selectable options for the front p anel key mode
switch: NORMAL, SECURE , and SERVICE .
NORMAL position is used for standard AIX operation. The system
will boot to multiuser mode and support user login. The RESET
button is operational.
SECURE position is used to inhibit rebooting a running system or
starting a system that has been shut down. The RESET button is
System Boot and Shutdown
Power-on S e l f - t e s t
Locate Boot Devi c e
Load Boot Kerne l
Bui l d RAM F i l e Sys tem
Con f i g Base Devi ces
Varyon r o o t vg
Mount Root F i l e Sys tem
S tart VMM and Pager
Con f i g All Devi ces
Remount Root
Merge ODM Data
Trans i t ion to Runt ime
Start Runtime ! n i t
New Roo t File Sys tem
Free Boot RAM
Save Base Conf ig
Single User Mode
Invoke i n i ttab Entries
Figure 5 . 1
S tart Subsys t ems
Mul t iuser Mode
Boot block diagram.
not operational. This position secures changes in the run state of
the system.
SERVICE position is used when you want to run system diagnos­
tics or bring the system up in stand-alone mode. See Sec. 5.8 for
more information on running system diagnostics.
As a precaution, keep one of the two keys supplied with the system
unit and the other tucked away where you won't easily forget it. You
can always get a replacement key from IBM; however, turnaround
time may be a problem for your users.
ROS Initialization
A ROS IPL is invoked when hardware events trigger a system reset.
Normally this occurs when you turn the system on or pre s s the
RESET button. Resets also occur in the event of a hardware failure or
System Installation and Operation
machine check. One of two types of IPL is performed, depending on
the value of the system reset count-cold IPL or warm IPL.
Cold I PL Reset Count
0 OCS B I ST Checkout , OK LED = 1 0 0 .
Warm IPL Reset Count = 1 BIST Bypas sed . ROS IPL .
Built-in self-test (BIST)
A cold IPL is started each time the computer is turned on (see Fig.
5.2). If the model is equipped with an on-card sequencer (OCS), the
OCS performs a built-in self-test (BIST) of the processor complex. The
OCS is an 8-bit 805 1 processor with 4 KB of ROM. The OCS fetches
3 1 -bit seed and signature patterns from ROM to test and validate
each processor component. The seed pattern is sent to a common on­
chip processor (COP) resident on each of the processor chips . Test
results are compared with the signature data. BIST performs the fol­
lowing functions:
1. Initialize and test COPs and embedded chip memory
2. Test ac/dc logic
3. Initialize and reset hardware for ROS IPL
A warm IPL occurs when the RESET button is pressed on a run­
ning system or initiated via software control. For example, a warm
IPL results when the reboo t command is executed at run time. The
BIST phase is bypassed during a warm IPL. Processor memory,
cache, and registers are reset and the system branches to the warm
IPL entry point in ROS.
C o l d I PL Only
Tes t ac / dc Logic
On-card Sequencer Check
Reset Hardware for IPL
ISC Test
CSC Test
I PLC Locate Boot Device
Boot Kernel
Val i date Boot Record
Load Boot Image
Figure 5.2
Create RAM File Sys tem
Start Di spatcher
ROS initialization block diagram.
System Boot and Shutdown
Power-on self-test (Posn
At this point, the power-on self-test (POST) code is executed. POST
processing further verifies system components. There are three phas­
es to POST processing: initial sequence controller (ISC) tests, core
sequence controller (CSC) tests, and IPL controller (IPLC) boot device
interrogation and kernel load.
Initial sequence controller test
ISC begins by performing a CRC check on system ROM. If an error is
found, you may be able to refresh ROM by switching the key mode
switch to the SERVICE position and rebooting. If the CRC still fails,
it's time to place a call to IBM Service.
Next, ISC inspects the system check stop count stored in NVRAM.
Under normal circumstances, the value is 0. A nonzero value indi­
cates that some type of noncorrectable machine check has occurred.
The system is halted and the error code associated with the machine
check is displayed on the front panel LED display.
Physical memory is interrogated and a bit map is built representing
each 16-KB block of available memory in the system. This bit map is
stored in the IPL control block for later use (see / u s r / inc lude / sys
I ipl cb . h). The ISC verifies that 1 MB of contiguous memory is avail­
able for loading the boot image from a boot device.
1. Perform CRC on system ROM. Error LED
2 . Inspect system check stop value i n NVRAM .
I f nonzero, halt; LED
error code.
3 . RAM POST-check physical memory.
4. Build and store memory bit map in IPL control block.
5. Reserve 1-MB boot image area.
Core sequence controller test
ISC passes control to CSC, which completes POST testing. Routines
stored in ROS are used by CSC to test and validate the operational
presence of all devices required for successful booting of the system.
CSC records the IDs of all devices and adapters discovered in the IPL
control block.
1. Locate and validate boot devices.
2. Complete DMA, 1/0, interrupt, SCSI POSTs.
3. Recorded device information in IPL control block.
System Installation and Operation
IPL controller load boot image
!PLC takes control and begins looking for a boot device and path from
which to load an IPL record and boot image. The boot device list is
read from NVRAM corresponding to the boot type, and each device in
the list is polled in turn until a valid boot record is found. If the selec­
tion process fails, !PLC will enter a boot list rebuild/retry loop in an
attempt to locate a valid boot device. The front panel LED alternates
between 229 and 2 2 3 for each iteration of the retry loop. If the
NVRAM boot list is invalid, then the system default boot list is used.
Once the boot device i s locate d, the system validates the IPL
record. The IPL record describes the media characteristics and the
location, length, and entry points of the boot kernel code and file sys­
tem (see / u s r / inc lude / sys / bo o t record . h). !PLC loads the boot
record into memory and makes it part of the IPL control block. From
the information contained in the boot record, !PLC begins loading the
boot kernel into the 1-MB memory area reserved by the ISC.
If the reserved memory space is exhausted during kernel loading,
noncontiguous memory may be used if the fragmentation flag is set in
the boot record. If fragmentation is disallowed, then !PLC aborts and
tries the next device in the bootlist. Upon load completion, interrupts
are disabled and control is passed to the boot kernel along with a
pointer to the IPL control block. ROS initialization is complete.
1. Retrieve boot device list from NVRAM.
2. Locate boot device from list.
3. Load and validate boot record.
4. Load boot image into reserved 1-MB RAM
5. Pass control to boot kernel.
Boot Kernel Configuration
We're still a long way from user and process scheduling at this point.
The object data manager (ODM) has yet to be configured, there is no
logical volume manager (LVM) support, and the scheduler and pager
services are not available.
The newly loaded boot kernel determines the type of RS/6000 it is
running on and saves base custom vital product data (VPD) for subse­
quent ODM configuration. A free list of memory is built based on the
bit map created earlier by the ISC. The kernel uses a section of this
memory space to create a RAM disk, I dev I ramO , which will be used
to support the RAM file system data read from the boot device. The
RAM file system contains the programs and file system structures
required to support the remainder of kernel initialization. A proto­
type template defines which files will make up the RAM file system
based on the boot device type. These templates are used by the mkf s
command when creating the boot file system.
System Boot and Shutdown
disk . proto
Disk template
disket te . proto
Diskette template
tape . proto
Tape template
net . proto
Network template
cdrom . proto
CD-ROM template
Virtual memory manager (VMM) services are next on the list.
Structures for page device, page frame, repage, and hash tables are
created. These tables will be used by the VMM to track and allocate
virtual memory for each process in the running system. Translation
look-aside buffers (TLB) and kernel stack areas are allocated.
Address translation is enabled. The RS/6000 uses 32-bit effective
addresses in conjunction with a segment address to designate virtual
memory locations . The most significant 4 bits of the effective address
are used to index into one of sixteen memory segment registers. The
indexed 24-bit s e gment addre ss i s then concatenated with the
remaining 28 bits of the effective address to create a 52-bit virtual
address. Each segment represents 256 MB of virtual memory. The
RS/6000 hardware supports 2**24 segments per register.
The 1/0 subsystem is started after VMM initialization is completed.
First-level interrupts are enabled for attached devices and adapters.
Input I output channel controller (IOCC) support and the planar 1/0
address space is initialized. The IOCC provides the 1/0 pipe between
the Micro Channel bus and the planar CPU complex.
The process table is allocated and the remaining kernel structures
and services defined in ini t_tbl are set up. The system dispatcher is
invoked as pid(O) and process table entries for ini t and wa i t are
defined. Default exception handlers are set. The dispatcher is now
ready to begin process scheduling. From here on, the dispatcher is
referred to as the scheduler.
The scheduler maintains fair-share allocation of CPU resources by
periodically scanning the process table and recomputing process CPU
priorities and time slices. The scheduler also maintains repage history
in order to manage thrashing conditions. Thrashing and repaging
occur when memory has been overallocated, forcing processes to
refetch pages required for execution each time they are dispatched.
Thus, the term "thrashing'' is used to describe this rapid page-in/page­
out process. When the system repage rate exceeds 30 pages/sec, the
scheduler temporarily suspends processes to reduce thrashing.
1. Save base VPD.
2. Create / dev / ramO and RAM file system.
3. Initialize VMM.
4. Initialize 1/0 subsystem.
5. Set up kernel tables and structures .
6. Start the dispatcher/scheduler.
System Installation and Operation
Phase 1
The b o o t ini t image is loaded by the scheduler as pid( l ) from
/usr / l ib / boot / s sh in the RAM file system. This heralds the begin­
ning of Phase 1 (See Fig. 5 .3). Phase 1 is also referred to as base device
configuration phase. boot ini t starts by forking a shell and invoking
the I e t c I re . boot script with an argument value of 1. Base device
customization information is restored by invoking res tbase to build
the object data manager (ODM) / etc / obj repos database. c fgmgr is
executed and the Con f i g_Ru l e s object class is queried for all configu­
ration rules with a phase value of 1. The boo tmask for each rule is
checked to see if the rule is to be included for this boot type. Custom
configuration rule sequences can be defined by manipulating the boot­
mask for each rule or method. See /usr / inc lude / sys / c fgdb . h for
more information.
# c f gmgr -m <mask>
Run rules with specified mask
Boot mask
Note: bootmask 0 always run.
A list of Phase 1 rules is established and sorted by sequence num­
ber. c f gmgr invokes each method using o dm_run_me thod ( ) to
Invoke / et c / re . bo o t
Restore VPD to ODM
Bui l d Rul e s L i s t
Create Device F i les
Run Methods
Ini t Device Drivers
Ini t i a l i z e LVM
Varyon roo tvg
Figure 5.3
Phase 1 block diagram.
Mount Roo t F i l e Sys t em
Start Pager
System Boot and Shutdown
establish device state information in the ODM. Predefined methods
are located in / u s r I l ib / me thods .
Device states
Device listed in the custom DB. Not configured or avail­
Not represented in the custom DB.
Configured and available for use.
Configured but not available for use.
The de f sys method establishes the top-level system object sys O .
c fgrngr forks a child process for each dependent method until all
devices are configured . ODM custom dev ice ( C uDv) and custom
attribute (CuAt) status entries are updated and the associated meth­
ods run . These methods define device special files and install device
drivers. Each device is initialized by sys c on f i g ( ) and the device
switch table updated by a call to devswadd ( ) . Microcode is down­
loaded to the device if required and VPD information is updated.
It's worth noting that you may experience problems with third­
p arty S C S I disks when the c f g s c s i method is run . c f g s c s i
attempts to start SCIOSTART and query S C I OINQU each device identi­
fied at each SCSI ID I logical unit number (LUN) location. Devices
identify themselves via a 5-byte header and optional vendor data.
Disk device methods attempt to spin up each disk and query the
physical volume ID (PVID) associated with the disk. This can cause
problems for external disk devices that may have already spun up,
and it results in a ghost device defined with no PVID at the same
SCSI-ID and LUN. The old PVID definition is left in the DEFINED
state. Each PVID in a logical volume group must be set to the AVAIL­
ABLE state before the volume group can be varied on-line. You can
usually fix this problem by removing the ghost PVID entry and
rebooting the system after powering the disks off and on.
Phase 1 completes by initializing the logical volume manager
(LVM). The LVM is defined as a pseudodevice in the ODM. The LVM
device driver, lvdd , interfaces to the SCSI device driver, hs c s idd ,
to provide logical disk volumes.
Method list:
Start method invocation
LED 538
c fgsys
System/memory/IO planar
LED 8 13
c f gbus
Micro Channel bus
LED 520
c fgs c s i
SCSI adapters/devices
LED 869
de f lvm
Logical volume manger
LED 591
Complete methods
LED 539
Phase 1 complete
LED 5 12
System Installation and Operation
Phase 1 completes by varying the root volume group (rootvg) on­
line. The root file systems are checked and mounted. At this point,
root, "/", is mounted over /mnt . The pager is started via swapon .
Phase 1 :
1. b o o t i n i t invoked a s pid( l).
2 . Invoke I etc I re . boot 1 .
3. Invoke r e s tbas e to restore VPD to ODM.
4. Build Phase 1 config rules list.
5. Run Phase 1 methods, planar, MCA, SCSI, etc.
6. Create device special files, device drivers, etc.
7. Initialize LVM.
8. Varyon roo tvg .
9. Check and mount root file systems.
10. Start pager.
11. Phase 1 complete.
Phase 2
Control is returned to boot ini t , which restarts the / et c I re . boot
script with an argument value of 2 to begin Phase 2 (see Fig. 5.4). The
volume group map, device special files, and ODM object classes creat­
ed during Phase 1 are merged into the real root file system. Hardware
VPD information is deleted from the user customized ODM entries.
Devices not configured in Phase 1 are configured. After all device con­
figuration information has been updated in the root file system, the
Invo i c e / e t c / re . boot 2
Init Conso l e Line
Discipl ine
Con f i g All Devices
Merge ODM Data to roo t f s
Mount roo t f s Over boot f s
Figure 5.4
Phase 2 block diagram.
System Boot and Shutdown
root file system is remounted as "/" over the boot file system and new­
root is invoked.
Phase 2:
1. ini t invokes / e tc / rc . boot 2 LED = 55 1.
2 . Console line discipline initialized.
3. Merge RAM ODM and device files into roo t f s .
4. Configure any devices not configured by Phase 1.
5. Remount roo t f s over boo t f s ; LED = 5 17.
6. Phase 2 complete; LED = 553.
Phase 3
Phase 3 marks the transition from boo t ini t to runt ime i n i t or
Phase 2 service mode (see Fig. 5.5). Service mode is entered when the
key switch is set in the SERVICE position. All running processes
except the scheduler and boo t ini t are killed. After all of its chil­
dren exit; boo t i n i t exits and becomes a ZOMBIE process . The
scheduler discovers that pid( l) has exited and invokes newr o o t .
newroot releases the RAM file system, remounts the virtual root file
system and invokes proc l r e s tart ( ) , which starts / etc / ini t as
pid( l). boot ini t has now been replaced by runt ime ini t .
Phase 3:
1. Kill all running processes.
2. boo t ini t exits.
3. Scheduler invokes newro o t .
4. Old RAM file system freed.
5. VFS points at real roo t f s .
6. proc lres tart invokes runt ime ini t .
Trans i t i on to Runtime
Boot ini t Exi ts
Al l Running Procs K i l led
newroot to root f s
Figure 5.5 Phase 3 Block diagram.
boo t f s
System Installation and Operation
runt ime ini t begins by setting the init state to single-user mode
(see Fig. 5 . 6 ) . It examines entries in I e t c I ini t t ab and invokes
I etc I re . boot with argument of 3. The I tmp file system is checked
and mounted. c fgmgr is invoked based on the key mode switch set­
ting. If the key position is NORMAL, c fgmgr runs Phase 3 rules. If
the key position is SERVICE, c fgmgr runs Phase 2 rules. Phase 1
methods are rerun. The console pseudodevice is configured and
assigned. s aveba s e is executed to save custom ODM entries to
NVRAM for subsequent system boots. If the key mode switch is in the
service position, then system diagnostic pretest is run. If the key is in
the NORMAL position, the remaining single-user mode / e t c / ini t ­
tab entries are run. s rcms t r is started, which, in turn, invokes sub­
systems defined in I e t c I ini t tab . The init state is set to 2 and the
system transitions to MULTIUSER MODE. Login processing is now
available to your user base. The system's up! Start hacking!
1. ini t s tate to 1 SINGLE USER.
2. / et c / ini ttab entries invoked.
3. / etc / re . boot 3 started.
4. f s c k and mount / tmp .
5. c fgmgr Phase 2 if key = normal, Phase 3 if key = service.
6. Phase 1 rules rerun.
7. Config and Assign console pseudodevice.
Invoke / et c / re . boot 3
Rerun Device Config
Invoke / etc / inittab Entries
Save Base t o NVRAM
Key = SERVICE Diag
Key = NORMAL Continue
S tart Subsystems
Figure 5.6
Runtime init block diagram.
Enable Login Process ing
System Boot and Shutdown
/ dev/ h f t O LED = c 3 2
/ dev / t tyO LED = c 3 3
8. Invoke s avebas e to save custom settings to NVRAM.
9. If key = service then invoke diagnostics, key = normal complete
I e t c I ini t tab entries.
10. Set ini t s tate to MULTI USER.
1 1 . Start s rcms t r and subsys tems .
12. Enable login processing.
Stopping the System
Like all things in life, runtime must occasionally come to an end. In
this event, you can use the shutdown or reboo t to gracefully bring
services and the system off-line.
The shutdown command supports a number of flags to control how
the system is to be brought down. By default, it will warn users to
wait one minute, terminate active processes, sync the file systems,
and halt the CPU. You may indicate that the system is to be immedi­
ately restarted after shutdown by using the - r flag, or by invoking
the reboot command.
# shutdown
# shutdown - r
+ 5
System down to single user in 5 min
Shut down and reboot
# shutdown now
Shut down immediately
# shutdown -k
Abort shutdown procedures
The RS/6000 is very good about checking its hardware during the
built-in self-test (BIST) at power-up time. Keeping track of the LED
information during system power-up will assist you in debugging
hardware problems. If you suspect hardware problems or the system
won't boot, use the RS I 6000 Diagnostic Programs to assist in deter­
mining the failure. The diagnostic programs may be run in stand­
alone mode from diskettes, or in concurrent mode with AIX on-line,
using the diag command. For concurrent mode operation, as supe­
ruser, enter the diag command and follow the menu instructions.
Stand-alone mode is similar to booting from diskette as described pre­
viously. There are two different boot diskettes depending on whether
you have 8 M of memory or greater than 16 MB. There is a console
display definition diskette and several diagnostic diskettes for testing
and configuring adapters.
Booting from diagnostics diskettes:
1. With the system powered down, turn the key to service.
System Installation and Operation
2. Insert either the 8-M or 16-MB boot diskette per your config.
3. Turn the power switch on.
4. At each c 0 7 LED prompt, insert the next diskette #.
5. At the c 3 1 LED prompt, select the console.
6. Follow the diagnostic instructions displayed on the console.
While loading the diagnostics diskettes, if a c O 2 or c O 3 LED status is
displayed, you have either loaded the diskettes out of sequence or
inserted the wrong diskette, respectively.
lnfoExplorer Keywords
boo t l i s t
5.1 0
getroo t f s
mkboo t
res tba s e
mkd i spdskt
s avebas e
reboo t
mkins tdskt
System boot:
boo t l i s t
Set boot device list
Create new boot image
Stand-alone boot procedure:
1. Insert a diskette/tape containing a boot image and power-on the
2. At LED c 0 7 , insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select the Maintenanc e option from the menu.
6. Select the S t anda l one
Ma int enan c e
She l l option from the
7. Access the root volume group: getroo t f s hdi skO .
Start-up files:
/ etc / re . bo o t
Boot phases
/ etc / init tab
Subsystem start-up
System Boot and Shutdown
System shutdown:
shutdown now
Shut down immediately
shutdown -m
Shut down to single user
shutdown - k
Abort shutdown
Shut down and restart
Set system run level
System C onfi g u rati o n
a n d C ustom ization
Devices Confi g u ration and
the Object Data Manager
AIX Dynamic Device Configuration
Unlike many traditional UNIX system s , AIX supports dynamic
device configuration and management. In many cases, you can con­
nect external devices to a running system, configure the device
attributes, and begin using the new device. No kernel rebuild! No
system reboot! How this works is that AIX allows dynamic kernel
extensions and device driver installation to a running kernel, and
dynamic device configuration through the object data manager
(ODM). If you spend much time with AIX, it's essential that you
develop a good understanding of ODM structure and operation. Since
device management and the ODM are so tightly coupled, it makes
sense to begin the discussion on devices by outlining the functional
characteristics of the ODM.
ODM Overview
In the beginning, there were UNIX system configuration tables. They
were sent forth to the BSD and SYSV masses, bringing all into a com­
mon fold of administration. But lo, workstations multiplied and pros­
pered. Configuration tables became large and unwieldy. Out of this
mire of table parsing, a new doctrine was prophesied which would
reduce the wailing and gnashing of teeth during login processing and
password updates. It was called dbm and it was good. dbm routines
reduced large configuration tables into a database of key-content
pairs. Items in a database are retrieved in one or two file I/Os. dbm
databases are represented as an index file, * . dir and a data file,
* . pag . A common example of a dbm database is the password pas s ­
wd . dir and pas swd . pag file.
System Configuration and Customization
IBM decided to take the dbm doctrine one step further by introduc­
ing a hierarchical obj ect-oriented database for configuration data
called the object data manager (ODM). The ODM centralizes a num­
ber of the standard configuration tables into a single management
structure with update validation. AIX commands and kernel routines
access ODM objects using SQL-like semantics.
ODM Components
The ODM consists of a database of object classes based on a simple
UNIX file access method. The database is managed using a library of
routines and commands. Information is stored as objects within an
object class. Each object is associated with a set of attributes associat­
ed with the object class definition.
ODM database
Object classes are implemented as standard UNIX files in a directory
which represents the ODM database. The ODMDIR environment vari­
able defines the directory path used as the ODM database. The
default ODMDI R path is set to / e t c / obj rep o s in the / et c / envi ­
ronment file. ODMDI R may be manipulated to designate custom appli­
cation databases.
/ e tc / obj repos
. .I
Con f ig_Rule s
DSMOp t i ons@
DSMOpt i ons . vc @
/usr / l ib/ obj repos
. .I
Conf ig_Ru l e s @
DSMOp t i ons
DSMOp t i ons . vc
GAI . vc
PDiagAt t
Default object class directory
PDi agAtt@
PDiagAtt . vc @
PDiagDev . vc@
SRCnot i fy
boo t /
conf ig_lock
errnot i fy
hi s t ory
history . vc
inventory . vc
lpp . vc
lvm_l ock
product . vc
sm_cmd_hdr . vc@
sm_cmd_opt . vc @
sm_menu_op t . vc @
sm_name_hdr . vc @
Additional A1X 3.2 directory
PDiagAtt . vc
PDiagDev . vc
boot /
h i s t ory
h i s t ory . vc
inventory . vc
lpp . vc
produ c t
produc t . vc
sm_cmd_hdr . vc
sm_cmd_opt . vc
sm_menu_opt . vc
sm_name_hdr . vc
swconf ig_info
swcon f ig_info . vc
Devices Configuration and the Object Data Manager
Objects and object classes
ODM objects are the data items which make up object classes. Object
attributes are mapped to a C language structure which represents the
object class definition. The object class definition describes the descrip­
tor = value pairs which make up an object. Object classes may be rela­
tionally joined to other object classes using a special link descriptor.
Initially the object class definition is constructed as an ASCII text
file identified by a ere extension. This description file is read by the
o dme r e a t e command to create the obj ect class . The result is an
empty object class and a . h header file which may be used by applica­
tion programs to populate and manipulate members in the object
class. As an example, consider the generic attributes of an inventory
object class for a music store.
inventory . ere object class definition
c l a s s Inventory {
char i t em [ 2 0 ] ;
char description [ B O ] ;
char color [ 2 0 ] ;
short uni t_nurnber ;
char manufac turer [ 2 0 ] ;
l ong quan t i t y ;
l ong uni t_pr i c e ;
method order_more ;
# odmcreate inventory . ere
Create an object class called inventory
Inventory object member
Inventory :
i t em
\\ Drum S t icks "
" Rudimental drum s t i cks , p l a s t i c t i p "
uni t_nurnber
manufac turer = " Prehi s t o r i c Logs "
quan t i ty
uni t_pri c e
/usr / l ocal /bin/ check_inventory
The obj ect class definition may specify a method descriptor (see
Table 6. 1). The method defines a program that is to be invoked by the
ODM Descriptors
2-byte short integer
4-byte long integer
Fixed-length null-terminated string
Variable-length null-terminated string
Arbitrary bit string
Link to another object class
Fork and exec child command or program
System Configuration and Customization
o dm_run_me thod routine . The method updates the state of the
object. In the example, the method would check the inventory and
change state when the inventory was exhausted. Each object in the
object class may specify a unique method program. Methods are rep­
resented as null-terminated 255-character strings. The special char­
acter "&" may be appended to the method for asynchronous execution.
Command and library interface
Users and applications manipulate ODM data via commands, library
routines, and the odme ODM editor. The list of commands and library
routines in Table 6.2 will give you a feeling for types of operations
permitted on ODM data.
ODM Editor
The odme editor is an excellent tool for browsing through configura­
tion information. In a real bind, it can be used to update problem
ODM Commands and Library Routines
Library routine
odm_create_c l a s s
odm_get_f irst
odm_get_l i s t
odm_free_l i s t
odm_c l o s e_c l a s s
odm_ini t i a l i z e
odmde l e t e
Set odm database location. ODMDIR
represents a shell environment variable.
Object class editor.
Retrieve customized objects from
boot image and store in ODM.
Store ODM customized objects in boot image.
Remove an object class.
Display object class definition.
Create empty object class with
associated C headers for applications.
Add an object to an object class.
Modify object attributes.
Delete object from an object class.
Retrieve an object in odmadd format.
Retrieve an object by its ID.
Remove an object by its ID.
Retrieve first object that matches criteria.
Retrieve next object that matches criteria.
Retrieve a list of objects that match criteria.
Free memory allocated for odm_get..:.l i s t .
Execute method associated with an object.
Close object class.
Retrieve error message string.
Lock object for update.
Unlock object.
Initialize ODM session.
Terminate an ODM session.
Devices Configuration and the Object Data Manager
account without write permissions for the object classes you would
like to browse to ensure integrity. Begin by selecting the object class
name of interest. You may then display and manipulate information
in the selected class.
As an exercise, set the ODMDI R environment variable to point to a
subdirectory in your $HOME directory. Use an editor to create a sam­
ple object class and invoke odmcreate to build the new object class.
Use odme and the commands listed in the previous section to manipu­
late data in the test object class. (See Figs. 6. 1 and 6.2.)
# odme
Set the default obj ect class type and then select Re t r i eve / Edi t
obj e c t s .
Configuration Tables and the ODM
To support traditional UNIX administration techniques, some ODM
information is mirrored in traditional UNIX configuration tables .
Care must b e taken t o make certain that ODM information i s kept
synchronized with configuration table contents. ODM and table syn­
chronization is performed automatically if updates are introduced
using SMIT. In some cases you can edit the standard configuration
file and invoke synchronization commands to incorporate the updates
into the ODM. For example, the TCP/IP I e t c I s e r v i c e s and
I e t c I inetd . c o n f tables may be built from ODM data using the
inet exp command, updated with an editor, then incorporated back
into the ODM using the inet imp command.
ll inetexp
Build /etc/services and /etcrmetd.conf from ODM information
ll inetimp
Import /etc/services and /etc/inetd.conf data into the ODM
Object Data Manager Editor
Set default object class
Display relational graphs
Create an object class
Selective search
Retrieve/Edit objects
Object class management
Delete an object class
<Esc>l = Help
Figure 6.1
Object data manager editor.
<Esc>3 = QUIT
System Configuration and Customization
Object Display
Object Class : CuDv Object: 1 Descriptor: 1 of 8
<Esc>l = Help
<Esc>6 = Copy
Figure 6.2
<Esc>3 = EXIT
<Esc>8 = PgDown
<Esc>2 = Search
<Esc>7 = PgUp
<Esc>4 = Add
<Esc>9 = Left
<Esc>5 = Delete
<Esc>O = Right
Sample odme panel.
Device Configuration
Device interface definitions and configuration attributes are stored as
objects in the ODM database. Each time the system is booted, the c fg­
rngr walks the 110 bus and Micro Channel and identifies all devices
present on the system. Device location and type information is stored
in the ODM and the associated configuration rules and initialization
methods are run to make the devices available for use (see Chap. 5).
c fgrngr can also be invoked on a running system from the SMIT
devi c e s menus (see Fig. 6 . 3 ) or by executing c f grngr , rnkdev ,
chdev , or rrndev from the command line. The same dynamic device
configuration activities performed at boot time are invoked while the
system is up and available for use. This feature allows you to make
new devices available without requiring a system reboot.
# srni t devi c e s
# mkdev -1 t tyO
# l s dev
Add a tty device
List existing SCSI devices
- s scsi -H
# chdev -1 rmt O - a block_s i z e
# lsattr -D -1 rmt O
Change tape block size
List tape attributes
# rmdev -1 rmt O -d
Remove a tape device
# c f gmgr
Update ODM and kernel
Devices Configuration and the Object Data Manager
Move cursor to desired item and press Enter.
Configure Devices Added After IPL
Asynchronous Adapters
Fixed Disk
CD-ROM Drive
Diskette Drive
Tape Drive
High Function Terminal (HFT)
SCSI Initiator Device
SCSI Adapter
Asynchronous 1/0
List Devices
Fl = Help
F9 = Shell
Figure 6.3
F3 = Cancel
Enter = Do
FS = Image
SMIT devices panel.
Sampling of AIX Object Classes
6. 7
F2 = Refresh
FlO = Exit
Predefined devices supported by AIX
Predefined device attributes
Predefined device subclass connections
Customized devices attached to the system
Customized device drivers
Customized device attributes
Custom device dependencies
Customized vital product data
Configuration rule sets
Predefined and Customized Devices
Device configuration information is separated into prede f ined and
cus t omi z e d obj ect classes (see Table 6.3). Predefined object class
information represents default configuration information for all
devices supported by AIX. Customized object classes represent the
devices actually present on the system.
/ e t c / obj repos / Pdxxx
ODM predefined devices/attributes
PdAt PdCn PdDv
/ e tc / obj repos / Cuxxx
ODM customized devices/attributes
CuAt CuDep CuDv CuDvDr CuVPD
Device object classes are linked hierarchically into subclasses. For
example, 7 2 0 7 and 3 4 9 0 E tape devices represent subclasses under the
System Configuration and Customization
tape object class. The tape object class in tum is a subclass of the
s c s i object class. This hierarchy enforces configuration relationships.
Parent object class information must be configured before child sub­
class configuration.
Parent object class information may not be modified if child sub­
classes exist.
Parent object classes may not be removed if child subclasses exist.
A special object class, predefined connections (PdCn), defines the hier­
archy of device classes and subclasses. Device attributes are main­
tained as separate attribute object classes.
You can display object class definitions using the odmshow command.
# odmshow <Obj ectClassName>
Tables 6.4 through 6. 7, representing the predefined and customized
device and attribute descriptors, will give you some idea how device
information is represented and linked.
Device States
The c fgmgr routine is responsible for updating custom device infor­
mation using the configuration rule sets. c fgmgr invokes the method
PdDv Descriptors
subc l a s s
chgs tatus
f ru
s e tno
Unde fine
unique type
Device type
Device class
Device subclass
Prefix name
Device ID
Base device flag
VPD flag
Device detectable flag
Change status flag
Bus extender
FRU flag
LED value
Set number
Message number
Catalog number
Device driver name
Define method
Configure method
Change method
Unconfigure method
Undefine method
Start method
Stop method
Inventory only flag
Unique type
Devices Configuration and the Object Data Manager
PdAt Descriptors
unique type
de f l t
n l s_index
Unique type
Attribute name
Default value
Attribute values
Type flags
Generic flags
Representative flags
NLS index
CuDv Descriptors
s tatus
chgs tatus
l ocation
c onnwhere
Device name
Device status flag
Change status flag
Device driver instance
Location code
Parent device
Where connected
Link to predefined device
CuAt Descriptors
gener ic
nl s_index
Device name
Attribute name
Attribute value
Attribute type
Generic flags
Representative flags
NLS index
specified for each attached device and updates the devices state. After
the device method is complete, the device is set to one of three states,
Device states
Device defined but not available for use
Device configured but not available
Device configured and available
Boot Devices
A small ODM database representing device configuration information
is maintained as part of the AIX boot images. This information can be
updated from the master ODM database using the s avebas e com­
mand. Likewi s e , ODM information from the boot image can be
restored to the master ODM database by invoking the r e s tba s e
command (see Chap. 5).
System Configuration and Customization
6.1 O
# savebas e
Save master ODM custom device data to the boot image
# res tbase
Restore custom ODM data from the boot image to the master ODM
Small Computer System Interface
The most common device interface for the RISC System/6000 is the
small computer system interface (SCSI). The SCSI standard defines a
generic interface and command protocol that will support most device
types. Devices are attached in a daisy chain fashion to the host
adapter. The total chain length cannot exceed the distance maximum
for the adapter type.
6.1 0.1
SCSl-1 and SCSl-2
The RISC System/6000 supports both SCSI- 1 and SCSI-2 adapters
and devices. Both SCSI- 1 and SCSI-2 devices may be mixed on either
adapter type; however, throughput to the device will be limited to
SCSI-1 speeds. The c f gmgr queries the device type during SCSI
device configuration and records the SCSI type. This eliminates the
need for device drivers to continually query the SCSI type to deter­
mine if extended SCSI-2 commands are supported. SCSI- 1 support
provides transfer rates up to 4 MB/s. SCSI-2 Fast SCSI mode extends
synchronous transfer rates to 10 MB/s. SCSI-2 signal control is also
two to three times faster than SCSI- 1.
6.1 0.2
Cables and adapters
The SCSI-2 cable uses the same pin assignments as the SCSI-1
adapter. The only difference is that on the adapter end, the SCSI-2
adapter only has 50 pins like the integrated SCSI cable.
If you are sharing a SCSI string between two machines, use IBM
Pass Through Terminator (PTT) cables between the first device and
the adapter on each end of the shared string. Device-to-device connec­
tions can use standard SCSI cables.
6.1 0.3
Single-ended and differential SCSI
Single-ended SCSI connections have a combined distance limitation
of 6 meters. Logic level of each wire is based on the voltage difference
with a common ground. Differential SCSI connections can run up to
25 meters. Logic levels on differential connections are based on the
potential difference between two signal wires.
Single-ended connections can be a real problem with some RS/60009XX: systems. The SCSI cable management arm in early 9XX racks
eats up approximately 4.75 meters of the total 6-meter cable length. A
single-ended SCSI to differential SCSI adapter can be used to get
around the problem.
Devices Configuration and the Object Data Manager
6.1 0.4
SCSI addressing
Each SCSI string supports eight addresses (0-7)that must be divided
up between the devices and the adapter. Some device controllers sup­
port multiple devices from a single SCSI ID using logical unit num­
bers (LUN). In most cases, you are only going to have seven addresses
that may be assigned to seven devices on the chain. The SCSI adapter
requires one of the addresses, normally SCSI ID 7. Arbitration on a
SCSI chain begins with the high address numbers, so better response
is provided to devices with larger SCSI IDs. Device SCSI IDs are com­
monly selectable via jumpers or from a selector wheel on the device
frame or housing.
SCSI address format
Two-digit SCSI address where:
A represents the SCSI ID
B represents the logical unit number
Devices are identified by a location code. Verify that the location
code matches the actual hardware slot and interface using the l s dev
Device location codes
6.1 1
Drawer location or planar
1/0 bus and slot
Adapter connector number
SCSI ID or port number
Updating the Product Topology Diskette
It's a good idea to update the topology diskette supplied with your
system each time you add a new device. These diskettes are used by
IBM service and support representatives to keep a record of your sys­
tem configuration. These are especially helpful for sites that have a
number of machines. After updating the diskette, send a copy to IBM
Hardware Support using the mailer and address label supplied with
the update diskette.
Topology update procedure
1. Shut down the system.
2. Set the key switch to the SERVICE position.
3. Boot the system.
System Configuration and Customization
5. At the FUNCT I ON
SELECT I ON menu, select the Serv i c e
Topol ogy options.
SELECTION menu, select the Produc t
7. Follow the instructions displayed. When prompted "Do you have
any update diskettes that have not been loaded?" answer "yes"
and insert the Product Topology Update diskette. Follow the
instructions to update the Product Topology System diskette. If
the EC AND MES UPDATES screen is displayed, select the PF key
to commit updates.
8. Repeatedly press PF3 to exit all D IAGNOSTICS menus.
9. Reset the key switch to the NORMAL position.
10. Reboot the system.
6.1 2
l nfoExplorer Keywords
inet imp
6.1 3
c f gmgr
me thod
res tbas e
Object data manager
/ e tc / obj repos
ODM database directory
/usr / l ib / obj repos
ODM database directory
export ODMDIR = <path>
Set ODM database path
ODM editor
inetimp / inetexp
Import/export TCP config files data from/to ODM
Add devices after IPL
c f gmgr
l s dev , mkdev ,
chgdev ,
Manage devices
Magnetic tape, due to its large storage capacity, low cost, and long
storage life (usually more than 2 years), has been the secondary stor­
age medium of choice for many years. The RISC System/6000 sup­
ports QIC �-in, 4-mm, 8-mm, 9-track, and 18-track drives.
Tape Characteristics
Before we look at the attributes of the individual device types and
tape formats, it will be helpful to do a level set concerning general
tape characteristics. An understanding of how data is represented on
the media will assist you in making better use of the resource.
7.1 .1
Physical characteristics
The earliest use of magnetic tape was German Magnetophons. These
devices used a plastic tape doped with iron oxide. Later on, the
United States experimented with paper tape coated with iron oxide.
This was followed by acetate and, finally, polymer-based tape. The
thickness of the oxide coating, particle density, and particle distribu­
tion on the tape surface determines the signal strength which may be
encoded. A thicker and denser oxide layer improves the signal
strength, but reduces high-frequency response for audiotape. If the
layer is too thin, print through may occur. Print through is the trans­
fer of recorded magnetic signal between tape layers on the reel. Tape
thickness and base substrate also determine transport friction, media
durability, and shelf life. Data-grade tape employs a thicker and
denser oxide coating than standard audiotape and is usually more
expensive. This is changing somewhat with digital audio tape (DAT).
The same is true for data and video 8-mm tape. Good quality video­
tape will work in your RISC System/6000 tape drive, but I wouldn't
recommend it. I learned the hard way!
System Configuration and Customization
Fixed Head
Tape Direction
Helical Scan Head
Tape Direction
Figure 7.1
Fixed head and helical-scan head.
Over the last few years we have also seen improvements in mechan­
ical transport and head technologies. Helical-scan heads are replacing
fixed head configurations for digital recording (see Fig. 7. 1). Helical­
scan heads spin as the tape moves across the head surface. This
reduces the transport speed requirements for the tape moving from
spindle to spindle. Data is written diagonally across the tape surface.
This will be an important point to remember when we talk about block
sizes later in the next section.
7.1 .2
Data format
Data is recorded on tape in blocks. Each block of data is separated
from the next by an interrecord gap. (See Fig. 7 .2.) Files on a tape are
delimited by tape marks or file marks. A tape mark indicates the
beginning of tape (BOT). Two tape marks in succession indicate end of
tape (EOT). BOT may also be followed by a special file called a tape
label. The label indicates the volume name, size, and sequence num­
ber in a multivolume set.
Blocks are either fixed or variable in length. Fixed block format
means that data is read and written in chunks which are all the same
size. The amount of data read and written to the media must be done
in multiples of the block size. Variable block format leaves it up to the
application to determine the length of each block of data. A request to
read more data than is available in the next tape block will result in a
Tape Gaps
Tape Blocks
Figure 7.2 Tape block and gap format.
short read when using variable format. This feature is useful for com­
mands like dd that will support short reads, but is detrimental to less
forgiving commands like tar , cpi o , backup , and res tore . The
good news is that when using variable block size, the dd command
can be employed with an excessive block size to buffer input to tar ,
cpi o , backup , and res tore .
# dd i f = / dev/ rmt 0 . 1 ibs = 6 4 k obs = 5 1 2
# dd i f = / dev/ rmtO . 1 ibs = 6 4 k obs = 5 1 2 0
# dd i f = / dev / rmtO . 1 ibs = 6 4 k obs = 5 1 2 0
7.1 .3
restore -xvB
tar -xvBf cpi o - ivB
Block size
Block size is an important consideration and will effect the total
media capacity and the time required to read or write data on the
device. Larger block sizes reduce the number of interrecord gaps and
make better use of the tape. The block size should also reflect the
physical block size written by the device. For example, an 8-mm tape
drive writes 1024 bytes per block diagonally across the width of the
tape. If the block size defined to AIX. for the device is fixed 5 12-byte
blocks, then the device will write out 5 12 bytes of data and pad the
remaining 5 12 bytes in the physical 1024-byte block. This effectively
reduces the media capacity by half. When variable length blocks are
defined in AIX for the example 8-mm device, block sizes larger than
1024 will fill each physical block on the tape. If the block size used by
the application is not a multiple of 1024, then the last physical block
written will be padded.
Block size is application-dependent. Selecting the wrong block size
can inhibit the ability to read AIX distribution and backup media,
and cause portability problems. IBM uses a default block size of 5 12
bytes for product distribution media. You must also use a block size of
5 12 bytes for backups of the root volume group. If you do not use a
System Configuration and Customization
block size of 5 12, the installation and restore programs will abort
with the error message:
/ dev / rrnt O : archive no t in backup format
You can change the default block size defined to AIX for a tape
device using the chdev command. Remember that this does not alter
the physical block size used by the device.
# chgdev -1 rmt O -a "block_s i z e = 0 "
# chgdev - 1 rmt O - a "block_s i z e = 5 1 2 "
# chgdev -1 rmt O -a "block_s i z e = 1 0 2 4 "
Variable block size
Fixed 5 12-byte block size
Fixed 1024-byte block size
If portability is an issue, you will want to define a default block size of
0 , which indicat e s a variab l e block si z e . Byte o r dering and
ASCII/EBCDIC conversion can be handled by the c onv option to the
dd command.
# dd i f = / dev / rmtO conv = swab
Swap byte pairs
# dd i f = / dev/ rmtO conv = a s c i i
Convert EBCDIC to
# d d i f = / dev/ rmtO i b s = 5 1 2 obs = 1 0 2 4 conv = sync
Pad blocks
Table 7 . 1 provides a few hints when using tar to move data from
an RS/6000 to one of the listed vendor types.
7.1 .4
Device names
Along with the block size, you must also be aware of the implicit tape
i o c t l operations associated with the device special file names.
Device special file names are associated with a unique major number
that identifies the tape device driver location in the device switch
table. A per-device unique minor number identifies entry points in
the tape device driver that correspond to various density and tape
control operations. If you are familiar with other UNIX tape systems,
you know that nearly everyone uses their own scheme for naming
device special files. Table 7 .2 represents the AIX V3 default device
names and the corresponding control operations and density.
RS/6000 Tape Conversions Using tar
Ok. Check for compatible tape type/density.
Sun uses 5 12-byte blocks by default. On
RS/6000, set block size to 5 12 or use dd
conv = sync to pad blocks when reading
Sun tapes.
Ok. Check for compatible tape type/density.
Swap byte pairs using dd conv = swab.
Tape Device Name Implicit Options
File name
Rewind on close
Retension on open
/ dev / rmt *
/ dev/ rmt *
/ dev / rmt *
/ dev/ rmt *
/ dev/ rmt *
/ dev/ rmt *
/ dev/ rmt *
/ dev/ rmt *
IBM Density Modes
Mode #
8-mm 5-GB compression mode
8-mm 2.3-GB mode
8-mm 5-GB compression mode
7207-12 QIC-120
7207- 12 QIC-150
7207- 12 QIC-525
7207-12 QIC-1000
7207-12 QIC- 1000
7207-1 1
7207-1 1
7207-1 1
7207-1 1
7207-01 QIC-120
7207-01 QIC- 150
7207-01 QIC-150
9-track 6250 bpi
9-track 1600 bpi
Sensed tape density
The high and low density values are dependent upon the device.
Consult the vendor documentation concerning the device characteris­
tics. The mode numbers in Table 7 .3 identify the density for the par­
ticular IBM device.
Make sure you take a close look at the nnt man page information
on how BOT, EOF, and EOT are handled for both reading and writ­
ing. You may be in for a surprise if you do not select the correct device
name for your applications requirements. This can be especially true
for EOT handling on 9-track tape drives . UNIX generally does not
sense EOT before reaching it. Improper tape positioning at EOT can
cause the application to run the tape off the end of the reel. You will
make few friends in the operations staff if you do this very often.
7.1 .5
Tape positioning
The tape device driver supports a somewhat standard set of ioctl
operations used to control tape positioning. These operations can be
invoked from the local command line, remotely, or within a program.
System Configuration and Customization
Local and remote positioning is handled by the t c t l and nnt com­
mands , respectively. If you are familiar with the mt command on
other UNIX platforms, you can link mt to t c t l , since their operation
is similar. rmt is used in conjunction with rcmd or rexec .
# t c t l - f / dev/ rmt O rewind
For remote operation, be aware that AIX ioctl call numbers don't
necessarily map one-for-one with those on the remote system. You
can fix the mapping problem by creating a wrapper for rmt to remap
the command line parameters to those in use by the remote system.
(See Table 7.4.)
Be aware of where you are during tape operations. After each pro­
gram read() or write() operation, the tape head is positioned at the
beginning of the next block or the beginning of blank space. Tape
marks are treated exactly like a file, so they must be accounted for
when skipping from file to file on a tape.
7.1 .6
Restricting access to tape devices tends to be a problem on many
UNIX systems. The device special files are commonly set "rw" by the
world. In the absence of additional tape allocation software, you can
easily create your own drive reservation application using the follow­
ing algorithm:
1. Check for a free device (absence of device lock files).
All devices in use then exit
Else continue
2. Fork and spawn a new shell.
AIX to UNIX Ioctl Mapping
ioctl #
ioctl #
Rewind unload tape
Rewind tape
Erase tape
Retension tape
Write end-of-file marker
Forward-space file
Backspace file
Forward-space record
Backspace record
Backspace t o BOF
Wait until process exit to release device
3. Create lock file for selected device.
4. Set permissions and ownership to requester.
Default device permissions
# l s - a l / dev/ rmt *
c rw- rw-rw1 root
crw-rw- rw1 root
crw-rw- rw1 root
c rw-rw-rw1 root
crw- rw- rw1 root
1 root
crw-rw-rwc rw-rw-rw1 root
crw- rw-rw1 root
sys tem
sys t em
sys tem
sys tem
sys t em
sys t em
sys tem
sys tem
22 ,
22 ,
22 ,
22 ,
22 ,
22 ,
22 ,
22 ,
/ dev/ rmtO
/ dev/ rmt O . l
/ dev/ rmt 0 . 2
/ dev / rmt 0 . 3
/ dev / rmt 0 . 4
/ dev / rmt 0 . 5
/ dev / rmt 0 . 6
/ dev / rmt 0 . 7
Tape Tools
AIX provides a limited set of tape utilities. The following set of com­
mands support tape manipulation:
Read/write variable block sizes and perform data con­
Display tape directory or copy tape to tape
Verify QIC tapes for errors
tar , cp i o , backup / res tore
Archive tools that may use tape as a medium
Public Domain Tape Tools
Due to the absence of tape allocation mechanisms, label support, and
tape librarians in UNIX, a number of vendor and public domain tape
handling applications have been developed. Vendor packages change
faster than the publication life of this book, so I encourage you to
refer to adverti sements and reviews in publication s like
RS I Magazine. I found the following set of public domain tools after
spending a few minutes with archi e , searching on "tape." No war­
ranty or guarantees implied! Use archi e to locate the archive site
nearest you.
ans i t ape :
Read and write ANSI and IBM standard labels in ASCII and
EBCDIC. Read multivolume tapes. Requires ioctl command changes
ala rmt on AIX.
ems tape
Process IBM VM/CMS TAPE DUMP format.
Tape-to-tape copy program.
Map and read a DEC ANSI labeled tape.
comp.unix.sources archive v08i099.
comp.unix.sources archive v07i008.
comp.unix.sources archive v10i099.
Manipulate a table of contents on the beginning of an 8-mm tape.
Read IBM standard labeled tape.
1 00
System Configuration and Customization
magtapet o o l s
Package of tape tools supporting: interrogating tape contents, tape
copy, read random blocks, and read/write ANSI labels.
rmt l ib2
Library and generic rmt . h file supporting remote tape operations
from a program similar to rmt.
Map a tape. Reports minimum/maximum block size and block count
for each file on the tape.
comp.unix.sources archive v18i109.
Copy tape package.
comp.sources.3bl archive volume02.
Tape device reservation with operator messages.
IBM Tape Devices and Characteristics
For third-party devices, see documents in pub / oemhw available via
anonymous FTP from ibminet.
Figuring out QIC tape portability characteristics is an art unto
itself. The following table for IBM 7207 models (Table 7 .6) is based on
data put together by Brian Murphy from IBM Development. Brian's
original information is available from comp.unix.aix archives May 93.
Column numbers represent 7297 model. DC300XLP and DC600A
tapes are not recommended and may cause head damage. DC9135,
DC9164, DC9200, and DC9210 tapes are not supported.
lnfoExplorer Keywords
cp i o
r e s tore
7207-1 1
7208-1 1
7208- 12*
� Inch
IBM Tape Device Characteristics
*AS/400 compatible.
Max. capacity
Max. transfer rate
370 Channel
IBM 7207 QIC Tape Compatibility
Read Compatibility
01, 11,12
01,1 1,12
01,11, 12
01,1 1,12
01,1 1,12
0 1 , 1 1,12
01,1 1,12
01,1 1 , 12
0 1 , 1 1,12
1 1 , 12
1 1,12
Write Compatibility
01,1 1,12
01,1 1,12
01,1 1,12
1 1 , 12
1 1,12
chgdev -1 <device> -a block_s i z e =
where NNN
tar ,
cpi o , backup
Set block size
Variable block size for compatibility
Backup/install block size
Efficient block size for 8-mm devices
Archive commands
Data dump tool, conversion, reblocking
Copy tape to tape
Control tape device
1 01
D isks and File Systems
Disk Evolution
Are your file systems half full or are they half empty? It doesn't mat­
ter how much disk space you throw into a system, they are always
half full and growing fast! With multimedia tools becoming common­
place, it's not unusual to see large numbers of audio and video files
where minimum sizes are well over a megabyte. It won't be long
before multimedia electronic mail will be shipping these multi­
megabyte files all over the network. If you aren't already thinking in
terms of multi-gigabyte personal computer and workstation storage,
then you are not going to be ready for the storm. A full-blown AIX
BOS installation requires one-third of a gigabyte just for the operat­
ing system. The InfoExplorer information bases can eat up another
third of a gigabyte. Remember when 10-MB hard files on an IBM
PC/XT seemed like more storage than you could ever use? What all
this means is that you better get comfortable installing new disks and
managing file systems.
Disk Hardware
Workstation and personal computer disk drives have primarily been
either an integrated drive electronics (IDE) drives or small computer
system interface (SCSI) drives. IDE drives integrate all the controller
functions into the disk housing. SCSI drives also integrate controller
function in the disk assembly, but require a more complex adapter
card on the 110 bus. The RISC System/6000 supports internal SCSI
disks and Micro Channel adapters for external singl e - e n d e d
SCSl/SCSI-2 and differential SCSl-2 devices.
The disks themselves are multiple platters stacked like records on
a hub (see Fig. 8. 1). Each platter is coated with a magnetic substrate.
One or more electromagnetic heads may be moved back and forth
across a platter from outer edge to inner edge. The heads react to the
1 03
1 04
System Configuration and Customization
Figure 8.1
Fixed-disk architecture.
polarization of the magnetic particles formatted in circular tracks
around the surface of the platter. The heads are positioned on the
platters by a disk controller circuit, which receives its instructions
from the operating system.
Most disks come preformatted with a bad-sector map allocated. If you
have to format a disk, invoke the diag command or reboot the system
from the diagnostic diskettes. From the function menu, select Servic e
Aid , followed by Disk Media and Format Disk and Cert i fy .
# diag
Func ti o n Menu
Servi ce Aid
Disk Media
Format and Cert i fy
Formatted space on the disk is made up of sectors or blocks. The
sector size will vary with make and model and may be either fixed or
variable. Tracks are made up of sectors aligned in circles on each
platter. Stacked tracks on the platters make up a cylinder.
Disk Installation
To add a new SCSI disk to the system, plug the disk onto one of the
SCSI adapters on the back of the system unit. This is best done with
the system powered down, but can be done on-line if you are very
careful. Multiple SCSI devices may be daisy chained off of a single
SCSI adapter. Each disk must represent a unique SCSI ID and logi­
cal unit number (LUN) in the chain. The SCSI ID is jumper- or
switch-selectable on the drive assembly or casing. SCSI IDs range
from 0 through 7, with 7 usually assigned to the adapter. When the
system is booted, the new disk is automatically identified and record­
ed in ROS and the ODM database. You can update device information
Disks and Fiie Systems
1 05
on-line by invoking c f gmgr or using the rnkdev command. The new
disk is assigned the next available hdi sk<nn> label.
# mkdev -c disk -s s c s i -t osdisk -p s c s i 2 -a pv = yes
# SMIT c fgmgr
Use the diag command to verify that the system can access the new
# diag
Logical Volume Manager
The physical disk is now available for partitioning. A partition is a
section of disk space which can be used for file systems or paging
space. Legacy UNIX systems restrict partitions to contiguous space
on a single disk. AIX uses the concept of logical volumes as indirec­
tion to physical space. A logical volume is represented by a mapping
of contiguous logical partitions to discontiguous physical partitions
residing on one or more physical disks. Each physical disk may con­
tain up to 65,535 physical partitions ranging in size from 1 to 256 MB
in powers of 2. The default physical partition size is 4 MB. One to
three physical partitions may be mapped to a logical partition.
Logical volumes are allocated from logical partitions within a logical
volume group (LVG). Each LVG is made up of 1 to 32 physical disks.
Partition mapping, volume management, and interfaces are imple­
mented through a pseudodevice driver and manager called the logical
volume manager (LVM). (Refer to Figs. 8.2 and 8.3.)
Vol u me Group
Physical Volume 1
Physical Volume 2
Logical Volume 2
Logical Volume 3
Logical Volume 1
Logical Volume 2
Figure 8.2 PV to VG to LV mapping.
Logical Volume 1
1 06
System Configuration and Customization
Logical Volume
Physical Volume 1
Figure 8.3 LV to LP to PP mapping.
Using the abstraction of logical to physical partition mapping, A.IX
is able to dynamically increase the size of volume groups, logical vol­
umes, and, ultimately, file systems without service interruption. Prior
to LVM support, you had to back up a file system to disk or tape,
destroy it, rebuild it with the new allocation sizes, and restore the
backup. LVM allows you to dynamically manage disk space on-line
rather than requiring hours of file system down time.
Tailoring the logical partition mapping allows you to optimize file
system placement. Busy file systems should be located in the center
of the physical disk and spread across multiple physical disks. The
LVM also supports mirroring, making duplicate copies of a logical
volume available for concurrent read access. Mirroring also improves
data availability.
Logical volume services are also a part of the Open Software
Foundation's OSF/1 operating system. Although the implementation
is different, the conceptual services are very similar.
Configuring Volume Groups
In order for a new disk to be made available to the logical volume
manager ( LVM ) , it must be de signated a physical volume and
assigned a physical volume identifier (PVID) and label. The PVID is a
sixteen-digit hexadecimal number.
II chdev -1 hdi sk<n> -a -pv = yes
You can list physical disks on your system using l s dev .
Disks and Fiie Systems
# l sdev
1 07
-c disk
hdi skO Available 00-00-0S-OO 1.2-GB SCSI disk drive (in 2 .4-GB
Disk Unit)
hdi skl Available 00-00-0S- 10 1 .2-GB SCSI disk drive (in 2.4-GB
Disk Unit)
hdi s k2 Available 00-04-00-30 Other SCSI disk drive
hdi sk3 Available 00-04-00-40 Other SCSI disk drive
hdi sk4 Available 00-04-00-50 Other SCSI disk drive
hdi sk5 Available 00-04-00-00 Other SCSI disk drive
hdi s k 6 Available 00-04-00-10 Other SCSI disk drive
hdi s k7 Available 00-04-00-20 Other SCSI disk drive
To list the PVIDs associated with these disks, use the l spv com­
# l spv
hdi skO
hdi skl
hdi sk2
hdi sk3
hdi sk4
hdi sk5
hdi s k 6
hdi s k7
0 0 0 0 0 8 8 7 0 00lc7el
0 0 0 0 1 5 0 8 fce5bbea
0 0 0 0 4 0 60c3 88efc4
0 0 0 0 1 5 0 8 2 c 6e 9 2 df
0 0 0 0 1 5 0 8 3 7ccla85
000015 082c28 f5c7
0 0 0 0 1 5 0 8 2 c2 9 3 1 f 5
0 0 0 0 1 5 0 82 c 2 9 6 d8 f
roo tvg
roo tvg
vgO O
vgO O
vgO l
vgO l
vgO l
vgO l
T o add the new disk to a new o r existing volume group use SMIT or
the mkvg and extendvg commands. (Refer to Fig. 8.4.)
# mkvg - f -y vgl O hdi skl O hdi s k l l
Create a volume group vglO using phys­
ical disks 10 and 1 1
Add a Volume Group
Type or s e l e c t values in entry f i e lds .
Press Enter AFTER making a l l des ired changes .
Phys ical par t i t ion S I Z E in megabytes
Act ivate volume group AUTOMATICALLY at sys t em res tart ?
* ACTIVATE volume group a f ter it is created?
Volume group MAJOR NUMBER
Fl = Help
F 5 = Undo
F9 = She l l
F2 = Re fresh
F 6 = Command
F l O = Ex i t
F3 = Cancel
F7 = Ed i t
Enter = D o
Figure 8 . 4 SMIT add volume group panel.
F4 = Li s t
F S = Image
[ Entry F i e lds ]
1 08
System Configuration and Customization
# extendvg -f rootvg hdi s kB
Add disk 8 to the rootvg volume group
# smi t mkvg
A volume group identifier (VGID) is assigned to each volume group.
The VGID is a sixteen-digit hexadecimal number. Each VGID in the
system is represented by an entry in the / e t c / vg directory.
# ls / etc /vg
. ./
vg0 0 0 0 1 5 0 8 3 7CAEE 4 5
vg0 0 0 0 1 5 0 8 3 7CB7 8DD
vg0 0 0 0 1 5 0 8 3 7CC1FBA
vg0 0 0 0 1 5 0 8 4 5 4 9 4 1 7 D
vg0 0 0 0 1 5 0 8 4 5 4 9 F 2 C 6
vg0 0 0 0 1 5 0 8AC 0 4 C2 3 2
vg0 0 0 0 1 5 0 8CA7 8 4 6C O
vg0 0 0 0 1 5 0 8CECC7A4C
vg0 0 0 0 1 5 0 8 EA5D85C7
vg0 0 0 0 1 5 0 8EA5DEB2 9
vg0 0 0 0 1 5 0 8 EA5F84DA
vg0 0 0 0 1 5 0 8 FCE8 0 4 2 7
To display the configuration of the existing volume groups on your
system use the 1 svg command.
List volume groups
# l svg
vgO l
vg0 2
vg0 3
# lsvg
roo tvg :
hdi skO
hdi skl
roo tvg
act ive
List physical volumes in the root volume group
0 0 . . 12 . . 04 . . 0 1 . . 0 0
00 . . 17 . . 00 . . 00 . . 26
Each physical volume in the volume group i s marked with a volume
gro up descriptor area (VGDA) and a volume gro up status area
(VGSA). The VGDA contains identifiers for all logical and physical
volumes and partitions that make up the volume group. The VGSA is
a bit map used to indicate which physical partitions on the disk are
stale and require synced update.
When a volume group is activated using the varyonvg command or
using SMIT, the LVM verifies that it has access to at least 5 1 percent
of the VGDA and VGSA copies before going on-line. This majority is
called a quorum and is required by the LVM to ensure data integrity.
Any physical volume not available is reported. The system adminis­
trator must decide whether to continue if a device is not accessible. If
a majority quorum is not established for the volume group, it is not
# varyonvg <VGname>
Disks and File Systems
1 09
You can take a volume group off-line using the varyo f fvg com­
mand or via SMIT. Note that all access to logical volumes in the vol­
ume group must be terminated. Any file systems located in the volume
group must be unmounted and any paging space must not be active.
# varyof fvg <VGname>
# smit varyo f fvg
To remove or replace physical volumes in a volume group for main­
tenance purposes, use SMIT or the chpv command.
# chpv -vr < PVname>
Remove disk from VG
# chpv -va < PVname>
Replace disk in VG
An entire volume group may be moved as a unit from one system to
another. Use SMIT or the exportvg and imp o r tvg commands to
export a volume group from the old system and import it onto the new
system. The volume group must first be deactivated before attempt­
ing to export it from the system. When the volume group is exported,
all references to it are removed from the system tables. When the vol­
ume group is imported on the new system, all device table, special
file, and / etc / f i l e sys t em entries are added automatically. You can
export and import a volume group on the same system to resynchro­
nize the VGDA and ODM information.
# exportvg <VGname>
# importvg <VGname> <PVname>
Root volume group-rootvg
A special VG called roo tvg is used by AIX for the operating system's
root file systems and the default paging areas. It's a good idea to use
separate volume groups for user and local application file systems.
This way you can export and import these volume groups before and
after operating system upgrades. Each AIX BOS installation destroys
all or part of rootvg .
Configuring Logical Volumes
To make use of the disk space available in a volume group you will
need to create a logical volume. Logical volumes are analogous to par­
titions on other UNIX systems, but they provide some significant
enhancements. The structure and features provided by logical vol­
umes should be well understood before proceeding with allocating
space for file systems or paging areas.
System Configuration and Customization
Logical volume type
Size in logical partitions
Interdisk partition layout
Write scheduling policy
Intradisk partition layout
Will it be mirrored
Logical volume types
The LVM basically manages all logical volume types the same way. A
logical volume may warrant special consideration when defining some
of the other attributes. For example you may wish to locate paging
logical volumes in the center of the disks to reduce head movement.
There are five logical volume types used by AIX:
File system
Holds file system data and metadata
Holds JFS metadata update log
Paging areas
Boot logical volume
Boot block and RAM file system code
Dump area
Holds panic dumps
Logical volume size
When you create a new logical volume or add space to an existing log­
ical volume, you will be working in logical partition units . If you
accepted the default 4-MB partition size, then a 512-MB logical vol­
ume will require 128 logical partitions. Define a maximum number of
logical partitions that will be used for the logical volume. This value
limits the size a file system may grow within the logical volume. If
additional file system space is required at a later date, the maximum
limit may be increased.
You may notice that, when you add up the number of partitions
represented by the physical volumes in a volume group, you have lost
somewhere between 7 to 10 percent of the total formatted space. This
is due to space overhead required by the LVM to manage the volume
group. Remember the VGDA and VGSA structures described in the
previous sections?
lnterdisk policy
The interdisk layout policy determines the range of physical disks that
may be used to allocate partitions for the logical volume. The interdisk
policy may be either MINIMUM or MAXIMUM , along with a RANGE limit
governing the number of physical disks that may be used.
Provides highest availability. All partitions are allocated on a single physical
volume. For mirrored logical volumes, the first copy will be allocated on a sin-
Disks and File Systems
gle physical disk. The second copy can be allocated across multiple physical
volumes up to the RANGE limit unless the strict option is selected.
Provides the best performance. Each logical partition in the logical volume
will be allocated sequentially across up to RANGE physical volumes. If one of
the physical disks fails, then the entire logical volume is unavailable.
lntradisk policy
The intradisk layout policy (Fig. 8.5) defines where partitions will be
allocated within a physical disk. One of five regions may be selected:
inner edge, inner middle, center, middle, and outer edge. Inner edge and
outer edge have the slowest seek times. Average seek times decrease
toward the center of the disk. Use the 1 svg command to display the
layout of existing logical volumes and the number of free partitions.
# l svg roo tvg
roo tvg
4 MB
574 (2296 MB)
60 (240 MB)
D isk Allocation Policy
Figure 8.5
Intradisk policies.
Outer edge
System Configuration and Customization
5 14 (2056 MB)
# l svg - 1 roo tvg
roo tvg :
LV name
LV state
hd6 1
Mount point
/ tmp
/ var
Adding a logical volume
After selecting the volume placement characteristics for the new logi­
cal volume, you can create it using the SMIT fast path, mkl v . (See
Fig. 8.6.)
# smi t mklv
For high-access file systems, mirrors provide a mechanism which
improves availability (a copy of the primary logical volume is main­
tained), and improves access time (multiple paths to the data). You
may choose to keep two mirrored copies in environments that require
higher levels of availability and fault tolerance.
When reading a mirrored logical volume, if the primary path is
busy, the read can be satisfied by the mirror. Writes are sequential to
logical volumes confined to a single physical disk. If mirrors occupy
more than one physical disk, write scheduling can be either sequen­
tial or parallel.
Sequential writes
Writes are ordered in the sequence in which they occur.
Each write operation is scheduled sequentially to each
copy and returns when both updates are completed.
Parallel writes
Writes are scheduled across the multiple disks at the
same time. The write returns after the longest write
Disks and File Systems
Add a Logical Volume
Type or s e l e c t values in entry f ields .
Pre s s Enter AFTER making a l l des i red changes .
[ TOP ]
Logical volume NAME
Logical volume TYPE
POSITION on phys ical volume
RANGE of phys ical volumes
MAXIMUM NUMBER of PHYSICAL VOLUMES to use for a l l ocat i on
Number of COPIES o f each logical par t i t i on
Mirror Wri t e Cons i s tency?
A l l ocate each logical par t i t i on copy on a SEPARATE phys i c a l volume ?
RELOCATE the logical volume dur i ng reorgan i z a t i on ?
Logical volume LABEL
Enable BAD BLOCK relocation?
SCHEDULING POLICY for wri t ing logical par t i t i on copies
F i l e containing ALLOCATION MAP
F l = Help
F 5 = Undo
F9 = She l l
Figure 8.6
F2 = Re f resh
F 6 = Command
F l O = Exi t
F3 = Cance l
F7 = Edi t
Enter = Do
[ Entry F i elds ]
( 12 8 ]
paral l e l
F4 = Li s t
F B = Image
SMIT add logical volume panel.
Add Cop ies to a Logical Volume
Type or s e l e c t values in entry f i elds .
Press Enter AFTER making a l l des ired changes .
* NEW TOTAL number of logical par t i t i on copies
POSITION on phys ical volume
RANGE of physical volumes
MAXIMUM NUMBER o f PHYSICAL VOLUMES to use for a l l ocation
A l l ocate each logical par t i t i on copy on a SEPARATE phys ical volume ?
F i l e containing ALLOCATION MAP
SYNCHRONIZE the data in the new logical par t i t i on cop i e s ?
Fl = Help
F 5 = Undo
F9 = She l l
F2 = Re f resh
F 6 = Command
F l O = Exi t
F3 = Cance l
F7 = Ed i t
Enter = D o
Figure 8 . 7 SMIT mirror logical volume panel.
F4 = Li s t
F B = Image
[ Entry F i elds ]
lvO l
System Configuration and Customization
Mirrors can be created when the logical volume is created by
requesting more than one copy. To mirror an existing logical volume,
use the SMIT fast path, mkl vc opy (see Fig. 8. 7).
Start SMIT and select logical volume to be mirrored
# smi t mklvcopy lvO l
8. 7
File Systems
The most common use of logical volumes is to contain file systems. A
file system is the structure which supports a UNIX directory and file
tree. A file system tree begins with the root directory at the top, with
subdirectory branches preceding down from the root. Each directory
level in the tree may contain files and directories. The primary struc­
tures which make up the file system are the super block, inodes, and
data blocks.
The super block describes the overall structure of the file system
within the logical volume. It contains the file system name, the size,
pointer to the inode and free block lists, etc. The super block is used
to keep track of the file system state during operation. Super block
information is also used to verify the integrity of the file system as
part of the boot process and in the event of a failure.
E ach directory and file in the file system is represented by an
inode. The inode can be thought of as an index entry. Each inode is
sequentially numbered from 1 up to the maximum number of inodes
defined for the file system. The inode identifies the attributes of the
file or directory it represents.
File mode
File type
Owning UID and GID
Date and time stamps
Number of links
Pointer to data blocks
Size in bytes
Size in blocks
The number of inodes created for file systems is based on the size of
the file system. The native AIX JFS file system doesn't permit granu­
lar control over the number of inodes allocated. This means more
wasted space for file systems that will contain a small number of very
large files-for example, databases. Each JFS inode is mapped to a 4KB block. You can list the inode numbers associated with files and
directories using the i flag to the 1 s command.
Disks and File Systems
# ls - a i l F
total 1 0 8 8
- rwx25
- rwxr-x-21
- rwxr-x-24
deroe s t
deroes t
deroes t
deroe s t
sys tem
sys tem
sys tem
sys tem
15 : 03
13 : 1 9
. .I
. forward*
. kshrc *
. l ogin*
I nformation for a particular inode can be displayed using the
i s tat command.
# i s t a t 25 / dev/hdl
Inode 25 on device 1 0 / 8 F i l e
Protec t i on : rwxOwner : 4 0 8 4 ( deroe s t ) Group : O ( sys tem)
Link count : 1 Length 27 bytes
Last updated :
Tue Apr 2 0 0 8 : 1 5 : 5 0 1 9 9 3
Mon Jan 1 1 1 4 : 0 1 : 2 4 1 9 9 3
Last modi f i ed :
Last acces sed :
Fri Aug 2 0 0 0 : 0 0 : 3 9 1 9 9 3
Block pointers :
To find the file name associated with the inode number use the
- inum flag with the f ind command.
# f ind /home -xdev - i num 2 5 -print
/home / deroes t / . forward
Data blocks are used to store the actual file data in the file system.
Each inode contains 13 data block address slots. The first 8 address
slots point at the first 8 file data blocks of the file. The 9th address
points to an incore inode structure. The disk inode information is
copied to this structure when the file is opened. The 10th through
13th addresses point to indirect data blocks which are used to address
data blocks for large files. Each indirect block supports 1024 address­
es. Because file addressing is restricted to 32 bits, third-level indirec­
tion is not used.
Virtual flle system
AIX V3 supplies a generic file system interface called the virtual file
system (VFS) that permits it to support a number of file system types.
VFS is an abstraction of the underlying physical file system mount
structure, inodes, and operations.
The underlying physical file system is represented in VFS by a
generic mount structure and an array of operations permitted on the
physical file system called v f s ops . VFS uses a paired abstraction of
vnode s and gnodes to reference the underlying file system inode
structures. One or more vnode structures reference a gnode which is
linked to the real inode. VFS operates on the underlying inodes using
vnode operations called vnodeops VFS-supported file system types
are defined in / e t c / v f s .
System Configuration and Customization
/ etc /vfs
i @ ( i ) vf s @ ( i ) 7 7 1 . 2 0 c om/ c f g / e t c /vfs , bos , bos 3 2 0 6 / 7 / 9 1 0 7 : 4 7 : 3 0
( C J COPYRIGHT Interna t i onal Bus ine s s Machines Corp .
Al l Rights Res erved
Licensed Material s-Property of I BM
1985 ,
us Government Users Res t r i c ted Rights-Us e , dup l ication or
di s c l osure res tric ted by GSA ADP Schedu l e Contrac t wi th IBM Corp .
thi s f i l e describes the known virtual f i l e sys tem implementations .
format : ( the name and vfs_number should match what is in
<sys /vmount . h> )
The s t andard helper directory is / etc / helpers
name vf s_number mount_helper f i l sys_helper
Uncomment the f o l l owing l ine to spec i fy the local or remote defau l t
vfs .
%defau l tvfs j f s n f s
j fs
/ sbin/helper s /n fsmnthe lp
/ sbin/ helpers /v3 f shelper
remot e
Journaled file system configuration
The native file system in AIX. V3 is a log-based file system called the
journaled file system (JFS). Log-based file systems like JFS improve
recovery by maintaining a circular update log. In the event of a fail­
ure, the JFS log is replayed to recover the file system state. Log
recovery of a file system is completed orders of magnitude faster than
a full f s c k walk of a file system. AIX. provides the f s ck to assist in
disaster recovery; however, it is not invoked as part of the standard
boot procedure.
When a JFS file system is created, a log logical volume is also cre­
ated if it does not already exist. A log logical volume can support sev­
eral file systems within a volume group.
Create or update a JFS file system using the SMIT fast path or the
c r f s and chf s commands. A new JFS file system may be created in
an existing empty logical volume, or a new logical volume will be built
to hold the new file system (see Fig. 8.8). Be careful when specifying
the size of the file system! File system blocks are 5 12 bytes in size.
The general rule of thumb is as follows:
Block size
5 12
Updating new or existing file system size
AIX commands that report file system use
Managing logical partitions for logical volumes
*Default logical partition size.
Disks and File Systems
1 17
Add a Journaled F i l e Sys tem
Type or s e l e c t values in entry f i elds .
Press Enter AFTER making a l l des ired changes .
Volume group name
* S I ZE o f f i l e sys tem ( in 5 1 2 -byte bl ocks )
Mount AUTOMATICALLY at sys t em restar t ?
Start D i s k Accounting ?
F l = Help
F 5 = Undo
F9 = Shel l
Figure 8.8
F2 = Re f resh
F 6 = Command
F l O = Exi t
F3 = Cance l
F7 = Ed i t
Enter = D o
[ Entry F i e l ds ]
roo tvg
[ 500000 ]
[ /myj f s ]
read/wr i t e
F4 = Li s t
F 8 = Image
SMIT add journaled file system panel.
If it was any clearer than this, it wouldn't be UNIX, and it sure
wouldn't be AIX.
# c r f s -v j fs -g uservg l -m /u4 -a s i z e = 1 0 4 8 5 7 6
SMIT crj fs
The file system attributes are recorded in the ODM custom data­
bases and the / e t c / f i l e sys t ern file . You may want to edit the
/etc/filesystems entry for the new file system to implement accounting
or disk quotas (see Chaps. 2 1 and 23).
/ etc /filesystems
* ORIGINS : 2 7
( C ) COPYRIGHT Interna t i onal Bus iness Machines Corp .
A l l Right s Reserved
L i c ensed Materials-Property of I BM
1985 ,
US Government Users Res t r i c ted Rights-Us e , dup l icat ion or
dis c losure restricted by GSA ADP S chedu l e Contrac t with I BM Corp .
Thi s vers ion of / etc / f i lesys t ems as sumes that only the root f i l e
sys tem is created and ready . As new fi l e systems are added , change the
check , mount , free , l og , vol and vfs entries for the appropriate
s tanz a .
/ dev/hd4
j fs
System Configuration and Customization
vo l
/ dev/hd8
automa t i c
boo t f s
/home :
vf s
vo l
/ dev /hdl
j fs
/ dev/hd8
/usr :
vo l
/ dev/hd2
j fs
/ dev/hd8
automa t i c
boo t f s
/ var :
vo l
/ dev/hd9var
j fs
/ dev/hd8
automa t i c
boo t f s
/ tmp :
vo l
/ dev /hd3
j fs
/ dev /hd8
automa t i c
/ tmp
/mnt :
vo l
v fs
/ dev/hd7
" spare "
j fs
/ dev/hd8
/blv :
vo l
/ dev/hd5
" spare "
j fs
/ dev / hd8
Disks and File Systems
/usr /bin/blv . f s :
= /usr /bin/blv . f s
vo l
= "/"
/us r / lpp / in f o / En_US :
/usr / lpp / info / En_US
fracio . geo . meca . com
nf s
opt ions
ro , bg , hard , intr
You may remove a file system using SMIT or the rmf s command.
41 rmf s /n5
Remove file system /n5
41 smi t rmj f s
Mounting file systems
File system data is made accessible by mounting the file system on a
mount point. The mount point is a directory in a previously mounted
file system like the root file system. You might think that this is a
"chicken and egg'' problem; however, the boot procedure handles the
special case of mounting the r o o t file system (see Chap . 5). The
mount point is usually an empty directory, but that is not a require­
ment. If you mount a file system over a populated directory, the pre­
vious subdirectory tree is not harmed, but it is no longer accessible
until the file system has been unmounted.
File systems may be mounted or unmounted from SMIT or using
the mount and umount commands. (See Fig. 8.9.)
Mount a F i l e Sys t em
Type or s e l e c t values in entry f i e l ds .
Press Enter AFTER making a l l des ired changes .
DIRECTORY over which to mount
TYPE of f i l e sys tem
FORCE the moun t ?
REMOTE NODE containing the f i l e sys tem to mount
Mount as a REMOVABLE f i l e sys tem?
Mount as a READ-ONLY sys tem?
Disal l ow DEVICE access via thi s moun t ?
D i s a l l ow execution o f SUID and s g i d programs in thi s f i l e sys tem
F l = Help
F5 = Undo
F9 = She l l
Figure 8.9
F2 = Re fresh
F 6 = Command
F l O = Ex i t
F3 = Canc el
F7 = Edi t
Enter = Do
SMIT mount file system panel.
F4 = L i s t
F8 = Image
[ Entry Fie lds ]
1 20
System Configuration and Customization
# mount / dev/hd5 /n5
Mount /dev/hd5 on /n5
# umount /n6
Unmount file system /n6
# smi t mount f s
You cannot unmount a file system that is busy. A file system is busy
if any application has a file or directory open. This can be caused by an
executing process or a user whose current directory path is within the
file system. Use tools like fuser and the public domain l s o f com­
mands to identify which processes and users have files open.
AIX open file listing
# fuser -u / dev/hdl
/ dev/hdl :
3 2 6 0 5c ( deroe s t )
4 3 1 0 0 c ( deroes t )
4 7 0 2 9 ( root )
Public domain open file listing
# l s o f / dev/hdl
/home ( / dev/ hdl )
/home ( / dev/ hdl )
/ home ( ! dev/ hdl )
Specify which file systems are to be mounted automatically at boot
time by adding the mount
automatic or mount
true parameters
for each file system stanza in the I e t c / f i l e sys tems .
File systems may also be identified as a group by adding a type
<name> parameter for the group in / etc / f i l e sys t ems . The group
name can then be used to mount or unmount all the file systems in
the group from a single command.
# mount -t n f s
Mount all file systems in /etc/filesystems with type
To display the currently mounted file systems and their state use
the df and mount commands.
# df -v
File system
Total KB
% used
% iused
Mounted on
/ dev/ hd4
/ dev/ hd2
/ dev /hd9var
/ dev/hd3
/ dev/ hdl
/ dev/ lv02
9093 12
2 1876
8 13052
1 11080
8 1819
/ var
/ trnp
/ home
/ inst . images
# mount
Disks and File Systems
1 21
ovg;r vfs
j fs
Aug 2 3
12 : 53
rw , log = / dev/ hd8
j fs
Aug 2 3
12 : 53
rw , log = / dev/hd8
/ dev/hd4
/ dev/ hd2
/ dev/ hd9var
j fs
Aug 2 3
12 : 53
rw , log = / dev/hd8
/ dev/hd3
/ tmp
j fs
Aug 2 3
12 : 53
rw , l og = / dev/hd8
/ dev/ hdl
j fs
Aug 2 3
12 : 55
rw , log = / dev/hd8
/ dev / lv02
/ in s t . images
j fs
Aug 2 3
12 : 55
rw , log = / dev / l oglv
AIX root tree
The root file system tree was reorganized with version 3 . 2 of AIX.
This was done to organize the data types in the root file system tree
to facilitate mounting and maintenance. It also improves compatibili­
ty with root trees available on other UNIX platforms. For backward
comparability sake, AIX 3 . 2 incorporates symbolic links emulating
the old 3 . 1 root file system tree.
The AIX 3.2 root file system tree groups operating system files into
the following structure:
AIX 3.2
/ e tc
/usr /bin
/usr / l ib
/ u s r / sbin
/ sbin
/ dev
/ tmp
/ var
/ home
/ export
AIX 3. 1 Link
Root mount point and superuser shell files
Machine-dependent configuration files
Shared executables and files
/ l ib
Executables and files needed to boot and mount /usr
Device special files
Temporary work files
Machine-dependent logs and spool files
User home directories
Server files exported to remote clients
Paging Space
Paging (swap) space is used by AIX to support virtual memory ser­
vices. When free memory becomes low or exhausted, AIX moves data
pages from primary storage to the paging areas based on a least­
recently-used algorithm. A threshold is maintained for virtual memo­
ry usage by the operating system. When the threshold is exceeded a
S IGDANGER signal is sent to all processes. If a second threshold called
the kill level is exceeded, then the operating system sends S I GKILL
signals to the biggest memory offenders. This process continues until
memory utilization falls below the threshold levels.
In order to keep this kind of trouble from occurring, you need to
make sure that sufficient paging space is available. How much is
1 22
System Configuration and Customization
going to depend on your system use profile. What are the average
working set sizes required by your work load? Multiuser systems run­
ning a number of processes with large working sets may require two
or more times the available real memory as paging space. A single­
user workstation can get away with far less, depending on available
real memory and disk. Paging space is allocated as paging logical vol­
umes. You can split up paging space as separate logical volumes on
separate physical disks to improve paging performance. Try to limit
paging partitions to one per physical disk.
Paging logical volumes can be managed using SMIT or the rnkps ,
chps , and rrnps commands. Note that you must deactivate a paging
logical volume and reboot the system before you can remove it. You may
increase paging logical volumes while they are active (see Fig. 8. 10).
II mkps
Add a new paging area
II chps
Increase the size of a paging area
II rmps
Remove a paging area
II smi t mkps
New paging areas may be activated with the system up, using
SMIT or the swapon command. Paging areas that are activated by a
swapon - a are identified in the / e t c / swapspaces file.
II swapon - a
/ e t c / swapspaces
* / et c / swapspaces
* This f i l e l i s t s a l l the paging spaces that are automatically put into
* service on each system restart ( the ' swapon -a ' command executed from
* / e t c / re swaps on every device l i s ted here ) .
* WARNING : Only paging space devi ces should be l i s t ed here .
* Thi s f i l e is modi f i ed by the chps , mkps , and rmps commands and r e f ­
* erenced b y the l sps and swapon commands .
Add Ano ther Paging Space
Type or s e l e c t values in entry f i e lds .
Press Enter AFTER making a l l desi red changes .
Volume group name
S I Z E o f paging space ( in logical par t i t i ons )
Start us ing this paging space NOW?
Use thi s paging space each t ime the sys tem is RESTARTED
F l = Help
FS = Undo
F9 = She l l
Figure 8.1 0
F2 = Re fresh
F 6 = Command
F l O = Ex i t
F 3 = Cancel
F7 = Edit
Enter = Do
SMIT add paging space panel .
F4 = L i s t
F 8 = Ima.,ge
[ Entry Fi elds ]
Disks and File Systems
1 23
hd6 :
dev = I dev / hd6
hd6 1 :
dev = / dev /hd6 1
paging O O :
dev = / dev/paging O O
To display the current allocated paging logical volumes use the
l sps command.
ll l sps -a
Page Space
pag ing O O
hd6 1
%Used Ac t ive
Phys ical Volume Volume Group S i z e
fuj ivg
4 0 0MB 2 9
hdi s k2
4 0MB
hdi skl
4 0MB
hdi skO
Auto Type
Occasionally stale pages from processes are left on the paging logical
volumes. To clean up paging space, use the s l ibc l ean<n> c ommand .
ll s l ibc l ean
Clean up paging space
Volume Maintenance
Other than the cases of reducing the size of existing file systems or
paging areas, the AIX LVM and JFS systems make disk management
a breeze. It's the "other than" cases that still require a bit of work.
Moving file systems
File systems may be moved within a machine, provided there is suffi­
cient free disk space. If you are short on disk space, follow the proce­
dure as described in Sec. 8.9.3 concerning resizing file systems. To
migrate the file system logical volume to a new location, use the
migrat epv command or the SMIT pv fast path.
1 . Use l s lv to identify the current logical volume location and pro­
duce a physical disk map.
2. Use the migratepv
to move the logical volume to its new loca­
Moving volume groups
You can also move a volume group from one system to another using
the exportvg and importvg commands or from using SMIT vg fast
1. Unmount all the file systems and deactivate any paging areas con­
tained in the volume group to be moved.
2. Export the volume group using exportvg .
1 24
System Configuration and Customization
3. Move the physical disks containing the volume group to the new
4. Import the volume group on the new system using importvg . All
table references will be updated automatically.
5. Mount the file systems and active paging space on the new system.
Resizing file systems
Increasing the size of a file system, logical volume, or volume group
can be done on the fly with SMIT as described in the previous sections.
To decrease the size of a file system requires doing things the old-fash­
ioned way: back up the file system, recreate it, and restore the backup.
It gets even trickier if you are resizing one of the operating system file
systems, like /usr . Let's use / u s r as an example since it's a worst­
case scenario. The prqcedure is also a bit different on AIX 3 . 1 .
Before you begin, if you will b e using tape a s a backup device, make
sure that the block size is set to 5 12.
II chdev - 1 rmt O - a block = 5 1 2 - T
AIX 3. 1
1. Back up old / u s r .
II f ind / u s r -print
backup - ivf / dev/ rmtO
2. Shutdown to maintenance mode.
II shutdown -Fm
II export LANG = C
3. Remove the old / u s r file system.
II umount /usr
II rmf s /usr
4. Create new /usr file system. The new <size> is specified in logical
partition units.
II mklv -yhd2 -a ' e ' rootvg < s i z e >
II c r f s -vj f s -dhd2 -m ' / usr ' -Ayes -p ' rw '
II / e t c / mount /usr
5. Restore the / u s r backup.
II restore -xvf / dev/ rmtO
AIX 3.2
Disks and Fiie Systems
1 25
1. Export any non-rootvg volume groups. This makes for peace of
# exportvg <VGname>
2. Invoke mks z f i l e to create a . f s . s i z e table of the current file
system attributes.
# mk.s z f i l e
3. Edit the . f s . s i z e and set the new size for / u s r . Remove any
non-roo tvg file systems if any are present in the file.
rootvg 4 hd2 / u s r 1 0 4 0 j f s
The number 1 0 is the number of logical partitions and the num­
ber 40 is the size in megabytes. MAKE CERTAIN YOU LEAVE
4. Create a roo tvg backup using mksysb .
# mksysb / dev/ rmtO
5 . Reboot the system from the maintenance diskettes. After the AIX
3 . 2 Ins ta l l a t i on and Maint enanc e menu is displayed, select
2 "Install a system that was created with the SMIT Backup the
Sys tern'' function or the mksysb command. Follow the instructions
for selecting the restore device.
6. Reboot the system after the restore is complete and import the
non-roo tvg file systems that were exported in step 1.
# importvg <VGname>
8.1 O
Troubleshooting disk hardware, LVM, and file system problems usu­
ally require intimate knowledge of the event history leading to the
problem. For hardware problems:
Check cabling
Check SCSI terminator
Check SCSI ID jumpers or switch settings
Run diagnostics from the diagnostic diskettes or using diag
AIX V3. 1 and, to some degree, AIX V3.2 had problems with SCSI
disks that auto-spinup when powered on. AIX likes to request spinup
as part of identifying the device. Disable the hardware auto-spinup if
1 26
System Configuration and Customization
For LVM related problems, try resynchronizing the ODM and con­
figuration table entries by exporting the problem volume group fol­
lowed by an import. You can narrow down the problem area by using
1 s 1 v to display logical volume attributes and maps.
If a file system has become corrupted, take the file system off-line
and run the f s c k command. f s c k will walk the file system struc­
tures and identify problem entries or chains. In . an emergency situa­
tion (no backups), you can use the file system debugger to modify
super block and inode entries. Do not try this one unless you are very
familiar with these structures.
Occasionally a volume-group-related ODM update may abort, leav­
ing the volume group locked. To unlock a volume group , issue a
get lvodm , put lvodm sequence using the volume group name as an
# put lvodm -K ' get lvodm -v roo tvg '
8.1 1
8.1 2
Unlock rootvg
lnfoExplorer Keywords
/ etc /vfs
c fgmgr
roo tvg
/ etc / f i l e sys t ern chps
l spv
/ et c / swapspaces
rni rgratepv
get lvodm
l sp s
l svg
put lvodm
rrnf s
s l ibcl ean
i s tat
mks z f i l e
varyo f fvg
f ind
External SCSI drives may be added while the system is on-line.
c f gmgr
Configure disks added after IPL
Diagnostic, certify, and format routines. May also be invoked from diag
Volume groups:
Before a disk may be used, it must have a PVID and be a member
of a volume group.
Disks and Fiie Systems
mkdev - 1 <hdis k ? > -a -pv = yes
Create a PVID
mkvg -f -y <VGname> <hdi sk? hdi sk ? >
Create a VG
l svg
List VG
extendvg - f <VGname> <hdisk>
Add to a VG
varyonvg /varyo f fvg <VGname>
VG on-line/off-line
importvg / exportvg <VGname> <hdi s k ? >
Import/export VG
exportvg <VGname>
Export a VG
putlvodm -K ' ge t lvodm -v <VGname> '
Unlock a VG
1 27
Journaled file system:
File systems may be quickly created from an existing VG by
invoking SMIT c r j f s .
smi t crj fs
Create JFS
/ e tc / f i lesys t ems
File system attributes
mount ,
Mount/unmount file sys
fuser ,
Locate open files
Logical volumes:
Custom file systems may require that a logical volume first be
created using SMIT mkl v . The file system may then be created in the
new logical volume.
smi t mklv
Create LV
l s lv
List LV
Paging space:
smi t mkps
Create page space
l sps - a
List page space
swapon - a
Active all page space
Term i nals and M odems
Terminal Types
We've come a long way from the days when the term "TTY" referred
to a real teletype device. I remember the satisfaction of finally leaving
the card punches behind and getting access to the teletype lab in my
undergraduate days. TTY is now loosely used to describe everything
from serial cathode ray terminals (CRT) to software-driven pseudo­
TTY (PTY) devices. The attributes and configuration options associat­
ed with these devices quite often overlap. In many cases, the termi­
nology used to describe these attributes are holdovers from the tele­
type days. Add to this mix vendor enhancements and you end up with
what can be a fairly confusing configuration and management task.
Serial TTY Support
One might think that a well-seasoned specification like RS-232D
wouldn't still be causing so much grief. I know that a good deal of my
gray hair has come from sweating over a soldering iron and a break­
out box in the wee hours of the morning, trying to get those old TTY
and modem connections up and running on the new box in town.
First comes cabling. Common RS-232C interfaces use DB25 or DB9
male and female connectors. Signal direction and the wiring configu­
ration at each end of the cable depend on whether you are connecting
to a data terminal equipment (DTE) or data communication equip­
ment (DCE) device. DTE devices are usually workstations or termi­
nals. DCE devices are most often modems (modulator/demodulator)
devices used for dial-up service. Only a subset of the EIA-CCITT defi­
nition signals are used in most instances (see Table 9. 1).
1 29
1 30
System Configuration and Customization
EIA CCITT Interface Signals
Frame ground
Transmit data
Receive data
Request to send
Clear to send
Data set ready
Signal ground
Data carrier detect
Data terminal ready
Ring indicator
Positive voltage = 0, Space
Negative voltage = 1, Mark
If you want to do things strictly by the gospel according to IBM, you
can order the following cables, and save yourself a bit of work with
the solder gun. The native S l and 82 ports on the back of vintage
RS/6000 system units feature a 10-pin modu interface similar to the
IBM RT/PC (see Fig. 9. 1).
Modem/DCE wiring
AIX. assumes a DCE (modem) interface by default. These interfaces
require a 10-pin modu to DB25 adapter, PN#59F3740. You can then
attach async cable PN#6323741 feature code 2936 or any standard
DB25 connector. Newer RS/6000s provide standard DB25 interfaces.
This is all you need if you are going to plug in a DCE device-for
example, a modem (see Fig. 9.2).
Modem connections have to see DCD. If carrier is lost on the line,
they must hang up the connection. There are many horror stories of
modems not hanging up the line on a long distance call, resulting in
phone bills larger than the national debt.
Figure 9.1
Ten pin modu to
DB25 pin-out.
Terminals and Modems
1 31
Figure 9.2
DTE to DCE pin-out.
ITV/DTE wiring
A DTE device, like a TTY or printer, will require a null modem cable
or adapter. IBM calls this a terminal /printer interposer, PN#58F2861
feature code 2936. A null modem cable basically connects the trans­
mit line from one end of the connection to the receive line on the
other, and vice versa, to support DTE to DTE communication. You
may also need to wire hardware flow control lines as well.
Most terminals don't use RTS/CTS handshake signals, although
this is not a hard and fast rule. There are some vendors that require
an RTS/CTS handshake to jump start connections before commencing
data flow. DSR and RI are only useful for modem connections. AIX
assumes a DCE port by default. This means the host will expect to
see DCD go high (+ 12v) before it will start sending data. For a termi­
nal connection, the DTE-to-DTE pin-out configuration in Fig. 9.3 will
satisfy the DCE DCD/DSR condition by raising these lines when the
terminal exerts DTR.
You can reduce the number of signal lines required by using soft
carrier. Soft carrier is a term referring to software pretending that
DCD is present. To use soft carrier, you can add clocal to the stty set­
tings defined for the port via SMIT. We will look at SMIT definitions
a little later. Using soft carrier, you should be able to run your termi­
nal with the wiring configuration shown in Fig. 9.4.
:J .
Figure 9.3
DTE to DTE null
modem pin-out.
1 32
System Configuration and Customization
Figure 9.4
TTY pin-out.
For twisted pair wiring, use one pair for data send, and one pair
for data receive. The second wire in each pair should be connected to
ground. This will compensate for voltage spikes on the line. For a
safe connection, the shield should be connected to frame ground on
one end only. If your terminal type requires an RT8/CT8 handshake
to jump start the connection, bridge the RT8/CT8 together on the
device end. This configuration works very well with RJ1 1/RJ45 to
DB25/DB9 modular connectors. These modular connectors can then
be used with factory-terminated RJ1 1/RJ45 flat cables. This type of
connection will allow you to move things around quickly and easily
by unplugging the cable from the adapter without having to remove
adapter screws.
Serial cable length
How far can these cables be run? According to EIA-232D, cables
should not exceed a length of 200 ft, providing they do not exceed a
load of 2500 pF (picofarads). The lower the capacitance, the longer the
cable. The length is also somewhat dependent on baud rate. As stan­
dards tend to be on the conservative side, in practice you can run
cables much farther than 200 ft. I've run cables over 500 ft, but if
you're nervous about playing fast and loose with standards, you can
use a short-haul modem or mux to boost the signals.
Port addressing
You may notice some ambiguity concerning port and adapter names.
The first planar serial port, marked "81," is referred to as location
"00-00-81-00," parent adapter "saO," and port number "sl." The sec­
ond serial port labeled "82" follows as location "00-00-82-00," parent
adapter "sal," and port number "s2."
TTY location addressing:
Planar, drawer, or expansion and slot number
BB :
Bus and slot number
Adapter connector number
Port number
Terminals and Modems
1 33
AIX TTY Definition
Now that the device is cabled and connected to the system unit, define
the TTY device characteristics to the operating system. AIX TTY
device attributes are stored as ODM objects. The type of information is
similar to what you may be used to seeing in the BSD / e t c / t tys ,
/ et c / t tytype, and / et c / get tytab files, or the SYSV / e tc / in i t ­
t ab, / et c / ge t tyde f s , and / etc / get tytab files. Like SYSV, AIX
sets the initial boot state of each TTY in I etc I ini t tab.
To define or modify TTY attributes, invoke SMIT or use the mkdev
command. Considering the number of parameters that must b e
defined, i t will b e easier to use SMIT.
If you are adding or updating a large number of devices, add one
device via SMIT and then use the $ HOME / smi t . s c r ipt file as a boil­
erplate shell script for defining the remaining devices. E dit the
smi t . s cript file and look for the mkdev line used to configure the
first device. Remove any old commands and text from previous SMIT
runs. Duplicate the mkdev line and update the address information
for each new device . Save the file and execute it to configure the
remaining devices. This approach is quite useful when configuring
terminal servers and concentrators. For best results, make sure the
device is powered up during configuration.
# smi t makt ty
# mkdev <op t i ons>
When updating an existing TTY port, use the SMIT fast path,
chgt ty . The configuration menu contains the same parameter list as
makt ty with the exception that the existing port number and location
are displayed.
# smi t chgtty
The SMIT menu will display the list of TTY attributes which must be
customized for the device type. (See Fig. 9.5.)
You will need to supply the default line speed, data format, termi­
nal type, control characters, line discipline, and login state. SMIT fills
in the fields with default information which will assist you in deter­
mining the type and format of the data to be supplied.
Line speed
Line speed is also called baud rate. This is the bits-per-second band­
width between devices across the wire. Setting this entry is usually
straightforward in cases where a single data rate is specified for the
device. It gets a little trickier when you want to support multiple data
rates for dial-in connections. Supporting multiple data rates is called
1 34
System Configuration and Customization
Add a TTY
Type or s e l e c t values in entry f i e lds .
Press Enter AFTER making a l l des ired changes .
[ TOP ]
TTY type
TTY inter face
Des cription
Parent adapter
PORT number
Enable LOGIN
BAUD rate
BITS per character
Number o f STOP BITS
TIME before advanc ing to next port s e t t ing
XON-XOFF handshaking
INTERRUPT charac ter
QUIT character
ERASE character
KILL charac t er
END OF F I LE charac t e r
END OF LINE character
2 nd END OF LINE charac ter
L ITERAL NEXT character
START character
STOP character
WORD ERASE character
REPRINT L INE character
DISCARD character
INPUT map f i l e
OUTPUT map f i l e
CODESET map f i l e
STTY a t t r ibut e s f o r RUN TIME
STTY a t t r ibutes for LOGIN
RUN she l l ac t ivi ty manager
Opt i onal LOGGER name
STATE to be configured at boot t ime
F l = Help
F 5 = Undo
F9 = Shel l
Figure 9.5
F2 = Refresh
F 6 = Command
F l O = Ex i t
F3 = Cance l
F7 = Edi t
Enter = Do
[ Entry F i elds ]
t ty
rs 2 3 2
Asynchronous Terminal
di sable
( 9600 ]
[ none ]
[ dumb ]
[ Ac ]
[ Ah l
[ AU ]
[ Ad i
[A' I
[ Ay ]
[ AV ]
[ Aq ]
[ As]
( AW ]
[ Ari
[ Ao ]
[ none ]
[ none ]
[ sbc s ]
[ hupc l , c read , brkint , i cr>
[ hupc l , c read , echoe , c s B , >
[ avai l able ]
F4 = Li s t
F B = Image
SMIT add a TTY panel.
autobaud. Autobauding allows the port to cycle through a range of
baud rates on a time slice basis or when control break is received on
the line. Each data rate is tried until the line speed matches that of
the connecting device.
To get autobauding working on the RISC System 6000, enter the
desired baud rates separated by commas into the BAUD rate field.
Note that they can be entered in any order. Set the T IME be fore
advancing t o next port s e t t ing to the number of seconds to
wait before cycling to the next baud rate in the list. If the user does
Terminals and Modems
1 35
not enter a login ID before the time slice expires, or sends a control
break (ESC), then the next baud rate in the list is tried. The system
will continue to cycle through the list until the list is exhausted or the
user successfully logs in. If the cycle time is set to "O," manual control
breaks are required to cycle through the list.
BAUD rate ( 3 0 0 , 1 2 0 0 , 2 4 0 0 , 4 8 0 0 , 9 6 0 0 ]
TIME before advanc ing t o next port s e t t ing [ 6 ]
Data format
When characters are sent across the wire, they are framed into
sequences of bits which enables the hardware and software to vali­
date the data. Each frame is constructed of the data bits followed by a
number of stop bits and parity. The most common selections are
PARITY [ none ] -or- [ even ]
BITS per character [ 8 ]
Number o f STOP BITS [ 1 ]
There are also a number of compression and error-checking protocols
that may be used to send more data across the wire. These techniques
are handled by the hardware and do not require configuring into the
operating system.
Terminal type
If it is known that a particular terminal type will always be using the
port, you may define the terminal name in the TERMINAL type field.
The name used must match an entry in the SYSV terrni n f o and
optionally B S D t e rm c a p file s . E ach of the s e files defines the
attribute character strings which are used by AIX to initialize and
control terminal attributes.
For modem connections, you may not know the terminal types that
will be connecting to the system. I recommend selecting a terminal type
of dumb, in this instance. This notifies AIX to use very rudimentary ter­
minal control when the connection is established. Use the t s e t com­
mand in the . pro f i le, . login, or shell . re scripts to query the termi­
nal type after the user logs onto the system. tset can negotiate most of
the common terminal types connecting to your system. In the case that
it is balled, it will prompt the user to enter the terminal type and may
also be configured to supply a default suggested type. After terminal
type negotiation is complete, l ogin stores the type in the TERM environ­
ment variable for use by the various shells and commands.
The following example can be used in a . pro f i l e or . l ogin script
to prompt the user for a terminal type and suggest a default of vt l O O
if nothing is entered.
t s e t -m ' dumb : ?vt1 0 0 '
1 36
System Configuration and Customization
AIX interacts with your terminal type based on the characteristics
defined in the /usr / l ib / terminfo files. Entries in the terminfo are
identified by file name descriptors for various vendor terminal
devices. Field attributes for a particular terminal type describe the
special character sequences used to initialize the terminal, highlight
or underline text on the screen, identify function keys, etc.
The terminfo definitions for each terminal type are stored in binary
form. E ach terminal file i s l o c at e d in a sub dire ctory under
/usr/ l i b / t erminfo based on the first character of the file name.
Terminfo binaries are compiled from source code definition files by
using the t i c command. The terminfo source may also be extracted
from the binary file by using a public domain program like unt i e or
infocmp . Source code for the distribution terminal types is provided
in /usr / l ib / termin f o . Source files are identified by a . t i suffix
in the file name.
Sample terminfo source:
vt 1 0 2 l vt 1 0 0p l vt 1 0 0p-nam l dec-vt 1 0 0p l dec vtl O Op ,
am , mir , xenl ,
xon ,
c o l s# 8 0 ,
l ines #2 4 , v t # 3 ,
bel = AG , bl ink = \ E [ 5m$<2 > , bold = \ E [ lm$< 2 > ,
c l ear = \ E [ ; H\ E [ 2 J$ < 5 0 > , e r = \ r , c s r = \ E [ % i %p 1 % d ; %p2 %dr ,
cubl = \ b , cudl = \n , c u fl = \ E [ C ,
cup = \ E [ % i %p1 % d ; %p2 %dH$ < 1 0 > ,
dl l = \ E [ M ,
ill = \E [ L ,
cuul = \ E [ A , dchl = \ E [ P ,
ed = \ E [ J $ < 5 0 > , el = \ E [ K$< 3 > , home = \ E [ H , ht = \ t ,
ind = \ n , i s 2 = \ E [ l ; 2 4r \ E [ 2 4 ; 1H , kbs = \ b ,
kcubl = \ EOD , kcudl = \ EOB , kcu f l = \ EOC , kcuul = \ EOA ,
k f l = \ EOP , k f 2 = \ EOQ , k f 3 = \ EOR , k f 4 = \ EOS , r e = \ E B ,
rev = \ E [ 7m$<2 > ,
rf = /usr / l ib / tabse t / vt l O O ,
ri = \ EM ,
rmir = \ E [ 4 1 , rmkx = \ E [ ? 1 1 \ E > , rmso = \ E [ m , rmul = \ E [ m ,
r s 2 = \ E > \ E [ ? 3 1 \ E [ ? 4 1 \ E [ ? 5 1 \ E [ ? 7 h \ E [ ? 8h , SC = \E7 '
sgrO = \ E [m$<2 > , smir = \ E [ 4h , smkx = \ E [ ? lh \ E = , sms o = \ E [ 7m ,
smul = \ E [ 4m ,
AIX also supplies a rudimentary / et c / termcap file fo r use with
BSD applications. You can also convert termcap definitions into ter­
minfo source using the c ap t o i n f o program. The majority of the
termcap attribute identifiers map to terminfo identifiers; however,
there are some exceptions.
Sample termcap source:
vt 1 0 2 l vt 1 0 0p l vt 1 0 0p-nam l dec-vt 1 0 0p l dec vt l O Op : \
: am : al = \E [ L : bl = AG : bs : cd = 5 0 \ E [ J : ce = 3 \E [ K : c l = 5 0 \ E [ ; H\ E [ 2 J : \
: cm = 1 0 \ E [ % i % d ; %dH : c o # B O : e r = AM : c s = \E [ % i % d ; %dr : de = \E [ P : \
: dl = \ E [M : do = AJ : ei = \ E [ 4 l : ho = \ E [ H : im = \ E [ 4h : i s = \ E [ 1 ; 2 4 r \ E [ 2 4 ; 1H : \
: kl = \ EOP : k2 = \EOQ : k3 = \EOR : k4 = \ EOS : kb = AH : kd = \ EOB : ke = \ E [ ? l l \E> :
: kl = \ EOD : kr = \ EOC : ks = \ E [ ? lh \ E = : ku = \EOA : le = AH : l i # 2 4 : \
: rod = 2 \ E [ lm : mr = 2 \ E [ 7m : mb = 2 \ E [ 5m : me = 2 \ E [ m : mi : \
: nd = \ E [ C : nl = AJ : pt : rc = \ E 8 : rf = /usr / l ib / tabs e t / vt l O O : \
: rs = \ E> \ E [ ? 3 1 \ E [ ? 4 1 \ E [ ? 5 1 \ E [ ? 7 h \ E [ ? Sh : \
: sc = \ E 7 : se = \E [ m : s o = \ E [ 7m : sr = \ EM : ta = A I : ue = \ E [ m : \
: up = \ E [ A : us = \ E [ 4m : vt # 3 : xn :
Terminals and Modems
1 37
Control characters
The AIX TTY device drivers intercept a set of input control characters
defined by the termio interface which force execution of various ioctl
routines. These routines do things like start and stop screen display,
edit characters in the terminal input buffer, etc. You are probably
familiar with using CTRL-C to interrupt execution of a process,
CNTRL-Z to suspend a process, and CTRL-H to erase characters on
the command line. Thes e ar� examples of the interaction of the termio
control characters and the device drivers. In most cases you will want
to take the default character set presented by SMIT. These characters
can 1:1lways be overridden on an individual basis from the command
line or from login scripts using the s t ty command. The s t ty com­
mand allows you to tailor termio behavior for your session. s t ty will
be explained further in the following section on line discipline.
# s t ty -a
Display current termio setting
# s t ty erase A ?
Define ctrl-? as erase
Line discipline
You will need to define the default RUNTIME and LOGIN line disci­
pline options for each TTY port being configured. The LOGIN options
are those in effect when a connection is made and during login pro­
cessing. The RUNTIME options are those which control terminal 1/0
processing after login is completed, unless overridden by s t ty in the
login scripts or from the command line. (See Table 9.2.) In most cases,
you can accept the defaults provided by SMIT.
AIX supports layering multiple line disciplines via a stack. POSIX
line discipline is used by default. BSD line discipline is also available
and may be set as default or added to the stack. There are some prob­
lematic BSD options like cbreak that don't behave like you would
expect. Be advised that most of the AIX applications which control
TTY 1/0 expect POSIX.
# s tty di sp berk
Set BSD line discipline
# s t ty disp posix
Set POSIX line discipline
# s t ty add berk
Add BSD line discipline to the stack
Like the control characters described here, the line discipline options
control how TTY I/O processing is handled. Options are set and
queried using the s t ty command.
Login state
The Enab l e LOGIN parameter indicates how connections are estab­
lished to the TTY port after system boot is completed. Use LOGIN
1 38
System Configuration and Customization
i c rnl
opo s t
onl c r
i c anon
i exten
ixo f f
Hang up on close
Enable receiver
Signal INTR on break
Map CR to NL character
Process output options
Horizontal tab style
Map NL to CRNL
Check for INTR and QUIT characters
Canonical input with line editing
Echo input characters
Echo erase character
Echo NL and KILL cha:r:acter
Echo control characters
Echo KILL by erase
Echo bell on input full
Recognize other function data
Character size 8 bits
START/STOP handshaking on output queue
START/STOP handshaking on input queue
state to restrict the port to incoming, outgoing, or bidirectional data
traffic. This parameter is very important when setting up lines for
modem support. LOGIN state values include ENABLE , DISABLE ,
Use for direct-attach TTY or dial-in-only modem support. AIX
starts a getty process for each enabled port. The getty process
locks the port for exclusive use. An incoming connection negoti­
ates line speed and raises DCD. Upon detecting DCD, getty
presents a login herald on the connection. The connecting sys­
tem may now log in to AIX
Use for dial-out-only support. No getty process is started and
the port is available for dial-out applications like k e rmi t ,
a t e , etc.
Use for bidirectional support. AIX starts a g e t ty -u on the
port which does not lock the port until it sees the DCD signal go
high. The port may be locked and opened for use by other
processes. When DCD is present, but the port has been locked
and in use by another application, the getty process associated
with the port loops attempting to lock. If the port has not been
locked, getty will lock the port and present a login herald on the
line when DCD is asserted.
Similar to SHARE. A g e t ty - r is started on the line. Rather
than relying on the DCD signal to indicate a connection
request, getty waits for a character on the input buffer before
locking the port and presenting the login herald. The port is
available to other processes when not locked for use by getty.
Terminals and Modems
1 39
The initial TTY state for each port is defined in I e t c I ini t tab .
The inittab format is not what you may be familiar with in SYSV
UNIX, yet the information supplied is similar.
Sample / et c / ini t tab entry:
Forma t :
Ident i fi e r : run l evel : Ac t i on : CoIIUlland
t ty1 : 2 : o f f : / e t c / ge t ty / dev / t tyl
t ty2 : 2 : on : / e t c / ge t ty / dev / t ty2
Disable TTYl at multiuser
Enable TTY2 at multiuser.
Modem Support
In the previous sections describing TTY configurations, options asso­
ciated with DCE devices have been discussed. However, modems
require special attention.
Most modems come from the factory with settings that assume connec­
tion to a personal computer. The idea is to either strap signals high or
ignore them altogether to make life easier for the novice PC user.
Unfortunately these settings can cause real grief to UNIX systems.
Dial-up connections will require that the modem be set for autoan­
swer. For Hayes series modems, autoanswer is enabled by setting the
s o flag to value greater than zero. You will also need to set the TTY
port status to ENABLED, SHARED, or DELAY.
Answer incoming calls on the third ring
If the port state is set to ENAB LED or S HARE D , the getty
process will present a login herald when DCD is raised, due to
modem carrier detection on the wire. The modem should also hang
up and drop DCD when remote carrier disappears. This interaction
requires that the modem DCD signal follows the presence of the
remote carrier.
DCD signal follows remote carrier
If DCD is strapped high on the modem and command echoing is
set, this configuration will cause a getty race condition when the port
is enabled. The getty process sees DCD, so it locks the port and
asserts the login herald. The modem echoes back the login herald
which is interpreted as an inval i d login attempt; thus , getty
respawns and a new login herald is asserted. The modem echoes it
back. Get the picture? Make certain that DCD follows the carrier as
described, and if your applications don't require command echoing,
disable it!
Don't echo modem command strings
1 40
System Configuration and Customization
For you UNIX old-timers who still like to use t ip , you will need to
have the modem always assert DCD. If you intend to use the line for
both dial-in and dial-out connections , send the AT&C O command
string to the modem when you intend to use t ip .
Modem response strings can also cause problems if they are not set
to local only. The RING status sent to the port when an incoming call
is detected will be echoed back to the modem. The modem thinks
that it has received a command, so it dutifully hangs up on the
incoming call.
Disable command response strings
You want the modem to enable auto-answer and be ready to accept
commands when the RS/6000 presents the DTR signal on open() .
When DTR dropped o n close(), the modem should hang u p and reset
to accept new connections.
Hang up at DTR drop, reload default parameters
Making certain that DCD and DTR handshaking is working cor­
rectly will reduce the possibility of receiving a phone bill that rivals
the national debt.
In most cases, you will want to use hardware handshaking for
modem connections. For example, XON / XOFF flow control characters
will confuse UUCP checksumming. Unfortunately, AIX/6000 has been
notorious for dropping RTS / CTS hardware flow control settings at
each system boot. You can get around this problem by setting hard­
ware handshaking for each TTY port from the boot re scripts. From
the command line, use the standard s t ty command.
% s t ty add rts < / dev / t tyN
You might think you can just add this command to your boot .re
scripts. You'll want to think again. The s t ty call may block and hang
your system! Example code in App. B provides a quick and dirty C
program that will set r t s on the specified TTY device name without
blocking. You can get a version that will read a list of TTYs to set
from IBM Austin Support.
To debug or test TTY ports, connect the TTY device and enable the
port. You should see the login herald displayed on the screen. If the
login herald is not displayed, check the cable connections and wiring.
If you have a break-out box, add it to the cabling between the device
and RS/6000. These devices make it much easier to validate signal
Terminals and Modems
1 41
If the characters displayed are garbled, validate that the parity and
bit definitions for the TTY device are correct. Parity and bits per
character may also be a problem if the login herald is displayed but
input characters are not recognized.
For modem lines, you could try playing with ate or kermi t , but
these applications require a whole level of configuration in themselves.
I recommend using the simpler cu program. Disable the line if it isn't
already disabled. Add the following stanza to the / l ib / uucp / Devi ces
file for the serial port you are using. In the example, I'll assume
I dev I t tyO , a Hayes modem, and a 2400 baud line speed.
Direct t tyO - Any direct
ACU t tyO - 2 4 0 0 hayes \ D
After adding the port to / l ib / uucp / Devi c e s , you should be able
to connect to the modem using the cu command. Once connected, you
can begin sending commands to the modem.
# cu
1 / dev/ t tyO -b2 4 0 0
I f you have problems, add the - d flag t o the cu command to start a
diagnostic trace on the connection. If you can't connect, then check
the cabling and signals with a break-out box. If characters are gar­
bled, check the line speed, parity, data, and stop bits.
High-Function Terminals
High-function terminal (HFT) devices are a different sort of beast
from the serial-attached TTY devices I have described thus far. AIX
treats an HFT as an ASCII pseudodevice or virtual terminal that con­
sists of a combination of display, keyboard, mouse, dials, lighted func­
tion keys, and sound devices. These device options provide a wider
array of capabilities which must be configured . Primarily these
include the keyboard I display map, national language I locale, display
fonts, display color palette, and speaker sound level. There are enough
option combinations that you will likely spend more time trying to
decide what you want than defining them to the system. Fortunately,
you can play with them while the system is on-line. Most of the initial
configuration will be done when AIX is installed on the computer.
You must define a keyboard map for the type of locally attached key­
board in use on the RS/6000. The keyboard map reflects the location
and function of each key on the keyboard. AIX supports three key­
board types: the 101-key keyboard, the 102-key keyboard, and the 106key keyboard. The keyboard map is a table that defines the ASCII
character string transmitted by each key. The keyboard map tables
1 42
System Configuration and Customization
are located in the / u s r / l ib / nl s / loc directory. Entries in the key­
board map table are configurable as required by custom applications.
S o urce fi l e s for each keyb o ar d map table are l o c ated in the
/usr I l ib / n l s I loc directory and are identified by the . src suffix.
To create or modify a keyboard map, edit the source file as required
and execute the genxl t command to compile the code set. See the
InfoExplorer document or man page for the genxl t command for a
description of the format of the code-set source files.
# genxlt < codeset . src > cods e t . new
Keyboard maps are associated with the locale in use. The locale
defines the language and code set in use (see Table 9.3). Multibyte
code sets are not supported for HFT devices. To display the keyboard
maps available, use the l skbd command. Note that many of the com­
mands associated with HFT configuration must be entered from the
HFT primary device.
# l s kbd
To switch to a new keyboard map, use the mkkbd -n command to
make the map available for use, followed by the swkbd -v .
# mkkbd -n c odes e t . name
# swkbd -v c odes e t . name
You can also use the s e tmaps command to set, display, and debug
terminal and code-set maps. AIX-supplied terminal maps are located
in the /us r / l ib / nl s / termap directory.
# se tmaps
Display current map and code set
# setmaps -t tty-map
Set TI'Y map
# setmaps -s code-map
Set code-set map
Depending on your typing speed, you may wish to change the
default keyboard delay and repetition rate. The default delay rate is
500 ms and the repetition rate is 11 characters/s. The delay rate can
be set to 250, 500, 750, and 1000 ms. Repetition rate spans from 2 to
30 characters/s. To alter the delay and repetition rates, use the chh­
wkbd command.
# chhwkbd -d <delay> -r < repet i t i on>
You may also turn the keyboard key "click" on or off. I've never
understood why vendors enhance keyboard noise. Naturally, the
default state is keyboard click on. Use the chs ound command to tog­
gle keyboard click.
chsound - q
Silence is golden!
Terminals and Modems
AIX Locale and Code Sets
Code set
e l_GR
e s_ES
f i_FI
I s_I S
i s_I S
I t_IT
i t_IT
j a_JP
Danish, Denmark
Danish, Denmark
German, Switzerland
German, Switzerland
German, Germany
German, Germany
Greek, Greece
English, Great Britain
English, Great Britain
English, United States
English, United States
Spanish, Spain
Spanish, Spain
Finnish, Finland
Finnish, Finland
French, Belgium
French, Belgium
French, Canada
French, Canada
French, France
French, France
French, Switzerland
French, Switzerland
Icelandic, Iceland
Icelandic, Iceland
Italian, Italy
Italian, Italy
Japanese, Japan
Japanese, Japan
Dutch, Belgium
Dutch, Belgium
Dutch, Netherlands
Dutch, Netherlands
Norwegian, Norway
Norwegian, Norway
Portuguese, Portugal
Portuguese, Portugal
Swedish, Sweden
Swedish, Sweden
Turkish, Turkey
1 43
The RS/6000 supports a number of natively attached displays and
graphics adapters. There are some common parameters that may be
tailored that span most of these devices. These include the display
fonts, color palette for color displays, and cursor shape. You will have
to refer to the installation instructions for configuration options spe­
cific to the device. I can't keep up with IBM development fast enough
to list all the options here!
1 44
System Configuration and Customization
Display fonts
Display fonts are as religious an issue as favorite editors and operating
systems. The available HFT fonts are located in / u s r / lpp / font s .
You can get a list of the available fonts using the l s f ont command.
# ls font
You may define a default font palette which consists of up to eight
alternate font identifiers. Available font alternates are identified by a
number ranging from 0 through 8. To make a new font available, use
the mk f ont -n command.
# mkf ont -n f ontname . path
To list all the font identifiers available in the current font palette, use
the chfont - 1 command.
# chfont - 1
You may switch between alternates b y invoking c h fo n t
# chfont -as
Switch display font to alternate number 5
You may also set the display fonts and font palette using SMIT.
# smi t chfont
# smi t chfontpl
Display palette
Color HFT devices will support a palette of 16 colors from which fore­
ground and background display colors may be selected. Select the color
map from SMIT. Each color is represented as an integer from 1 to 16.
# smi t palettevalues
After selecting the palette colors, you may set the foreground (text)
and background color using SMIT.
# smi t backforg
You may also select one of six cursor shapes for the display (see
Table 9.4).
# smi t chcursor
Dials and lighted function keys
Dial and light programmable function (LPF) key pads are defined via
SMIT. A logical device name is associated with the parent adapter slot
and port number used by the device. Port values are either 1 or 2 for a
Terminals and Modems
1 45
Cursor Options
0 - no cursor
1 single underscore
2 double underscore (default)
3 - lower half character cell
4 - midcharacter dash
5 - full character cell
graphics adapter, or s l and s2 for the standard serial port. You may
also add a short text string that identifies the function of the device.
Speaker volume
To get a handle on the beeps and honks emanating from the RS/6000,
you need to set the speaker volume. Use the chs ound command to set
the speaker volume level. Volume selections include off, low, medium,
and high.
# chs ound - o
Turn sound off
Virtual terminals
AB I mentioned, an HFT device is a virtual terminal interface. The
AIX operating system supports up to 16 virtual terminal interfaces per
physical display. Each virtual terminal supports all the attributes of
an individual physical display. Under AIX, each virtual terminal ses­
sion controls distinct shells allowing the user to have up to 16 separate
application sessions active at one time. The open command is used to
initiate each new virtual terminal session. The user switches between
the virtual. terminal displays using the ALT RIGHT-CTRL keys.
# open she l l - name
To limit the maximum number of virtual terminal sessions allowed,
use the chnumvt command.
# chnumvt 1 - 1 6
I n most cases, the system console will either b e the primary display
or ttyO. You can redirect console output to another device or file using
the chcons and the swcons commands. The chcons command sets
the console path for the next system boot. The swcons command redi­
rects console output for the current session.
# chcons pathname
Switch output on next boot
# swcons pathname
Switch output now
1 46
System Configuration and Customization
To check the current console path use l s c ons .
# l s c ons
Console problems
If you are running a system without an attached console or sharing a
console between systems, make certain that you have the termio
option c l o c a l defined for the device. This inhibits console output
from blocking if the device is not available. You will end up with mul­
tiple s rcms t r daemons running if console output is blocked. This sit­
uation tends to confuse the srcms tr as the current state of any sub­
system it is controlling. Bad news!
In some instances, an HFT device can become hung or inhibit dis­
play output. If the HFT device is also the system console, this can be
a nuisance. In many cases, you can free a hung HFT by writing to
/ dev / h f t , directing an s t ty command sequence to the device, or
using the tpu t command. These techniques may also work with other
TTY devices.
# echo " Open Sez -A-Me " > / dev / h f t
# s t ty sane
# tput - Th f t c l ear > / dev/hft
Note that it may take around one minute for these commands to take
Pseudo-ITV Devices
It's difficult to decide where to talk about pseudo-TTY (P'rY) devices.
You will see texts discuss PTYs in relation to TCP/IP and Xl l appli­
cations . I thought it best to discuss them along with other TTY
devices, in that they exhibit many of the same characteristics.
A PTY device is represented by a pair of character device drivers in
a master/slave pair that implements a pseudo-TTY connection. The
master/slave pair may be operating on different systems in a network
or on the same computer. The master, / dev /pty side of the connec­
tion sends and receives data like a user at a real TTY. The slave,
I dev I t ty side of the connection provides the standard terminal
interface to applications such as login shells.
AIX implements two PTY interfaces. The default PTY type is
opened as / dev / p t c . The operating system allocates both the mas­
ter PTY and slave TTY devices, which eliminates the need for the
application program to test both sides of a PTY connection to deter­
mine if it is in use. The number of standard AIX PTYs is limited
only by the file table size (see App. B for sample C code to allocate
PTY pair).
Terminals and Modems
1 47
Chang e / Show Charac ter i s t i c s of the PTY
Type or s e l e c t values in entry f ields .
Press Enter AFTER making a l l des i red changes .
[ Entry Fields ]
[ avai l abl e ]
Number of BSD STYLE symbo l i c l i nks
STATE to be c on f i gured a t boot t ime
F l = Help
F5 = Undo
Figure 9.6
F2 = Re f resh
F 6 = Command
F3 = Cancel
F7 = Edit
F4 = Li s t
F S = Image
SMIT change TTY panel.
AIX also supports BSD-style PTYs for use with traditional BSD
applic ation s . This implementation consists of b o th master
/ dev / p ty [ p O - s f ] and slave / dev / t ty [ p O - s f ] special files. You
can create up to 64 BSD PTYs via SMIT (see Fig. 9.6). You may also
create additional BSD PTYs manually, using chdev .
# smi t chgpty
# chdev -1 ptyO
-a • num = 6 4 "
DOS TTY Definition
Since many of us are running DOS applications under pcsim on AIX,
I thought it would be useful to mention a few configuration options
and files involved in supporting modems and TTYs with pcsim. To
use pcsim with TTYs via direct connection or dial-in, make sure your
terminal key map is defined in the / u s r / lpp / p c s im/ t ty directory.
You can take a look at the default key maps supplied by IBM to get a
feel for what you need. If you are looking at purchasing TTYs for use
with pcsim, check to see if they support PC scan code. This allows a
TTY to emulate the 25-line monochrome PC screen, and, in many
cases, to support AT or PS/2 keyboards. This makes life much easier
for users unfamiliar with using key maps. You also need to initialize
pcsim for serial ports at boot time.
/ e t c / tty/ t tyconf -1 p c s im
See the lpp . README file in / u s r I lpp / pc s im for a description of ser­
ial port setup. Finally, to use a serial port as a COM port from pcsim,
use the following command when you start a pcsim session. Note
that, in this example, I dev I t tyO is the defined serial port.
p c s im - c oml / dev / t tyO
This information should alleviate some of the frustration involved in
getting a TTY or modem connection running on your AIX workstation.
1 48
System Configuration and Customization
At least you'll be able to keep all your hair and keep your family hap­
pier about your working hours. If nothing else, I wanted to present
enough basic information to get you pointed in the right direction. For
more information, go ahead and plow through the InfoExplorer docu­
mentation. I would also recommend UNIX System Administration
Handbook, by Evi Nemeth, Garth Snyder, and Scott Seebass (Prentice
Hall). If you have an IBMLink connection, there are a number of good
"HOWTO" memos covering TTY and modem topics an all the AIX plat­
forms. Good luck!
lnfoExplorer Keywords
c aptoinfo
l skbd
makt ty
s t ty
ge t ty
s etmap s
swc ons
t erminfo
/ e tc / ini t tab
srcms tr
O termcap
t ip
chs ound
t s et
mkf ont
l s f ont
chf ont
t tyconf
unt i e
genx l t
pc s im
9.1 O
Serial port settings:
smi t maktty
Create 'ITY port
smit chgtty
Modify 'ITY port
cu -1 / dev / t tyO -b2 4 0 0
Test modem port
Line states set by I e t c I ini t tab entry:
getty running on port and login herald presented.
No getty running on port. Dedicated dial-out.
getty - u running on port with no lock. Wait for DCD high,
then lock and present login herald.
getty - r running on port. Wait for characters on input buffer
before presenting login herald.
Defining terminal type and attributes:
/usr / l ib/ terminfo
SYSV 'ITY database
t i c , unt i e ,
Manage terminfo src
Terminals and Modems
t s e t -m ' dumb : ?vt 1 0 0 '
Query TI'Y type
/ e tc / termcap
BSD TI'Y database
c ap to info
termcap to terminfo src
1 49
t tyconf -1 p c s im
Line discipline:
# s t ty -a
Display port attributes
# s t ty disp <berk l posix>
BSD or POSIX line display
HFT devices:
Disable keyboard click
chsound -q
chhwkbd -d <delay> -r < r epe t i t i on>
Set keyboard rate
s e tmaps
Display/set keyboard map and code set
smi t chfont
Display/set font set
tput -Thft c l ear > / dev/ h f t
Unlock hung HFT
l s cons ,
Console path
chcons ,
Virtual terminals:
open < she l l -name>
Start virtual terminal
chnumvt < l - 1 6 >
Set # virtual terminals
PTY devices:
Autoallocate PTYs
smi t chgpty
Set number BSD PTYs
t tyconf -1 p c s im
Pri nters
1 0.1
Printing Overview
The ADC printing subsystem provides a rich set of commands and con­
figuration options that goes far beyond the printing facilities offered
by many other UNIX implementations. If you are familiar with the
traditional BSD or SYSV printing environments, you will find that the
ADC printing subsystem is not only interoperable with these environ­
ments, but it also involves some significant differences. The printing
subsystem in ADC comprises approximately forty commands designed
to meet the demands of the distributed printing technologies found in
most networked work groups. Many of these commands are provided
to support compatibility at the user interface level with BSD, SYSV,
and older versions of ADC Before we can delve into the details of this
command set, it will be helpful to understand how ADC manages the
print queuing system from a high-level functional viewpoint.
The AIX printing subsystem is made up of the following logical and
physical components:
Print device
Device driver and hardware interface
Queue device
Holding area for files waiting to be printed on the associ­
ated print device
Holding area for files waiting for delivery to another
queue or queue device
Virtual printer
Logical abstraction of queue and device based on data­
stream format
The normal life cycle of a file in the ADC printing subsystem begins
when a user or application submits the file for printing with a speci­
fied queue name. When the file's priority in the queue brings it to the
top of the list of waiting jobs, the qdaemon determines the next step
in processing based on queue definition stanzas in the / et c / qcon­
f i g file. The device and backend entries in the queue stanza may
1 51
1 52
System Configuration and Customization
indicate that this is a virtual printer and the file is to be filtered and
passed to a queue device. If these stanza entries indicate that this is a
queue device, then the file is directed to the device driver of an avail­
able local print device. (Refer to Fig. 10. 1 . ) The stanza may indicate
that this is a remote queue and the file is to be routed over the net­
work to a remote lpd daemon for further handling.
It is the system administrator's responsibility to tailor the stanzas
in / e tc / qc on f i g to apply the appropriate filtering and routing to
jobs in the queuing subsystem to ensure that they arrive at their des­
tinations with the appropriate attributes for printing. This must be
done in a way that hides the complexities of the underlying process­
ing and interfaces from the end users.
/ e tc / qc on f i g stanza
lp :
d i s c ipl ine = f c f s
up = TRUE
devi c e = dlpO
dlpO :
f i le = / dev / lpO
header = never
trai l e r = never
access = wri t e
backend = /us r / l ib / lpd / p i obe
The following sections will cover the steps required to configure
print devices, queue devices, local and remote queues, and virtual
printers. Although these procedures will involve tailoring the subsys­
tem interfaces using SMIT, the corresponding stanzas in / et c / qc on­
fig are generated automatically by SMIT. You may find that once you
have become familiar with the overall process and the format of the
hp laser
hp laser
Figure 1 0.1
Print queue, virtual printer, device relationship.
1 53
qconfig stanzas, you may wish to edit the / etc / qconfig file directly
and avoid using the SMIT panels. I would recommend that you avoid
doing this initially until you feel comfortable with the interaction of all
the components in the printing subsystem.
1 0.2
Print Devices
Local printer and plotter devices managed by AIX will usually be
attached to a serial RS-232/RS-422 port or parallel port. Access to
networked print devices is handled by the remote queuing facilities
which will be discussed in a later section. The RS/6000 system planar
supports both serial and parallel ports marked P and Sn , respective­
ly. You may also use multiport serial adapters, available from both
IBM and third-party vendors, for connecting additional devices. The
planar female DB25 parallel port may require the use of a DB25 to
Centronics adapter cable to connect the device to the system. For the
planar serial ports, you will need a 10-pin MODU to DB25 or DB9
adapter. The following pin-out diagrams describe the serial DB25
interface for the planar connection and the RJ45 to DB25 interface
used by the IBM multiport concentrators (see Fig. 10.2). Note that the
RS/6000 expects to see CTS high when the printer is powered up. You
can force the CTS signal high by connecting CTS and RTS on the
computer side of the interface if the printer does not supply CTS.
Next, carefully review your printer's hardware manual concerning
the attributes of the device interface and printing characteristics (see
Fig. 10.3). These include things like number of bits per character,
parity bits, signal handshaking, lines per page, special control codes,
etc. This information will be required to tailor the AIX device driver
configuration for the device. Make sure that the device is connected to
. L a
Figure 1 0.2
:J .
Serial cable pin-out.
1 54
System Configuration and Customization
Add a Printer
Move cursor to des i red i tem and pres s Enter .
Add a Printer / Pl o t ter
Con f i gure a Def ined Printer / Plotter
F l = Help
F 9 = Shel l
Figure 1 0.3
F 2 = Refresh
FlO = Exit
F3 = Cance l
Enter = Do
FB = Image
SMIT add printer panel.
the system and powered up before beginning the device driver config­
uration process. Use the SMIT fast path mkprt to begin device driver
# SMIT mkprt
Select the SMIT option Add a Printer / Pl o t ter . SMIT will dis­
play a set of preconfigured driver selections for various IBM and ven­
dor printers and plotters (see Fig. 10.4). If the device type you are
using is not displayed, then select one of the options Other par a l l e l printer or Other s e r i a l printer. If the printer you are
adding emulates one of the IBM-supplied devices, it may be easier to
select one of these entries if you are not certain of the correct device
characteristics required for the driver definition. I have always found
that there are fewer headaches involved if you can make one of the
standard configurations work. You can always go back later and cus­
tomize it to meet your requirements.
Printer / Plotter Type
Move cursor to des ired i tem and pres s Enter .
[ TO P ]
3 812-2
3 81 6
[ MORE . . . 4 1 ]
F l = Help
F 8 = Image
Figure 1 0.4
Personal Printer I I
Pers onal Printer I I
Pers onal Printer I I
Personal Printer I I
Mode l 2 Page Printer
Page Printer
Mode l 2 Proprinter II
Mode l 3 Proprinter I I I
Mode l 2 Proprinter I I XL
F2 = Re f resh
F l O = Exit
SMIT printer/plotter panel.
F3 = Canc e l
Enter = Do
1 55
Printer / Plotter Interface
Move cursor to des i red i tem and press Enter .
para l l e l
rs2 3 2
F l = Help
FS = Image
Figure 1 0.5
F2 = Re fresh
FlO = Ex i t
F3 = Canc e l
Enter = Do
SMIT printer/plotter interface panel.
SMIT will now prompt you for the type of interface you are using
(see Fig. 10.5). The screen options displayed will depend on the type
of interfaces supported by the previously selected printer model. For
example, a preconfigured entry for a parallel printer will not prompt
you for a selection of serial port options like bits per character, parity,
and number of start/stop bits. If a serial port is selected, SMIT may
further prompt you for parent adapter and port number.
After you have selected the interface type, the real work begins.
SMIT will display the panel of driver options supported by the chosen
device type (see Fig. 10.6). The device driver configuration will deter­
mine how the input data stream is interpreted and whether carriage
control information is to be generated and/or passed through to the
device. For example, a form feed control character can be generated
automatically by the device driver and sent to the printer when the
input line count exceeds the number specified by Number o f L INES
per page and if S end FORM FEEDS is enabled. Remember that you
can get into confusing situations when you have a printer jumpered
for generating auto-form feeds at the desired number of lines and also
have the device driver configured to do the same. Most of the options
are self-explanatory, but must be mapped closely to the printer's
hardware settings and capabilities.
1 0.2.1
Testing the device and driver
Once you have completed the device driver configuration, you may
test the interface by sending a file directly to the printer, bypassing
handling by the queuing system. This can be done using an applica­
tion like the cat command to direct a file to the device special file
name for the printer.
# cat < F i l eName> > / dev/ lpO
If you want to disable the translation done by the device driver to test
the printer hardware interface and settings, use the splp command
to enable transparent access to the printer.
# splp -p + / dev / lpO
Enable transparent access
1 56
System Configuration and Customization
Add a Printer / Plotter
Type or s e l e c t values in entry f i e lds .
Press Enter AFTER making a l l des i red changes .
[ TO P ]
Printer / Plotter type
Printer / P l o tter interface
Des cript i on
Parent adapter
* PORT number
Printer TIME OUT period
STATE to be conf i gured at boot t ime
[ Entry F i elds ]
para l l e l
I BM 2 3 8 0 Personal Prin>
ppa O
[ s tandard ]
[ avai labl e ]
+ II
The f o l l owing attributes have meaning only when the Printer / Plotter is not used
with a Print Queue :
Number of COLUMNS per page
Number of columns to INDENT
Send a l l characters to printer UNMODIFIED
WRAP CHARACTERS beyond the spec i f ied width
Conver t l owercase to UPPERCASE
EXPAND TABS on e i ght pos i t ion boundaries
Return on ERROR
F l = Help
F 5 = Undo
F9 = She l l
F3 = Cancel
F7 = Edi t
Enter = Do
F2 = Refresh
F 6 = Command
F l O = Exi t
+ II
+ II
F4 = L i s t
F 8 = Image
Figure 1 0.6 SMIT add printer/plotter panel.
II cat < F i l eName> > / dev/ lp O
Direct file to the interface
II splp -p
Enable driver translation
/ dev/ lpO
Another useful tool for testing the device driver and interface is the
lpt e s t command. lp t e s t will produce a ripple pattern of characters
which can be directed to the device special file name. You can control
the number of columns and lines produced with options on the com­
mand line. This is useful when testing line-wrap handling and the
generation of auto-form feeds.
II lpt e s t <Co lumns> <Lines> > / dev/ lp O
Modifications to the printer device driver may be made via SMIT
chgpr t .
II smi t chgprt
The SMIT panel options are similar to the driver options listed when
you initially added the device. You may also update device options
1 57
from the command line using splp . If no options are included on the
command line , then the current driver settings are displaye d .
I dev I lpO i s used a s a default i f no device name i s specified.
devi c e = / dev/ lpO ( + yes ! no )
CURRENT FORMATTING PARAMETERS ( ignored by qprt , lpr , and lp commands )
Note : -p + causes the o ther f o rma t t ing parame ters to be i gnored .
s end carriage returns ?
pas s - through?
-c +
-p !
s end l ine feeds ?
page l ength ( l ines )
-n +
-w 80
page width ( co lumns )
-r +
carri age rtn after l ine feed?
-i 0
indentat ion ( c o lumns )
-t !
suppre s s tab expan s i on?
-w !
-b +
s end backspaces ?
wrap l ong l ines ?
-C !
conver t to upper c a s e ?
-f +
send form f eeds ?
-T 6 0
timeout value ( s econds )
return on error?
1 0.3
Print Queues and Queue Devices
Print queues are somewhat like teller lines at the bank. Each file
waits its turn in line for the next available printer or queue. Just like
preferred customer and short transaction tellers, you may define cus­
tom scheduling disciplines for high-priority and quick-j ob queues .
When defining your print queuing topology and scheduling decisions,
it will be important to understand the difference between a queue and
a queue device. Basically, a queue device holds files for dispatching to
local device drivers, whereas a queue may dispatch to yet another
queue or queue device. The procedures for creating both queue types
are the same, with the exception of the destination as defined by the
f i l e = stanza. To create a queue, use the SMIT fast path command
mk.que . (Refer to Fig. 10. 7 . )
# smi t mkque
1 0.3.1
Local and remote queues
AIX supports both local and remote printer queues (see Fig. 10.8).
Local queues are used to feed printers directly attached to the local
machine, whereas remote queues are local holding tanks for files
Add a Queue
Move cursor t o des ired i t em and pres s Ent er .
Add a Local Queue
Add a Remo te Queue
F l = Help
F 9 = She l l
Figure 1 0.7
F2 = Re f resh
FlO = Exi t
SMIT add queue panel.
F3 = Cancel
Enter = Do
F S = Image
1 58
System Configuration and Customization
Host A
Host B
P rint Job
'/ qdaemon
Figure 1 0.8
Local remote print queuing.
which are to be transferred over the network to a remote machine.
Although both queue types are functionally equivalent, · they are con­
figured and handled differently by the queuing subsystem. Common
configuration options for local and remote queues require that you
supply a queue name, activation state at system boot time, a schedul­
ing discipline , and accounting options . The scheduling discipline
defines the priority a job has in relation to other jobs in the queue.
Most commonly these are either Short e s t Job Next ( SJN } or
F i r s t Come F i r s t Serve ( FCFS } . The accounting options will be
covered in the chapter on A.IX accounting (Chap. 2 1). You may also
specify that the queue is the system default if no queue name is speci­
fied on the command line when a job is submitted for printing.
1 0.3.2
Backend programs
The primary differences in how files in local and remote queues are
handled are governed by the backend program invoked by the qdae­
mon for each job in the queue. The backend program is responsible
for housekeeping chores, data filtering and conversion, and dispatch­
ing the file to its destination. For local queues, the backend program
is usually p i obe and for remote queues, the rembak program is used.
It is also possible to include your own program or shell script as a
backend program for custom applications. A simple batch scheduling
1 59
system may be implemented using the print queuing system to con­
trol the dispatching of batch jobs. Backend programs may be used to
execute shell scripts submitted by a user with preconfigured resource
limits. The queuing system will govern the number of batch jobs exe­
cuting on the system and delineate priorities based on the scheduling
disciplines used.
The default local queue backend, / u s r / lp d / p i obe , creates a
pipeline of filters for converting data formats. The output from the fil­
ter stream is directed to the printer with header and trailer pages as
specified by the configuration options . Whether the configuration
defines a queue, queue device, or custom queue will depend on the
values supplied for the backend
, file
and a c c e s s
stanzas. In
the case of a queue device, the output file is normally the device spe­
cial file name of the printer. If the queue will be used to dispatch files
to other local queues , then the name of the destination queue can be
used. For custom applications, you can control the access permissions
the backend program has to the output file. Normally, access will be
defined as write-only or read-write. (Refer to Fig. 10.9.)
Remote queues (see Fig. 10. 10) are processed by a /us r / lpd/ rem­
bak The rembak backend program creates an lpd control file for
each print job which will be passed along with the data file to a remote
lpd daemon. These control files contain tag information that specifies
the data-stream type, origin information, and handling options as
specified when the user submitted the job for printing. When configur=
Add a Local Queue
Type or s e l e c t values in entry f ields .
Press Enter AFTER making a l l des i red changes .
* NAME o f queue to add
ACTIVATE the queue?
Wi l l this become the DEFAULT queu e ?
Queuing D I S C I PLINE
NAME of device to add
ACCESS MODE of backend output f i l e
Number of FORM FEEDS prior to print ing
Print HEADER page s ?
Print TRAILER pages ?
ALIGN pages between f i les wi thin j obs ?
F l = Help
F5 = Undo
F9 = Shel l
Figure 1 0.9
F2 = Re f resh
F 6 = Command
F l O = Ex i t
F3 = Cancel
F7 = Edi t
Enter = Do
SMIT add local queue panel.
[ Entry F i elds )
f i r s t come f i r s t serve
wr i t e only
[ /u s r / lpd/pi obe ]
F4 = L i s t
F B = Image
1 60
System Configuration and Customization
Add a Remote Queue
Type or select values in entry f i e lds .
Press Enter AFTER making a l l des ired changes .
* NAME of queue to add
ACTIVATE the queue ?
Wi l l thi s become the DEFAULT queue?
* DESTINATION HOST for remote j obs
Pathname of the SHORT FORM F I LTER for queue status output
* Pathname of the LONG FORM F ILTER for queue s tatus output
* Name of QUEUE on remot e printer
NAME o f devic e to add
F l = Help
F5 = Undo
F9 = Shel l
Figure 1 0. 1 0
F 2 = Re f resh
F 6 = Command
F l O = Exi t
F3 = Cance l
F7 = Ed i t
Enter = D o
[ Entry Fields ]
f i r s t come f i r s t serve
[ / u s r / lpd / aixshort l
[ /usr / lpd/aixl ong ]
[ /u s r / lpd/ rembak ]
F4 = Li s t
F 8 = Image
SMIT add remote queue panel.
ing the remote queue entry i n SMIT, you will need t o specify the
remote host's domain name and remote queue name. You will also
need to specify the short and long filter names to be used to filter the
status information passed by remote lpd systems. Use the default
aixshort and aixl ong filters for remote AIX Version 3 systems and
aix2 short and aix2 l ong for AIX Version 2 on remote RTs.
1 0.3.3
Postscript printing
AIX provides support for postscript printing through the use of the
Adobe TranScript utilities (see Table 10. 1). These utilities are also
available in source code from AT&T as part of their AT&T Tool Kit.
These utilities are primarily filters which may be used as backends to
convert from ASCII, troff, plot, Tek4010, and Diablo into Postcript.
Postscript header and trailer programs for banner pages are located
in the / u s r I lpd / pi o / burs t directory.
TABLE 1 0.1
Code Conversion
TranScript utility
psc , psdi t , psro f f
p splot
ps4 0 1 0
ps 6 3 0
ASCII to Postscript
troff to Postscript
plot to Postscript
Tek4010 to Postscript
Diablo to Postscript
1 0.3.4
1 61
Custom backends
You may wish to use your own custom shell scripts and programs as
queue backends. If your backend application requires access to vari­
ables and data handled by the qdaemon, there is a library of routines
supplied in /usr ! l ib/ l ibqb . a which will allow you to communicate
with the elements of the queuing system. Normally your backend pro­
gram should write to standard out. qdaemon will open and lock the out­
put file specified in the f i l e = parameter in the qconfig stanza for you.
For a complete list of the routines supported in /usr / l ib / l ibqb . a ,
see InfoExplorer's Understanding Backend Routines in libqb.a.
1 0.3.5
BSD and SYSV support
The AIX printing subsystem will interoperate with BSD and SYSV
print spooling systems. Many of the standard BSD and SYSV com­
mands are available in AIX to allow users to easily move back and
forth between systems in a heterogeneous environment. They don't
have to use different commands on each system. As a system adminis­
trator, you will find that the AIX printing subsystem is much closer to
SYSV than to BSD in the way it handles remote printing. Many of the
lpd control file tags supported in the BSD environment are not avail­
able in AIX. When print jobs are inbound from a remote BSD system,
AIX will ignore these unsupported control file tags. The control file
tags used by AIX and SYSV are the same in most cases. Use the bsd­
short and bsdl ong filter names for remote status queries for BSD
systems. Use a t t short and a t t l ong for SYSV status information.
1 0.3.6
Customizing banner pages
If you will be using header and/or trailer pages for a local queue, you
can customize their format to match those used by other systems in
your environment. The format templates for burst pages are stored in
the /usr / lpd/pi o / burs t directory. For each format template, a file
name prefix of H is used to indicate header definitions and T for trailers.
There are sample definitions provided for ASCII, plotter, and Postscript
banners. The templates consist of program, text, and variable sections.
Variables are prefixed with a % sign: (Refer to Table 10.2.)
Example H . a s c i i banner:
* ############################################# ######### #########
* EXAMPLE H . as c i i Banner
* ###############################################################
* *****************************************************************
% t %T
%p % P
%q %Q
%h %H
1 62
System Configuration and Customization
TABLE 1 0.2
Banner Template Variables
Formatting flag values
Banner user name
Machine name
Time printed
Time queued
Submitting user name
Escape for percent sign
%s %S
%d =
= = = = > %D < = = = = =
You may wish to add your own custom banner definitions to this
directory. Use one of the existing header or trailer pages as a template.
You can update the associated queue entry via the SMIT fast-path
command chvipr t . You may find it much easier to simply edit the
appropriate printer field in the /usr I sbin / pi o / cus tom file and build
a new memory image of the definition for use by piobe . The memory
image is built by / u s r I lpd/ p i o / e t c / p i o d i ge s t . The memory
images are kept as colon files in the directory / u s r / lpd/pi o / ddi .
Since the p i odige s t options are a little verbose, you can quickly cre­
ate a new colon file by executing I e t c I l s v i rp r t without any
attribute options for the given queue or virtual printer name.
# / e tc / l svirprt -d lpO
Remember to conserve paper. Only use burst pages when they are
needed. You may also specify that a single header and/or trailer page
will be used for all of a particular user's queued files by grouping.
Encourage your users to recycle and keep recycle bins near your
printers and plotters.
1 0.4
Virtual Printers
Virtual printers allow you to direct print j obs to particular queue
devices based on the data-stream format of the file. A virtual printer
name represents a logical view of the queue, queue device, and print­
ers associated with a print job based on its attributes. When you con­
figure a virtual printer, you will supply all three of these components.
To create a virtual printer, use the SMIT fast path mkvirprt .
# smi t mkvirprt
1 0.5
1 63
Testing and Modifying Printer Configuration
You may test your virtual printer, queue, queue device, and print device
combinations with the same tools used when testing the hardware
interface and driver. Simply use the virtual printer, queue, or queue
device name when using the / u s r / bi n / cat or / u s r / bi n / lpte s t
# cat < F i l eName> > lp
# lptest <Co lumns> <Lines> > lp
It goes without saying that you must verify the operation of the AIX
printing subsystem in the same way your end users will interoperate
with it. Develop a short suite of print commands and options based on
the environments used by your user community to validate the sub­
system any time you have made any changes. Depending on your user
base, you may need to test all of the AIX, BSD, and SYSV commands.
When you need to display or modify your configuration, it is helpful
to remember that AIX uses a two-character command and SMIT fast­
path prefix scheme with the unique suffixes that represent virtual
printers virpr t , queues and queue devices que, and print devices
prt . These prefixes are usually rnk to add, ls to list, ch to change, and
rm to remove a component. For example the fast-path names to make,
list, modify and remove a queue are mkque, l s que, chque, and rmque,
respectively. This is not always the case, but you may find it a helpful
rule that will reduce the time you spend in InfoExplorer. In some cases,
you will have to remove the entry and then re-add it to make the
desired modification.
1 0.6
qdaemon and /etc /qconfig
The AIX printing subsystem is managed by the master print daemon,
/ e t c / qdaemon. qdaemon is started, refreshed, or stopped similar to
other subsystems under AIX with the s tart src, r e f resh, or s top ­
src commands.
# s tartsrc -s qdaemon
Start the qdaemon
# r e f resh -s qdaemon
Build new /etc/qconfig.bin
# s topsrc -s qdaemon
Stop the qdaemon
qdaemon is automatically started and stopped during system boot
and shut down when the init state change s as s p e c i fi e d in
I e t c I ini t tab.
qdaemon : 2 : wai t : /bin/ startsrc - s qdaemon
qdaemon reads the queuing system configuration from a binary
copy of the I e t c I qc o n f i g file, called I e t c I q c o n f i g . b i n . The
1 64
System Configuration and Customization
binary copy is automatically created by / u s r / l ib / l pd / di ge s t
when qdaemon is started or refreshed.
Once you have become familiar with the process of configuring the
queuing subsystem, you may find it tedious using the SMIT fast-path
menus. You can make your modifications by modifying the stanzas in
/ e t c / qconf i g with a standard editor. After you have made your
change s , r e f r e s h q d a e m o n t o bring them into producti o n .
Remember that fo r new printers and plotters you will also need to
create the associated device special files.
Example / e tc / qc on f i g :
* / etc / qconfig
* Local Queue Device
lp :
discipl ine = f c f s
up = TRUE
device = dlpO
dlpO :
f i l e = / dev/ lpO
header = never
trai ler = never
access = wr i t e
backend = /us r / l ib / lpd/piobe
* Remo te BSD Queue
rp :
host = da f fy . acme . com
s_s tat f i l ter = / u s r / lpd/bsdshort
l_s tat f i l ter = / u s r / lpd/bsdlong
rq = apple laser
device = drp O
drp O :
backend = /usr/ lpd/ rembak
* Po s t s c r ipt Queue to Convert ASC I I
ps :
devi ce = dps
d i s c ipl ine = f c f s
dps :
backend = /bin/ ensc r ipt
file = lp
* Batch Queue for Running She l l Scripts
bsh :
devi ce = bshdev
disc ipl ine = f c f s
bshdev :
backend = /bin/ sh
* Cus t om Queue Backend
alw :
devi ce = dalw
1 65
up = TRUE
dalw :
f i l e = / dev/nu l l
backend = / u s r / local / e t c / lpd2prt
1 0.7
lpd Daemon
Inbound print requests from a TCP/IP-based network are managed by
the / u s r I sbin / lpd daemon. The lpd daemon manages incoming job
requests from the network and deposits them into the appropriate
queues for subsequent processing by qdaemon . Like qdaemon , the
lpd daemon is a subsystem which can be started as part of system
boot and shutdown processing by adding it to / et c / ini t tab , or as
required from the command line. The / e t c / lpd / l ocks file contains
the PID of the currently running lpd daemon.
# s tartsrc -s lpd
# s topsrc -s lpd
To control which remote systems may communicate with lpd and
access your local queues, you must add the host name of each remote
system into the I e t c /hos t s . lpd file. A single " + " in the hos ts . lpd
file indicates that any remote system may have access to your local
Example / et c / ho s t s . lpd
# / e t c /hos ts . lpd
# Thi s f i l e def ines whi ch foreign hos t s are permi t ted to remo tely
# print on your hos t . To a l l ow a user f r om another host to print
# on your hos t , that foreign hos tname mus t be in thi s f i l e
daf fy . acme . c om
j udy . acme . com
s tar . acme . com
C ommunication with remote l p d daemons is handled by the
wr i t e s rv subsystem. If you have trouble communicating with a
remote system that is responding to other network services, make
certain that the wri tesrv subsystem is running and that it is listen­
ing to a socket.
# l s s r c -s wri t e s rv
# ps aux
grep wri tesrv
# netstat -a
1 0.8
grep wri t e s rv
Verify subsystem operative
Verify process is running
Verify socket connection
Administering Jobs and Queues
Now that you have the print queuing subsystem configured, the real
fun begins. This might be analogous to opening a new freeway. You
1 66
System Configuration and Customization
are going to need to define policies as to how the system is to be used
and provide tools for your traffic cops to keep things flowing smoothly.
Queue management and administration tasks in AIX can be han­
dled by one command, / b i n / enq. AIX does provide wrapper pro­
grams for enq which may be easier to remember, but in most cases
they use the same options. Once you have a handle on the option set,
it will likely be easier to use enq. If you are familiar with the BSD or
SYSV print management commands, you may use these in the AIX
environment to provide uniformity in a heterogeneous environment.
For the sake of this discussion, we will focus on enq and its wrapper
counterparts. For the weak of heart, you can perform these functions
using SMIT. The basic administration responsibilities for the queuing
subsystem include starting and stopping access, listing queue jobs
and status, promoting j obs in a queue, and removing j obs from a
queue. The enq command and its associated wrapper programs may
focus the action of each of these tasks to all jobs or queues, specific
queues, specific users, or specific j obs using the following options:
1 0.8.1
All queues
- P printer
Specific printer
-u user
Specific user
-# number
Specific job
Long-format output
Starting and stopping queues and printers
From time to time you may find you will have to stop a queue due to a
device malfunction or to let a backlog of jobs clear out before accept­
ing additional print requests . Use qadm or the enq command to
manipulate the availability of a queue or device. Note that these com­
mands have no effect on remote queues. To stop qdaemon from send­
ing more jobs to a queue and let the currently queued jobs print, use:
# qadm -D <Printer>
# enq -D <Printer>
To keep qdaemon from queuing more jobs and to kill the currently
printing jobs, use:
# qadm - K < Printer>
# enq - K < Printer>
To bring the queue and printer back on-line use:
# qadm -u <Printer>
# enq -U <Printer>
1 0.8.2
1 67
Listing print jobs
In order to manipulate jobs in the queuing subsystem or to review
their status, you will need to display the contents of each queue. This
is done using the qchk, qs tatus , and enq commands. The display
format of each is similar. To list the print jobs in all queues, enter one
of the commands :
# qchk - A
# qstatus - A
# enq - A
T o list the jobs queued t o a particular printer, use:
# qchk - P <Printer>
# qstatus - P < Printer>
# enq -A < Pr inter>
F i l es
smi t . s c r ipt
payro l l . rpt
i zar
PP #
The display will list the jobs by queue and device, status, job number
and file name, the submitting user, percent printed, size in blocks,
copy count, and priority. You will use the information listed in these
fields to manipulate the jobs in the queue. The status field provides
feedback on the state of the queue, device, and current jobs.
1 0.8.3
Printer accepting print requests
Printer is off-line
Printer state is unknown
Printer waiting operator response
Printer not ready
Print job being queued or printing
Print job is ready for printing
Changing priority
There are times when special circumstances require that you change
the priority of jobs in a queue overriding the default queuing disci­
pline. It may be that you want to defer printing a large j ob, or an
impatient user is leaning over your shoulder with that "I needed this
yesterday" look. To change the standing of a job in the queue, use the
qpri or enq commands. To move a job up in priority, give it a higher
number. You cannot change the priority of jobs in a remote queue.
Once the priority is changed, you should see the position relative to
other jobs in the queue change by the value in the rank field.
1 68
System Configuration and Customization
# qpri -P <Pr inter> - # <JobNumber> -a <Prior i ty>
# enq -P < Printer> -# <JobNumber> -a <Priority>
1 0.8.4
Removing print jobs
To remove a print job from a queue, use the qcan or enq commands.
If the job you wish to remove is printing, you will first have to stop
the printer before removing the job.
# qcan - P < Printer> -x <JobNumber>
# enq -P < Pr inter> -x <JobNumber>
If circumstances require that you remove all jobs in a queue, use the
-x flag.
# qcan -P < Printer> -X
# enq - P <Pr inter> -X
1 0.9
ASCII Terminal Printers
Many ASCII terminals support an auxiliary serial port or parallel
port for screen print and printing from connected computers. Routing
a print job from the remote computer to the auxiliary port on the ter­
minal requires the sending of a special sequence of characters before
and after the print job to enable and disable connection to the auxil­
iary port. It may be the case that when using this printing capability
it will temporarily disrupt normal terminal interaction. The IBM 64port concentrator will allow concurrent printing and terminal interac­
tion via the AIX / e t c / t ty / s t ty- l i on program. The s t ty- l i on
program requires the start and stop auxiliary print sequences to be
given, and the priority that printing is to take over terminal activity.
# / e t c / tty / s tty- l i on in_xpar < StartAuxSequence> \
lv_xpar < S t opAuxSequence> <Priori tyNumber> < / dev / t tyNN
1 0.9.1
Pass-through mode
A number of public domain applications exist that will send vtlOO
auxiliary port sequences to a remote terminal or terminal emulation
1. Saving TTY state
2. Setting the TTY to raw mode
3. Sending the start aux sequence
4. Sending the file
5. Sending the stop aux sequence
6. Restoring TTY state
1 69
Many terminal emulation packages for personal computers support
vtlOO pass-through mode sequences. These include kermi t for direct
connect and dial-up access and NCSA telnet for TCP/IP.
1 0.9.2
lned Prtty
The AIX !Ned editor provides pass through mode printing support
with the prt ty command. prt ty may be used as a stand-alone com­
mand and is configurable to supp ort any auxili ary p o rt p rint
# prtty -1 <Number> < F il eName>
The - 1 number option asks prt ty to prompt you after number lines
have been printed. You define the start and stop auxiliary sequences
in the !Ned / u s r / l ib/ INed / t ermcap / terms . bin file for each ter­
minal type you intend to support. You must use the !Ned editor, e , to
edit the /usr / l ib / INed / termcap / de f . trm file. For each terminal
type, set the k2 field with the start auxiliary print sequence, and the
k3 field with the stop auxiliary print sequence. When you have com­
pleted editing, create a new / u s r / l ib / INed / t ermc ap / terms . bin
file by using the !Ned tdiges t command.
# tdige s t / us r / l ib / INed/ termcap / de f . trm \
/ u s r / l ib/ INed/ termcap / terms . bin
With pass-through mode printing support , you can define AIX
queues for routing j obs to terminal-attached printers . Supply the
pass-through mode application name as the backend program and the
TTY device special file as the output file in the / et c / qcon f i g stanza
for the queue.
/ e tc / qcon f i g TTY stanza:
ttyp O :
devi ce = dttypO
dt typO :
f i l e = / dev/ t tyO
header = never
trailer = never
access = wri t e
backend = /bin/prtty
1 0.1 O
X Station Printers
AIX supports printing to printers attached to IBM X stations. You
may also be able to support printing to other vendor X terminals
using either l p d or the pass-through mode printing technique
described for AS C I I terminals . When using the IBM X Station
Manager, define an X station-attached printer to the queuing subsys­
tem with the mkvirprt command.
1 70
System Configuration and Customization
# smi t mkvirprt
Select option 2 Printer or P l o t ter At tached t o Xs t a t i on
from the SMIT menu and supply the X station name. You will be
asked to supply the interface type, X station model, printer baud rate,
parity, bits per character, start/stop bits, and printer model. This is
quite similar to the procedure for adding a standard locally attached
printer. Refer to the previous sections on Print Devices (Sec. 10.2)
and Print Queues and Queue Devices (Sec. 10.3).
The backend program u s e d for IBM X station printing i s
/ u s r / lpp / x_s t_mgr /bin/ lpx . The stanza generated by SMIT for
the / etc / qconfig file should look like the following entry:
I etc I qc onf ig X station stanza:
Xs tation Queue Device
xceed :
discipl ine = s j n
u p = TRUE
devi ce = dxceed
dxceed :
file = false
header = never
trai ler = never
backend = lpx xceed -s 1 9 2 0 0 , n , 8 , 1
1 0. 1 1
OSF Palladium
As AIX moves further into the Open Software Foundation (OSF) spec­
ifications , it will be helpful to understand how printing will be
defined and managed in this environment. The OSF printing system
is based on the Palladium distributed printing system developed by
MIT Project Athena and based on ISO DP 1 01 75 Document Printing
Application (DPA). The technology was submitted to the OSF and
accepted as part of their Distributed Management Environment
( D ME ) . Pallad i u m w a s ext e n d e d to u s e the O S F D i s tribute d
Computing Environment to provide a client/server-based distributed
printing system that supercedes the traditional UNIX lpd environ­
ment. It is designed to be operating system and architecture indepen­
dent, and to be amenable to being the RPC interface between these
unlike entities. A two-level API is defined, which separates human
language printing attributes from that of the servers and underlying
operating system.
The Palladium distributed printing system is made up of four com­
ponents that interact to provide a seamless print service to the end
user. These components are:
Print clients
Print servers
Printer supervisors
1 71
Print clients act as the user agent for submitting and accepting com­
mands to and from the print service. It is made up of both the high­
level and low-level APis. Print servers accept requests from applica­
tion clients and schedule them on print supervisors. Print supervisors
are responsible for dispatching files for printing on a printer. Printers
represents the physical printer device and interface. All interactions
are based on the DCE RPC.
Palladium supports the two notions of queue and logical printer.
These may be thought of as analogous to the ADC constructs of queue
device and virtual printer. The queue, as in the ADC printing subsys­
tem, holds jobs destined for physical printers and remote routing. A
logical printer represents an abstraction of the attributes a user has
requested for their print job. The print servers and supervisors use
these attributes to decide how the job will be queued and routed to a
Logical and physical printer names are stored in the DCE name
service along with the names of the print servers that provide the
access service for each. Typically, commands will resolve to the name
of a logical printer server unless only the physical printer server is
listed. To improve robustness and reliability in this distributed envi­
ronment, more than one server will be listed for both logical and
physical printers. Clients may then try each server until the request
is accepted. DCE name service groups are also supported to provide
multiple names for printer and servers.
The following list of Palladium user commands represents the four
operations defined by the ISO DPA:
Submit a job to a print server for logical printer
Modify attributes of a print job
Cancel a submitted job
pdl s
List attributes of object instances and classes from a server
The following list of Palladium management commands represents
the four ISO DPA administrative operations as well as extensions:
pdc l ean
Remove all jobs from a server, queue, or printer
Disable server, queue, or printer
Enable server, queue, or printer
pdin i t
Initialize attributes of a server, queue, or printer
Interrupt current job and resume after specified action
pdpaus e
Pause a printing job
pdpromo te
Increase priority of a job
Resubmit a job
Resume a paused job
1 72
1 0.1 2
1 0.1 3
System Configuration and Customization
Set the attributes of a DPA or Pd object
Shut down the specified server, queue, or printer
lnfoExplorer Keywords
pi obe
/ etc / qconfig
/ l ib/ l ibqb . a
/usr/ lpd/pio /bur s t
l svirprt
qs tatus
s tart src
lpte s t
/ e t c / t ty / s t ty- l i on
s tops re
l s src
tdige s t
nets tat
/ u s r / lpp /x_s t_mgr /bin/ lpx
/ etc / qconfig
Printer definitions
smi t mkprt
Create new printer
splp -p + / dev/ lpO
Transparent access
splp -p
Enable translation
/ dev/ lpO
cat < F i l eName> > / dev / lp O
Test the interface
lptest <Co lumns> <Lines> > / dev/ lpO
Print test pattern
s tartsrc - s qdaemon
Start qdaemon
/ et c / qconfig
Printer definitions
bsdl ong bsdshort
lpd control file support
Local print backend
# s tartsrc -s lpd
Start lpd remote print
Remote print backend
/usr/ lpd / p i o / burst
Banner pages
l svirprt - d lpO
Create new colon file
smi t mkvirprt
Create virtual printer
enq <op t i ons>
Admin print subsystem
prtty -1 <Number> < F i l eName>
!Ned transparent print
tdige s t
Compile !Ned termcap
s t ty- l i on
64-pt concentrator print
Network C onfi g u ration
and C ustom ization
1 1 .1
Internet History
Network technologies took form and began to appear in the late
1 9 6 0 s . Much of what was available at the time was house d in
research labs and based on many different design models. It was rec­
ognized early on that differing network models would ultimately
result in roadblocks to information sharing. Standards organizations
came into being to address the problem of interoperability and to for­
mulate a common network model. The Open Systems Interconnect
( O S I ) model w a s pro p o s e d by the In ternational Standards
Organization (ISO) and adopted as the basis for the majority network
development over the last 30 years.
1 1 .1 .1
OSI model
The OSI model is a layered protocol abstraction that is delimited as
seven functional interfaces. At the bottom layer, the model defines
the hardware interface for transferring data as signals on the physi­
cal medium. Higher levels of the protocol specify packet definition,
routing, data integrity, and connection authentication. At the highest
levels, data formats and user interfaces are defined.
OSI model:
7 Application
User interface and services
6 Presentation
Application data transformations
5 Session
Connection authentication
4 Transport
End-to-end data ordering
3 Network
Routing and reporting mechanisms
2 Data
Packet, integrity, and address definition
1 Physical
Physical hardware specification
1 75
1 76
Network Configuration and Customization
A unit of data in the model is based on the packet or, in newer pro­
tocols, on the cell. Packets are of variable length, whereas cells are of
fixed length. Each is made up of a header and data component.
Depending upon the protocol and layer, header information identifies
the type, address, sequence number, and checksum. Each layer in the
OSI stack adds or subtracts headers to facilitate end-to-end delivery
of the information.
1 1 .1 .2
Around the same time that the OSI model was being formulated, the
Defense Advanced Research Project Agency (DARPA) funded a proj­
ect to build a national network connecting government and university
research labs. The ARPANET was built using an early point-to-point
protocol called the Network Control Program (NCP) and p acket
switching minicomputers running a protocol called 1822. This topolo­
gy was replaced in the early 1980s with the CCITT X.25 p acket
switching protocol and a new protocol developed by Bolt, Baranek,
and Newman (BBN) called Transmission Control Protocol /Internet
Protocol (TCP/IP). The TCP/IP suite was bundled into BSD UNIX 4.2,
and, due to popularity and widespread use, became the de facto stan­
dard for internetworking.
Internet protocol definitions are based on a request for comment
(RFC) process. Draft RFCs are presented to the Internet Activity
Board for review. RFC draft status is documented quarterly in the
JAB Official Protocol Standards. RFC documents are available from a
number of sites electronically via anonymous FTP.
Network bandwidth and security problems quickly overcame the
rapidly growing ARPANET community. In the late 1 9 8 0 s , the
ARPANET was divided into the Defense Research Internet (DRI) and
the National Science Foundation Network (NSFNET). DRI took with
it the military research labs from the original ARPANET, leaving the
NSFNET to provide wider communication support to universities and
other research organizations.
1 1 .1 .3
The National Science Foundation (NSF) funded a phased migration
from the ARPANET into a new three-level hierarchical topology. A
national backbone would interconnect regional networks. The region­
al networks provide access to the NSFNET backbone to universities
and organizations residing in their areas of service. NSFNET band­
width has migrated from Tl to T3 service in most locations. NSFNET
long distance circuits are provided by MCI and interconnected using
IBM-developed nodal switching systems (NSS). Early NSS systems
were based on nine IBM RTs which have since been replaced by a sin-
1 77
gle RS/6000 . Thus, the early nickname for the NSS , "Nine Small
Systems." NSFNET is managed and operated by Merit Inc.
1 1 .1 .4
While the evolution of the Internet was taking place, two other popu­
lar university-based networks converged to form the Corporation for
Research and Education Network (CREN). These original networks
were the Computer Science Network (CSNET) and the Because It's
Time Network (BITNET), which were originally based on dial-up/X.25
and NJE/BISYNC connections, respectively. CREN is moving toward
an IP topology similar to NSFNET. A first step has involved encapsu­
lating NJE in IP for the existing BITNET sites. It's worth mentioning
CREN because of the role it played in popularizing network use and
the role it will likely play with NSFNET in the future of large-scale
1 1 .1 .5
Future net-ATM
There is a race going on, involving the telcos, cable companies, com­
puter vendors, and the entertainment industry, to bring full multime­
dia services into your living room or work place. The telcos have the
switching equipment but lack the bandwidth from the curb into your
home or office. Cable companies have the bandwidth but lack the
switching infrastructure. The computer and entertainment industries
hold the applications and products of interest to the consumer com­
munity. The result is collaborations and partnerships in an attempt
to bring all the pieces together.
To manage the traffic explosion of worldwide interactive audio­
video services requires the implementation of a low-overhead network
protocol. Such a protocol is Asynchronous Transfer Mode (ATM). ATM
is based on small 53-byte fixed-length cells. Not much room to sup­
port both header and data! By dynamically multiplexing small cells
between multiple paths, ATM eliminates the problem of continuous
large-block data like video causing network traffic jams. ATM speeds
begin at 155 megabits/s . First-generation switches will run at 2.4
gigabits/s. Gateways to traditional network protocols will be support­
ed to ease migration. Don't be surprised to eventually see ATM-like
protocols emerge to manage data within the workstation.
1 1 .2
TCPn P Suite
It's difficult to get a one-to-one mapping between the TCP/IP and OSI
models. TCP/IP bundles much of the functionality defined in the OSI
model into a smaller number of layers. Rather than attempt to define
a TCP/IP to OSI mapping, it is pertinent to this discussion to present
a model of the TCP/IP suite.
1 78
Network Configuration and Customization
Application OSI 5-7
Transport O S I 4
Physical OSI 1 -2
I nternetwork OS I 3
Figure 1 1 .1
Ethernet, Token Ring, FD D I , SOCC, H i P P I , ETC
TCP/IP stack.
The physical layer represents a conglomeration of hardware inter­
faces and protocols that interoperate via the conduit defined in the
upper layers (see Fig. 1 1 . 1). These interfaces employ a wide range of
data speeds and physical architectures.
The internetwork layer combines the OSI data link layer and a por­
tion of the OSI network layer. The layer is composed of two protocols,
Internet Protocol (IP) and Internet Control Message Protocol (ICMP).
IP and ICMP are connectionless datagram protocols that provide the
basic data buckets and control in the network.
The transport layer defines two protocols, Transmission Control
Protocol (TCP) and User Datagram Protocol (UDP). TCP ensures a
reliable ordered transport, whereas UDP service is unreliable and
does not ensure delivery. It has been shown that TCP reliability oper­
ations cause a significant bottleneck in network throughput on fast
processors and networks. The conj ecture is that the current network
transports are significantly cleaner than those around when the pro­
tocol was defined. TCP checksum processing ties up host cycles that
could be better used elsewhere. Newer network interface hardware is
moving TCP processing into the interface and off of the host processor
to improve throughput.
The application layer in the TCP/IP suite, like the OSI model, imple­
ments the user interface. Client/server protocols are most often defined
at the application layer. Common application level services include
Telnet, File Transfer Protocol (FTP), Simple Mail Transfer Protocol
(SMTP), Network File System (NFS), and the Xll Window System.
1 1 .3
Whether you are new to TCP/IP or sport a fair number of stars on
your wizard's hat, installing or upgrading your network infrastruc­
ture will require some careful planning and plenty of homework. If
1 79
you aren't considering the implications of the multimedia boom in
your bandwidth calculations , then you probably need to increase
them by an order of magnitude. Once you turn on the information
faucet, your users won't be able to get enough! Have you thought
about how you're going to back up all those low cost multi-gigabyte
disks populating your workstations? How about telecommuting capa­
bility? Fortunately, gateway configurations will allow you to mix and
match components to meet most of your connection and bandwidth
needs. Notice that I did say most!
1 1 .4
Hardware Components
The RISC System/6000 supports the gamut of traditional hardware
interfaces as well as newer high-speed adapters approaching gigabit/s
transfer rates. In the following sections I'll outline the attributes of
each of these network interfaces , along with cabling and support
1 1 .4.1
RISC System/6000 M icro Channel
We will begin by looking at the Micro Channel in the R I S C
System/6000. Latency and buffering problems i n the older 40-MB/s
Micro Channel bus could only sustain 9 MB/s under the best condi­
tions. Multiple adapters on the bus will degrade throughput during
simultaneous transmissions. Thus, the older 40-MB bus was a signifi­
cant bottleneck for connections requiring s p e e d s beyond basic
Ethernet or token ring. The 80-MB/s bus in new systems sustains
data rates up to 72 MB/s. Multiple Micro Channel buses are an option
on larger systems.
1 1 .4.2
Ethernet is a 10-MB/s broadcast-based network developed in the
early 1980s by Xerox. Ethernet comes in three flavors : Version 11980, Version 2-1982, and IEEE 802. 3-1983. It is a broadcast­
based protocol that uses collision detection and avoidance to regulate
traffic. The Carrier Sense Multiple Access I Collision Detection
(CSMA/CD) protocol allows any system to start a conversation on the
wire, but requires it to back off and wait a pseudorandom period of
time if it detects that it has interrupted an existing conversation.
The wait-before-retry interval is bounded by a multiple of 5 1 . 2 µs.
5 1 . 2 µs is the time it takes to transmit a 5 12-bit packet. Although
the specified data rate of Ethernet is 10 MB/s, in reality it will only
sustain around 1 MB/s.
The ether exists on a segment of cable terminated at each end. The
segment terminators absorb signals inhibiting reflections from either
1 80
Network Configuration and Customization
Figure 1 1 .2 Ethernet network.
end of the wire. Computers and other peripheral equipment are con­
nected to the segment using a tap and transceiver. Cable segments are
bridged together into larger networks using repeaters. (See Fig. 11.2.)
Ethernet segments are commonly constructed from coaxial or twisted
pair cable. The choice of cable will depend on the environment and
dictate the cost. As you might expect, twisted pair is the cheapest and
easiest medium to install and manage. Newer media options like opti­
cal fiber, digital radio, digital microwave, or satellite links may be
used between segments to span almost any distance you might have
in mind. (Refer to Table 1 1 . 1 . )
A transceiver i s used t o connect the computer adapter t o the Ethernet
segment. Internal transceivers located on the adapter card attach to
the Ethernet segment using a "T" tap. External transceivers are pow­
ered from the segment itself and attach to the adapter via a drop cable.
Drop cables may be constructed using shielded twisted pair or optical
TABLE 1 1 .1
Common Ethernet Media
10BASE5 Thickwire*
10BASE2 Thinwiret
lOBASET Twisted pair
Max seg len
RG l l
RG 58
24 AWG
500 m
185 m
lOO m
*Transceivers 2.3 m apart and segment lengths multiples of 23.4 m.
tTransceivers .5 m apart.
1 81
fiber, depending on distance requirements. Multiport transceivers may
be used to connect multiple machines to a segment using one tap.
Drop cable DB15 pin-out:
Version 1,2
Shield (ground)*
Collision ( +)
Transmit ( +)
Receive (+)
Power return
Collision ( )
Transmit ( )
Receive ( )
IEEE 802.3
Not connected
Collision ( +)
Transmit (+)
Logic reference (ground)t
Receive (+)
Power return
Not connected
Not connected
Collision ( )
Transmit ( )
Not connected
Receive ( )
Not connected
Not connected
*Version 1,2 shields attached to pin 1 and hood.
tIEEE 802.3 inner shield attached to pin 4, outer shield
attached to casing.
It smi t chgenet
Figure 1 1.3 reproduces the SMIT Ethernet adapter panel.
You may want to incre ase the values of the TRANSMIT and
REC E IVE queues . These values represent queues of buffers for
incoming and outgoing packets. Values may range from 20 to 150.
Expanding the size of an Ethernet network beyond a single seg­
ment requires the use of active devices to recondition packets and to
isolate and route traffic. These tasks are performed by repeaters,
bridges, and routers, respectively. Repeaters are used to connect seg­
ments separated by distance. Remote repeaters are used in pairs and
connected together via optical fiber. Repeaters retime and retransmit
packets from one segment to the next. Bridges reconstitute packets
similar to repeaters. In addition, they learn the addresses of the
machine s on e ach side of the bridge and eventually determine
whether to pass traffic from one side to the other based on the
addresses of the sender and receiver. Routers determine which seg­
ment a particular packet must take to reach its destination. Routers
exchange data concerning who their neighbors are to create a picture
of the network topology.
New blood is being pumped into Ethernet technology due to the
large customer base it currently enj oys. Proposals for 100-MB/s
Ethernet are being reviewed by the IEEE. Some of the proposed pro-
1 82
Network Configuration and Customization
Change/ Show Charac ter i s t i c s of an Ethernet Adapter
Type or select values in entry f i elds .
Press Enter AFTER making a l l des ired changes .
Ethernet Adapter
Des cription
S tatus
Loca t i on
TRANSMIT queue s i z e
RECEIVE queue s i z e
STATUS BLOCK queue s i z e
O f f s et to ETHERTYPE f i e l d
O f f s e t to 8 0 2 . 3 ETHERTYPE
Apply change to DATABASE only
F l = Help
F 5 = Undo
F9 = She l l
Figure 1 1 .3
F2 = Re fresh
F 6 = Command
F l O = Exit
[ Entry F ields ]
ent O
Ethernet High-Performa>
Ava i lable
[ 92 ]
[ Ox )
[ 12 )
F3 = Canc e l
F7 = Edi t
Enter = Do
F4 = L i s t
F 8 = Image
SMIT Ethernet adapter panel.
tocols are already available in the marketplace. Proposals before the
IEEE include mechanisms for parallel twisted pair configurations ,
multiple packet priority, and new multilevel code protocols.
1 1 .4.3
Token ring
Token-ring networks provide a little bit better throughput than stan­
dard Ethernet (see Fig. 1 1.4). They were originally developed by IBM
and later adopted by the IEEE as specification 802.5. Token-ring pro­
tocol uses a token passing mechanism to regulate traffic on the ring.
A particular workstation on the ring must gain control of a token
Figure 1 1 .4
Token-ring network.
1 83
before it can transmit data onto the ring. While data is being trans­
mitted on the ring, a token is not available to other stations. A dual­
ring topology will provide a degree of fault tolerance. If the ring is
broken, the dual paths are used to form a new ring. Token ring sup­
ports either 4- or 16-MB/s bandwidth. At the high end, token ring can
sustain around 12 MB/s throughput.
Each computer in the ring is configured with an adapter card. The
adapter is connected to a multistation access unit (MAU) with an
adapter cable. A MAU is a concentrator that supports up to eight sta­
tion ports along with a ring-in and ring-out port to interconnect other
MAU s . Like Ethernet, repe aters are u s e d to extend distances
between MAUs by retiming and retransmitting packets. A repeater
may be integrated into a MAU, making it an active MAU. MAUs local
to the work space can be rack-mounted in a wiring closet. A number
of cable options are available to fit most environmental, cost, dis­
tance, and speed requirements. (Refer to Table 1 1.2)
A star ring topology can be built from a central ring with one or
more MAU devices. Dual-pair cables connect each MAU to the ring
and represent the lobes of the star. For Type 1 cable, lobe lengths can
be no more than 100 m, with a maximum of 260 stations on the main
ring. Type 3 cable, being unshielded, allows no more than 45 m for
each lobe unless active MAUs are used to boost distance. A maximum
of 72 stations may be attached to a Type 3 main ring.
Ring traffic control is distributed among all active stations. Each
station receives a token or data frame from its nearest neighbor. If
the station is not the intended recipient, it retransmits the frame
back onto the ring to the next station on the ring. Figure 1 1 . 5 dis­
plays the SMIT token-ring adapter panel.
II smi t chgtok
1 1 .4.4
Fiber Distributed Data Interface (FDDI)
Fiber Distributed Data Interface (FDDI), ANSI X3T9. 5 , is a token
passing protocol similar to token ring, but implemented using optical
fiber rings. FDDI and its copper-based cousin, Copper Distributed
TABLE 1 1 .2
Token-Ring Media
22 AWG
22 AWG
24 AWG
26 AWG
26 AWG
26 AWG
2 shielded pairs
2 shielded, 4 unshielded pairs
1 unshielded pair
Solid-core optical fiber
2 stranded shielded pairs
2 parallel shielded pairs
2 solid-conductor shielded pairs
1 84
Network Configuration and Customization
Change I Show Charac ter i s t i c s of a Token Ring Adapter
Type or select values in entry f i elds .
Pre s s Enter AFTER making a l l des ired changes .
Token Ring Adapter
Descrip t i on
S t a tus
Loca t i on
Rec eive data trans fer OFFSET
TRANSMIT queue s i z e
RECEIVE queue s i z e
STATUS BLOCK queue s i ze
RING speed
Receive ATTENTION MAC frame
Receive BEACON MAC frame
Apply change t o DATABASE only
F l = Help
F 5 = Undo
F9 = She l l
F2 = Re f resh
F 6 = Command
F l O = Exi t
[ Entry F i e lds ]
Token-Ring High-Per for>
Avai lable
[ Ox4 0 0 0 5 0 7 0 8 3 7 6 ]
F3 = Cance l
F7 = Ed i t
Enter = D o
F4 = L i s t
F 8 = Image
Figure 1 1 .5 SMIT token-ring adapter panel.
Data Interface (CDDI), support data rates at 100 MB/s. FDDI was
designed to be implemented as a network backbone. It has been slow
to gain acceptance due to high per-node cost. Although FDDI provides
significant bandwidth improvements over standard Ethernet and
token ring, it is thought to be too little too late when compared with
other emerging technologies.
FDDI, like token ring, operates with distributed control over all
stations connected to the ring. Each station receives token or data
frames from one neighbor and, if not the recipient, passes them on to
the next neighbor. The media access control (MAC) layer of the FDDI
specification supports tailoring of the token-handling time to reflect
the data types generally transmitted over the ring. Low time values
provide better interactive response, whereas high values are better
for moving large block data.
The RS/6000 supports both single-ring and dual-ring topologies. A
single attach station (SAS) is used for single-ring configurations. The
dual-attach station (DAS) adapter provides the ability to support a
primary and secondary ring topology. In this configuration, the sec­
ondary ring supports traffic flow in the opposite direction from the
primary ring. This allows a fail-over ring to be formed in the event
the ring is segmented. Note that the secondary ring is available for
fault tolerance only and may not be used as a separate network.
It is recommended that 62.5/125-µ multimode optical fiber be used
for each ring. You can get away with using other popular fiber sizes
1 85
Change / Show Charac ter i s t i c s of a FDDI Adapter
Type or select values in entry f i e lds .
Press Enter AFTER making a l l des ired changes .
FDDI adapter
S tatus
Receive Data Trans fer O f f se t
Receive Queue S i z e
Transmi t Queue S i z e ( in mbu f s )
S tatus Block Queue S i z e
Enable Al ternat e Mac / SMT Address
A l ternat e Mac / SMT addre s s
PMF Pas sword
TVX ( nsec )
TVX ( ns e c )
TVX (nsec )
TVX (nsec )
T_REQ ( ns e c )
T_REQ ( nsec )
T_REQ ( nsec )
T_REQ ( nsec )
USER data
Receive Beacon Frames
Receive SMT Frames
Receive NSA Frames
Apply change t o DATABASE only
F l = Help
F 5 = Undo
F9 = She l l
Figure 1 1 .6
F2 = Re f resh
F 6 = Command
F l O = Ex i t
[ Entry F i e lds ]
fddi O
FDDI Primary Card , S in>
Avai lable
[ 10 ]
[ OxO ]
[ OxO ]
[ 2 5 0 92 0 0 ]
[ 1000192 0 ]
[ 1000192 0 ]
[ 10 0 0 19 2 0 ]
[ 10 0 0 1 9 2 0 ]
F3 = Cancel
F7 = Edi t
Enter = Do
F4 = Li s t
FB = Image
SMIT FDDI adapter panel.
as long as you keep signal loss to a minimum. FDDI concentrators
may be connected as lobes in a star ring topology. Fiber distribution
panels can be located in wiring closets similar to token-ring MAUs.
See Fig. 1 1 . 6 for the SMIT FDDI adapter panel.
# smi t chgfddi
1 1 .4.5
The RISC System/6000 supports TCP/IP over dial-up lines using
Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP).
The hardware employed by these protocols uses standard serial ports,
modems, and switched lines (see Chap. 9).
SLIP is a very simple protocol for framing IP packets on a serial
line. It does not support packet addressing or type fields, data com­
pression, or reliability. Only one protocol may be supported on a link
at a time. SLIP links must be started manually.
1 86
Network Configuration and Customization
PPP goes further than SLIP by including a Link Control Protocol
(LCP) for link control and a set of Network Control Protocols (NCP) to
support multiple protocols at a time. PPP will likely replace SLIP as
the standard protocol for serial links.
In most instances, you will want to use links speeds at or above
9600 bits/s.
1 1 .4.6
Serial optical channel converter (SOCC)
In the absence of a standard high-speed network solution, IBM sup­
plied a proprietary fiber pipe for the RISC System/6000 called the ser­
ial optical channel converter (SOCC). Although the device is not an
IBM strategic direction for networking, it does provide a high-speed
option for interconnecting RISC System I 6000s.
SOCC adapters have two half duplex fiber channels each operating
at 220 MB/s . The adapters are connected directly to the planar,
enabling fast data paths to system memory, bypassing the Micro
Channel bus . The architecture can sustain speeds at 18 MB/s in
native mode . TCP and UDP are supported at slower rates due to
packet processing overhead in the central CPU. SOCC is a point-to­
point architecture (see Fig. 1 1 . 7). Network Computing Systems mar­
kets a DX switch that may be used to interconnect SOCC adapters in
a star topology. It also provides gateway adapters for Ethernet, token
ring, FDDI, HIPPI, and Hyperchannel.
# smi t ops change
1 1 .4. 7
High-Performance Parallel Interface (HIPPI)
The High-Performance Parallel Interface (HIPPI) standard, ANSI
X3T9.3, is based on the High-Speed Channel project work, and Cray's
HSX Channel. HIPPI runs at speeds of 800 MB/s and can be extended
Change I Show Charac teri s t i c s of the Serial Optical Link
Type or select values in entry f i elds .
Press Enter AFTER making a l l des i red changes .
* Processor ID number for this machine
RECEIVE queue s i z e
STATUS BLOCK queue s i z e
Apply change to DATABASE only
F l = Help
F 5 = Undo
F9 = Shel l
Figure 1 1 .7
F 2 = Re f resh
F6 = Command
F l O = Exit
SMIT SOCC panel.
F3 = Cance l
F7 = Edit
Enter = Do
[ Entry F i elds ]
[ 80]
F4 = Li s t
F 8 = Image
1 87
to 1600 MB/s. HIPP! uses a copper-cable interface supporting dis­
tance of up to 25 m in a point-to-point topology. HIPP! extenders mul­
tiplex copper onto fiber to reach distances exceeding 10 k. HIPP!
switches and crossbars may be used to interconnect multiple devices.
The RISC System/6000 supports HIPP! connections using the
High-Performance Parallel Interface Driver Group I 6000 in conjunc­
tion with HIPP! Micro Channel adapters. The driver set supports
TCP, UDP, and master/slave IPI-3 (Intelligent Peripheral Protocol).
The TCP/UDP protocol set may be used to interconnect to other com­
puters. The IPl-3 protocol is employed for connecting to mass storage
systems and devices.
1 1 .4.8
Fiber Channel Standard (FCS)
Just around the corner are some interesting technologies being devel­
oped for high-speed connections. The Fiber Channel Standard shep­
herded by the HIPP! ANSI group defines a fast fiber pipe operating
at 1 gigabit/s to support network protocols. IBM and business partner
Ancor are working to define an open architecture based on FCS for
clustering RISC System/6000s. The proj ect includes Micro Channel
adapter cards and a high-speed FCS switch. FCS will support dis­
tances up to 10 km between stations.
1 1 .4.9
Asynchronous Transfer Mode (ATM)
In Sec. 1 1 . 1.5, I described the emerging Asynchronous Transfer Mode
(ATM) protocol, which is the likely candidate for the next nationwide
network s . IBM will b e m arketing ATM adapters for the RISC
System/6000 architecture in 1994. Along with ATM adapters, the strat­
egy includes an ATM hub and ATM switch for wide area networks.
1 1 .5
TCPn P Software Configuration
The RISC System/6000 provides a couple of methods for configuring
and maintaining TCP services. Like other AIX. services, TCP configu­
ration information is stored in the ODM and maintained using SMIT.
You may also edit the / et c / re . ne t script such that it will configure
network interfaces and set the host name and routes in the tradition­
al way. Commands are also available to import/export configuration
information between the standard tables and the ODM databases.
1 1 .6
Each computer in the network must be known by a unique identifier.
TCP/IP uses three levels of addressing: hardware address, IP number,
and domain name.
1 88
1 1 .6.1
Network Configuration and Customization
Hardware address
Manufacturers encode a unique hardware address into each adapter
that they produce. You might think that this should satisfy network
uniqueness, so why the three levels? Using Ethernet as an example,
the hardware address of an interface is a 48-bit number. The first 24
bits identify the manufacturer. The second 24 bits are assigned
sequentially to represent each Ethernet adapter produced by the
m anufacturer. This number i s all that is require d to identify
machines at the physical network layer. These numbers are a bit
hard to remember, even when represented in hexadecimal.
1 1 .6.2
IP address
A unique IP address is assigned by the network administrator to rep­
resent each computer in the network. The IP address abstracts the
hardware address to a more general use. At this address level, we
aren't concerned with the adapter interface type used on a particular
machine. The IP address format is common across the network.
An IP address is a 32-bit number represented as four octets. Each
octet is a number in the range of 0 through 255: The
address is split into two parts at octet boundaries representing a net­
work address and a host address on that network. The network and
host portions represent address classes. There are three address class­
es: class A, class B, and class C. See RFC 1 166-Internet Numbers for
a complete description of IP address definition.
IP address classes:
16 M*
64 K*
N-network address.
H-host address.
*Numbers 0, 127, 255 are reserved.
Address classes are assigned to organizations depending on the
number of machines they proj ect attaching to the network. If the
organization represents a number of departments, they may want to
request a class A or class B address. This will allow them to assign
class B or class C network addresses respectively to each of the
departments. The departments may then assign and administer the
host addresses available within the network address class.
An example class C network address of 128.99.233 will allow the
administrator to assign host addresses in the range of 128.99.233. 1
through Numbers 0, 127, and 255 are reserved. The
1 89
number 0 is used to represent an octet unknown to the local host. The
number 127 indicates a loopback or local host address. The number
255 is used for broadcast.
Since IP numbers must be unique on the Internet, they are admin­
istered by a central authority. General Atomics I CERFnet, lnterNIC is
a Network Information Center sponsored by the National Science
Foundation. You can obtain the necessary forms to register your site
from JnterNIC . Return the completed forms to: hostmaster@inter­
General Atomics (U.S. Registration)
P.O. Box 85608
San Diego, CA 92186-9784
(619)455-3990 (fax)
ftp site for forms
gopher and wais server
RIPE NCC (European Registration)
Kruislaan 409
1098 SJ Amsterdam
The Netherlands
3 1-20-592-5065
3 1-20-592-5090 (fax)
Even if you don't initially intend to connect to the Internet, it is a
good idea to have the NIC assign you an address class. The address
set assigned will be recorded for your use and will not be assigned to
any other organization. You may administer numbers within the
class. Later on if you connect to the Internet, it will eliminate the pos­
sibility of having to renumber all your host addresses due to address
collisions with other sites.
1 1 .6.3
Domain address
Although IP addresses uniquely identify computers on the network,
they are not easily remembered. This brings us to the third level in
the addressing hierarchy, domain address.
The simple solution is to map host names to the associated IP num­
bers. These host tables are installed on each machine in the network
and provide a directory for host name to IP number address resolu­
tion. This works for small networks but immediately breaks down as
we scale up to large numbers of systems. Mapping host names to IP
1 90
Network Configuration and Customization
numbers is subject to the same scaling problems encountered when
mapping given names to phone numbers in a large city. There are far
too many name collisions and the phone book is too large for timely
incorporation and distribution of updates.
1 1 .6.4
Host tables
For small networks , the simplest address resolution method is to
record the host name to IP number of all the machines in the network
in a table. The table is then distributed to each machine in the net­
work. This method is implemented by the I e t c / ho s t s file.
Example / e t c / ho s t s :
1 1 .6.5
ll IP Number
Host Names
127 . 0 . 0 . 1
1 2 8 . 95 . 13 5 . 13
1 2 8 . 9 5 . 13 5 . 24
1 2 8 . 9 5 . 142 . 3 0
140 . 27 . 133 . 4
daf fy
donal d
Domain name service
To address the scaling problem, a hierarchical name space methodolo­
gy was adopted for the Internet community which enforces uniqueness
and supports timely distribution of updates. This name space system
is a client/server protocol called BIND Domain Name Service (DNS).
Computers and organizations in DNS are identified by a domain
name. A domain name is a name tuple, delimited by "."s, which repre­
sents the administrative hierarchy of the name space of which it is a
member. Domain names are usually represented in two to four levels.
Note that there is no implied mapping of subdomains to IP number
Domain names:
Format :
hos tname . subdomain . subdomain . topdomain
Examples : dingo . bornes . com
vne t . ibm . com
For large networks, the DNS provides a more efficient and distrib­
uted name management and resolution. In the DNS hierarchy, upper­
level domains (see Table 1 1.3) need only record the names of the next
lower level in the tree along with the IP numbers of the name servers
that resolve addresses for that level. A name-resolving protocol called
BIND is used to recursively query name servers until a domain name
is resolved to an IP number. All name servers must know the
addresses of the top-level Internet name servers. This system sup­
ports local management of the name space and ensures timely infor­
mation to the network at large. (Refer to Fig. 11.8.)
TABLE 1 1 .3
Top-Level Domains
Other networks
Two-character international identifier
Country code
1 91
Figure 1 1 .8
Sample Internet domain subtrees.
Name service for an organization or department is handled by two
servers, a primary and a secondary name service daemon, named .
You don't need to run named on each machine in your network. The
named daemon obtains local configuration information from a local
startup file and table. It caches query data it has received from
remote name servers to reduce network traffic. The cached data is
time-dependent and is flushed periodically.
At initialization time, the named daemon reads / e t c / named . boot
to determine if it is a primary or secondary server, the default
domain, zone of authority, and configuration table path.
I e t c / named . boo t for primary server:
; / et c / named . boot primary
directory / etc ; named table path
domain foe . bar . erg ; de fau l t domain
cache . named . ca ; cache f i l e
primary foe . bar . erg primary/named . data ; hos t info
primary 0 . 0 . 1 2 7 . in- addr . arpa primary/named . rev ; reverse info
/ e tc / named . boot for secondary server:
; / e t c / named . boot secondary
directory / e t c ; named table path
domain foe . bar . erg ; de fau l t domain
cache . named . ca ; cache f i l e
1 92
Network Configuration and Customization
secondary foo . bar . org s erverl secondary/named . data ; host info
primary 0 . 0 . 1 2 7 . in- addr . arpa primary/ named . rev ; reverse info
The secondary server will contact the primary server ( s erverl in
the sample) and request a zone transfer of host and reverse pointer
information. It will cache local copies of this data in secondary/
{ named . dat a named . rev } files. This cached data will allow the sec­
ondary server to obtain zone information at startup when the primary
server cannot be contacted.
Once named has identified the configuration path, it reads the
cache file named . ca , the host data file pr imary / named . dat a , and
the reverse data file named . rev to obtain the remainder of the con­
figuration data. IBM provides sample configuration tables in the
/ u s r I lpp I t cp ip I s amp l e s directory.
The cache prime file ( / etc / named . ca in the example) defines the
IP addresses of the authoritative name servers for root domains.
/ etc / named . ca :
root cache
Ini t i a l cache data for root domain servers .
NS . NIC . DDN . MIL .
Prep the cache ( ho twire the addresses ) . Order does not matter
NS . NIC . DDN . MI L .
198 . 41 . 0 . 4
192 . 112 . 3 6 . 4
192 . 3 3 . 33 . 2 4
192 . 5 . 2 5 . 82
12 8 . 6 3 . 4 . 8 2
26 . 3 . 0 . 29
1 9 2 . 3 3 . 4 . 12
128 . 8 . 10 . 90
128 . 102 . 16 . 10
192 . 52 . 19 5 . 10
192 . 3 6 . 14 8 . 17
The host data file pr imary I f o o , identifies table version number,
cache refresh and expire times, query retry time, and host to IP num­
ber identification data for zone foo. The reverse file, named . rev , is
used to supply IP number to host name mapping. Sample awk scripts
are supplied to create named . da t a and name d . rev from existing
/ et c / ho s t s tables .
# hos t s . awk / etc / ho s t s > / e t c / named . data
# addrs . awk / etc /ho s t s > / et c / named . rev
1 93
Information in the files is represented as fields. The fields, in order,
are NAME, Time To Live (TTL), CLASS, TYPE, and Resource Data
(RDATA). The NAME field identifies the host name associated with
the following data. The TTL field indicates the longevity of the infor­
mation in seconds. The CLASS field indicates the protocol type, which
in our case is IN, indicating the Internet. The TYPE and RDATA
fields identify descriptive information for the associated NAME. The
type of data i s based on a set of predefined record type s called
resource records (RR) (see Table 1 1.4).
named . data :
named . data
s erverl . foo . bar . org .
serial number for updates
refresh t ime seconds
retry t ime seconds
expire t ime seconds
s erverl . foo . bar . org .
server2 . foo . bar . org .
1 2 3 . 14 5 . 1 0 0 . 1
123 . 14 5 . 1 0 0 . 2
daf fy
128 . 145 . 100 . 13
"RS / 6 0 0 0 - 5 3 0 , AIX 3 . 2 "
"Je f f Jones , 1 2 3 - 4 5 6 7 "
10 mai l s erver . foo . bar . org
donal d
1 2 8 . 14 5 . 1 0 0 . 3 0
"DEC Alpha , OSFl "
" Jenny Smi th , 1 2 3 - 6 7 8 9 "
10 mailserver . foo . bar . org
$ ORIGIN foo . bar . org .
3 600000
Name Servers
s erverl
s erver2
; Hos t Names
named . rev :
TABLE 1 1 .4
Resource Records
IP address of the site
Canonical name-other alias names
Descriptive host information for the site
Preferred mail handler for the site
Identifies authoritative name server
Pointer to another part of the name space
Start of zone of authority
Well-known services supported at this site
1 94
Network Configuration and Customization
named . rev
serverl . foo . bar . org .
serial number for updates
refresh t ime seconds
retry t ime sec onds
expire t ime sec onds
s erverl . foo . bar . org .
s erver2 . foo . bar . org .
serverl . f oo . bar . org .
server2 . f oo . bar . org .
da f fy . foo . bar . org .
donald . foo . bar . org .
3 600000
Name Servers
Hos t Names
The named daemon may also be run as a caching only server. In the
caching only mode, the server does not supply any preconfigured host
data. It only gains data by querying other name servers.
Each machine in the organization that will be using name service
must have an / e t c / r e s o lv . c o n f file that identifies the default
domain name and a list of name servers. When resolving a name to
IP address, a query is sent to the first name server in the list. If the
timeout period expires before an answer is received, then the second
name server is tried.
/ e tc / re s o lv . conf :
; / etc / resolv . conf
name server
names erver
1 1 .7
foo . bar . org
123 . 145 . 100 . 1
123 . 145 . 100 . 2
defau l t domain
name s erver
name server
Network Routing
It's not enough to know someone's name in the network. In order to
send messages to them you have to also know where they are and
how to get there. Just like the interstate highway system, in order to
navigate a network we rely on information provided by third parties
concerning which path to take at each junction. This is called routing.
In the previous discussion on hardware, I talked about how routers
and gateways exchange network topology information based on each
device's view of their neighborhood. It is this information that we are
trusting when we embark on j ourneys through the network. These
devices use a number of tried and true protocols (see Table 1 1.5) to
derive their view of the network at large. These protocols are based
TABLE 1 1 .5
1 95
Routing Protocols
External Gateway Protocol
Routing Information Protocol
Internal Gateway Routing Protocol
Initial "Fuzzball" NFSnet Protocol
Open Shortest Path First Protocol
on algorithms that maintain hop count metrics or compute spanning
trees to determine the best route through the network jungle.
Routing information may be determined dynamically by querying
the routers for a path from point A to point B, or by the use of static
routes configured by the system administrator. Static routes work
fairly well for small networks, but as with the name space, they break
down as the network size gets large.
1 1 .7.1
Static routes
Static routes are set with the r o u t e command. In most cases, a
default route is set for all instances to a knowledgeable local router.
Additional static routes may be set for networks and individual hosts.
Static routing information is normally set as part of the systems tcpip
startup procedur e s . It may be set via SMIT, or by e diting the
/ e tc / re . tcpip startup script. When adding a static route, specify
the type of route (network, host), IP address of the destination, IP
address of the router, and the number of hops.
Static routes:
Default route
/ etc / route add de fau l t 1 2 3 . 1 4 5 . 1 0 0 . 1 0
/ e t c / route add ne t 1 2 3 . 1 4 5 . 5 0 . 0 1 2 3 . 1 4 5 . 5 0 . 1 0 0
Route to a net
/ etc / route add hos t 1 2 3 . 1 4 5 . 4 0 . 2 1 2 3 . 1 4 5 . 4 0 . 3 3
Route to a host
/ e tc / route - f
Flush all routes
You may query defined routes using the ne t s tat - rn command.
The - r indicates that ne t s tat is to report routes and the -n flag
specifies not to use name service to determine names. This is much
faster and will keep ne t s tat from hanging when there are routing
problems that inhibit access to name service.
# ne tstat -rn
Routing tables
Dest ination
Netmasks :
( root node )
(0) 0
( 0 ) 0 ffOO 0
( 0 ) 0 ffff ffOO 0
( root node )
Route Tree for Protocol Fami ly 2 :
( root node )
F l ags
1 96
Network Configuration and Customization
de fau l t
12 8 . 9 5 . 13 5
( root node )
12 8 . 9 5 . 13 5 . 1 0 0
12 7 . 0 . 0 . l
1 2 8 . 95 . 13 5 . 13
4243 9693
Route Tree for Protocol Family 6 :
( root node )
( root node )
1 1 .7.2
Dynamic routes
Collecting and/or broadcasting dynamic routing information is the job
of the routed and gated daemons. The routed daemon understands
the RIP protocol. RIP bases routing data on hop counts. A site with a
hop count larger than 16 is deemed unreachable. The gated daemon
understands RIP, EGP, and Hello protocols. EGP also responds to
Simple Network Monitoring Protocol (SNMP) queries. The routed
and gated daemons use information configured in the / etc / ga t e ­
way s t a b l e to identify other network gateways w i t h which t o
exchange information. I f the RIP protocol is used, then known net­
works are also listed in the / e t c / networks table. Unless you are
setting up a network router, you will want to use routed in query­
only mode to learn routes from the active routers in the network.
When used, the routed or gated daemons are started with the tcpip
subsystem. You may enable them using SMIT or by editing the
/ et c / re . ne t startup script.
/ et c / routed - q
Query-only mode
/ et c / routed - s
Announce routes
/ e tc / routed - t
Trace packets
# startsrc -s gated
Start gated daemon
/ etc / ne tworks :
loop 1 2 7 loopback
e thernet 1 2 3 . 14 5 . 1 0 0
/ e tc / gateways :
net FOOnet
1 1 .7 .3
gateway serverl
metric 0
act ive
Subnets are a mechanism that allows an organization with many
internal networks to hide the internal structure and routing and
announce a single network address to the outside world. A subnet
mask is used to mask out a portion of the host half of an IP address to
be used for routing. Most commonly this is done by using a class B
address known to the outside world and masking the third octet as
subnet numbers.
1 97
When a machine within the organization wants to send a packet to
another system, it applies the subnet mask to the destination address
to see if the address is on the local network or if it must send it to a
router for delivery.
The subnet mask is a four-octet number that indicates which bits in
the address are to be masked as the network and subnet portion of
the address. The low-order bits of the mask designate the host portion
of the address.
1 1 .7.4
netmask Oxf f f f f f f O
1 4 hosts per subnet ( 0 and 1 5 excluded)
netmask Oxf f f f f f f 8
6 hosts per subnet (0 and 7 excluded)
Interface configuration
To begin using the network, the adapter interface must be configured
with the local machine IP address, subnet mask, and broadcast
address. The interface may be configured using SMIT or by adding an
i fc on f i g entry in the I e t c / re . net startup script (see Fig. 1 1.9).
II smi t chgeth
i fconfig parameters:
i fconfig enO 1 2 3 . 14 5 . 1 0 0 . 1 8 netmask Oxf f f f f f O O broadcast 1 2 3 . 14 5 . 1 0 0 . 2 5 5
Minimum Con f i guration and Startup
To Delete exi s t ing configurat i on data , please use Further Configuration menus
Type or select values in entry f i elds .
Press Enter AFTER making a l l des i red changes .
* Internet ADDRESS
( do tted decimal }
Network MASK ( dot ted dec ima l }
Internet ADDRES S ( do t ted decima l )
Defau l t GATEWAY Addre s s
( do t ted dec imal o r symbol i c name }
Your CABLE Type
START TCP / I P daemons Now
F l = Help
Esc + 5 = Undo
Esc + 9 = She l l
Figure 1 1 .9
F2 = Re f resh
Esc + 6 = Command
Esc + 0 = Exi t
SMIT TCP config panel.
[ Entry F i elds ]
[ l orri e ]
[ 12 3 . 14 5 . 1 0 0 . 1 8 ]
[255 . 255 . 255 . 0 ]
[ 12 3 . 1 4 5 . 1 0 0 . 1 ]
[ foo . bar . org]
[ 12 3 . 14 5 . 100 . 1 0 0 ]
F3 = Cance l
Esc + 7 = Edi t
Enter = Do
F4 = Li s t
E s c + 8 = Image
1 98
Network Configuration and Customization
The adapter interface can be brought up and down for maintenance
or testing using SMIT or, from the command line, using the i f c on­
fig command. Note that this will interrupt service to tcpip daemons.
1 1 .8
# i fcon f i g enO up
Start Ethernet interface
# i f config tkO down
Stop token-ring interface
System Resource Controller
The system resource controller (SRC) is a facility that allows the sys­
tem administrator to easily manage a group of associated daemons
and services as a single entity called a subsystem. Each of the dae­
mons or services belonging to a subsystem is known as a subserver.
Subsystems that are related in function can be combined as a subsys­
tem group. SRC administration commands allow the system adminis­
trator to start, stop, refresh, and trace subsystem groups, subsystems,
and subservers as a unit, thus eliminating the complexity of dealing
with each component individually.
SRC commands:
s tartsrc / s topsrc [ -g ]
refresh [ -g ]
traceon/ traceoff [ -g ]
l s src ( - 1 ]
[ - s ] < subsystem>
[ - s ] < subsystem>
[ - s ] < subsys tem>
[ - s ] < subsys t em>
Start/stop a group or subsystem
Refresh a group or subsystem
Turn trace on or off
List subsystem status
The SRC system master daemon, / et c / s rcms tr, is started at boot
time by an entry in I e t c I ini t t ab. Subsystems are also started by
entries in / e tc / init tab using the s tartsrc command.
1 1 .8.1
TCP/IP subsystem
TCP/IP runs as a subsystem under ADC. This means that it is under
the control of the system resource controller (SRC). The associated
daemons that make up the TCP/IP subsystem are known as sub­
servers. Daemons controlled by the master TCP/IP daemon, inetd,
like f tpd, are known as subservers. All services associated with
TCP/IP may be started or stopped using the SRC s t a r t s r c and
s tops rc commands.
1 1 .8.2
# s tart s rc -g tcpip
Start tcpip services
# s topsrc -g tcpip
Stop tcpip services
Master daemon-inetd
Rather than running some of the TCP/IP service daemons continu­
ously, they can be started when a request is made for the service and
shut down when the service has been completed. This capability is
supported by the inetd daemon.
1 99
Configuration for inetd is located in the I e t c I inetd . conf and
/ e t c / s ervi c e s tables. These tables are mirrored by the Ine t Serv
object class in the ODM. Any changes to the table information must
be reflected in the ODM. Changes made to these tables through SMIT
will automatically be incorporated in the table and the ODM. SMIT
updates will also refresh inetd . If you want to maintain the tables
using your favorite editor, you may use the inet imp and inet exp
commands to copy table information to the ODM and from the ODM
# inet imp
Import inetd.conf and services to InetServ ODM
# inetexp
Export InetServ ODM to inetd.con and services
Entries in the I e t c I inetd . c o n f file indicate the service name
and startup information. The / e t c / s ervi c e file lists the service
name, whether it uses TCP and/or UDP protocols , and the well­
known port number associated with the service. Any time updates are
made to either of these tables, you will need to refresh inetd. This
can be done with the SRC r e f resh command or by sending a hangup
signal to the inetd process. Note that some daemons require that the
portmap daemon be running.
# refresh inetd
# ki l l - HU P < inetd-pid>
/ et c / inetd . c onf :
# inted . conf
# s ervice
# name
dis card
dis card
f tp
t ime
t ime
t f tp
l ogin
she l l
s t ream
s tream
s t ream
s tream
s tream
s tream
s tream
s tream
s tream
s tream
s tream
s tream
pro otcol
wai t /
nowa i t
nowa i t
wai t
nowa i t
wai t
wai t
nowa i t
wai t
nowa i t
wai t
wai t
wai t
nowa i t
wai t
wai t
wai t
/ e tc / f tpd
/ e t c / t elnetd
/ e t c /bootpd
/ e tc / t f tpd
/ e tc / fingerd
/ e t c / rexecd
/ e t c / rlogind
/ e t c / rshd
/ e t c / talkd
/etc / talkd
/ et c / uucpd
/ e tc / comsat
argument s
f tpd
te lnetd
tf tpd -n
f i ngerd
r l ogind
Network Configuration and Customization
The / e tc / s ervi c e s file represents the mapping of service name
to associated well-known ports.
/ etc / servi c e s :
# Network wel l known s ervices
# Service
Por t / Protocol
sys tat
nets tat
f tp-data
f tp
arc f tp
t ime
t ime
who i s
t f tp
rj e
f inger
l ink
hos tnames
x4 0 0
x4 0 0 - snd
au th
s f tp
snmp - t rap
she l l
7 / tcp
7 / udp
9 / tcp
9 /udp
l l / tcp
1 3 / tcp
1 3 /udp
1 5 / tcp
1 7 / tcp
1 9 / t cp
1 9 /udp
2 0 / tcp
2 1 / tcp
2 2 / tcp
2 3 / tcp
2 5 / tcp
3 7 / tcp
3 7 /udp
3 9 /udp
4 2 /udp
4 3 / tcp
5 3 / tcp
5 3 /udp
5 7 / tcp
67 /udp
6 8 /udp
6 9 /udp
7 7 / tcp
7 9 / tcp
8 7 / tcp
9 5 / tcp
1 0 1 / tcp
1 0 2 / tcp
1 0 3 / tcp
1 0 4 / tcp
1 0 5 / tcp
1 0 9 / tcp
1 1 1 / tcp
1 1 1 /udp
1 1 3 / tcp
1 1 5 / tcp
1 1 7 / tcp
1 1 9 / tcp
1 2 3 / tcp
1 2 3 /udp
1 4 4 / tcp
1 6 1 /udp
1 6 2 /udp
1 9 9 / tcp
2 0 0 /udp
5 1 2 / tcp
5 1 3 / tcp
5 1 3 /udp
5 1 4 / t cp
s i nk nul l
s i nk nul l
quot e
t tyts t source
t tytst s ource
# unitree auto login
mai l
t ims erver
t imserver
resource # resource location
name # IEN 1 1 6
nameserver # name -domain server
# deprecated
# bootp s erver port
# bootp c l ient port
netrj e
t ty l ink
hos tname # usual ly from sri-nic
pos to f f ice
readnews untp
# network t ime protocol
( exp )
snmp reques t port
snmp moni tor trap port
snmpd smux port
Sys tem Resource contro l l er
cmd # no pas swords used
sys log
ef s
t imed
c onf erence
netwa l l
new- rwho
remo t e f s
5 1 4 /udp
5 1 5 / tcp
5 1 7 /udp
5 1 8 /udp
5 2 0 / tcp
5 2 0 /udp
5 2 5 /udp
5 2 6 / tcp
5 3 0 / tcp
5 3 1 / tcp
5 3 2 / tcp
5 3 3 /udp
5 4 0 / tcp
5 5 0 /udp
5 5 6 / tcp
5 6 0 /udp
5 6 1 /udp
spooler # l ine printer spooler
# for LucasFi lm
router routed
t imeserver
# for emergency broadcas t s
uucpd # uucp daemon
rf s_server r f s # remo te f i l esystem
Table 1 1 . 6 represents a selection of servers that may be managed
by inetd . The list is not exhaustive, but represents some of the more
common applications.
1 1 .8.3
Other network daemons
Not all TCP/IP service daemons run under control of inetd . You
may also choose to run an inetd subserver as a stand-alone daemon
to service high traffic loads. This eliminates the overhead involved in
restarting the daemon for each service request. Start stand-alone ser­
vice daemons using an entry in I e t c I i n i t t ab or from a local
re . l ocal file (see Table 1 1 . 7).
1 1 .8.4
Start-up configuration
The TCP/IP subsystem is normally started at system boot via an entry
in I etc I ini t tab . The subsystem I etc I re . net and I etc I re . tcpip
configuration files contain entries to enable the network interface, set
TABLE 1 1 .6
f tpd
te lnetd
s endmai l *
c omsat
f ingerd
t f tpd
ins t s rv
inetd Subserver Daemons
File transfer daemon for f tp
Network login daemon for t e lnet
Network remote login for r l ogin
Remote shell daemon for rsh
Remote command execution daemon
Network mail daemon
Network chat daemon for talk
Announce incoming mail
Display user information for f inger
Trivial file transfer daemon for t f tp
TCP/IP to UUCP gateway
Support bootp requests
AIX network installation server
*Sendmail may run as a subserver of inetd or as a stand­
alone subsystem.
Network Configuration and Customization
TABLE 1 1 .7
t imed
sys l ogd
TCPnP Subsystem Daemons
Master TCP/IP daemon. Listens to ports
and launches associated subserver dae­
Routing daemon supports RIP, EGP, and
Routing daemon supporting RIP.
Domain name service daemon.
Packet tracing support.
List logged in users on subnet systems.
Network time server.
Log daemon for network services.
*Make certain that these two daemons are not running at the
same time.
the host name, set the default route, start inetd , etc. If you want to
start tcpip s ans SRC and the ODM, comment out the entrie s in
/ etc / re . ne t following the text Part I-Conf iguration using the
data in the ODM database . Remove the comments from section
Part I I-Tradi t i onal Con f i guration and tailor the host name,
network interface, and default routes per your installation.
Example / e tc / re . ne t Part II:
################################################################# #
# Part II - Tradi t i onal Con f i gura t i on .
/bin /hos tname lorrie . foo . bar . org
/usr/ sbin / i fconfig enO inet ' ho s tname ' up
/usr/ sbin/ route add default 1 2 3 . 1 4 5 . 1 0 0 . 1 0
1 1 .9
> > $ LOGFI LE 2 > & 1
> > $ LOGFILE 2 > & 1
> > $ LOGFI LE 2 > &1
The RS/6 0 0 0 supports dial-up TCP/IP via Serial Line Internet
Protocol (SLIP) provided with AIX, and Point-to-Point Protocol (PPP)
from third-party vendors. SLIP is a very simple encapsulation proto­
col which will likely be replaced by the more robust PPP. In the fol­
lowing configuration discussion, it is assumed that a serial port has
been defined to the system for modem connections. Note also that the
standard TCP/IP addressing and routing specifications apply to SLIP.
Refer to Fig. 1 1 . 10.
The TTY port must be set to DISABLE for SLIP. You cannot use
the DELAY or SHARE states.
The dial string is modem-dependent and will be set for either dial­
out or auto-answer for incoming connections. The format of the dial
string is the same as used by UUCP.
Sample Hayes Dial String:
ATZ OK ATDT 1 2 3 - 4 5 6 7 CONNECT
Nul l from modem
Minimum Conf igurat ion & Startup
To Delete exi s t ing con f i gurat ion data , please use Further Conf igurat i on menus
Type or s e l e c t values in entry f ields .
Press Enter AFTER making a l l des i red changes .
* Internet ADDRESS
( dotted dec ima l )
Des t inat i on ADDRESS
Network MASK ( dotted decimal )
* Ac t ivat e the Inter face After Creat ing i t >
Security Level
* TTY Port for SLIP Network Interface
Baud Rat e
D i a l String
Fl = Help
Esc + 5 = Undo
Esc + 9 = She l l
Figure 1 1 .1 0
F2 = Re fresh
Esc + 6 = Command
Esc + 0 = Exi t
[ Entry F i elds ]
[ l orr i e ]
( 12 3 . 14 5 . 5 0 . 1 8 ]
( 123 . 145 . 50 . 10 ]
( 2 55 . 2 55 . 255 . 0 ]
[ t tyO ]
( 19200]
F3 = Cance l
E s c + 7 = Edi t
Enter = Do
F4 = L i s t
Esc + 8 = Image
SMIT SLIP config panel.
Send reset to modem
Response from modem
Send dial command to modem
Connection s tring
On the system to be dialed into, start SLIP using the s l at tach com­
# s lat tach t ty< ? >
O n the dial-out system, start s l at tach . Note that you may include
the baud rate and dial string on the command line.
# s l a t tach t ty< ? > 1 9 2 0 0 " " ATZ OK ATDT1 2 3 - 4 5 6 7 CONNECT
To disable a SLIP connection, send a hangup { HUP ) signal to the
s la t tach process. DO NOT USE - 9 { KI LL ) , as this may cause sys­
tem panics.
PPP goes beyond the simple encapsulation protocol used by SLIP.
It provides session negotiation options, link level error detection, com­
pression, and authentication. PPP is available from a number of
third-party vendors.
1 1 .1 O
Anonymous FTP
Anonymous FTP is a common service available on the Internet that
provides public access to repositories of public domain applications
and information. Care must be taken when configuring an anony-
Network Configuration and Customization
mous FTP server, since you are granting a level of access to your sys­
tem without password protection. You want to limit the commands
and the directory paths that are accessible.
Create an account (ftp) and directory path to be used for anony­
mous ftp. The f tpd daemon provides a level of protection by invoking
chroot ( 2 ) to set the root directory to the directory owned by the ftp
account, effectively hiding anything outside that path. Create bin ,
e t c , and pub subdirectories in the ftp account home directory. Copy
the l s command to the bin subdirectory. Install edited copies of
/ etc /pas swd and / e t c / group in the etc subdirectory. These files
should only contain root, daemon, and ftp accounts. Install software
and documents you wish to make available in the pub directory. Refer
to Table 11.8.
A replacement f tp d server that provides additional options for
anonymous ftp is available from wuarchi ve . wu s t l . edu .
1 1 .1 1
Network security is often viewed as a contradiction of terms. It is cer­
tainly true that you increase exposure to unauthorized access when
you permit any outside access to your computing resource. Packet
sniffers are publicly available, allowing users to watch all the data
traversing the wires. Wiretaps for broadcast networks like Ethernet
are easily installed. A workstation in the hands of a hacker can
impersonate trusted addresses. The tradeoffs between exposure and
additional service must be weighed carefully. Network security is not
really the oxymoron that the j oke implies. You have the ability to
implement security measures ; however, as you tighten down the
locks, you may lose services and ease of use.
1 1 .1 1 .1
Network Trusted Computing Base
AIX supports a set of access control and auditing facilities called the
Trusted Computing Base (TCB). The TCB system also encompasses
TABLE 1 1 .8 Anonymous FTP
Directory Permissions.
*Write access will allow incoming data.
You may wish to create a special directo­
ry under -ftp/pub for incoming data.
network support and is known as Network Trusted Computing Base
(NTCB). Along with TCB user authentication mechanisms, NTCB
supplies connection authentication, secure session, auditing of net­
work configuration files and events, and an enhanced security TCP/IP
operation mode.
Connection authentication is provided by defining which remote
host addresses are allowed to connect to the local system. Security
levels may be defined for each network interface to limit the activities
that may take place over a given interface.
Secure sessions are enforced through the use of trusted path, trust­
ed shell (tsh), and secure attention key (SAK). The trusted path and
shell limit the applications that may m ake use of a terminal session.
The SAK establishes the environment necessary for a secure session.
The AIX auditing system records changes in permissions, modifica­
tion times, checksums, and network events.
A full s e t of s e curity fe atur e s may be enabled using the
securetcpip command. s ecuretcpip disables untrusted commands
and restricts access to interfaces that are not configured at specified
security levels. The Berkeley r-commands rsh, rep, r l ogin, and rsh
are disabled, along with t f tp . The f tp , t e l n e t , and rexec com­
mands provide additional security checking. Once the s ecuretcpip
command is invoked, the tcpip lpp must be reinstalled to restore stan­
dard operation. Interface security levels are based on the IP Security
option described in RFC 1038.
1 1 .1 1 .2
Traditional security measures
There are some less drastic measures you can take to secure your
environment . The first i s the j udicious u s e of . r h o s t s and
/ et c / ho s t s . equiv files. Using these files allows use of the Berkeley
r-commands without requiring a password. This eliminates p ass ­
words sent in the clear over the net and limits the damage that may
be done with PTY sniffer programs. It is true that if these files are
compromised they can present a nasty security hole. Care must be
taken when implementing their use. Basically these files list the
hosts and user names that are allowed to execute r-commands with­
out a password.
Connection authentication can be implemented on a service-by-ser­
vice basis by implementing a wrapper program for inetd . The wrap­
per program validates and logs the connecting systems address based
on an access table. The t cpd program available via anonymous ftp
from cert . org is an example of this type of application. The t cpd
system controls access by service class as well as by individual service.
Another authentication mechanism gaining popularity is based on
an encrypted ticket-granting algorithm authorizing timed access to a
service. Tickets are granted by a secure trusted third party. Both the
Network Configuration and Customization
client and server must have the ticket authentication interface incor­
porated into their respective source code. The Kerberos authentication
system follows this schema and is being implemented by most ven­
dors. Kerberos is also the authentication system used by OSF tech­
1 1 .1 1 .3
Security information
The Computer Emergency Response Team (CERT) based at Carnegie
Mellon University tracks and disseminates vendor security information.
CERT regularly posts information to the c omp . securi ty . announc e
Usenet group. They also support an anonymous ftp site containing secu­
rity-related documents. Another Usenet security-related discussion
group is al t . secur i ty . general .
CERT address:
Computer Emergency Response Team/Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
24hr Hot Line: (412)268-7090
anonymous ftp:
1 1 .1 2
Network Management
Implementing and maintaining a smooth-running TCP/IP network
requires a similar network of individuals who plan, administer, oper­
ate , and troubleshoot the components that make up the system.
There are far more models for the assignment of bodies and responsi­
bilities for the people-side of network management than the number
of protocols to be managed. Thus, I won't talk about that here .
However, to make any management structure work, you need good
data collection and alert tools.
A great deal of standards work has gone into defining the Structure
and Identification of Management Information (SMI - RFC 1155), the
Management Information Base (MIB - RFC 1 156), and the Simple
Network Monitor Protocol (SNMP - RFC 1157). SNMP has been recom­
mended by the Internet Activities Board (IAB) as a short-term network
management tool while the ISO Common Management Information
Protocol (CMIP) and CMIP over TCP I IP (CMOT) protocols are investi­
SNMP is a protocol which is used to communicate network element
(NE) statistics and control information to network management sta­
tions (NMS). The NMS clients may set or query variable information
collected by an NE . Asynchronous traps may be generated by an NE
and delivered to an NMS client. The standard defines communication
based on UDP. Variable types are grouped as obj ects. RFC 1213 pro­
vides a complete list of MIB obj ects and variable descriptions.
1 1 .1 2.1
AIX SNMP and NetView/6000
AIX V3 provides both SNMP client and agent functions. The client
snmp i n f o application supports SNMP GET, NEXT, and SET func­
tions. The AIX SNMP agent, snmpd , supports these MIB-11 groups :
system, interface, at, ip, icmp, tcp, udp, egp, transmission, and snmp.
An API is provided for application access to MIB data and alerts.
MIB variables are stored in the / etc /mib . de f s and / e tc / mib_des c
files. MIB obj ects are managed using the mo sy command. Refer to
RFC 1213 for a complete list of MIB-11 groups.
The NetView I 6000 Entry licensed program product can be used to
manage and graphically display information of up to 32 snmpd
agents. NetView/6000 provides a dynamic discovery capability which
automatically scopes out and maps your network for management.
The Motif based GUI can be used to graphically display network
topologies and graph MIB information. For networks larger than 32
nodes, the System View NetView I 6000 V2 licensed program product is
available. Additional support includes a number of APis and CMOT
support. Refer to Table 1 1.9.
C o nfigurati on data for the s nmp d agent i s s p e cified in the
I etc I snmpd . conf file. Configuration information includes the path
and size of the log file, MIB views, access permissions, traps , and
snmpd parameters. Well-known port numbers for snmpd network
access must be defined in / et c / s ervi c e s .
TABLE 1 1 .9
SystemView NetView/6000 MIB Support
c i s c o - 9 . 1 . mib
f ibermux-cros sbow . mib
hp -unix
ibm- 6 6 1 1 -vlrl . 1 . mib
ibm-alert . mib
ibm-nv6ksubagent . mib
net- lwx- rl . mib
nove l l -hubnvl e - 1 . 0 . mib
nove l l -hubnvl tr-2 . 0 . mib
nove l l - l antern- 1 . 3 . mib
nove l l -nw2 snmp - 1 . 0 . mib
ods -RFCEnBridge . mib
ods - enc . mib
ods - tr . mib
proteon . mib
r fc 1 2 1 3 -MIB- I I
r fc 1 2 2 9 -GINTF
rfc12 3 0 - 8 0 2 . 4
rfc 1 2 3 1 - 8 0 2 . 5
r f c 1 2 3 2 -DS 1
r fc 1 2 3 3 -DS3
r f c 1 2 4 3 -APPLE
r f c 1 2 5 3 -0SPF
r f c 1 2 6 9 -BGP
r fc 1 2 7 1 -RMON
r fc 1 2 8 4 -ETHER
r f c 1 2 8 5 -FDDI
r f c 1 2 8 6 -BRIDGE
r f c 1 2 8 9 -DECNET
rfc1 3 0 4 -SIP
r f c 1 3 1 5 -FRAME
r f c 1 3 1 6 -CHAR
r f c 1 3 1 7 -RS2 3 2
r f c 1 3 1 8 - PARALL
suminet - 3 5 0 0 - 1 . 0 . mib
synop t i c s - common . mib
synop t i c s - e thernet . mib
synopt i c s - i eee 8 0 2 3 . mib
synop t i c s - tokenring . mib
synop t i c s - trap . mib
ung-ba s s - asm3 2 0 - 1 6 . 7 . mib
ung-ba s s - suprv- 1 6 . 7 . mib
wel l f l e e t - 6 . 0 . mib
xylogi c s - annex- 7 . 0 . mib
xylogi c s - annex . mib
xypl ex-boo t - c l i ent . mib
xypl ex-bo o t - s erver . mib
xyp l ex-bridge . mib
xyp l ex- charac ter . mib
xyp l ex-decnet . mib
xyplex-etherne t . mib
xyp l ex-hub . mib
xyp l ex - i eee -hub . mib
xyp l ex- int erne t . mib
xypl ex- lat . mib
xypl ex-mini . mib
xypl ex-param- c l i ent . mib
xyp l ex- sys t em . mib
Network Configuration and Customization
snpd I e t c I servi c e s ports:
srunp- trap
1 6 1 / upd
1 6 2 /udp
1 9 9 / tcp
/ etc / snmpd . c onf :
II smpd . conf
II Log attributes
l ogging f i l e = /var / srunpd/ log enabled
l ogging s i z e = 0 l evel = 0
II MIB views
II View name is an arbi trary three integer ident i fier
<view name>
<MIB l i s t >
II view
1 . 15 . 7
1 . 15 . 6
sys tem
II Who has access to agent MIB information
II Communi ty names de fined in / e t c / communi ty
II communi ty <name>
<address> <netmask>
communi ty publ i c
communi ty private daf fy
<permi s s i on> <view name>
2 5 5 . 2 5 5 . 2 5 5 . 0 readWri t e
1 . 15 . 7
II traps to catch
block no traps
II trap mask :
block c o l dStart trap
block warmStart trap
Block both coldS tart and warmS tart traps
<view name>
<communi ty name>
II trap
publ i c
da f fy
1 . 15 . 7
II snmpd parameters
snmpd maxpacket = 1 0 2 4 querytimeout = 1 2 0 smuxt imeout = 6 0
The s nmpd daemon can be started and stopped as a subsystem
using the SRC s tart s r c and s t opsrc commands or via SMIT. It
can also be started with the tcpip subsystem.
1 1 .1 3
II startsrc -s snmpd
Start srunpd
II s topsrc
Stop srunpd
-s srunpd
If something can go wrong, it will go wrong. Sounds like Murphy was
talking about computer networks! Distributed systems magnify the
compl exity of s t a n d - alone systems by orders of magnitu d e .
Unfortunately, there isn't much in the way of integrated tools to
assist the administrator with troubleshooting problems.
1 1 .1 3.1
Probably the best tool to have handy for medium-to-larger networks
is a sniffer. A sniffer is a custom computer that attaches to the net­
work to analyze packet traffic. These systems are compact, so they
can be taken anywhere and are tuned to keep up with packet rates.
Packet types can be filtered and logged to provide statistics over time.
For the budget-minded, there are packages available for workstations
and PCs which provide many of the same functions.
1 1 .1 3.2
AIX iptrace
If portability isn't a problem, the AIX iptrac e and ipreport com­
mands do a very good job at collecting IP traffic traces. The iptrac e
command supports options to record traffic by protocol, host, port,
and interface. Protocol types must be defined in the I e t c / p r o t o ­
c o l s file. Output from iptrace i s recorded i n a file which can later
be formatted into a report using the ipreport command.
# iptrace / tmp / trace . data
# ipreport / tmp / trace . data / tmp / trace . report
1 1 .1 3.3
Interface status
The ne t s tat command can be used to display interface statistics and
connection status for a given workstation or host. An interval flag
may be used to record snapshots over time.
Useful net s tat f l ags :
1 1 .1 3.4
Summary packet rates and errors by interface
Display active connection status
Display routing table information
Display mbuf allocation and usage
When you want to check reachability, the ping command is a useful
tool. ping sends ICMP echo requests to a remote site. Statistics are
gathered and displayed based on the round-trip time and dropped
packets. In most cases, reachability problems will be related to rout­
ing information or netmask.
# ping foe . bar . com
PING foe . bar . com ( 1 3 0 . 1 1 1 . 5 8 . 1 ) : 5 6 data bytes
6 4 bytes from 1 3 0 . 1 1 1 . 58 . 1 : icmp_seq = 0 ttl = 2 5 2 t ime = 8
64 bytes from 1 3 0 . 1 1 1 . 58 . 1 : icmp_seq = 1 t t l = 2 5 2 t ime = 3
6 4 bytes from 1 3 0 . 1 1 1 . 58 . 1 : i cmp_seq = 2 t t l = 2 5 2 t ime = 8
64 bytes from 1 3 0 . 1 1 1 . 58 . 1 : i cmp_seq = 3 t t l = 2 5 2 t ime = 5
-- foe . bar . com ping s t a t i s t i c s -4 packet s transmi tted, 4 packe t s received , 0% packet l o s s
round- trip min / avg/max = 3 / 5 / 8 ms
21 0
Network Configuration and Customization
1 1 .1 3.5
Server applications
The t e lnet command can be used to validate the operation of a serv­
er application that is listening on a particular port number. Use the
port number option with telnet to connect to the remote port. Once
you have connected, you can interactively initiate a dialog with the
# telnet daf fy . foo . bar . org 2 5
1 1 .1 3.6
Telnet to smtp port
Name service
To validate the operation of your name servers, use the ns l o okup
command. ns l ookup can be directed at individual name servers and
request specific resource record information. It also supports specify­
ing the query type to use.
# ns l ookup
> daf fy . foo . bar . org
Server : <de faul t . server>
Addres s : 1 2 1 . 9 1 . 1 3 0 . 1
Non-authoritative answer :
Name : daf fy . foo . bar . org
Addre s s : 1 2 1 . 9 1 . 1 3 5 . 1 4
1 1 .1 3. 7
mbuf allocation
Large networked multiuser or application server systems often run
into the problem of exhausting network buffers called mbufs. mbuf
structures are used to store data moving between the network and
the operating system. Under older versions of UNIX, when you hit
the mbuf wall, you had to increase a kernel parameter for mbufs
and/or mbclusters, rebuild the kernel, and reboot. This is real bad
news for your up-time statistics.
AIX provides an mbuf management facility that dynamically con­
trols the allocation and use of mbufs and mbclusters. The default allo­
cation is based on a low-to-medium packet rate and is somewhat
dependent on the number of adapters. The mbuf management facility
netm controls the minimum and maximum available free space in the
pools, and the maximum amount of memory that may be used for the
pools. Note that the mbuf and mbcluster pools are pinned in memory.
netm increases the pool sizes as network load increases. The mbclus­
ter pool is reduced as load decreases; however, the mbuf pool is never
decreased. Each mbuf is 256 bytes in size and each mbcluster is 4096
bytes. (Refer to Table 1 1 . 10.)
You don't want netm to be dispatched unnecessarily, and you don't
want to overcommit memory to mbuf pools. What you need to do is
monitor your packet rates under normal loads and adjust the mbuf
parameters at boot time to pin as much memory as you will need and
no more. You can modify the following mbuf parameters with the no
TABLE 1 1 .1 0
21 1
Kernel mbuf Variables
l owmbuf
l owc lust
thewa l l
Free mbuf low water mark
Free mbcluster low water mark
Max number of free clusters
Max memory available mbufs and clusters
command. Build a script which is run at boot time to set the parame­
ters and execute a packet spray program or ping in a loop to generate
enough network traffic to pin the memory required.
1 1 .1 4
lnfoExplorer Keywords
traceo f f
t f tpd
chgene t
l s s rc
boot pd
s rcms tr
ops change
/ e tc / ini t t ab
s l a t tach
ine td
/ e t c / inetd . conf
s ecure tcpip
/ et c / servi c e s
/ et c / ho s t s . equiv
/ et c / ho s t s
inet imp
/ e tc / re s o lv . conf
nets tat
f tpd
/ e tc /mib . de f s
te lnetd
/ e tc /mib_de s c
rl ogind
mo sy
/ e t c / gat eways
/ et c / snmpd . c onf
/ et c / networks
/ et c / re . ne t
iprepor t
i f config
s endma i l
/ et c /pro t o c o l s
s tart src
c omsat
p ing
re fresh
f ingerd
ns l o okup
trace on
1 1 .1 5
Network adapters:
21 2
Network Configuration and Customization
smit chgene t , chgtok, chgfddi , opschange
Adptr config fast paths
i fcon f i g
Config interface
/ etc /ho s t s
Static host table
/ e tc / resolv . conf
Name servers for address resolution
/ etc / named . boot
Name server config
/ etc / named . ca
Root name server cache
/ etc / named . data
Address listing
/ etc / named . rev
Reverse pointer listing
ns lookup
Query name server info
Network routes:
Administer routes
netstat -rn
List defined routes
Routing daemon (RIP)
Routing daemon (RIP, EGP, Hello)
/ et c / gateways
Known gateways
/ etc / networks
Known networks
/ e tc / s ervi ces
Well-known ports
/ etc / inetd . conf
inetd subservers
inetimp / inetexp
Import/export tables to/from ODM
TCPIP Group Subsystem:
/ e tc / re . net
TCPIP startup config
s tartsrc -g tcpip
Start all tcpip subsystems
s tartsrc -s inetd
Start master Internet
Start packet trace
Format trace output
nets tat
Network statistics
Check reachability
Network Trusted Computing Base
Computer Emergency Response Team
/Coordination Center
Software Engineering Institute
Carnegie Mellon University
Secure TCP
Pittsburgh, PA 15213-3890
24-hr Hotline: (412)268-7090
anonymous ftp:
Security checkout package
1 2.1
UUCP Overview
The UNIX-to- UNIX Copy Program (UUCP) is almost as old as UNIX
itself. It was originally developed by Mike Lesk at Bell Labs around the
mid 70s. In the early 80s, it was rewheeled by Peter Honeyman, David
Nowitz, and Brian Redman and became HoneyDanBer UUCP. UUCP
is a simple mechanism which supports remote command execution, file,
and e-mail transfer between consenting systems over dial-up and LAN
connections. AIX knows UUCP as the Basic Networking Utilities
(BNU), which are based on the HoneyDanBer version of UUCP. BNU
services are part of BOS Extencled Services lpp.
UUCP provides an ideal avenue for downloading Usenet News or
providing Internet e-mail access when you don't want to support a con­
tinuous connection to the Internet. Connections may be established
from the local site to trusted remote sites within restricted operation
parameters. UUCP uses a store-and-forward mechanism to communi­
cate with sites beyond immediate neighbors . Files are transferred
from one machine to the next using hop addressing and host tables.
The down side of the store-and-forward nature of UUCP is the extra
administration complexity involved in maintaining the host tables.
1 2.2
Using U U CP
A user invokes a UUCP command to transfer a file to a remote site. A
work file containing address and control information, and a copy of
the file to be transferred, are created in the spool directory. The
uuc i c o daemon is started, which looks up the name of the first host
hop in the / u s r / l ib / uucp / Sys t ems file. The Sys t ems file entry
identifies a connection device which uuc i c o matches to an entry in
the / u sr / l ib / uucp / Devi c e s file.
With the connection information in hand, uuc i c o attempts to con­
tact the remote system. The connection involves logging in to the uucp
21 5
21 6
Network Configuration and Customization
account on the remote system. Passwords to remote sites are main­
tained in the local Sys tems file. A successful login starts uuc i c o on
the remote system. The two uuc i c o daemons communicate as a mas­
ter-slave pair. If permitted by the remote system, the local uuc i c o
daemon transfers any files destined for the remote site. The remote
site, if permitted, may use the connection to transfer files destined for
the local site. The connection is dropped once transfers are complete.
In the event that a connection could not be established, or transfer
was aborted, the transfer request remains in the uucp spool. Periodi­
cally, the uus ched daemon may be spawned by c ron to attempt to
deliver any queued requests.
1 2.2.1
U UCP addressing
UUCP addresses specify each machine name (hop) in the path from
the local to the remote destination. The hop path is read from left to
right and terminates with the recipient user name. Each name in the
path is delimited by an "!".
hopl ! hop2 ! hop3 ! user
daf fy ! beaver ! j e f fries
1 2.3
UUCP Configuration
UUCP operation requires that connection information for neighboring
remote sites is configured into a set of local tables, and that this infor­
mation is coordinated with these neighboring UUCP sites . The easi­
est way to coordinate access with the UUCP community is by joining
UUNET. UUNET is a large UUCP network that provides access to
other UUCP sites and gateways to networks like the Internet and
Bitnet. A small connection and use charge is required, which provides
access to a large number of network services and topology coordina­
tion. For more information on UUNET, contact:
UUNET Technologies Inc.,
Falls Church, Virginia
(703) 204-8000
uunet ! l ia i s on , l i a i son@uunet . uu . ne t
uunet ! info , info@uunet . uu . net
f tp . uu . net
1 2.3.1
Internet Anonymous FTP Site
UUCP login ID
As indicated in Sec. 12.2, each system participating in the network
must supply access to an account for UUCP connection. The AIX
BNU installation process creates a uucp account with UID 5, GID 5 ,
home directory / u s r / s p o o l / uu c p p u b l i c , and l o gi n shell
/ u s r / l i b / uucp / uuc i c o . This account is used to schedule UUCP
activities on the system.
uucp : ! : 5 : 5 : unix to unix
c opy : / usr/ spool /uucppubl i c : /usr / l ib / uucp /uuci co
To reduce the possibility that a remote site could modify local UUCP
configuration tables, create nonprivileged accounts for remote access.
Each additional account should be a member of the uucp group, GID
5. Notify each of the remote site system administrators concerning
the account name and password that they should use when connect­
ing to your system.
1 2.3.2
Host name
Select a host name that identifies your system to the network. If the
number of machines in your network is small, the task is trivial. AIX
BNU supports hosts names up to eight characters. If you will be con­
necting to a large network like UUNET, you will need to coordinate
the selection of a host name such that it does not collide with other
names in the name space. You can query the local host name with the
uunarne command.
ll uuname - 1
1 2.3.3
Directories a n d permissions
Special attention should be devoted to verifying the command, config­
uration files, and spool permissions defined for UUCP. BNU makes
use of four directories:
/usr /bin
User commands
/usr/ lib/uucp
Configuration files and daemons; symbolic link to /et.duucp
for configuration files, /usr/sbin/uucp for daemons and admin·
istrative commands
/usr/ spoo l / uucp
Logs and daemon work space
/usr/ spoo l / uucppubl i c
User directories and UUCP home
All uucp files and directories other than those owned by users in
/ u s r / spoo l / uucppub l i c should be owner and group uucp . Special
permissions are as follows:
/usr / l ib/uucp
uucp / System
Remote sites and passwords
uucp / uuc ico
Master UUCP daemon
uucp / uus ched
Schedule daemon
uucp / uuxqt
Command execution daemon
uucp / { cmds , script s }
Support commands
uucp / { f i l e s }
Other configuration files
21 8
Network Configuration and Customization
/usr/ spoo l / uucp / { subdi rs }
Log and work directories
/usr/ spoo l / uucppub l i c
Public access
Use the uuchec k command to validate directory ownership and
# uucheck
1 2.3.4
Configuration tables
UUCP makes use of five configuration tables : Sys t ems , Devi c e s ,
Permi s s i ons , D i a l e r s , and D i a l codes . You can build a func­
tioning UUCP system by modifying the first three and accepting the
defaults from the Dialers table. The tables may be edited manually
or through the use of the / u s r / l ib / uucp / uucpadm command. uuc ­
padm is a menu-driven utility that allows you to configure table stan­
zas similar to SMIT (see Fig. 12. 1).
# /usr / l ib / uucp/uucpadm
Configuration tables:
Sys tems
Who you will talk to
Devi ces
What interfaces are available for connections
Permi s s i ons
Permissions supported for each remote system
Dial ers
Modem handshaking and negotiation
Dial codes
Phone numbers
1 /usr/ l ib/uucp/ Systems . The Systems table defines who
you will talk to. Because the Systems file contains passwords for
remote systems, special care must be taken to make certain that it is
not accessible by unauthorized users. Each remote system is repre­
sented by a stanza that defines :
System name
Times when connections are allowed
Link type
Uucpadm Opt i ons :
Re turn to thi s menu
Add/Change UUCP Devices
Add/Change UUCP Permi s s i ons F i l e
Add/Change UUCP Sys tems
Add/Change UUCP P o l l F i l e
Add/Change UUCP Dialcodes
Exi t
s e l e c t i on :
Figure 1 2.1
uucpadm panel.
Link speed
Phone number
Login handshaking, user name, and password
21 9
System names may be represented more than once . Additional
entries represent alternate communication links. When a connection
is requested, uuc i c o will try each entry in turn, attempting to estab­
lish the connection.
The Times field represents the days of the week and the 24-hour
clock representation of the times when connections are supported.
Inversely, time intervals outside those represented inhibit connection
attempts . Weekdays are represented with the following character
codes : Mo, Tu, We, Th, Fr, Sa, Su, Wk, and Any. A connection retry
interval in minutes may be specified following the time intervals sep­
arated by a ";". Default retry time is five minutes.
Example time fields:
Wk2 3 0 0 - 0 8 0 0 , sasu
Weekdays between 11
and 8
any time on Saturday and
Access allowed any time
WkO B 0 0 - 1 7 0 0 ; 5
Weekdays from 8 AM to 5 PM with a five-minute retry interval
The Type field represents any device type identified in the Devi ces
file and a conversation protocol. The default protocol is g . (Refer to
Table 12. 1 . )
Device types:
Direct serial link
TCP/IP connection
The C l a s s field defines the line speed in bits per second. If the line
supports any line speed, use the keyword Any .
The Phone field specifies the full phone number for a dial-up con­
nection. If the entry represents a prefix number that is used in multi­
ple entries, an alphabetic abbreviation may be substituted which rep­
resents an entry in the D i a l c odes file.
TABLE 1 2.1
Conversation Protocol
Used for modem connections. Provides
packetizing and checksum functions.
Assumes error-free channel. No packetiz­
ing or checksums.
Use for direct BNU connections. Not reli­
able for modem connections.
Network Configuration and Customization
Example Dialcodes prefix:
local 5 6 4 8
"local" Dialcodes 9
The Login field is a short handshaking script that represents the
login negotiation for connecting to the remote system. It is a graphic
representation of the send and receive character streams that would
be used if you were logging in interactively. The remote site sends
l ogin : . The local site responds with the u s er name. The remote site
sends pas sword : , and so on. It is sufficient to list only enough of the
prompt strings to make them recognizable.
Example Login script:
• • \ r \ d \ r login : -login : uucp word :
Zx&zaO l
Login Script Special Characters
Expect null string
Expect null string
Send End Of Transmission
Send a BREAK signal
Send a BREAK signal
Send a BREAK signal
Suppress new line
Delay one second
Start echo checking
Turn off echo checking
Pause for .25 to .5 seconds
New line
Carriage return
\ ooo
Octal digits
Example system entries:
goofy Any ACU 2 4 0 0 - • • \ r \ d \ r in : -in : uucp word : qrs
venus Any TCP - in : -in : rudy word : l j x7 3 3 z
1 /usr / lib/uucp/Devices . The Devi c e s file defines the con­
nection device types that are available on the system. They are identi­
fied by a Type string, followed by Line, Line2 , Clas s , and Dialer
Tokens (see Table 12.2). Note that the second Line2 field is a holdover
from the old days when modems and dialers were separate devices.
The Type field is commonly:
Direct connect serial link
TCP/IP connection
TABLE 1 2.2
Devices Fields
D i a l e r Tokens
Device type identifier
Second port for 801 dialer
Line speed
1Vlode1n identifier
The Line and Line2 parameters identify the ports used by the con­
nection-for example, t tyl . For a TCP connection, use a "-" charac­
ter as a placeholder.
C l a s s matches the speed parameters specified in the Sys tems file.
It can either be a value representing bits per second or the multi­
speed parameter Any .
The Dialer Token field represents the name of a modem type list­
ed in the Dialers file. It may be followed by a flag indicating where
an associated phone number is located. The \ D flag indicates that the
phone number is specified in the Sys terns file. The \ T flag specifies
the D i a l c ode s file as the source for the phone number. For TCP/IP
connections, use the parameter TC P . For direct connections, specify
direc t .
Example Devi c e s entries:
ACU t tyl - 1 2 0 0 hayes \ D
Direc t t ty2 - 9 6 0 0 direct
1 /usr/ lib/uucp/Permissions . The Permi s s i ons file speci­
fies the privileges available to each UUCP login account or machine
name. Each entry in the Permi s s i ons file specifies the account name,
the send/receive permissions, and the commands that are allowed for
execution. Be very careful not to include setuid shell scripts as part of
the command list. In general, setuid shell scripts are not a good idea
anywhere. Note that these permissions do not affect access to non­
UUCP login accounts. A user at a remote site may access a non-UUCP
login account using c t , cu, or t ip and obtain the full set of permis­
sions and command paths available to the account.
Permissions file stanzas are represented as parameter
Permissions parameters:
LOGNAME = <LoginID : LoginID ... Options >
UUCP account stanza
MACHINE = <MachineName : MachineName ... Opt i ons>
Syste1n stanza
MACHINE = OTHER <Opti ons>
Generic system stanza
Network Configuration and Customization
REQUEST = <yes /no>
Request to transfer
SENDFILES = <yes /no>
File transfer allowed
READ = < PathName : PathName ... >
Read paths
NOREAD = < PathName : PathName ... >
Read exception paths
WRITE = < PathName : PathName ••• >
Write paths
NOWRITE = < PathName : PathName ••. >
Write exception paths
COMMANDS = <Command : Command : ... >
Commands allowed
All commands allowed
VALIDATE = <Name : Name>
Used with COMMANDS = ALL
CALLBACK = <ye s / no>
Callback required
Once configured, you can validate the format of the Permi s s i ons
file using the uucheck command.
# uucheck
Example Permi s s i ons Entry:
LOGNAME = vas e
VALIDATE = j os e
READ = /ul / j o s e
WRITE = / ul / j ose
COMMANDS = l s : who
MACHINE = goofy
UUCP maintains a log of connection attempts by sites not listed in
the Permi s s i ons file. Unauthorized connection attempts are logged
by the remo t e . unknown script in the / u s r / spoo l / uucp / . Admin
/ Fore ign file.
1 /usr/lib/uucp/Dialers . In most cases, you can accept the
default Dialers file as distributed with AIX BNU. The Dialers file
defines the attributes and command strings required to initialize var­
ious modem types. Each modem entry in the file is represented by a
name, dial tone and wait characteristics, and initialization and con­
nection sequence. Add entries to this file when you are using a modem
type that is not listed. (Refer to Table 12.3.)
Default D i a l ers File:
# @ ( # ) 7 1 1 . 3 com/ cmd/ uucp /Dialers , bos , bo s 3 2 0 6 / 1 5 / 9 0 2 3 : 5 7 : 0 9
TABLE 1 2.3
Dialers Special Characters
Wait for dial tone
Null no wait
Delay one second
Carriage return
New line
Pause . 2 5 to .5 seconds
Send telephone number
* ORIGINS : 1 0 2 7 3
* ( C ) COPYRIGHT International Bus ine s s Machines Corp . 1 9 8 5 , 1 9 8 9
* A l l Rights Reserved
* Licensed Materials - Property of IBM
* US Government Users Res tr i cted Rights - Use , duplication or
* di s c losure restric ted by GSA ADP Schedule Contrac t with IBM Corp .
* Execute /usr / l ib / uucp /uucpadm for on- l ine uucp conf igurat i on help .
\ dAT \ r \ c OK \pATDT \ T \ r \ c CONNECT
= W- P
penr i l
\d > s \p9 \ c ) -W \ p \ r \ ds \ p9 \ c - ) y\c : \ E \ DP > 9 \ c
vent e l
\ r \p \ r \p- \ r\p- $ <K\D% % \ r > \ c ONLINE !
= &-%
\ r \p \ r \p- \ r \ p - $ < K \ D% % \ r > \ C ONLINE !
= &-%
= K-K
\ 0 0 5 \p * - \ 0 0 5 \p- * \ 0 0 5 \p- * D\p BER? \ E \ D \ e \ r \ c
mi com
\ s \ c NAME? \ D \ r \ c GO
1 /usr/lib/uucp/Dialcodes . The D i a l c odes file is basical­
ly a phone prefix directory for UUCP. Each prefix number is repre­
sented by an alphabetic identifier. The identifiers are used as short­
hand for phone numbers in the Sys t ems file. Dial tone, " = , " and
pause, " - " characters may be used as required in the prefix number.
Dialcodes format and example:
1 2.4
Prefix number
9 = 356
UUCP Daemons
AIX BNU support is managed by four daemons:
uuc i c o
Master daemon responsible for connection and transfer control
uus ched
Schedules UUCP requests
Execute command requests from remote sites
Support UUCP over TCP/IP
Network Configuration and Customization
The UUCP master daemon, uuc i c o , establishes connections and
transfers files created by the uucp and uux commands. Transfer
requests are spooled to the / u s r / spoo l / uucp / < Sys t emName> direc­
tory. uuc i c o records transfer activities and status to the / u s r
/ spoo l / uucp / . Lo g / uuc i c o file. The uuc i c o daemon i s invoked by
uucp , uux , and uus ched . It can also be invoked from the command
line to debug connections.
The uu s ched daemon is started periodically by c r on using the
uudemo n . h o u r command. uu s c h e d locates files queued in the
/ u s r / spoo l / uucp / < SystemName> directory and invokes uuc i c o to
attempt delivery. Each request type is identified by a prefix charac­
ter, c . * (command files), D . * (data files), and E . * (execute files).
uuxqt is invoked periodically like uus ched by c ron . It scans the
/ u s r / spoo l / uucp / < Sys temName> directory for execution requests
from remote systems. The remote execution requests are identified by
the x . * prefix.
UUCP over TCP/IP connections are established by the uucpd dae­
mon. uucpd runs as a subserver invoked by inetd . The server uses
reserved port number 540 which must be configured in I e t c I s er­
vices .
/ e tc / s ervi ces uucpd entry:
1 2.5
5 4 0 / tcp
Housekeeping and Logs
UUCP requires periodic housekeeping to ensure a smooth-running
facility. The chores include periodically running uus ched and uuxqt
to handle queued requests and clean up log and work files. These
types of activities are handled by c ron . The following uucp crontab
is supplied as part of the default AIX BNU configuration and can be
enabled to take care of UUCP housekeeping chores. To enable c ron
support, edit the crontab and remove the comments from the schedule
lines. Adjust the times per your environment.
/ u s r / spoo l / cron / c rontabs / uucp :
# UUCP Crontab - Housekeeping Chores .
2 0 , 5 0 * * * * /bin/bsh -c " / usr / l ib / uucp /uudemon . po l l > / dev/nu l l "
2 5 , 5 5 * * * * /bin/bsh -c " / usr / l ib / uucp / uudemon . hour > / dev/nul l "
4 5 2 3 * * * /bin/bsh - c " /us r / l ib / uucp /uudemon . c leanu > / dev/null "
48 8 , 1 2 , 1 6 * * * /bin/bsh -c " / usr / l ib/uucp /uudemon . admin > /dev/nu l l "
Like most other A IX systems, BNU creates a number o f log files
that periodically need to be closed and archived. Log files are com­
pacted and cycled by the uudemon . c l eanu command. The uude ­
mon . c l eanu utility is configured in the default uucp crontab.
1 2.6
UUCP connections are supported over serial links and TCP/IP as
described in the previous sections. Refer to Chap. 9 and Chap. 11 for
detailed descriptions concerning serial and TCP/IP-based interfaces.
1 2. 7
UUCP Commands
It's helpful to understand the command set that makes up a service.
The combination of user and administrator commands can provide
insights into how the service can be used and enhanced.
1 2.8
Convert non-BNU UUCP files to BNU
Validate Permissions file
List host names from Systems file
Tailor configuration files
uucl ean
Clean spool directories
uuc leanup
Clean spool directories
Establish connection with debug support
Display log information
uupol l
Poll a remote site
Display scheduled job queue
Display status
uus tat
Display statistics
Establish a debug connection overriding retry limits
Transfer a file to a remote site
Execute a command on a remote site
Encode a binary file for text transfer
Decode a uu-encoded file
c t , cu , tip
Establish connection to a remote site
uus end
Send a file to a remote site
Copy a file to a remote site
Testing a new or problem connection can be done using uuc i c o or
uutry . The uuc i c o debug flag -x<num> will display a connection
trace. You control the verbosity of the trace by specifying a <num>
value from 1 to 9.
# uuc i co - r l - x 9 - sgoofy
c onn ( goofy)
Device type goo fy wanted
getto ret 6
expe c t : ( " " )
got i t sendthem ( AMDELAYAM)
expec t : ( l ogin : )
t imed out
Call Fai l ed : LOGIN FAILED
conversat i on compl ete : Status FAILED
Network Configuration and Customization
You can use this feedback to validate your entry in the Sys tems file
for the particular site. You can also use a simple connection command
like cu to validate that your link is operational. See Chap. 9 for infor­
mation on testing serial links.
Use the uucheck command to validate file permissions and config­
urations defined in the Permi s s i ons file. Use uulog to display con­
nection histories.
1 2.9
l nfoExplorer Keywords
/us r / l ib / uucp / Permi s s i ons
uuc i c o
/ u sr / l i b / uucp / Dialers
/ us r / l ib / uucp / Sys t ems
/ u s r / l ib / uucp / Di a l c odes
/usr / l ib / uucp / Devi c e s
uus ched
c ron
/ usr / spoo l /uucppub l i c
/usr / l ib / uucp / uu c i c o
uuchec k
1 2.1 0
host l ! ho s t 2 ! user
UUCP store-and-forward hop addressing format
/usr / l ib/uucp
Configurations files
/usr / spoo l / uucppubl i c
Public spool directory
/usr/ spool /uucp
Logs and work space
/usr / l ib / uucp / Sys tem
Host table
/usr / l ib / uucp / Devi ces
Network interfaces
/usr / l ib/uucp /Dial codes
Phone numbers
/usr / l ib / uucp / Dialers
Modem control and logon handshaking
/usr / l ib / uucp / Permi s s i ons
UUCP login privileges
uuc i c o
Master UUCP daemon
UUCP scheduler daemon
Execute a command
UUCP configuration tool
See Sec. 12. 7.
UUNET Technologies Inc,
Falls Church, Virginia
(703) 204-8000
uunet!info, Internet Anonymous FTP Site
Network F i l e System
1 3. 1
Virtual File System
Distributed file systems are made possible by generalizing UNIX file
system data structures to provide a common interface to various
underlying file system architectures. This open interface is called a
virtual file system (VFS). E arly work by Bell Labs used this VFS
abstraction to develop their remote file system. Later on Sun
Microsystems decided to move the interface abstraction down to the
file level to better facilitate a common operation interface. File system
architectures supported by VFS are represented in the I e t c / v f s file.
/ e t c /vfs
cdr f s
j fs
I sbin / helper s / n f smnthe lp
/ sbin/helpers /v3 f shelper
remot e
Incore VFS structures allow the kernel to operate on various local
file system architectures. VFS structures also provide a switch point
for determining local or remote file system operations. The general
mount structure for a virtual file system contains an array of opera­
tion types supported on the underlying file system. This array is
called vsop s . Likewise, a VFS inode abstraction called vnodes con­
tains an array of inode operation types called vnodeops . A gnode
structure is used to map inodes and vnodes .
1 3.2
Network File System
To support remote file system operations, a facility is required to trap
and reroute file system operations from one machine to another. This
must include support for file system operations between machines
with different architectures and operating systems. A method is need­
ed to map data formats from one architecture to another. Sun devel­
oped a remote procedure call (RPC) mechanism which allows a remote
Network Configuration and Customization
N FS Server
Figure 1 3.1
cache: /usr
NFS Client
NFS server-to-client interface.
machine to execute functions on behalf of the local system and return
the results to the originating process. Sun also provided an external
data representation CXDR) language that is used to communicate data
formats between machines . Thes e specifications along with VFS
semantics became the basis of Sun's Network File System (NFS). NFS
is based on a client/server architecture that enables applications to
seamlessly interoperate with files and directories shared between
networked machines without regard to their locale (see Fig. 13. 1).
Sun later placed this architecture in the public domain and it became
a de facto standard for distributed file systems.
1 3.3
Starting N FS
NFS is managed as a subsystem by the AIX s r cms t r . Thus, NFS
subserver daemons may be started or stopped as a group, using the
s t ar t s r c and s topsrc commands. NFS operation may also be man­
aged from the SMIT n f s submenus.
# s tartsrc -g nfs
Start NFS subsystem
# s topsrc -g nf s
Stop NFS subsystem
N F S s t art-up options and d a e m o n s are configured in the
I etc I re . nfs script. The script begins by starting the NFS block 1/0
biod daemons. If the / e tc / exports file exists, it is exported using
exp o r t f s - a , followed by n f s d and rpc . mount d start-up . The
script finishes up by starting the rpc . s tatd and rpc . l o c kd dae­
mons. The I etc I re . n f s script also contains entries for starting NIS
and HANFS subsystems and subservers.
Network File System
NFS may be made the default remote file system type by defining it
as the de fau l tv f s in / e t c / v f s . Uncomment the following lines in
the / et c / v f s table.
%defau l tvfs j f s nfs
n f s 2 / e t c / helpers / nf srnn t help none remo te
1 3.4
NFS Server
The NFS server is designed as a stateless system. This eliminates
the need to support recovery operations in the event of a server or
client failure. It turns out that this is not entirely true. NFS uses
UDP as a transport, and we all know that UDP does not guarantee
packet delivery or packet order. To overcome the deficiencies of UDP,
NFS servers must maintain a volatile cache of recent RCP hand­
shaking state to avoid duplicate, out-of-order, or lost 1/0 operation
packets. This also means that the server must keep track of who it is
talking to. To keep the n f s d daemon stateless, additional daemons
are used to track machine connections, RPC status , and file locks.
IBM's High Availability Network File System (HANFS) makes use of
the volatile cache state and lock daemon information to support
backup NFS servers.
To ensure file integrity, NFS servers use a write-through cache,
forcing file updates immediately to disk. Data integrity is maintained
at the sake of performance. Asynchronous write support is available
in some architectures to improve read performance when data
integrity is not an issue.
1 3.4.1
N FS server daemons
NFS servers rely on a number of daemons to manage distributed file
system services. 1/0 requests from multiple clients are multiplexed
through a configurable number of n f s d and b i o d daemons. The
n f s d daemons manage file 1/0 operations and the b i o d daemons
control block 1/0 services. The actual number of n f s d and b i o d dae­
mons required is based on the client load the server is expected to
support. The default configuration starts eight nf sd daemons and
six biod daemons.
Being that NFS is RPC-based, the NFS servers must register them­
selves with the por tmap daemon. The portmap daemon maintains
the available set of RPC applications on a particular machine. Each
application is represented as a tuple of application name, version, and
port number. S ervers register their application data with the
portmap daemon. Client applications query the portmap daemon to
learn the port number associated with a known server application
name and version. portmap listens to a well-known port number list-
Network Configuration and Customization
ed in I etc I servi c e s , thus avoiding the "chicken and egg" problem
of determining what por tmap's port number is.
The rpc . mountd daemon is used by the server to manage and track
client mount requests. Recent RPC operations between clients and
servers are cached by the rpc . s ta td daemon. SYSV advisory file and
record locking is supported by the server's rpc . lockd daemon.
NFS server daemons:
1 3.4.2
NFS server daemon
NFS block I/O daemon
RPC program-to-port manager
rpc . mountd
NFS mount manager
rpc . s tatd
RPC status manager
rpc . lockd
NFS lock manager
Exporting server file systems
Each file system or directory available for remote mounting is identi­
fied by an entry in the server's / e tc / exp o r t s file. Along with the
directory path name, the / e t c / exports entry controls which machine
names are allowed root permissions and write access. If NFS root
access is not enabled for a remote NFS client, the root UID of the serv­
er is mapped to a default UID of -2 (4294967294), user name nobody.
This restricts access against the superuser UID on a remote machine.
The I etc I exports is a flat ASCII text file which may be edited or
maintained via the SMIT mkn f s exp fast path (see Fig. 13.2). Updates
to the / e t c / exports file must be made known to the server daemons.
Update notification is achieved by invoking the /usr / sbin/ export f s
Add a Directory to Exports L i s t
Type or s e l e c t values in entry f ields .
Press Enter AFTER making a l l des i red changes .
* PATHNAME of directory to export
* MODE to export directory
HOSTNAME l i s t . I f exported read-mo s t ly
Anonymous UID
HOSTS a l l owed root access
HOSTS & NETGROUPS a l l owed c l i ent access
Use SECURE opt i on?
* EXPORT directory now , sys tem restart or both
PATHNAME of Exports f i l e if us ing HA-NFS
F l = Help
F S = Undo
F9 = She l l
Figure 1 3.2
F2 = Refresh
F 6 = Command
F l O = Ex i t
SMIT NFS exports panel.
F3 = Cancel
F7 = Ed i t
Enter = D o
[ Entry Fi elds ]
read-wr i t e
[ -2 ]
F4 = Li s t
FS = Image
Network Fiie System
Example / e t c / expor t s :
/usr I lpp / inf o / En_US -ro , access = alph , l i s a
/home - rw , root = alph , access = alph , l i sa , armada
# /usr/ sbin/ expor t f s -a
# smi t mknfsexp
1 3.5
NFS Clients
To improve performance, the NFS clients implement clientside data
caching. This requires that some level of cache consistency be main­
tained between multiple NFS clients and the server. A time stamp
expiration mechanism is used to allow the clients to update cache
information when it becomes stale.
Each client runs multiple copies of the NFS biod block 1/0 dae­
mon. Clients also run the portmap daemon. portmap is queried to
identify RPC services and bind port connections to NFS servers.
NFS RPC mechanisms allow clients to block applications in the
event of a server failure. 1/0 operations continue when access to the
server is restored. A retry limit is provided such that client applica­
tions do not wait forever in the case of long-term server failures. Sun
also added hard and soft mount options so that a client could be inter­
rupted when server access is blocked.
NFS client daemons:
1 3.5.1
NFS block I/O daemon
RPC program-to-port manager
Importing file systems
Client NFS file system definitions are configured as stanzas in the
/ e tc / f i l e sys t ems file. The stanza is similar to a local file system
definition with the addition of the remote owning site name listed in
the nodename
parameter. The dev
parameter defines the direc­
tory path on the remote machine to be mounted. / e t c / f i l e sys tems
entries may be edited directly or managed using the SMIT mkn f smnt
fast path (see Fig. 13.3).
# s m i t mknfsmnt
Example / etc / f i lesys t ems NFS stanza:
/usr / spoo l / news / nn/NN :
= / news /nn/NN
= nfs
nodename = news
= true
= nfs
opt i ons = ro , bg , s o f t , intr , nosuid
account = false
Network Configuration and Customization
Add a F i l e System for Mounting
Type or select values
in entry f i elds .
Press Enter AFTER making all
des ired changes .
[ TOP ]
[Entry F i e lds ]
* PATHNAME of mount point
* PATHNAME of remote directory
* HOST where remote direc tory resides
Mount type NAME
* Use SECURE mount opt i on?
* MOUNT now ,
* MODE for thi s NFS f i l e system
* ATTEMPT mount in background or foreground
add entry to / e tc / f i lesystems or both?
/ e tc / f i l esystems entry wi l l mount the directory on system RESTART .
to attempt mount
Bu f f er S I Z E for read
Buf f er
Bu f f er S I ZE for wri t e s
for wri tes
In tenths of a second
In tenths o f a second
Internet port NUMBER for server
* Mount f i l e system s o f t or hard
Allow keyboard INTERRUPTS on hard mounts ?
Minimum TIME ,
i n seconds ,
for holding attr ibute cache a f ter f i l e modi fica t i on
Maximum TIME ,
in seconds ,
for holding attribute cache a f ter f i l e modi ficat ion
Minimum TIME ,
in seconds ,
for holding attribute cache a f t er directory modi f ication
Maximum TIME ,
in seconds ,
for holding attribute cache a f t er directory modi f i c a t i on
[ 60 ]
Minimum & Maximum TIME ,
in seconds ,
for holding attribute cache a f ter any modi ficat ion
The Maximum NUMBER o f biod daemons a l l owed to work on thi s
f i l e sys t em
* Allow DEVICE access via thi s mount?
* Server supports long DEVICE NUMBERS?
ye s
* Allow execution o f SUID and sgid programs in t h i s f i l e system?
Fl = Help
F 2 = Ref resh
F3 = Cancel
F4 = L i s t
FS = Undo
F 6 = Command
F7 = Ed i t
FS = Image
F9 = She l l
F l O = Exi t
Enter = Do
Figure 1 3.3
SMIT NFS mount panel.
The type
nfs parameter may be added to the stanza definitions
to identify NFS file systems as a group. This way they can be mount­
ed or unmounted as a group using the - t option of the mount and
umount commands.
# mount - t n f s
# umount - t nfs
1 3.6
Secure N FS
NFS suffers from a few security holes. These security problems are
primarily due to collisions in the UID and GID name space, and the
lack of authentication in the RPC . For example, UID 1234 might be
user sleepy on one machine and user tulip on another. If the file sys­
tem with sleepy's home directory is NFS-mounted on tulip's machine,
then tulip will have owner permissions over sleepy's files.
To solve these problems, Sun implemented a distributed file man­
agement and authentication system called Yellow Pages (YP) or
Network File System
Network Information System (NIS). AIX provides secure NFS services
using the Sun YP management tools. Since the YP prefix is used for
most NIS commands and daemons, I'll use YP when referring to
secure NFS tools in the following sections. Yellow Pages is the older
and probably better-known terminology.
AIX also supports access control lists (ACL) over NFS. This feature
is an add-on function to the RPC and does not alter NFS protocol. AIX
ACL support is only available to AIX V3 NFS clients.
1 3.6.1
Yellow Pages
The Yellow Pages system uses a master server, and one or more slave
servers, to distribute a common set of system configuration files to a
collection of client machines under the jurisdiction of the YP domain.
Each file in the distribution set is converted into ndbrn database for­
mat and stored as a YP map file in the server / et c / yp / <DornainNarne
directory. YP maps are created from text files using the rnakedbrn com­
mand. The maps are then distributed using the yppush command. A
common ndbm Makefile, / e t c /yp /Make f i l e , is used to create YP
maps. Collectively the YP map files make up the YP database as creat­
ed by the yprnake command. A YP database may be transferred to
another domain using the ypxfr command.
1 3.6.2
VP name space
The YP domain name and the set of participating machine names are
defined using the / b i n / dornainnarne command. The domain defines
the area of administrative control available to the servers.
# /bin/ domainname <DomainName>
YP Netgroups define collections of machines that are identified for
special configuration and administration requirements. A netgroup
does not necessarily correspond to a particular domain. It might be
that a subset of machines in the domain are configured with a differ­
ent / e t c / ho s t s . equiv file from the rest of the domain. The net­
group definition file, I e t c / ne tgroup s , identifies each netgroup
name followed by participant tuples . Each tuple is enclosed in paren­
theses and identifies the machine, user, and domain name of the net­
group participant.
/ et c / ne tgroups format:
( hos t , user , domain )
( hos t , user , domain)
( ho s t , user , doma i n ) ...
( hos t , user , domain ) ...
Users within domains and groups are identified by a net name. A
net name is a concatenation of the operating system name, user name,
Network Configuration and Customization
and Internet domain name. Net names are maintained in the
/ et c / yp / < Doma inName> /ne t i d . byname YP map.
Net name format and example:
Operat ing Sys tem Name . User Name @ Domain Name
unix . j anice@f ido . ne t
Net names incorporate the primary host name entry from the
/ e t c / ho s t s table. Sites that use domain name service must also
have / e tc /ho s t s tables available which match name service entries.
1 3.6.3
VP file classes
The YP versions of the distribution files for the domain use the same
format as their local system counterparts. What differs is how they are
used. Three classes of files govern the behavior of client machines in
the YP domain: local, global, and optional. Local files override YP
copies of the same information. For example the local / e t c / pa s swd
file takes precedence over / et c /yp /yppas swd . Global files override
their local counterparts. Examples would include files like / e t c
/ ho s t s and / etc / networks . Optional files override local copies if the
local copy contains a netgroup identifier or the magic YP "+" character.
The "+" prefix to a table entry indicates that the YP-equivalent infor­
mation should be used.
All the distribution files may be updated on the server, then pushed
to the slave servers and clients. Local client updates are possible in
some instances through the use of YP update commands. For exam­
ple, the YP version of the passwd file, ypp a s swd , can update global
password information if the user changes the password using the
yppas swd command.
1 3.6.4
VP servers and clients
To create a YP master server, YP slave server, or YP client, invoke
the SMIT fast paths mkma s t e r , mks l ave , or mkc l i ent , respec­
tively. Servers may be initialized by invoking ypini t from the com­
mand line. (See Fig. 13.4.)
# smi t mkmas ter
# ypini t - m
Initialize a master
# smi t mkmas ter
# ypinit - s
Initialize a slave
# smi t mkc l i ent
1 3.6.5
Initialize a client
Public key authentication
NFS authentication is implemented through the use of DES Public
Key services. Users in the YP domain must have their own publ i c
and private encryption key entries i n the / et c / publ i ckey file.
The system administrator defines new user entries in the file via the
newkey command. Users update their public keys using the chkey
Network File System
configure thi s Ho s t as a NIS Mas t er Server
Type or s e l e c t values in entry f i e lds .
Press Enter AFTER making a l l des i red changes .
[ Entry Fi elds ]
HOSTS that wi l l be s l ave servers
* Can exi s t ing MAPS for the domain be overwr i t ten?
* EXIT on errors , when creat ing master server?
* START the yppasswdd daemon?
* START the ypupdated daemon?
* START the ypbind daemon?
* START the mas ter s erver now , at sys tem restart , or both?
F l = Help
F 5 = Undo
F9 = She l l
Figure 1 3.4
F2 = Re f resh
F 6 = Command
F l O = Ex i t
F3 = Cancel
F7 = Edi t
Enter = Do
F4 = Li s t
F8 = Image
SMIT NIS master server panel.
command. The / e t c / p ub l i c k ey file is then YP map p e d to
/ e t c / yp / pub l i c key . byname. Users' entries are identified in the
files by their net names.
# newkey -u username
Create user public key entry
# newkey -h hos tname
Create root public key entry
# cd / etc /yp ; make publickey
Build YP publickey.byname
The keys erv daemon encrypts the public keys and stores them as
private keys in the / e t c / k eys t o r e file. A separate file, / e t c
I . rootkey, is used to hold the superuser private key. This avoids
problems when private keys are wiped clean during a system reboot
following a crash. To initialize the keys erv server, invoke the SMIT
mkkeyserv fast path or the / u s r I e t c /yp /mkkeys erv command.
# smi t mkkeyserv
# / u s r / e t c /yp /mkkeyserv -B
The key l o g i n command is used to decrypt a user's secret key,
which is stored by the keys erv server for secure RPC operations.
keyl ogin can be added to the default system login profile. A keys erv
entry is required to access file systems flagged with the - s ecure
option in / e t c / expo r t s and / e t c / f i l e sys t ems . Note that this
mechanism requires synchronized clocks between participating
machines. System time is used to create and expire keys stored in the
server. The default secure NFS expiration is 30 minutes.
1 3.6.6
Starting YP (NIS) services
Like NFS, YP is managed as a subsystem under AIX. YP daemons
are started using the SRC s tartsrc and s topsrc commands. The
Network Configuration and Customization
/ e t c / r e . n f s script contains code to start up YP services before
bringing up NFS.
# startsrc -g yp
# stopsrc -g yp
YP daemons:
1 3.6. 7
YP server daemon
YP server binding manager
YP passwd update daemon
YP map update invoked by inetd
Public key server daemon
RPC program-to-port manager
The aut omount daemon can be run in a large YP network to simplify
NFS file system access. The automount daemon will automatically
mount a file system whenever a file or directory in the file system is
opened. Files and directories associated with an automount file sys­
tem are kept in a YP map. Automount forks child processes that
appear as NFS clients which monitor file systems based on the infor­
mation in the maps. The daemons umount file systems that have not
been accessed in the last five minutes. The master automount map
file is aut o . ma s t e r .
/usr/ sbin/ automount
1 3.7
Automount daemon
Complex distributed services like NFS and NIS present a real debug­
ging puzzle when things run amuck! Based on the symptoms and
error messages associated with the problem, begin examining each
component of the system. Refer to Chap. 12 for details on debugging
network problems.
Begin troubleshooting problems by listing and verifying the current
set of client mounts known to the server. The client mount list is record­
ed in / et c / rmtab and displayed using the showmount command.
# showmount -a
as imov : /usr/ l oca l / gnu
as imov : / usr / l oc a l / bin
as imov : / usr/ local / l ib
s o f ty : /nO
s o f ty : /nl
The showmount command can also be used to verify the list of
exported directories as recorded in the / e t c / xtab file. This informa-
Network Fiie System
tion should match up with the entries in / et c / export s . If the data
doesn't match, invoke export f s - a to refresh / et c / xtab.
II showmount - e
alph , l i s a
s o f ty
s o f ty
as imov
as imov
as imov
/usr/ lpp / info / En_US
/us r / l ocal / gnu
/us r / l ocal / l ib
/usr/ local /bin
NFS 1/0 statistics can be reset and displayed using the n f s s tat
command. Statistics include the number and success of RPC and NFS
calls for both servers and clients.
II /usr/ sbin / n f s s tat
Server rpc:
badcal l s
nul l recv
Server nfs:
cal l s
nul l
0 0%
0 0%
mkdi r
832 0%
badcal l s
821190 9%
wri t e
608394 7%
592 0%
2 3 522 0%
15528 0%
9 9 62 9 4 1 1 %
0 0%
13485 0%
f s s tat
427981 5%
4641837 54%
4400 0%
readl ink
2884 0%
l ink
9 4 0 0%
932979 10%
syml ink
2059 0 %
Client rpc:
badc a l l s
r e trans
wai t
Client nfs:
3 04494
nul l
0 0%
0 0%
2 0%
badcal l s
55533 18%
wri t e
53 0%
rmdi r
0 0%
3 04494
54 0%
36 0%
35008 11%
nc l s l eep
0 0%
27 0%
f s stat
15798 5%
96869 31%
19 0%
readl ink
213 0%
l ink
0 0%
100873 33%
syml ink
9 0%
RPC errors like App l i c a t i on No t Reg i s t ered are related to the
portmap daemon. Check to see that the portmap daemon is running
on both the local and remote system. You can also verify the app l i ­
cat i on , ver s i on , protoc o l , and port data maintained by local
and remote portmap daemons using the rpc in f o command.
Network Configuration and Customization
i rpc info -p da f fy
3 0 0082
3 00082
3 00049
3 00049
pro to
rs tatd
s tatus
s tatus
l l ockmgr
l l ockmgr
Verify that the s r cms t r daemon is aware of the current NFS and
NIS subsystems and subservers states. Erratic behavior will occur if
the SRC environment is out of sorts. Subsystem and subserver states
can be displayed using the l s src command.
i lssrc -g nfs
rpc . mountd
rpc . s tatd
rpc . l o ckd
Since small deltas in client/server response times can add up quick­
ly for large NFS environments, you may want to closely monitor traf­
fic between systems. You can easily collect statistics with network
sniffers or using a public domain package like n f swatch .
1 3.8
Highly Available N FS Servers
Those of you who have been dealing with IBM for any number of
years have surely heard of Reliability, Availability, and Serviceability
(RAS). To remain competitive in the glass-house environments, UNIX
must provide the same 7 by 24 availability that has been the hall­
mark of operating systems like MVS. The proliferation of X stations
and diskless workstations in departmental computing environments
means that there are a whole lot of folks out there who are depending
on those RS/6000 servers to be ready whenever they are.
Network Fiie System
Like anyone else, I hate any system interruptions. Whenever a sys­
tem or service drops out of sight, I want that service back as quickly
as possible. The sooner it is back up and running, the happier I am
going to be. A highly available system should be able to survive a sin­
gle point of failure and impose only the minimum required delay
while service recovery transitions occur.
1 3.8.1
High Availability Network File System/6000
One of the problems with NFS is that when the NFS server goes
down, so do all your applications and diskless workstations that were
depending on the servers' file systems. High Availability Network
File System/6000 (HANFS) provides an extension to standard NFS
services that allows a second RS/6000 to act as a backup NFS server
should the primary NFS server fail. HANFS can be configured such
that each RS/6000 may be acting as primary NFS servers for distinct
file systems while acting as backup servers for the other, the primary
requirement being that they share physical connections to external
SCSI disks and additional network adapters (see Fig. 13.5). Note that
the shared disks volume groups are only online to the primary NFS
server, and that internal disks are not supported.
HANFS makes use of the server's RPC cache information along
with the journaled file system (JFS) logs to enable NFS server recov­
ery on the backup system. The primary server's NFS RPC cache
information is recorded in the JFS logs and is read by the backup
server to reconstruct the cache.
During normal operati o n , the HANFS s ervers periodically
exchange alive messages. When the primary NFS server fails, the
backup server takes over the volume groups and checks their consis­
tency. It rebuilds the duplicate cache from the information stored in
the JFS logs and begins impersonating the failed server's network IP
addre s s . NFS locks are then re synchroni z e d by stopping the
- ·
- ·
k:::J k:::J
System A
Disk A
Disk 8
System 8
..:. · - · - · - · - · - · - · - · - · - · - ·
..:. · - · ·
...:. · - · - · - · - · - · - · - · - · - · - · - · ...:. · - · - · ·
Figure 1 3.5 HANF S interface diagram.
Network Configuration and Customization
rpc . l ockd daemon from accepting new locks while the rpc . s tatd
daemon requests all NFS clients to reclaim their locks. After a grace
period, the rpc . l o c kd daemon begins to accept new lock requests.
Other than the notification to reclaim file system locks, remote NFS
clients only experience a short delay while server recovery procedures
are completed. Recovery time after a server failure is somewhere in
the neighborhood of 30 to 300 seconds.
HANFS also supports the automatic reintegration of the primary
server once the problem failure has been rectified and the system is
back on line. Basically the procedure described in the previous para­
graph is reversed and the servers go back to doing their old jobs. Note
that no changes to standard NFS client software is required to make
use of HANFS services. HANFS will work fine with your Sun, HP,
DEC, and other standard (grain of salt here) NFS clients and servers.
1 3.8.2
Configuring HANFS
HANFS requires that each system have three network interfaces, the
primary interface, a secondary interface that will be used in takeover
mode, and a slip interface for the exchange of aliveness messages. These
interfaces can be configured using the SMIT hanf s_rnktcpip_prrn ,
hanfs_rnktcp_s ec , and hanf s_rnkt cp_ter fast paths.
# smi t hanf s_mktcpip_prm
Primary network interface
# smi t hanf s_mktcpip_sec
Secondary takeover interface
# smi t hanf s_mktcpip_ter
Tertiary aliveness interface
Set the alternate hardware address of the secondary adapters to
match the hardware address of primary adapters.
# l s c fg -1 entO -v
Display hardware address
# smi t hanf s_chgenet
Set alternate Ethernet address
# smi t hanf s_chgtokn
Set alternate token-ring address
Once the network adapters have been configured, set the primary
adapters to the detach state. This prevents HANFS from attempting
to access the network with the same address on both machines. Verify
that all network connections are functioning correctly.
# smi t hanf s_chdev
Set primary net adapter to detach
Next, connect the shared SCSI disk strings to both machines, one
on each end of the SCSI string. Use pass-through terminator (PTT)
cables and terminators (IBM #29 15) on shared strings between the
host adapters and the first disk devices. You can use standard device­
to-device cables between disks on the string. Do not terminate the
PTT cables . Keep in mind that you only have six SCSI addresses
available for disks. SCSI IDs 6 and 7 are used by the host adapters on
Network File System
each end of the chain. Configure the adapter SCSI IDs on each
machine using the SMIT hanf s_chs c s i fast path.
Set SCSI adapter addresses
# smi t hanfs_chs c s i
Power up the primary machine and verify that the disks on the string
are in the Ava i l ab l e state.
With the hardware configuration completed, you're ready to config­
ure HANFS software. Begin by tailoring the HANFS configuration
table on each system. Once again you can use SMIT to complete this
task. The configuration table identifies adapter addresses, host
names, and default HANFS parameters.
# smi t hanfs
Create or varyon the shared volume groups and file systems on the
primary server. The default NFS exports file identified by the HANFS
configuration file is / et c / exports . hanf s . Update this file with the.
new shared file systems or the existing NFS export information from
/ e tc / export s .
# smi t mknfsexp
Configure exports
Start the HANFS daemons on each system.
# smi t hanfs_starthanfs
1 3.8.3
High .Availability Cluster Multiprocessor/6000
High-Availability Cluster Multiprocessor/6000 (HACMP/6000) goes
beyond HANFS by providing configurable recovery and restart capa­
bilities for critical applications on the backup server during a system
failure. HACMP/6000 is essentially a small cluster of up to four loose­
ly coupled RS/6000s (see Fig. 13.6), each of which may be custom-tai­
lored to support application-specific recovery procedures in the event
of a failure on the primary server.
HACMP/6000 operates in one of three modes. A mode 1 operation
involves using RS/6000s as an idle standby system. The standby sys­
tem will take over support of the shared SCSI devices and network
services in the event of the primary systems failure. A mode 2 opera­
tion permits independent use of all RS/6000s connected in the cluster.
All systems are running independent workloads as well as acting as
backup servers for each other. Should either system fail, critical
applications and devices may be recovered and restarted on the sur­
viving system. You will take a performance hit on the survivor due to
increased load. Mode 3 operation will allow concurrent shared disk
access by the same application running on all processors, as well as
providing the same backup recovery facilities in modes 1 and 2 .
Network Configuration and Customization
, , r·r
- ----t-tkd
'_ 8
-----�' ,m� B
! !
Heart eat
Disk A
Disk B
-· ....:. · ; ·-·-·-·-· ; · ....:. ·- · -·-·-· ; · ....:. · - · ·
Figure 1 3.6 HACMP interface diagram.
Applications developed to make use of mode 3 operation will remain
available during recovery and restart processing.
1 3.9
High-speed NFS
There are several bottlenecks that contribute to slow NFS throughput.
You begin with limited network bandwidth. At only 10 megabits/a, a
moderately loaded Ethernet can cause significant delays for NFS traf­
fic. The 10-ms wait for collision detection and avoidance in Ethernet is
also significant overhead for frequent low-cost NFS operations. NFS
server CPU cycles and memory must be shared between all operating
system components. Network processing, file system buffering and
control, kernel scheduling, and other OS daemons are all competing
for the same resources. Finally, device interfaces are not optimized for
network file system serving. NFS synchronous disk writes block other
NFS traffic on the device. This all adds up to slow NFS response.
1 3.9.1
To improve NFS performance, Legato Prestoserv software and hard­
ware support is available for RS/6000 NFS servers. Prestoserv accel­
erates NFS performance by caching synchronous write activity to
memory rather than directly to disk. Data is saved in battery-backed
nonvolatile memory to ensure integrity in the event of a failure.
1 3.9.2
7051 network dataserver
To support high-speed NFS traffic between a large number of clients,
consider the IBM 7051 POWER Network Dataserver. The 705 1 is a
Network File System
1 6-384MB
RS/6000 340R
1/0 Cache
55 MB/s VME Bus
1 -4 Dual
1 -2 File
1 -3
Store Proc
Write Accel
Figure 1 3.7 Dataserver architecture.
hybrid multiprocessor architecture that is dedicated to NFS server
operation. The 705 1 can exceed and sustain data rates at 2000 NFS
1/0 operations per second. A fully configured 705 1 can easily support
over 200 NFS clients.
The 7051 is based on technology developed by Auspex. The func­
tional multiprocessing (FMP) architecture implements intelligent
processors, running in parallel on a VME bus, that control each piece
of the server framework (see Fig. 13. 7). The network, file system, and
storage management functions are removed from the host processor
and embedded in dedicated 32-bit intelligent processors. Note that
these FMP processors DO NOT run UNIX. This complex of processors
is then supported by a large dedicated 1/0 memory cache. The 1/0
cache is use to co alesce random NFS data into sequential blocks for
the storage servers. The cache also maintains inode and indirect
block information that might otherwise be repeatedly written to disk.
Transient network packets may also be found in the 1/0 cache. All
message passing and 1/0 processing between the server processors
and the cache flow over the VME bus and do not interrupt the host
7051 components:
RS/6000-340R host processor. The host processor supports NFS
mount requests, account management, and system backups. It may
be used to run other AIX applications as required. The 340R's
Micro Channel slots may be used to connect other devices. Support­
ed devices include token-ring adapter, FDDI adapter, SCSI con­
troller, BMX channel adapter, and ESCON control unit adapter.
Network Configuration and Customization
A maximum of four dual-port Ethernet adapters supporting up to
eight Ethernet connections. The Ethernet processors handle all
network processing on the card. Protocols supported on-board
include IP, UDP, RPC, XDR, NFS, and SNMP. NFS requests are
passed directly to the file processors.
One or two file processors maintain file system metadata for the
file systems residing on the dataserver's disks. The file processors
support local memory as well as access to the 1/0 cache memory.
16-MB to 384-MB 1/0 cache handles data block, metadata, and net­
work packet buffering.
One to three storage processors control the array of SCSI disk used
for file system support.
One to three write accelerators with nonvolatile storage. These
optimize host processor disk activity for dumps, and improve NFS
One or two storage racks, depending upon the model. The storage
racks may contain a combination of hot pluggable 2-MB or 2.4-MB
disk and 4-mm or 8-mm tape devices. The model 840 rack provides
from five to twenty slots for up to 48 GB of on-line storage. The
model 800 rack adds five to forty slots for an additional 96 GB.
Combined, they total 144 GB of NFS served storage.
The dataserver's virtual partition manager (VMP) allows you to
dynamically allocate disk partitions on the fly. The storage proces­
sors support mirroring and striping to give you RAID 0 + 1 perfor­
mance. Partitions may span physical devices. Fragmented partitions
may be concatenated to reclaim space. A performance monitor is also
available to assist you in managing the storage space and to identify
problem areas.
To improve availability and integrity during backup processing, you
can create a mirror of an active partition. Detach the mirrored parti­
tion from active use, then back up the mirrored image. Backups may
be directed to SC SI-attached, rack-mounted, or networked tape
devices. Optical and tape jukeboxes are supported.
1 3.1 0
Andrew File System
In order to impose additional levels of authentication and administra­
tion and to improve the scalability of NFS, Carnegie Mellon University
developed the Andrew File System (AFS). AFS, now a product of
Transarc Corporation, uses a remote procedure call mechanism called
RX to support client/server interactions. AFS uses the Kerberos authen­
tication system to validate client access to remote file systems. AFS
introduces the notion of a c e l l , which defines the administrative
Network File System
domain over file systems in the shared space. A consistent view of the
shared file system space is provided using a common root tree I a f s .
Subtrees for each cell follow the root, using the cell name / a f s / c e l l ­
name / . Note that no restriction is placed on mount points or naming
under NFS. AFS cells are identified by a database called C e l l ServDB .
AFS security is further enhanced through the use of access control
lists (ACL). ACLs extend the standard UNIX file permissions to pro­
vide a finer degree of granularity on access rights. AFS uses the first
four UNIX permission bits to define read, lookup, insert, write, delete,
lock, and administer (rliwdka) permissions. Note that AFS ACLs only
apply to the directory levels of a file system. AFS also uses a
UserL i s t to define access rights and mapping. Users gain access to
the AFS shared file space via the klog command which grants them
a Kerberos ticket for access, and then they release their rights via the
unlog command. Under AFS, the standard path can no longer be
used to access files on the server.
Another important enhancement for distributed file systems is that
AFS separates the logical file system structure from the disk blocks
used to contain the file system. AFS volumes may contain one or many
file system hierarchies. The volumes are made up of partitions that
are collections of disk blocks identified by the special name, vicepnn ,
a,b,c, . . . . AFS also improves client cache consistency using a call­
back mechanism to invalidate data blocks which have been modified.
Release-level file system replication is also supported by AFS.
1 3.1 1
OSF Distributed File System
The Open Software Foundation selected a design based on AFS V4
from Trans arc C orporation for their Di stributed C o mp uting
Environment (DCE) Distributed File System (DFS). Conceptually,
DFS is quite similar to AFS. The major differences involve the inte­
gration of DFS with the other DCE services, and the underlying DCE
local file system. Thus, DFS requires a larger number of support dae­
mons than normally used with AFS. Users who are familiar with AFS
will be able to adapt to the DFS semantics easily. System administra­
tors will require a little more homework in order to configure and
activate all the DCE services on which DFS depends, as well as DFS
configuration itself.
Like AFS, DFS uses a Kerberos based authentication system, and
cell administrative domains. Users gain access to DFS using the
dc e_l ogin command, and release access with the kde s troy com­
mand. Cell and DFS administrative information is served to DFS par­
ticipants by DCE directory services. DFS shared file system trees are
also similar to AFS in that a common root is identified with the next
level delimited by cell name. The DFS shared root is named I .. . and
cell subdirectories follow as I ... / c e l lname / .
Network Configuration and Customization
ACLs are also used in DFS, and they apply to both directories and
files. DFS modifies the standard UNIX file permission bits to support
read, write, execute, control, insert, and delete (rwxcid) permissions.
The UNIX permission bits reflect the ACL permissions when viewed
with standard commands like l s . DFS users are identified uniquely
and globally to the DCE environment, such that problems with UID
and GID collisions are eliminated.
Interaction between DFS clients and servers is controlled by the
Network Computing System (NCS) protocol developed by Hewlett­
Packard and Apollo. DFS client cache consistency is maintained via a
token-passing mechanism. The DFS server controls the rights to file
access tokens, which must be acquired by a client. The cache manager
pulls a large chunk (64K) of data when a file is opened. This mecha­
nism supports a high number of clients to servers. DFS also supports
both scheduled and release file system replication.
DFS can export any VFS that has been enhanced to support DCE
VFS+ . DFS also provides an NFS protocol exporter for access by NFS
clients. The protocol exporter does not support authentication. AFS
and DFS may also be used independently on a file server. Any DFS
user may export locally owned files into the shared file system space.
These capabilities allow DCE DFS to be easily integrated into exist­
ing NFS and AFS environments.
1 3.1 1 .1
DCE local file system
In order to gain the full benefit of DFS services and access control,
you must use the DCE local file system architecture. File systems
structures are separated from the physical disk storage which hold
them similar to AFS. A DCE fileset is analogous to the AFS volume,
and represents the unit of file system administration. Likewise, disk
storage sets are called aggregates and map to the AFS concept of par­
titions. Files within the file system are allocated in structures called
containers. Containers are built from disk blocks and may grow and
shrink dynamically as required. Containers provide three modes of
storage: in-line mode, which uses extra space in an anode to store
small amounts of data; fragment mode, which combines small con­
tainers in a single disk block; and blocked mode, used to build large
files. The anode tables are analogous to UNIX inodes. Each aggregate
of storage is described by three types of containers: a bitmap contain­
er maps logged and unlogged fragments in the aggregate; a file table
container supplies an array of anodes for each fileset; and a log con­
tainer holds the aggregate transaction log.
The DCE local file system is a log-based file system similar to the
AIX journaled file system (JFS). All file system metadata updates
are grouped and logged as atomic transactions. Groups of transac­
tions against a single object are also grouped into an equivalence
class to facilitate recovery. The transaction equivalence class ensures
Network File System
that either all or none of the updates will be applied during system
Filesets may be moved between aggregates while maintaining on­
line access via a procedure called fileset cloning. Space must be avail­
able in the partition to build a copy of the fileset. The cloned fileset is
marked "read-only'' and kept up to date via copy-on-write procedures
until the move is complete . This facility, along with logging and
dynamic container sizing, provides a highly available file system that
is quite easy to administer.
1 3.1 2
lnfoExplorer Keywords
/ etc /vfs
rpc . lockd
mkc l i ent
j fs
de faultvfs
cdr f s
/ etc/publ i ckey
nf smnthelp
s tartsrc
s topsrc
expor t f s
net group
/ etc / keys tore
/ et c / services / et c / netgroups / etc / . rootkey
srcms tr
mknf sexp
yppas swd
/ etc / exports mount
/ etc /networks
nf sd
/ etc /ho s t s
mkmas ter
n f s s tat
rpc . mountd
mks lave
rpc info
rpc . s tatd
1 3. 1 3
/ e t c / export s
Exported file systems
/ e tc / f i lesys tems
File system mount info
/ e t c /vfs
File system type info
s tartsrc g n f s
Start nfs subsystem
Server 110 mux daemons
Client I/O mux daemons
rpc . lockd
File lock daemon
Network Configuration and Customization
rpc . s tatd
Status daemon
rpc . mountd
Track mount requests
RPC port mapping daemon
Yellow Pages:
s tartsrc -g yp
Start YP services
/ etc /yp / Make f i l e
Create YP maps
Define hosts in YP domain
/ e t c / netgroups
Collection of hosts for admin purposes
/ etc /yp
YP maps
/ et c / yp / yppas swd
YP password file
smi t mkmaster , ypinit -m
Make YP master server
ypini t - s
Initialize YP slave
smi t mkc l i ent
Make YP client
keys erv
YP encryption daemon
/ e t c / keys tore
Private key file
/ e tc / . roo tkey
Root private key
/usr / e t c / yp /mkkeyserv
Initialize keyserv
High Availability NFS:
smi t hanfs_mktcpip_ { prm sec ter }
Define interfaces
smi t hanf s_chg { ene t tokn }
Set alternate adapter
smi t hanfs chsc si
Set SCSI addresses
smi t hanf s_s tarthanfs
Display client mounts
n f s s tat
NFS statistics
rpc info
RPC port accessibility
Network Com puti n g System
1 4.1
NCS Overview
The Network Computing System (NCS) is a set of remote procedure call
based tools that support distributed processing and data manipulation
in a networked environment. NCS is a component of the Network
Computing Architecture developed by APOLLO. The NCS RPC should
not be confused with Sun RPC. NCS uses an object-oriented approach
to access and manipulate network resources. Network resources are
identified as objects by class or category. The interface used to access a
network object is defined by the operation set associated with the the
object class. NCS objects may be replicated in the network.
NCS consists of a network computing kernel (NCK) and a network
interface definition language (NIDL). The network computing kernel
consists of the RPC run-time library and a location broker. These
components are used to build NCS-based applications.
1 4.2
NCS Remote Procedure Cal l
NCS RPC uses BSD sockets and UDP to create client/server connec­
tions (see Fig. 14. 1). An NCS client application invokes an operation on
a network object via an RPC without any knowledge of the interface
implementation. The RPC request is passed to the client stub which
uses the RPC run-time library to pass the operation request to the NCS
server application. The operation request indicates the desired network
object. Three types of operation requests are supported:
No server or host information is included in the request.
The request is broadcast on the network and accepts the
first server response.
The operation request specifies a host identifier. The
request is sent to the location broker on the host to
resolve the server port address.
Network Configuration and Customization
Client Stub
Server Stub
R PC Runtime Lib
RPC Runtime Lib
-- · - · - � - · - · - · - · - · - · -
Figure 1 4.1
NCS RPC interface.
The operation request identifies server port and host.
The NCS server hierarchy is similar to that of the NCS client. The
server application uses a server stub to access the RPC run-time
library routines.
1 4.3
Network Interface Definition Language
The NCS Network Interface Definition Language (NIDL) is used to
define the interface stubs and the RPC operations supported. The
NIDL compiler creates two stub files defining the interface. One is
linked with the client and the other with the replicated server. The
NIDL compiler generates C and Pascal syntax. Each stub controls
data transfer, conversion, and corinection binding.
1 4.4
Location Broker
The NCS location brokers register server data and respond to queries
from NCS RPC clients. (Refer to Table 14. 1.) Location brokers are
accessed via a set of callable routines called location broker agents. A
TABLE 1 4.1
Location Broker Database Entries
Object UUID
Interface UUID
Socket address len
Socket address
128-bit object identifier
Object type
Interface operation set
Global or local information
Text description of service
Socket field length
Server location
Network Computing System
location broker may either be a local location broker (LLB), which
supports a local host, or a global location broker (GLB), which regis­
ters server applications for the network at large. Location brokers
may be replicated. Consistency between brokers is maintained via a
data replication manager.
1 4.5
Configuring NCS
NCS local and global location brokers are started via the I etc I re . ric s
script. NCS is managed as an SRC subsystem, and, as such, is started
or stopped using the SRC s tartsrc and s t op s r c commands. (See
Fig. 14.2.)
1 4.6
$ s tartsrc -g ncs
Start NCS subsystem
$ s tartsrc - s l lbd
Start local location broker
$ s tartsrc -s nrglbd
Start global location broker
Resource License Manager
The IBM resource license manager (RLM) is an NCS subserver that is
used to provide concurrent license access to applications available
over network. RLM will grant access until the concurrent license
limit is reached for a particular application.
RLM regulates access in one of two methods: node locking and site
licensing. Node locking permits invocation of the application only on
Global Location Broker
0 8
- · - � · - r · - · - · - · - · - ·'-- · - r · - · - · - ·
8 8
Figure 1 4.2 NCS network.
Network Configuration and Customization
the specified node. Site licensing provides unrestricted access to any of
the machines at the site. See /usr / lpp / r lm/ db / nodelock . README .
Sample / u s r / lpp / rlm/ db / node l o c k file:
# Vendor ID
3 8 2 4 1 e8 5 0 0 0 0 . 0d . O O . O O . da . b4 . 0 0 . 0 0 . 0 0 87 thcmbc 4 4 7 4 eeamascqaaa
2 8 2 2 1 f 8 5 0 0 0 0 . 0d . O O . O O . bd . 1 4 . 0 0 . 0 0 . 0 0 k7 tvcmnc 4 8 8 4bvvma sccgaz
To manage application licenses, one or more RLM servers run
under NCS on networked systems at the site. Each server maintains
its own license database and is responsible for a portion of the licens­
es available. The RLM servers respond to license access requests from
client applications. RLM components include a GUI and command
line administration interfaces, the license server, database, security
access configuration, and a logging facility.
RLM components:
Motif-based administration GUI
License server
rlmadmin ,
rlms tat ,
Command line administration interfaces
/usr/ lpp / rlm / db / l i c [ fru . S ] db
Vendor product license database
/usr/ lpp / r lm/db/user
User access control
/usr / lpp / rlm/db/ l og f i l e
License server event file
/usr/ lpp / r lm/db/nodelock
Node locked license registration file
RLM is started along with NCS as defined in / e tc / rc . nc s . The
r lmd subserver can also be started from the command line using the
s tart src command.
$ s tartsrc -s rlm
1 4.7
Using RLM
The RLM Motif interface can be invoked in an XU environment by
entering the r lm command on the command line.
$ rlm
To use RLM services from an ASCII display, enter the r lmadmin ,
r lms t a t , and rlmrpt commands at the shell prompt.
Add Vendor ACME S o f tware to the RLM Databas e
$ rlmadmin
Add x3270 license for node tulip
$ rlms tat - i
Display server license information
$ rlmrpt - 1
List license events
Network Computing System
1 4.8
1 4.9
l nfoExplorer Keywords
s tart s rc
s topsrc
nc s
rlms t a t
l lbd
r lm
/ e t c / rc . ncs
NCS Configuration
s tartsrc -g ncs
Start NCS subsystem
s tartsrc - s l lbd
Start local location broker
s tartsrc -s nrglbd
Start global location broker
Resource license manager:
/usr/ lpp / rml / db
Configuration files
Motif admin tool
rlmadmin , rlms tat , rlmrpt
Line mode admin tools
r lmd
License server
System Network Arch itectu re
1 5.1
Introduction to SNA
System Network Architecture (SNA) is a layered proprietary network
architecture developed by IBM for interconnecting systems. To fully
address SNA configuration and operation requires an understanding
of a large set of SNA program and hardware components spanning a
number of operating system environments. This subject is beyond the
scope of this book. The following discussion will concentrate on how
the RISC System/6000 can be incorporated into the SNA environment
and the services it provides. To provide a level set for those new to
SNA, I'll begin by defining basic SNA lingo, along with a diagram of a
logical SNA network.
1 5.2
SNA Overview
Each system participating in an SNA network is known as a node
(see Fig. 15. 1). Nodes are interconnected to other nodes via links.
Nodes are classified based on the services they provide as either
boundary nodes or peripheral nodes. Boundary nodes manage routing
and address translation for the global network. Peripheral nodes have
a local view of the network and support limited routing and address­
ing capability. They rely on the boundary nodes to hide the structure
of the global network. Nodes are also further broken down into types
based on the interfaces they support.
Each node contains a set of resources called network addressable
units (NAU). An NAU can be either a physical unit (PU), a logical
unit (LU), or a control point (CP). A PU controls real physical
resources like links, storage, and I/O hardware . An LU provides
transparent network access to the end user. An end-user LU is either
a program or device. A CP manages a node. A master CP, called the
system services control point (SSCP), manages all the nodes defined
Network Configuration and Customization
r- ·
\ I\
•./ \
(·-·�-����;·-·'>-- ·
_ __ _ _ _ _ _ _ . ..... .
Figure 1 5.1
_,,,,. .
SNA network.
within its domain. Multiple SSCPs may exist on a network, intercon­
necting their domains in a peer-to-peer relationship . Like nodes,
NAUs are also broken down into types based on their characteristics
and legacy.
Physical unit types:
PU type 2. 1. Peripheral node with limited addressing and routing
control. Provides multiple links and multiple LU sessions.
PU type 4, 5. Boundary node providing address translation and
routing control. PU type 5 contains the domain SSCP.
Logical unit types:
LU type 0. Primary and secondary LU support via API access for
point-of-sale devices.
LU type 1. LU support for input/output devices (printers, punches,
storage devices, console).
LU type 2.
LU emulation of 3270 data streams.
LU type 3.
LU emulation of 3270 printer streams.
L U type 6. 2. Advanced Program-to-Program Communication
(APPC) between LUs on a peer-to-peer basis vs. primary-to-sec­
Information exchange between NAUs on remote nodes involves cre­
ating paths at each layer of the protocol (see Fig. 15.2). At the physi­
cal layer, an attachment must be started in either outgoing call or
System Network Architecture
Application O S I 7
S ession OSI 4-6
Logical U n it
Path Ctl OSI 3-4
Path Control
P hysical OSI 1 -2
Figure 1 5.2
Data Link
Logical U nit
Path Control
· - · - · - · -
Data Link
SNA protocol stack.
incoming listen mode. The attachment represents the hardware and
driver programs that interface the node to the network.
A connection is created between the n o d e s . The connection
describes the network path between the nodes. This includes the
attachments, addresses, and application descriptions.
A session must be established between the two NAUs. Sessions are
long-lived paths that may be used serially by a number of applications.
At the top level, the LUs coordinate information transfer via a con­
versation. A resource id (rid) is returned when a conversation is start­
ed to identify the conversation. A conversation description clearly
identifies the send and receive application roles.
1 5.3
AIX SNA Services/6000
The RISC System/6000 can be incorporated into an SNA network
through the facilities provided by the AIX SNA Serv ices I 6000
licensed program product. AIX SNA Services/6000 implements a set
of programs, C library routines, device drivers, and configuration files
that provide LU and PU application transaction support. AIX SNA
Services/6000 does not provide PU type 4 or 5 boundary node support.
SNA services run as subsystems under the system resource con­
troller (SRC). The SNA system resource manager (SRM) interacts with
SRC to coordinate LU sessions and conversations. SRM is responsible
for starting and stopping connections and sessions, and maintains
secure conversations.
Applications access SNA network services via a set of library rou­
tines which interact with a multiplexed device driver, I dev I sna .
The library routines resident in I 1 ib I 1 ibsna . a manage network
interaction and data flow work through the equivalent AIX operating
system calls. AIX standard 1/0 library calls are supported by the SNA
device driver. This allows applications and standard AIX commands
to interact with SNA network services just like any 1/0 device. A con-
Network Configuration and Customization
nection identifier name may be used as an extension to the I dev I sna
device special file name to indicate the remote service to be used with
the application.
# cat f i le-name > / dev/ sna / <connec t i on-ident i f ier>
1 5.3.1
Physical interface
AIX SNA Services/6000 supports Ethernet ( standard and IEEE
802.3), token ring, X.25, and synchronous data link control (SDLC)
protocols. SDLC is a synchronous packet protocol which supports seri­
al data over switched and nonswitched point-to-point and multipoint
links. SDLC protocol is available for EIA232D, EIA422A, X.21, V.25,
and V.35 physical links. SNA and TCP/IP may coexist on a single
Ethernet or token ring adapter.
1 5.3.2
Defining the network
SNA configuration data is defined via SMIT and stored as structured
objects in a database. Access to configuration profiles is controlled via
subroutine calls to a data manager. Under AIX 3.1, profile informa­
tion is located in / u s r I lpp / sna / obj repos . In keeping with the file
system tree restructuring in AIX 3.2, the profiles have been moved to
I e t c I o b j r e p o s I s n a . Profiles describe the characteristics and
attributes of all network interactions.
Profiles descriptions:
Defines attributes and environment of SNA SRM and SRC.
Defines network link characteristics. May be referred to
by multiple connection profiles. Related hierarchically to
lower-level control point, logical link, and physical link
Control point
Describes local PU. May be referred to by multiple
attachment profiles.
Logical link
Defines the protocol used by an attachment.
LU address reg
Generic LU addresses.
Physical link
Defines physical interface hardware type.
Defines characteristics of the network link.
Local LU
Local LU definition associated with a TPN. May be
referred to by multiple connection profiles.
TPN list
Lists all transaction programs that may access a connec­
Defines a transaction program.
RTPN list
Lists all remote transaction programs that may access a
Defines remote transaction program.
System Network Architecture
Local LU
Mode List
TPN List
Control Point
Figure 1 5.3
Logical Link
LU Address
Physical Link
Profile hierarchy.
Mode list
Lists all mode rule profiles associated with a connection.
Defines a rule set that governs interaction on a connection.
You may have noted that the profile descriptions indicate that they
are related hierarchically (see Fig. 15.3). When defining a new ser­
vice, configure the associated profiles from the bottom level of the pro­
file to the top. This will make configuration procedures easier, since
higher-level protocols refer to lower-level names. Select a connection
name for the service and use it to name the other related profiles.
SMIT will append profile-specific suffixes to this name.
After installing AIX SNA Services/6000, you will be prompted to
configure your network interfaces along with the local and remote
applications that will communicate over the link. The configuration
information is applied by completing the profiles associated with each
level of the service. Since some of this information is defined by remote
sites and the domain SSCP, you will want to collect this data before
running the initial configuration. Sample profile forms are supplied in
AIX Communication Concepts and Procedures, Vol 2, GC23-2203 in
the section entitled "AIX SNA Services Customization Forms." The
peu command is used to create the profiles which are verified by the
ver i fysna command. These are invoked automatically by the instal­
lation procedures, but may be invoked later if required.
1 5.3.3
Network Configuration and Customization
Starting and stopping services
AIX SNA Services/6000 may be started at each boot by editing the
I e t c / re . sna script and uncommenting the SRC s tartsrc - s sna
command. You may also start the sna daemon manually or via SMIT.
# s tartsrc -s sna
Attachments and connections may also be started with the SRC
s tarts re command. These can be started as needed or as part of the
boot procedures by incorporating them in I e t c I re . sna . The type
and name are included as arguments to s tart s r c .
# s tartsrc -t attachment -o name
# startsrc -t conne c t i on -o name
Once started, the resource state may be active, inactive, or pending.
The active state indicates that the resource is available for use. The
inactive state indicates that the intended device is not available. If
the server has received the start request but has not completed start­
up processing, then the state is pending.
SNA services may be stopped using the SRC s topsrc command or
via SMIT. Three types of stops are supported as selected by the asso­
ciated s top s r c flag: normal, forced, or cancel. A normal shutdown
waits for application activity to complete. A forced shutdown does not
wait for application completion, but informs the remote stations that
the link is being dropped. Cancel is similar to forced, but no notifica­
tion is sent. Stopping attachments and connections requires the speci­
fication of the type and the name.
1 5.4
# stopsrc -s name
Normal shutdown
# s topsrc -f name
Forced shutdown
# s t opsrc -c name
Cancel shutdown
SNA Security
Secure communications on the network are enabled through the use
of two passwords, a communication authority password and a BIND
password. If the configuration profile database is not secured, then a
communication authority password is not required. The communica­
tion authority password is required on secured systems to change
configuration profiles. You may set the communication authority
password using the mksnapw command from the command line or via
SMIT. To change the password, use the chsnapw command or SMIT.
To remove the password, setting the security level to unsecured, use
rrnsnapw or SMIT.
System Network Architecture
II mksnapw
II chsnapw
II rmsnapw
BIND passwords may be required for LU 6.2 sessions. Specify the
password when configuring the profile for the LU. The password is
requested from the remote system when a connection is requested.
You can generate cryptic BIND passwords using the security keys
facility. This can be done via SMIT or using the genkeys command.
Specify the encryption phrase and number of keys as arguments.
II genkey -n <number> < encryption phrase>
The B IND p a s sword may b e updated via SMIT or using the
chsnaobj command.
II chsnaobj
1 5.5
-t c onnection -u lu6 . 2 -v no <name>
Network Management
SNA network management procedures are implemented and operat­
ed from Ne t Vi e w running on the domain S S C P . The R I S C
System/6000 can b e configured t o pass topology and alert informa­
tion from attached networks and local applications to the central
NetView manager on the SSCP. This is implemented using an SSCP­
PU connection between the SSCP NetView and an AIX network
manager application.
Network management applications have been a moving target over
the lifetime of AIX V3 . Initially AIX Network Manager I 6000 was
used to manage SNMP information on TCP/IP-based networks. This
product has been replaced by NetView I 6000 Entry for networks up to
32 SNMP agents. System View NetView I 6000 V2 is used for networks
larger than 32 SNMP agents. The NetView/6000 Entry manager pro­
vides all the necessary communication support to interchange data
with the central SSCP. The SystemView NetView/6000 V2 manager
requires both SNA Services/6000 and AIX NetView Service Point to
communicate with the central SSCP. See Chap. 1 1 concerning SNMP.
1 5.6
Since SNA resources are initiated by SRC, you can display limited
status information using the SRC l s src command or via SMIT.
II l s src -1 -s sna
Display general link status
II l s src -1 -t connection -o name
Display connection status
II l s src -1 -t a t tachment -o name
Display attachment status
Network Configuration and Customization
SNA links may also be traced using the trace facility. Specify the
trace level and associated name to the trac e s on and trac e s o f f
commands. Flags and options are similar to the l s src command. Use
trcrp t to generate a report. As always, tracing can also be managed
from SMIT. Trace output is located in /usr / lpp / sna for AIX 3 . 1 and
/ var I sna for AIX 3.2.
# traceson - 1 - t type -o name
Start a trace
# trac e s o f f - t type -o name
Stop a trace
# trcrpt / var / sna / name
Generate a report.
API level traces may be managed using the trace and t r c s t op
commands or using SMIT. Reports are generated using trcrpt .
# trace -a -j 2 7 1
Start an API trace
# trc s t op
Stop an API trace
# trcrpt -d 2 7 1
Generate a report
SNA events and errors are logged to an internal error log called
/ u s r / lpp / sna / snalog . * under AIX 3 . 1 and /var / sna / sna l o g . *
at AIX 3 . 2 . You can interrogate the error log using your favorite
pager. Remember to periodically clear the log using errc l ear .
# more /var / sna/ snalog . *
1 5.7
1 5.8
Display log entries
l nfoExplorer Keywords
/ l ib! l ibsa . a
/ dev / sna
l s s rc
s tart s r c
trac e s on
trac es o f f
veri fysna
trcrp t
/ e tc / rc . sna
trac e
t r c s t op
/ l ib/ l ibsna . a
SNA C 110 library
System Network Architecture
/ dev/ sna
SNA multiplexed device
Create SNA profiles
veri fysna
Verify profiles
s tartsrc - s sna
Start SNA subsystem
s tartsrc -t a t tachement -o <name>
Start SNA attachment
s tartsrc -t connec t i on -o <name>
Start SNA connection
mksnapw , chsnapw, rmsnapw
Connection authority pw
Gen encryption key
Update SNA config
System Services
and Resou rces
P rocess Management
1 6. 1
Process Overview
A group of processes executing under AIX is analogous to the genera­
tions of a family tree. Child processes are begotten by parent process­
es. Processes are born, live out their life's avocation, then pass away.
Process id 1, ini t , is the great-grandparent from which all process
generations owe their being. Like a loving grandparent, ini t takes in
the orphan processes that have lost their parents. Each process gets
its tum to execute on the CPU. Like little children, they require the
guidance of the scheduler so that everyone is ensured a fair share of
the CPU. The system administrator represents the grand overseer
over the process universe, wielding ultimate control over the lives of
all processes. A benevolent and all-seeing system administrator will
learn the ways of process life in the AIX world in order to maintain
tranquillity and peace.
1 6.2
Process Attributes
A process consists of an executing program and its address space.
Each process is named by a positive integer number called the process
identifier (PID). The PID is a vector index in the kernel process table.
PIDs are unique and are allocated in a somewhat random fashion.
Process table entries point to per-process kernel data structures. The
proc data structures define the attribute values associated with the
process. See / u s r / inc lude / sys /proc . h . The global AIX process
table can support up to 131,071 PIDs. Let's see you get that many
running on one machine!
Sampling ofprocess attributes:
Process identifier
Process group identifier
Process parent identifier
System Services and Resources
Process owner
Effective and real user and group identifiers
Controlling terminal
Address space
Size in pages
Paging statistics
Resource utilization
Process state
1 6.2.1
Displaying process attributes
Active process attributes can be interrogated from the command line
using the ps command. You can also use SMIT to invoke p s , but you
may find that using ps from the command line is faster. AIX supports
two flavors of ps : SYSV and BSD. The SYSV personality is used
when the command line arguments are preceded by the "-" character,
otherwise the BSD format is used.
SYSV process display format
It ps - e lk
2 14 0
2 004
5 8 0b
5 8 cb
7 8a f
12ce9 6 0
5a5 5 3 5 8
3 f0a8
pts / 0
7 : 37
2 2 : 02
67063 : 23
18 : 55
0 : 00
65 : 33
0 : 00
0 : 00
8 : 10
10 : 18
0 : 00
0 : 00
0 : 00
0 : 00
0 : 08
0 : 00
0 : 00
0 : 00
0 : 00
0 : 00
ini t
srcmst r
t sm
sys log
s endma i l
BSD process display format
It ps auxw
Jul 1 3
Jul 13
Dec 3 1
Dec 3 1
Dec 3 1
Jul 1 3
Jul 13
7 :36
22 : 00
66978 : 43
18 : 53
0 : 00
65 : 33
0 : 00
/ e t c / init
/ e t c / qdaemon
Process Management
2 140
p ts / 0
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
Jul 1 3
11 : 5 2 : 2 5
0 : 00
8 : 09
10 : 17
0 : 00
0 : 00
0 : 00
0 : 08
0 : 00
0 : 00
0 : 00
0 : 00
0 : 00 -
/ etc / syncd 6 0
/ etc / cron
/ et c / s rcms tr
/usr / l ib / errdemon
/ e t c / sys l ogd
/usr / l ib/ s endma i l
/ e t c / uprintfd
/usr / e t c / portmap
/ e t c / inetd
The COMMAND and CMD columns represent the program being run in
the process address space. A special set of kernel processes, kpro c s ,
are represented to collect accounting data for system overhead. You
may notice that one kpr o c process collects very high amounts of
CPU. There is no cause for alarm. This kproc entry collects the sys­
tem wait and idle time and represents it in the CPU field.
1 6.2.2
Process Identifiers
Along with its PID, each process records the integer ID of its parent
and its group membership, parent process identifier (PPID), and
process group identifier (PGID). Process groups are collections of one
or more processes. The group leader has a PGID equal to its PID and
each member has a PGID that matches the leader. Unless reset by a
s e tpgrp ( ) call, a process inherits the PGID of its parent. Process
groups provide a mechanism for signaling all processes within the
group using the PGID. This eliminates the need to know each mem­
ber's PID. The PID, PPID, and PGID are the primary handles used by
the system administrator for controlling process behavior.
1 6.2.3
Effective and real UID and GID
Processes are associated with an owning user identifier (UID) and
group ide ntifier (GID). The UID and GID name space are maintained
as part of the system account management and are recorded in the
/ e t c /pas swd and / e t c / group files (see Chap. 2 1). The real UID
and real GID numbers identify process owners for accounting and
process control purposes. An effective UID (EUID) and effective GID
(EGID) are assigned to each process and represent the permissions
and privileges available to the process during its lifetime.
1 6.2.4
Controlling terminal
Processes other than system daemons are usually associated with a
control terminal. The control terminal represents the default device
for standard input, output, and error channels and for sending sig­
nals via keyboard control characters. The control character to signal
mapping is user-customizable and recorded in the termi o structure.
System Services and Resources
See Chap. 9 for details on keyboard mapping. The controlling termi­
nal is identified in the ps TTY column.
1 6.2.5
Resource utilization and priority
AIX uses a priority-based set of run queues to allocate CPU resources
among active processes. Priorities values range from 0 to 127, each of
which is represented by a run queue. Lower-numbered queues are
scheduled more often than higher-numbered queues. Processes in a
run queue level are scheduled in a round robin fashion. E ach
process's queue priority is calculated from the sum of its short-term
CPU usage (0 to + 100), its nice value (0 to 40), and the minimum
user process level (40). The priority value increases for processes that
execute frequently and decreases for those that are waiting for execu­
tion. Processes with a priority value exceeding 120 will execute only
when no other process in the system requires CPU resources. Process
short-term CPU usage, priority, and nice value are displayed in the
PRI , c, and NI fields using the SYSV ps - 1 option.
The nice value is an integer that represents coarse priorities
between processes. AIX supports both the BSD nice value range of 20
to -20, and the SYSV range of 0 to 39. The larger the number, the
lower the scheduling priority. The two-value ranges are mapped such
that BSD - 20 corresponds to SYSV 0 for highest priority, and BSD
20 to SYSV 39 for lowest priority.
New processes inherit the nice value of their parents. The nice
value may be altered dynamically during the process lifetime. The
owning UID for a process can lower the process nice value. Only the
superuser can improve nice priority. The nice value can be set from
the command line using the n i c e command.
# nice -n <value> <coI1U11and>
Process owners and the superuser can modify existing process nice
values by using the reni c e command.
# renice <value> -p <PID>
Be aware that the BSD # C PU field represents the percentage of
CPU resources that a process has used in its lifetime. You may see
short-lived processes shoot up to very high # C PU numbers. A better
gauge for identifying CPU crunchers or runaway processes is the
T IME column.
1 6.2.6
Process state
The scheduler parcels out CPU time slices at a frequency that makes it
appear as if all processes are executing at the the same time. In fact,
Process Management
TABLE 1 6.1
Process States Displayed by pa
Available kernel process
they are being scheduled one at time, except in the case of multiproces­
sor systems. When a process isn't executing on the CPU, it may be
waiting on a resource or lock, sleeping on an event, suspended, or mov­
ing through some dispatch or scheduler state. The process state is
maintained as part of the proc structure information. The process
state is displayed by ps in the STAT column when the BSD 1 or SYSV
- 1 flag is used (see Table 16. 1). For processes that are flagged Waiting,
the WCHAN column identifies the address of the event being waited on.
1 6.3
Parent-Child Inheritance
A parent process creates a new child process by invoking the f ork ( )
system call. The kernel reserves a vacant PID for the child and copies
the attribute data associated with the parent into the child's proc
structure. The child is a clone of the parent until either the child, the
parent, or a privileged authority modifies the child's attributes via a
system call. The most common method of modifying a child's proc
attributes is by invoking a new program via the exec ( ) system call.
1 6.4
Controlling Processes
In Sec. 16.2.5, I talked about using the nice and renic e commands
to coarsely control the scheduling priorities between processes. What
do you do when process management requires a heavier hand? You
use ki l l !
The command name k i l 1 sounds much more ominous than it in
fact is. What ki l l does is send a specified signal to a process. The sig­
nal does not necessarily cause process termination. Note that ki l l is
a built-in command for some shells-for example, / b i n / c sh. The
behavior of the shell version of ki l l and /bin / ki l l may be different.
# ki l l [ - S ignal ]
[ PI D PID PID ... ]
PID > 0
Send signal to specified PIDs
Send signal to PIDs which have PGIDs equal to the sender
Send signal to all PIDs with EUID equal to the sender
System Services and Resources
PID < - 1
Send signal to all PIDs with a PGID equal to the absolute value of the
specified PID
If you want to send a signal to all your processes except the sending
process, use the ki l l a l l command.
# ki l la l l [ - s ignal ]
To display the set of supported signals, use the - 1 argument to
ki l l .
# /bin/ k i l l - 1
AIX signals are based on the SYSV implementation; however, some
BSD signals are mapped to their SYSV counterparts, and BSD signal
system calls are available. (Refer to Tables 16.2 and 16.3.) When writ­
ing or porting programs that use BSD signals and calls, be aware that
signals are not automatically reset after being caught. They must be
specifically reset to the required behavior in the signal handler routine.
1 6.4.1
Rules of thumb
It seems to be a common practice to use the KILL ( 9 ) signal to ter­
minate a process. I recommend that you do this only as a last resort
after first trying HUP ( 1 ) and ABRT ( 6 ) . The latter two signals
allow a process to terminate gracefully. In the case of ABRT, a core file
is produced which may be used for debugging. The K I LL signal basi­
cally attempts to yank the process out of the process table without
permitting any cleanup activities.
# ki l l -1 <PID>
First try HUP
# ki l l
Then try ABRT
6 <P I D>
# ki l l -9 <P I D>
KILL if all else fails
Occasionally, a user may try out some ingenious bit of C code that
contains a statement along the lines of
whi l e ( l )
fork ( ) ;
I'm not insinuating that this is done on purpose, but it can be a pain
in the neck to stop. New processes are being created as fast as you
can kill them. One little trick you can try is to kill them by PGID. Use
the formatted output, - F , option with SYSV ps to display the PGID.
Then send a signal to the negative PGID.
# ps - e l -F pgid , runame
# k i l l - 6 - <pgid>
Process Management
TABLE 1 6.2
Signal Names and Numbers
TABLE 1 6.3
Hang up at terminal disconnect.
illegal instruction.
Trace trap.
Abort process and core dump.
EMT instruction.
Floating-point exception.
Kill process. Can't be caught or ignored!
Bus error.
Segmentation violation.
System call bad argument.
Write on a pipe with no one reader.
Alarm clock timeout.
Termination signal.
Urgent condition on I/O channel.
Stop. Can't be caught or ignored!
Interactive stop.
Continue. Can't be caught or ignored!
Sent to parent on child stop or exit.
Background read attempted from control terminal.
Background write attempted to control terminal.
I/O possible or completed.
CPU time limit exceeded.
File size limit exceeded.
Input data is in the HFT ring buffer.
Window size changed.
Power-fail restart.
User-defined signal 1.
User-defined signal 2.
Profiling time alarm.
System crash imminent; free page space!
Virtual time alarm.
Migrate process (Locus TCF).
Programming exception.
AIX virtual time alarm.
HFT monitor mode granted.
HFT monitor mode should be relinquished.
HFT sound control has completed.
Secure attention key.
Signal Compatibility Mapping
Printer to backend error signal.
Base Ian I/0.
PTY I/0.
Abort process.
Death of child.
BSD signal ??
1 6.4.2
System Services and Resources
Ignoring hangup
A common problem is starting a command in the background or as a
daemon from the command line of a login shell only to find that the
command exits when you log out. This is because a hangup (HUP)
signal is sent to the process when your terminal connection has been
broken. You can specify that these commands are to ignore HUP by
using the nohup command.
# nohup < conunand> &
1 6.5
Background process ignoring hangup.
Scheduled Processes-cron
The UNIX c ron utility provides a basic means for scheduling jobs to
be run at a particular time of the day or on a periodic basis. cron can
be used to take care of regular system housecleaning tasks like
sync ' ing disk writes, cleaning out I tmp , and running accounting
programs. These types of periodic tasks may be tailored through the
use of crontabs. A crontab is a list of commands and scripts with
designated run times that will be invoked by c ron under the EUID of
the owner. c ron reports any errors or output information to the own­
ing user after the commands are executed. c ron logs errors to a log
file, / var / adm / c ron/ log, and if AIX auditing is enabled, produces
audit records.
1 6.5.1
To create a c rontab, use your favorite editor and create a table with
the following format:
Each of the time-associated fields may be represented as a comma­
separated list. A " * " may be used to represent all possible times. For
example, if I wanted to display upt ime statistics every half hour on
the system console, I would add the following line to my crontab file.
0 , 3 0 * * * * /bin/up t ime > / dev/ conso l e
Once you have your c rontab file tailored to your liking, hand it off
to cron by invoking the crontab command.
# crontab <YourCrontabFi l e>
All c rontabs are stored in / var / adm / cron / c rontabs under the
owning user name.
User adm Cron tab :
Process Management
# ( C ) COPYRIGHT Interna t i onal Bus iness Machines Corp . 1 9 8 9 , 1 9 9 1
# All Right s Reserved
# Li c ensed Materi a l s-Proper ty of IBM
# = = = = = = = = = = = = = = = = = = = = = = = = = =
8 am-5pm act ivi ty reports every 2 0 mins during weekdays .
act ivi ty repor t s every an hour on Saturday and Sunday .
6pm- 7 am act ivity reports every an hour during weekdays .
Daily summary prepared at 1 8 : 0 5 .
#= = = = = = = = = = = = = = = = =
# Dai ly summary prepared at 1 8 : 0 5 .
#= = = = = = = = = = = = = = = = =
8 - 1 7 * * 1 - 5 /usr / l ib / s a / sal 1 2 0 0 3 &
* * * 0 , 6 /us r / l ib / s a / sal &
1 8 - 7 * * 1 - 5 /usr / l ib / s a / sa l &
1 8 * * 1 - 5 /us r / l ib / s a / sa2 -s 8 : 0 0 -e 1 8 : 0 1 - i 3 6 0 0 -ubcwyaqvm &
# = = = = = = = = = = = = =
= = = = = = = = = = = = = =
runacct at 1 1 : 1 0 every night
# dodi sk at 1 1 : 0 0 every night
# ckpacct every hour on the hour
# monthly accounting 4 : 1 5 the f irst of every month
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
1 0 2 3 * * 0 - 6 /usr / l ib / ac c t / runacc t 2 > / u s r / adm/ ac c t / n i t e / ac c terr
> / dev/ null
0 2 3 * * 0 - 6 /usr / l ib / acc t / dodisk > / dev / null 2>&1
* * * * /us r / l ib / ac c t / ckpacc t > / dev/ nu l l 2>&1
1 5 4 1 * * /usr / l ib / ac c t /monacct > / dev/ null 2 > & 1
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
The system administrator can enforce access controls on who may
use c r o n s ervices by listing user name s , one p er line , in the
/ u s r I c r o n / { c r on . a l l ow , c r o n . deny } files. c r on checks
these files' authorizations, before invoking a user's crontab file. The
default is to allow access to all users.
1 6.5.2
Ad hoc jobs
Suppose you want to run a job off-hours, but don't want to create a
c rontab entry for it. It may be a one-time-only run . You can do this
using the at and batch commands. Note that batch is just a script
that invokes at. Execute at, specifying the time and the input stream
of commands . The j ob stream is copied to the / u s r I s p o o l
/ cron / at j obs directory. c ron then executes the job stream at the
specified time. Authorization to run at jobs is controlled like c rontab
by listing user names in the / u s r / a dm / c r o n / { a t . a l l ow ,
at . deny } file. The default is to allow access to all users.
# at < t ime> input <Ctrl -D>
Start a job at time
# at -r j obnumber
Remove a job
# atq <username>
List scheduled jobs
If a more sophisticated batch scheduling system is required, see
Chap. 27.
1 6.5.3
System Services and Resources
Managing cron activities
In active batch environments, you might want to place some limits on
cron scheduling. The / u s r / adm / c ron / queuede f s file can be config­
ured to limit the number of concurrent jobs by event type, set the
default nice value, and set the retry limit. Event controls are listed
one per line in the queuede f s file.
queuede f s format:
e . [ j # ] [ n# J [w# J
Event type
Max number of concurrent jobs
Nice value
Retry wait in seconds
queuede f s events types:
at events
batch events
crontab events
sync events
ksh events
c sh events
The queuede f s file is shipped empty. Default values for all event
types support 100 concurrent jobs, at nice value 2 with a 60-second
retry limit.
Example queuede f s entry:
c . 2 j 2n9 0v
1 6.6
2 crontab jobs, nice value 2 , retry every 90 seconds.
System Resource Controller
AIX. provides a mechanism for controlling and managing sets of pro­
grams that function collectively as a unit. This mechanism is called
the system resource controller (SRC). SRC provides simple command
interfaces to display status, refresh, start, and stop system services as
a single entity. These interfaces reduce the operation and administra­
tion complexity of managing all the daemons and programs that
make up a particular service.
The collection of programs that make up an SRC service unit are
called subsy s t ems . The daemons that make up a subsystem are
known as subs ervers. Subsystems may be grouped by the overall ser­
vice they provide and are identified as subsys tem groups. For exam­
ple, the f tpd daemon is a subserver of the inetd subsystem. The
inetd subsystem is a group member of the TCP I P subsystem group.
Process Management
Figure 1 6.1
SRC hierarchy.
SRC allows the operator or administrator to operate on a service at the
subserver, subsystem, or subsystem group level (see Fig. 16. 1).
1 6.6.1
SRC components
Overall SRC is provided by the srcms t r daemon. srcms tr is started
at boot time by an entry in I e t c I ini t tab.
s rcms tr : 2 : respawn : / etc / srcms tr
# system resource controller
s r cms t r identifies subsystem components from definition in ODM
object classes I e t c / obj repo s / { SRC s ub sys , SRCno t i fy. Subsys­
tems and subserver configuration information is managed through
the use of the { mk , ch , rm } s erver and { mk , ch , rm } s sys commands.
In most cases, the subsytems and subservers are predefined for each
product at install ation time.
Once a subsystem group, subsystem, or subserver is configured into
the ODM, it may be operated on using the following commands:
s tartsrc
Start a subsystem
Stop a subsystem
ref re sh
Restart or refresh a subsystem
trace { on , o f f }
Trace a subsystem
l s src
Display subsystem status
Subsystems may be started at boot time following the srcms tr by
invoking the s tartsrc command as part of a boot re script or direct­
ly from / etc / ini t tab .
SRC command examples:
# s tartsrc -g tcpip
Start the TCPIP subsystem group
# s topsrc - s qdaemon
Stop the qdaemon subsystem
To display the status of all defined subsystems, use the l s src com­
mand. Note that subsystem control may also be invoked via the SMIT
subsys and subserver fast paths.
System Services and Resources
# l s s rc - a
1 6.7
1 6.8
sys l ogd
rpc . mountd
rpc . s tatd
rpc . lockd
wr i t e s rv
sendma i l
yppas swdd
l lbd
spo o l er
nf s
nf s
nf s
nf s
spoo ler
spoo ler
t cpip
t cpip
mai l
keys erv
lnfoExporer Keywords
ini t
reni c e
pro c e s s
ki l l
subsys t ems
s i gnal
/ et c / ini t tab
s e tpgrp
c ron
s rcms tr
/ et c / pa s swd
s tartsrc
/ et c / group
s topsrc
t ermi o
bat ch
l s src
a t j obs
Process management:
Process control:
Process Management
/usr/ inc lude / sys / proc . h
Process attributes
p s - < opt ions>
Display running process information (SYSV)
ps <opti ons>
Display running process information (BSD)
Lower process priority
BSD admin process cntrl
Send process a signal
kill -1
List signals
Kill all your processes
Ignore hangup signal
Batch support:
System job scheduler
/var/ spoo l / cron / c rontabs
cronjob tables
/usr/ adm / c ron/ { cron . al l ow , cron . deny }
Authorize cron use
Batch job support
/usr/ adm/ cron / queuede f s
cron job limits
s rcms tr
Subsystem master daemon
s tartsrc , s topsrc , refresh
Manage subsystems
l s src
List subsystem state
E lectro n i c Mai l
1 7.1
Mail System Overview
It is with mixed feelings that I write this chapter on configuring and
managing electronic mail-the reason being that electronic mail is
addictive! Don't try to tell me it's not. It's one of those things that
once you have it, you can't live without it. Everyday my mailbox
receives close to a hundred mail files. I find myself sneaking an e­
mail fix throughout the day, in the evenings, on weekends, after
church! I feel like I'm pushing an uncontrolled substance!
Seriously, electronic mail provides avenues of collaboration that are
changing the way we do business, research, and interact with each
other. Electronic mail is informal. People who have never been intro­
duced feel at ease to discuss almost any topic via electronic mail. The
impromptu nature of electronic mail seems to allow people to express
their views and feelings honestly (sometimes beyond their better
It's our duty as administrators to support this kind of interaction.
After all, information sharing is what this industry is all about. With
a little feeding and care, the electronic mail system can be a con­
trolled substance that is good for everyone.
The electronic mail (e-mail) system is conceptually, if not physical­
ly, divided into two components: the user agent (UA) and the mail
transport agent (MTA).
Mail components:
1 7.1 .1
/bin /ma i l or /usr/ucb/ma i l
User agent
/usr/ sbin / s endmai l
Mail transfer agent
Mail user agents
The mail user agent provides the user interface to the mail system.
The UA presents incoming mail to the user for reading and archiving.
System Sources and Resources
Editor facilities for composing, forwarding, or replying are managed
by the UA. A great deal of human factors research is being invested
in UA design. Sure, make it even more addictive!
The ATT and BSD mail programs provide all the basic elements of
a good UA. No frills, but they get the job done. For naive users, these
probably aren't good UAs to use. Full-screen menu-oriented UAs like
e lm or pine are probably a better choice. Because this is an adminis­
trator's text, I won't spend time on the pros and cons of the various
UAs. It's a religious issue best left to the practitioners. Since I am
employed by the University of Washington, I will at least say that you
can obtain a copy of p ine via anonymous ftp from f tpho s t . c a c
. washington . edu. You can find e lm and other user-friendly UAs
from a number of ftp sites on the network. Use archi e to find the ftp
site nearest you. See App. A.
In the following sections, when referring to a UA, assume basic
ATT or BSD mail functionality and options.
The system administrator is responsible for setting the default UA
configuration options . The default options are defined in the
/usr I l ib / . Mai l . re file. Each user may override the global defaults
by resetting the options in a local $ HOME I . mal. lrc file.
Configuration file for UA:
# /usr / l ib/Mai l . rc
# Opt i ons
set ask askcc dot save keep crt
# Don ' t display the f o l l owing header l ines
ignore Rece ived Mes s age-Id Res ent -Mes sage - I d
i gnore Status Mai l -From Return- Path Via
1 7.1 .2
Mail transport agents
The MTA is responsible for receiving and delivering mail. At a mini­
mum, the MTA must be able to accept mail from UAs and the network,
decipher addresses, and deliver the message to a local user mailbox or
to a remote MTA. Better MTAs will be able to detect e-mail loops, route
a single mail message for multiple recipients at the same site, support
privacy, and route problem mail to a site postmaster. Common MTAs
include BSD s endma i l , mmdf , sma i l , and mhs . In the following sec­
tions, I will discuss s endma i l configuration and administration.
1 7.1 .3
Addressing and headers
In order for a mail message to traverse from user A to user B, an
addressing mechanism that is understood by the MTAs must be used.
From the discussion in Chap. 1 1 concerning the domain name space,
Electronic Mail
you might think that this is a simple issue. However, e-mail gateways
to other networks involving other addressing protocols can make
address resolution an AI-hard problem (artificial intelligence).
The most common UNIX mail formats involve Internet domain
addressing and UUCP addressing.
us er@domain-address
Internet address
hos t l ! ... ! des t ina t i on ! user
UUCP address
Two types of mail headers are attached to each mail message that
defines the attributes of the message. The Simple Mail Transfer
Protocol (SMTP RFC 82 1) provides a command syntax that MTAs use
to negotiate mail transfer from one MTA to the next.
Example SMTP header:
HELO daf fy . foo . bar . edu
Introduce yourself to the MTA
MAIL From : raphael @park . foo . edu
Indicate the originator
RCPT To : rachael @ l i te . house . com
Announce the recipients
Supply the data
... ema i l mes s age
The second type of mail header is the RFC 822 header. It is used by
both the MTA and UA. The RFC 822 header identifies the path the
mail message has traveled, date, originator, recipients, subject, etc.
Example mail header:
Received : from mai ler . foo . edu
by l i t e . hous e . com id AA03 0 3 7 ;
Tue , 1 6 Jun 8 9 1 5 : 0 7 PST
Received : from park . foo . edu
by mai l er . foo . edu id aa12 2 4 2 ;
Tue , 1 6 Jun 8 9 1 5 : 0 1 PST
Date : Tue , 10 Aug 93 1 4 : 5 9 : 1 0 PST
From : raphael @park . foo . edu
To : rachae l @ l i t e . house . com
Subj ect : Meet ing Wednesday
Rachael :
Can we meet on Wednesday t o discuss mai l er
con f i gurat i on for the department works tations .
The ordering of the received lines indicates the MTA path that the
mail message has traveled. This path can be used to debug routing
problems and loops.
1 7.1 .4
How mall ls sent
When a user composes a mail message, the UA attaches a header
envelope to the message separated by a blank line. The UA then
hands the message off to the sendmail MTA. A new sendmail daemon
System Sources and Resources
is forked to process the new message. Sendmail passes each of the
addresses associated with the mail message through address transla­
tion rule sets. The rule sets parse the address line and determine if
the message destination is local or remote. If the message is destined
for a remote site, name service may be queried to determine if a pre­
ferred mail exchange site is requested for the remote site (name ser­
vice MX record). If the remote site is running a sendmail MTA, the
message is transferred to the remote site using the SMTP protocol
described previously. At the remote site, sendmail runs the addresses
through the rule sets again to determine if the recipient is local or
remote. If the recipient is local, the headers are rewritten and the
message is spooled to the recipients mail inbox.
1 7.2
Sendmail Configuration
The sendmail MTA i s probably the most common MTA in u s e .
Unfortunately, it i s one o f the most difficult to configure. Sendmail was
originally written by Eric Allman at the University of California at
Berkeley at a time when mail traffic was sparser than what we experi­
ence today. It is to Eric's credit that sendmail has proven to be general
enough to evolve with the traffic requirements. Sendmail has gone
through many changes since its inception and as a result has become
quite complex. Successfully configuring a s endmai l . c f file can cer­
tainly be considered one of the rites of passage to UNIX wizardom.
Sendmail data files:
/ e tc / s endmai l . c f
Sendmail configuration file
/ et c / s endmai l . c fDB
Compiled sendmail configuration file
/ e t c / s endmai l . nl
Sendmail national language rules
/ e tc / sendmai l . nlDB
Compiled national language rules
/ et c / a l iases
Mail aliases
/ et c / a l iases { DB , DB . pg }
Compiled alias file
/ e tc / s endmai l . pid
PID of sendmail daemon
/ et c / sendmai l . s t
Mail statistics
NOTE: These files are accessed via symbolic links from I usr I 1 ib .
1 7.2.1
sendmai l . cf
The sendmail configuration file, I e t c / s endmai l . c f , contains the
majority of the options and rules required by sendmail to deliver e­
mail. The s endma i l . c f file maintains three sets of configuration data:
Options, variables, and parameters
Address rewriting rule sets
Mailer identification and delivery
Electronic Mail
The best way to start configuring a new s i l . c f file is to
obtain a copy of one that works. AIX V3 supplies a boilerplate s end­
mai l . c f file that can be used with minimal changes if your e-mail
environment is not complex. By complex, I mean that you have a
number of mail gateways to other networks or a hierarchy of MTAs.
You can tailor the s i l . c f file using your favorite editor or
using the AIX / u s r / l ib / edcon f i g command. edc on f i g provides a
menu-oriented approach to editing s i l . c f components. For
those of you new to sendmail, it focuses your attention on the option
being changed. It's easy to get confused when working with the whole
file in an editor. The edconfig command (see Fig. 17. 1) may become
confused with custom s end.mai l . c f files. Use it only with the AIX­
supplied s i l . c f .
# / us r / l ib/ edc on f i g / etc / s endmai l . c f
Commands and definitions begin in column 1 in the s i l . c f
file. Comments begin with a "#" character. Blank lines are ignored.
Due to the number of special characters used, you need to be careful
when adding address types like DECNETS "::" node delimiters. A set
of predefined character symbols is used to indicate the definition of
new symbols, classes, options, macros, or rules. Using a "$ " sign with
a macro or variable name indicates the value of the variable or macro.
A "?" indicates a boolean test. In the following discussion, I'll define
the symbols used in each section of the s i l . c f file and provide
an example.
1 7 .2.1 . 1 Options and defi n itions section. The first section of the
s i l . c f file identifies the run-time options and variables.
These include definition of the host or domain name, if name service
mail exchange is supported, message precedence, etc.
Clas ses :
Return to this menu
Exi t wi thout wri ting edited con f i gura t i on f i l e
Wri t e edi ted configurat ion f i l e and exi t
Edi t Hos t Name Informat ion
Edi t Domain Name Parts
Edi t Conf igura t i on Opt i ons
Set the configura t i on f i l e level
Selection :
Figure 1 7.1
edconfig panel.
System Sources and Resources
Option symbols:
"D "
Defines a symbol from text or a built-in
DSfoo . bar . c om
Defines subdomain as var "S."
Defines a class from a list
CFho s t l ho s t 2 ho s t 3
Defines a host list as var "F."
Defines a class from a file
FF / u s r / l o cal / l ib/hosts
Obtains list "F" from hosts
Defines header formats
Example: D ? P ? Return- Path : < $ g>
Sets sendmail run-time options
Defines return-path format.
QA/ etc / a l i as e s
Defines alias file path.
Supports all nameservice
mail exchange records and
host table lookups.
Sets trusted users
Example: Tusernamel username2
These users may invoke send­
mail and masquerade as
other users.
Sets message precedence
p r i o r i ty =
j unk =
- 100
Indicates delivery priority if
Prec edence : header field is
found. Negative numbers do
not return mail on error.
1 7.2.1 .2 Address rules. The address rewriting rules are where the
apprentices are separated from the wizards. The s endma i l daemon
uses the rule sets to parse the address lines from the mail header to
determine how the mail message should be delivered.
Each rule set is made up of three parts: left hand side (LHS), right
hand side (RHS), and optional comment (C). Each part is separated
by a TAB. In general, if an address matches the LHS rule, then the
RHS rule is applied to the address. The rule sets are applied in order
until a failure occurs (see Table 17 . 1). Any number of rule sets can be
defined (see Table 17 .2).
To deliver a mail message, the rule sets must resolve to a (mailer,
host, user) tuple.
Example: Rule Set 7 Parses Domain String
#Domain addressing ( up to 5 l eve l )
@$2 . $3 . $4 . $5 . $6 . $7
R$+@ $ - . $ - . $ - . $ - . $ - . $ @$2 . $3 . $4 . $5 . $6
R$ + @ $ - . $ - . $ - . $ - . $ @$2 . $3 . $4 . $5
R$+@ $ - . $ - . $ - . $ @$2 . $3 . $4
R$ + @ $ - . $ - . $ @$2 . $3
R$+@$- . $ @$2
R$ +@ $ -
Electronic Mall
TABLE 1 7.1
sendmail . cf
Rule Sets
Rule set
Applied first and is responsible
for canonicalizing the address
to internal form.
Rewrite recipient address.
Rewrite sender address.
Applied last and determines
delivery. Address must be
resolved to a (mailer, host,
user) tuple.
Final rewrite of canonical
internal form to external form.
TABLE 1 7.2
Rule Set Symbols
LHS Tokens:
$$ =X
Match 0 o r more tokens
Match 1 or more tokens
Match exactly 1 token
Match any token in class X
Match any token not in X
$ >n
$ #mai l er
$ @hos t
$ : user
$ [ hos t $ ]
Use token n from LHS
Call ruleset n
Resolve to mailer
Specify host to mailer
Specify user to mailer
Get host from resolver
Terminates ruleset
Terminates current rule
RHS Tokens:
1 7.2. 1 .3 Mailer delivery. The last section of the s i l . c f file
identifies the mailers to be used to deliver the mail message. Each
mailer is identified by a name, a program used to transfer the mes­
sages to the mailer, the set of program flags, the send and receive
rules, and the argument set.
Mailer identification format:
M<ma i l er> P = <prog> F = < f lags> S = < s end- rule> F = <receive - rule> A =
< arguments>
Example local and OSIMF x . 4 0 0 RFC 9 8 7 Mailer Definition
Mlocal , P = /bin/be l lma i l , F = lsDFMmn , S = 1 0 , R = 2 0 , A = mai l $u
M9 8 7 gateway, P = /usr/ lpp / o s imf / et c / x4 0 0mai ler , F = sBFMhulmnSC , S = 1 5 ,
R = 2 5 , A = gateway - f / e t c / x4 0 0 gw . c f g $ f $u
Sendmail accesses configuration file information from a compiled
version of the / e t c / s end.mai l . c f table. To compile a new version of
the database use the sendmail bz flag.
System Sources and Resources
# /usr / l ib/ sendma i l -bz
1 7.2.2
Comp i l e a new sendmai l . c f database
sendmail . nl
The ADC-supplied s endma i l daemon also obtains national language
rule sets from the I e t c / s endmai l . nl file. The national language
rules are regular expressions that may be used to identify country
names or country codes to support language translation. If the coun­
try is identified in the list of NLS code sets, the message is converted
to the correct code set.
AIX-supplied / e t c / s endma i l . nl :
# aix_sc c s id [ ] = " c om/ cmd / send / s endmail . nl . bos , bos 3 2 0 AIX 6 / 1 5 / 9 0
2 3 : 2 5 : 54 "
# COMPONENT_NAME : CMDSEND sendma i l . nl
# ORIGINS : 10 2 6 2 7
# ( C ) COPYRIGHT Interna t i onal Bus iness Machines Corp . 1 9 8 5 , 1 9 8 9
# Al l Rights Reserved
# Licensed Materi a l s-Property of IBM
# US Government Users Res tric ted Right s-Us e , duplication or
# di s c l o sure res tric ted by GSA ADP Schedule Contrac t with IBM Corp .
# Created : 0 3 / 2 4 / 8 9 , INTERACTIVE Sys tems Corporat i on
# ###################################################################
# Thi s f i l e contains l i s t s of regular expres s i ons which are
# compared agains t the des tination address when sending out
# mai l to o ther sys tems . Each comma-separated l i s t is preceded
# by e i ther " NLS : " or " 8 8 5 9 : " . Addresses which match an i tem
# in these l i s t s wi l l have the body of the mai l i t em encoded
# as ei ther NLS escape sequences or ISO 8 8 5 9 / 1 charac ters ,
# respe c t ively .
# Be fore each address is compared wi th these l i s ts i t is passed
# through ruleset 7 , whi ch normally s trips the user information
# from uucp- s tyle addresses and route and user informa t i on from
# domain- s tyle address e s .
# The f o l l owing exampl e l i s t s shows how thi s f i le might look :
# # l i s t the nls compatible sys t ems
# NLS : A @ . *madrid\ . ,
# A @rome ,
# A @ . * i taly\ . europe $ ,
# ! nagasaki ! $ ,
# l i sbon ! ,
# munich ,
# berlin
# # l i s t the IS0- 8 8 5 9 compatible sys tems
# 8 8 5 9 : . *vi enna ! $ ,
# A @bangkok\ . tha i land ,
# A @ tangiers ,
# A @kinshasa
Electronic Mail
# Note that all do t s " . " in an address mus t be es caped with
# a backs lash " \ " . Al l s t andard regular expre s s i on rules apply .
# Several of the above examples are not recommended for ac tual
# use but are shown to give s ome idea of the f l exibi l i ty that
# is a l l owed . For exampl e , the f i r s t examp l e "madr i d " wi l l match
# any domain-s tyle address whi ch has thi s name as a subdomain .
# A more l ikely examp l e of this type i s " i taly . europe " whi ch wi l l
# match a l l domains that are i n that subdomain . The examples
# "munich" and " berlin• are no t recommended forms ei ther s ince they
# wi l l match a variety of addresses .
# Thi s f i l e mus t be comp i l ed us ing the " -bn " opt i on be fore sendmai l
# can u s e i t . I t i s recommended that this f i l e b e tested against
# common addres s e s using the " -br " opt i on to ver i fy that addresses
# are being interpreted correc t ly .
17 2 3
The sendmail alias database provides a mechanism for forwarding
mail to one or more users when mail is addressed to the alias name.
In particular you will want to set up aliases for the site p o s tmas ter
and MAI LER-DAEMON ids. The postmaster account is a standard used
by the network at large for requesting mail help and information for a
site. The MAILER-DAEMON account is used by sendmail to route
problem mail.
Example / e t c / a l i ases :
# A l i a s e s in thi s f i le wi l l NOT b e expanded in t h e header f rom
# Mai l , but WILL be vi sible over networks or from /bin/ma i l .
# >>>>>>>>>> The program " newal iases " mus t be run a f t er
# >> NOTE >> updat ing thi s f i l e before any changes
# >>>>>>>>>> show through to sendmai l .
# Alias f o r mai l er daemon
# The f o l l owing al ias i s requi red by the new mai l protoco l , RFC 8 2 2
postmas t er : root
# Aliases t o handl e mai l to msgs and news
msgs : " l /usr/ucb/msgs - s "
nobody : " l cat> / dev/ nul l "
# Alias for uucp maintenance
uucpl i s t : root
### These are local aliases # # #
trouble : roo t
root : deroes t
Sendmail accesses alias information from a dbm version of the
/ e t c / al i ases table. To compile a new version of the / et c / a l i a s e s
table, use the / u s r / l i b / n ewa l i a s e s command or / u s r / l i b
/ s endrna i l -bi.
# /usr / l ib / s endma i l -bi
Create new alias database
1 7.2.4
System Sources and Resources
Mail logs
It's a good idea to keep logs of sendmail activity. They are very help­
ful in diagnosing problems, identifying slow mail loops, and sleuthing
connections from remote sites. Sendmail logs activities using sys ­
l o gd. The default log file location per I e t c / sys l og . c onf is the
/ var I spo o l /mqueue / sys log file.
Example sys log :
Aug 9 1 3 : 1 9 : 0 1 da ffy s endma i l [ 1 4 6 0 2 2 ] : AA1 4 6 0 2 2 : mes s age - i d =
< 9 3 0 8 0 9 2 0 1 8 . AA0 5 8 3 6 @mxl . cac . washington . edu>
Aug 9 1 3 : 1 9 : 0 1 daf fy sendma i l [ 1 4 6 0 2 2 ] : AA1 4 6 0 2 2 : from =
<MAILER@UWAVM . U . WASHINGTON . EDU> , s i z e = 1 7 3 1 , class = 0 , received from
mxl . cac . washington . edu ( 1 4 0 . 1 4 2 . 3 2 . 1 )
Aug 9 1 3 : 1 9 : 0 2 da f fy s endmai l [ 5 1 0 4 7 ] : AA1 4 6 0 2 2 : to =
<deroest@da f fy . cac . washington . edu> , delay = 0 0 : 0 0 : 0 2 , stat = Sent
Because the log file tends to grow rapidly, you need to periodically
close it and archive it. This procedure can be handled via cron and
the /usr / l ib / smdemon . c l eanu script. The script closes the syslog
file and copies it to a l og . file for archiving. The default r o o t
crontab contains an entry for smdemon . c leanu . However, it i s com­
mented out. Remove the comment and replace the crontab to activate
log file cleanup.
Crontab for smdaemon . c l e anu :
4 5 2 3 * * * u l imi t 5 0 0 0 ; /usr / l ib/ smdemon . c l eanu > / dev / nu l l
1 7 .3
Starting and Stopping Send mail
Sendmail is invoked as a subsystem from the / etc / re . t cpip script.
The AIX sendmail automatically compiles the / e t c / a l i a s e s and
/ et c / s endma i l . c f files when it is started. If you are running a non­
IBM-supplied sendmail, you may need to force a compile of these files
as part of the start-up.
# /usr / l ib / s endma i l -bi
Compile /etc/aliases
# /us r / l ib / s endmai l -bz
Compile /etc/
# /usr / l ib/ sendma i l -bn
Compile /etc/
You can also use the / e t c / newa l i a s e s command to compile the
alias file. If you update any of the configuration information while
sendmail is running, compile the files and refresh the sendmail sub­
system by issuing an SRC r e f resh command or sending the daemon
# refresh -s sendma i l
# k i l l - 1 ' cat / e tc / sendmai l . pi d '
The basic start-up flags for sendmail should invoke sendmail as a
daemon and specify the time in minutes between mail queue scans for
Electronic Mail
postponed messages. These flags are -bd and - q< t ime> .
# /usr / l i b / s endma i l -bd -q3 0m
Start and scan mail queue every 30 minutes
To stop the s endma i l daemon, use the SRC s tops rc command or
send a SIGABORT to the daemon.
# s t opsrc -s s endma i l
# ki l l - 6 ' cat / e t c / sendmai l . p i d '
1 7.4
The simplest way to test sendmail is to use the -v verbos e flag with
/ u s r / b i n / ma i l . It provides feedback on the interaction between
# /usr/bin/ma i l -v bart@krusty . fun . com
Subj ect : test
t e s t mai l body
bart ... setsender : uid/gid = 4 0 8 4 / 0
bart@krusty . fun . com. .. Connect ing t o krus ty . fun . com . tcp...
bart@krusty . fun . com... Connec t ing to krus ty . fun . c om ( tcp ) ...
2 2 0 krusty . fun . c om Sendmai l 5 . 6 5 / Revi s i on : 2 . 2 8
ready at Mon , 9 Aug 93 1 2 : 4 0 : 4 2 - 0 7 0 0
> > > HELO mobius . bank . org
2 5 0 kru s ty . fun . com Hel l o mobius . bank . org , pleased to meet you
>>> MAIL From : <doogie@mobius . bank . org>
2 5 0 <doogie@mobius . bank . org>... Sender ok
> > > RCPT To : <bart@krus ty . fun . com>
2 5 0 <bart@krusty . fun . com> ... Recipient ok
>>> DATA
3 5 4 Enter mai l , end with
on a l ine by i t sel f
2 5 0 Ok
> > > QUIT
2 2 1 krus ty . fun . com clos ing connection
bart@krus ty . fun . com... Sent
Test rule sets by invoking sendmail with the -bt flag. Sendmail
will prompt for the rule sets to be invoked and the address. Separate
each rule set number with a comma.
rewr i t e :
rewr i t e :
rewr i t e :
rewrite :
rewr i t e :
rewr i t e :
rul e s e t
rul e s et
rul e s e t
# /usr / l ib/ s endma i l - b t - C / us r / l ib / s endmai l . c f
Enter < ruleset> <addres s>
> 2 , 4 , 0 deroe s t @washington . edu
\\ @ II
input :
" deroes t "
returns :
" deroes t "
input :
" deroes t "
"washington "
\\ @ II
returns :
'' deroes t "
''washington 11
input :
" deroe s t "
"washington "
" "V "
returns :
" l ocal "
" "' X "
" deroes t "
" ..
" ..
" ..
" ..
" ..
" edu "
" edu "
" edu "
" edu "
" edu "
" da f fy "
The sendmail command supports a number of debugging and trace
levels. They can be activated using the start-up option -d<nn> . <mm>,
System Sources and Resources
where <nn> and <mm> define the debug and trace levels. You'll want to
redirect the output to a file as it can be very verbose. The IBM AIX
s endma i l daemon only supports a value of 2 1 . <mm> where <mm> can
be any positive integer. If you are running a current copy of sendmail,
refer to the source code for debug and trace values.
# /usr/ l ib / s endmai l -bd - q3 0m - d2 0 . l
Check the logs, mail queue, and stats files periodically for stalled
mail or loops. You can list the pending delivery queue using the mai l q
# mai lq
Mai l Queue ( 1 reques t )
-QID--S i z e--Q-TimP----S ender / Rec ipient-­
AA4 9 8 7 2 ( no control f i l e )
Files i n the mail queue are identified b y a QID. The first character
of the QID designates the type of queue file.
Message data file
Lock file
" "
Backup file
Control file
Temp file
" "
Transcript file
The / e tc / s endmai l . s t file can be checked using the /us r / l ib
/ ma i l s t a t s command.
# mai l s ta t s
Mai l er
bytes_f rom
To reset mail statistics, invoke mai l s t a t s with the - z flag.
# mai l s tats - z
1 7.5
Managing Mail Queues
As administrators, it's our responsibility to inform users when mail
arrives and pester them to get rid of old unwanted mail. Since the lat­
ter is a difficult job at best, I'll start with the easy one of informing
users when mail arrives.
The c oms at daemon, when prompted by s endma i l , informs users
that new mail is waiting. This feature is supported by the MAI L and
MAI LMSG variables defined in the default / et c /pro f i l e .
Electronic Mall
MAIL = / var / spool /mai l / $LOGNAME
Path to incoming mail
Mail waiting message
The c oms at daemon must also be defined in I e t c / inetd . conf
c omsat
wai t
/ e t c / comsa t c omsat
It's also a good idea to inform users when mail is waiting at login
time. This can be accomplished by checking the mail from the default
login scripts for each shell. See Chap. 21 for details on setting up sys­
temwide default login scripts.
Sample login mail check:
II ! /bin/ sh
i f [ -s " $MAIL "
then echo " $MAILMSG"
Without being heavyhanded with your user community, it is diffi­
cult to encourage users to keep up with incoming mail. The best poli­
cy is to use regular reminders and track queue usage using disk uti­
lization commands like du .
1 7.6
# du -s /var / spool /mail
Disk usage for mail queue
II du - s /var / spool /mai l / *
Mail queue usage by user
OSIM F/6000
Chapter 11 described the Open Systems Interconnection (OSI) refer­
ence model for networking. Besides the reference model, there exist
OSI standards for transport, file transfer, and electronic mail ser­
vices. For sites interested in providing OSI protocol support, the
OSIMF I 6000 licensed program product is available for the RISC
System/6 0 0 0 which provi d e s the protocols listed previously .
OSIMF/6000 will coexist with the TCP/IP protocol stack on a single
system. This allows you to implement a protocol gateway between
For the purposes of this electronic mail discussion, X.400 MTA to
SMTP gateway support is defined by RFC 987 and can be configured
using OSIMF/6000. In this environment, you may elect to use either
RFC 822 style UAs or the X.400 UA provided by OSIMF/6000.
Since a complete description of X.400 protocol and components is
beyond the scope of this book, I'll briefly outline the steps in defining
an X.400 gateway.
1. After installing OSIMF/6000, edit the / u s r / l pp / o s im f / e t c
I l o admhs script and include the local presentation address of the
System Sources and Resources
MTA The presentation address is the MAC-level address of the
2. Next, edit the MTA configuration file, / et c /rota . c fg, and include
the O/R names (originator/recipient), UAs, and MTA/UA routing
information. Edit the X.400/SMTP gateway file / e t c / x4 0 0 gw . c fg
to define O/R name mapping attributes. Check the mailer section of
/ e t c / s endmai l . c f to see that OSIMF/6000 gateway support is
3. Invoke / u s r / lpp / o s imf / e t c / makemhs to build a new X.400
1 7.6.1
Starting and stopping the gateway
OSIMF/6000 start-up parameters are specified as arguments to the
/ etc / rc . o s imf command. To invoke X.400 mail support, use the
mhs argument.
# rc . os imf -mhs
Start X.400 mail support
To stop OSIMF/6000 protocols, use the o s imf . c l ean command.
# o s imf . c l ean -mhs
1 7. 7
Stop X.400 mail support
lnforExplorer Keywords
/usr / l ib / . Ma i l . rc mai l
/ u sr / l ib/ smdemon . c l eanu
. ma i lrc
mai lq
s endma i l
mai l s t a t s
c omsat
sma i l
/ et c / s endmai l . c f
/ et c /pro f i l e
/ et c / a l i a s e s
/ e t c / inetd . conf
edc on f i g
/ et c / s endmai l . nl
p o s tmas ter
/ e tc / sys log . conf
o s imf
sys l ogd
Electronic Mail
1 7.8
Electronic mail
Mail user agent:
/bin/ma i l or /usr /ucb/ma i l
User agent
/usr / l ib/Ma i l . rc
Global options
/home / $USER/ . ma i l rc
User options
Mail transfer agent:
/usr/ sbin / s endrna i l
Mail transfer agent
/ e t c / sendrnai l . c f
Send.mail configuration
/ etc / s endrnai l . c fDB
/ e t c / s endrna i l . nl
Sendmail NLS rules
/ e t c / s endrnai l . nlDB
Compiled NLS rules
/ e t c / al i ases
Mail aliases
/ et c / a l i asesDB
Compiled alias file
/ e tc / sendrnai l . pid
PID of sendmail daemon
/ e t c / s endrnai l . s t
Mail statistics
/ var / spool /mai l / $USER
Incoming mail
/ var / spool /mqueue
Queued mail
Mail subsystem:
s endrna i l -bi
Build new alias DB
s endrna i l -bz
Build new sendmail DB
s endrna i l -bn
Build new NLS DB
s endrna i l -bd -q3 0m
Start sendmail
mai l q
List queued mail
mai l s t a t s
List mail statistics
mai l -v <user@addres s >
Verify delivery
telnet <ho s t >
25 Telnet to SMTP port
s endrnail - b t - C / usr / l ib / s endrnai l . c f
Test rewrite rule sets
sendrna i l -d2 0 . 1
Run send.mail in debug
/var / spoo l /mqueu e / sys log
Sendmail log
1 8. 1
Read A l l About It
Usenet News is a network-based bulletin board system that reaches
hundreds of thousands of users via Internet and UUCP connections.
Users interact in electronic discussion groups called newsgroups
using interfaces called news readers. The news reader clients present
an interface that resembles electronic mail user agents. Usenet topics
range from serious research discussions to humor, hobbies, politics,
just about anything you can think of. News is another one of those
addictive network services. Providing news service is a carrot that
will assist in getting the hard sell folks to use your computers .
However, "Once you giveth you canst taketh away!"
1 8.2
News Resources
Any system on the network can host a bulletin board and accept or
provide news feeds with other interested sites. Depending on the feeds
a site is willing to accept, a news server can receive tens of megabytes
of news information a day. Dedicated spool space is required to house
news data. Control over who you accept feeds from, the news groups
you will accept, and setting expiration policies for old news allow you
to manage the disk resources required. It is a good idea to house news
in a file system of its own.
Network bandwidth is another important consideration. Sites
receiving news feeds via dial-up UUCP connections will want to run
transfers during off hours and implement high-speed modems with
data compression.
For very active news sites, the news server will require sufficient
memory and CPU to support the connection daemons and search pro­
cessing resources required by news reader connections. Using server
software that supports threaded searches will reduce search CPU
System Services and Resources
1 8.3
News Server
The news server machine receives and transmits news feeds and
accepts client connections using the Network News Transfer Protocol
(NNTP). The NNTP protocol is described in RFC977 along with the
general overview of how network news functions. NNTP represents a
basic protocol that supports a limited set of commands and responses
allowing for the selection and identification of news groups and arti­
cles (see Table 18. 1). The protocol is similar to that employed by elec­
tronic mail Simple Mail Transfer Protocol (SMTP).
There are a number of news software packages available via anony­
mous ftp. Packages like nn tp and inn provide the server support for
reader/poster clients, transfer clients for news feeds, and administra­
tion tools for controlling resource utilization. News server daemons
can be run stand-alone or they can be invoked by inetd. The choice
will depend on the traffic levels to be supported. The server forks a
daemon for each client connection which maintains the dialog for
news articles located in / us r / spool / news . Note that most of the
server software comes as a base package and then a large number of
patches are available. Make sure you get the whole set of patches
when installing a particular release.
Servers can restrict client access and posting by identifying trusted
sites in the / u s r I l ib / news / nntp . a c c e s s file. Trusted sites are
identified by address, access rights, post allowed, and news groups. A
host address may be either the host name, domain name, network
name, or IP address. Wild cards are supported using the "*" charac­
ter. Negation is implemented using the " ! " character.
/ u s r / l ib / news / nntp . ac c e s s :
# Exampl e nntp server access f i l e
# Address Access Post
defau l t
TABLE 1 8.1
NNTP Commands
Return news article, body, or header
Set current article pointer
Return first and last group article numbers
Return list of news groups
Return command summary
Identify article number to server
Set article pointer to previous article
New groups created since date and time
List of message IDs of new articles
Set article pointer to next article
Request posting to a group
End connection with server
This connection is to a slave server
ibm- competator
da f fy
* . whatsamata . edu
128 . 23 9 . 2 . 110
! comp . unix . aix
Although these packages provide their own NNTP protocol support
under the nn tpxmi t program, additional software like nntplink can
be incorporated to improve performance and provide time-based news
Your best bet is to take a look at all the server packages and pick
one that represents your sites requirements. Be sure to review the
documentation supplied with the server software carefully. Other
server sites with which you interact are depending on the coordina­
tion of feeds. Subscribe to the administration and new user news
groups for additional information.
News-related news groups:
news . sysadmin
news . s o f tware . b
news . s o f tware . nntp
news . s o f tware . readers
news . news ites
news . announce . newusers
news . announce . newgroups
1 8.4
News Readers
Like cars on the highways, there are a number of news reader pack­
ages to choose from (see Table 18.2). Most sites end up supporting
more than one news reader. "Different strokes for different folks!"
The news readers are responsible for user interaction with the
news groups. They perform functions like news group subscription,
archiving, searching, reading, and posting. Each user's news interac­
tion state is kept in a $ HOME / . news rc file. The . news rc file indi­
cates which groups a user has subscribed to and the identification
number of the last article read.
$ HOME / . newsrc :
a l t . activism ! 1 - 2 7 3 0 0
a l t . angs t ! 1 - 2 0 5 2
TABLE 1 8.2
News Readers
Read News
Threaded Read News
Xll Read News
No News is Good News
Threaded Internet News
Gnu Emacs News Macros
Email User Agent with News Support
Macintosh News Reader
System Services and Resources
alt . aquaria ! 1 - 1 2 6 8 3
alt . athe i sm ! 1 - 2 8 7 2 2
a l t . bbs ! 1 - 1 0 3 6 9
a l t . beer ! 1 - 5 0 5 8
alt . books . techni cal ! 1 - 9 5 3
alt . brother - j ed ! 1 - 1 0 7 5
alt . callahans ! 1 - 1 9 1 3 1
a l t . cd- rom ! 1 - 2 7 8 9
a l t . c o - ops ! 1 - 4 6 4
alt . cobol ! 1 - 7 8 1 , 7 8 5 - 7 8 6
alt . conf ig ! 1 - 8 2 8 5
It goes o n and on.
Some news readers incorporate their own posting software, yet
there are posting packages that may be added which provide addi­
tional features and improved header checking. In general, the posting
software validates the news header, appends a user-supplied s ig­
nature file, and transfers the file to the news server.
1 8.5
News Groups
The last time I looked at my . news rc file there were 2380 different
news groups. Mind you, I don't subscribe to them all . On the average,
I have noticed about five new news groups coming on-line each day.
Sites may add local groups as they see fit. Networkwide groups must
go through a balloting procedure before the group becomes public.
Many electronic mail discussion lists are forwarded into news groups.
A number of the Bitnet Listserv discussions are represented in news
groups under the b i t . l i s t s erv classification (see Table 18.3).
News groups that are related to AIX and UNIX administration are
listed as follows. You likely won't be able to follow them regularly, but
they are worth checking out.
TABLE 1 8.3
News Group Classifications
b i t . l i s t s erv
c omp
mi s c
vmsne t
Alternative topics
Genetics and biology topics
Bitnet Listserv discussion topics
Vendor topics
Computer-related topics
Gnu freeware topics
Elementary and secondary education topics
Miscellaneous topics
Usenet administration and use
Recreation topics
Scientific topics
Social topics
General topics
VMS topics
Various local groups
1 8.6
comp . unix . aix
A1X and RS/6000 discussion
comp . unix . wi zards
UNIX wizards Q&A
comp . unix . sources
Public domain sources
comp . unix . l arge
Large and distributed UNIX systems
comp . unix . os f . mi s c
OSF general discussion
comp . unix . o s f . os f l
OSF/1 discussion
b i t . l i s tserv . aix- 1
Bitnet A1X e-mail discussion
b i t . l i s t s erv . spl - 1
Bitnet POWER Parallel SPl discussion
b i t . l i s tserv . 1 1 - 1
Load Leveler batch discussion
b i t . l i s t s erv . power-pc
POWER PC discussion
b i t . l i s t serv . dqs - 1
Distributed Queuing System discussion
News Software Sites
The AIX public domain software repository at UCLA has both source
and binary news server and news reader packages. See App. A for
information on obtaining software from public servers.
1 8.7
News daemon
nntpxmi t
News transfer
nntpl ink
News transfer
/ var / spoo l / news
News spool
/usr / l ib/news / nntp . access
Restrict nntp access
rn , trn , xrn , nn ,
News readers
$HOME / . newsrc
tin , gnus
News group state
DOS Services
1 9.1
WARNING: The topic of this chapter may be offensive to hardened
UNIX afficionados. That's right, it's about MS-DOS. Gasp! As hard
as it is to believe, the majority of computer users don't run UNIX.
Alas, its true. Have no fear, the tools described will show you how
MS-DOS and AIX can coexist and interoperate peacefully on the
same hardware.
1 9.2
DOS Tools
Basic DOS file import and export capability is provided under AIX,
using the do s format , do s di r , do sread , doswr i t e , and do s ­
de l commands. These commands are useful when sharing text files
between the two operating systems. do s f o rma t uses an RS/6000
diskette drive to DOS format 3 . 5-in diskettes . The do s r e a d and
doswr i t e commands move files between AIX and DOS media with
selectable line end NL to CR-LF mapping and Ctrl-Z end of file inser­
tion. d o s d i r displays DOS diskette directory contents. do s de l
removes a file from the diskette media.
# dos format
Format a diskette
# dosdir
Display disketted directory
# dosread [ -a l <DOSFile> <AIXF i l e>
Copy a DOS file to AIX
# doswrite [ - a l <AIXF i l e > <DOSF i l e>
Copy an AIX file to DOS
# dosdel <DOSFi l e>
Delete a DOS file
Pacific Microelectronic's Common-Link software can be used to
include Macintosh disk formats. The program supports both DOS and
Mac file transfer via diskette with easy-to-use menus.
System Services and Resources
1 9.3
Intel Emulation
DOS emulation packages provide the next level of DOS functionality
under AIX. Packages like IBM's Personal Computer Simulator I 6000
(pcsim) and Insignia's SoftPC emulate the Intel hardware environ­
ment on top of AIX. Device support and application response may suf­
fer due to the multiple layers of emulation required and limited
device access. It's common to see a 10 X degradation in application
throughput and up to 20 x degradation for graphics display control
under software emulation.
1 9.4
Layer 6
Layer 5
Layer 4
Layer 3
Intel Emulation
Layer 2
Layer 1
RS/6000 Hardware
Personal Computer Simulator/6000
AIX Personal Computer Simulator I 6000 (pcsim) emulates an Intel
80286 PC hardware environment under AIX. The Intel emulation
doesn't support multitasking environments like Windows 3 . 1 or OS/2,
and there is no support for protected mode applications. Officially,
pcsim runs MS-DOS 3.30. MS-DOS 4.0 and 5.0 will work within lim­
its. You can run Windows 3.0 in real mode, but I question why you
would want to do this, even on a real 286 machine. pcsim shares dis­
play, disk, and diskette resources with AIX; however, there is no direct
control or access provided to RS/6000 devices or the Micro Channel.
1 9.4.1
Installing DOS on pcsim
The first problem many people run into after installing pcsim is that
they forget to install MS-DOS. You execute the pc s im command,
DOS isn't found, so you're thrown into the BASIC interpreter. Sigh!
The following procedure will fix you up.
1. Create a file for the emulated C drive
# touch /usr/ lpp /p c s im / Cdrive
2. Start pcsim with DOS diskette inserted
# pc s im -A 3 -C /usr/ lpp /pcsim/Cdr ive - s ave
3. Create DOS partitions
C> A : \ FDISK
DOS Services
4. Install DOS
C> A : \ SELECT C : 0 0 1 US
5. Exit pcsim and set permissions
# chmod 4 4 4 /usr/ lpp/pcsim/ Cdrive
1 9.4.2
Multiuser pcsim
pcsim supports a limit of five users in a multiuser environment. The
shared DOS OS and application base reside in the read-only c : drive,
/ u s r / lpp / p c s im/ Cdrive. A shared read-write data drive may be
set up as drive D . Create a directory called /usr / lpp /pc s im/ Drive
with permissions set to 777. Make sure that this drive is defined in
the default pcsim profile. Each pcsim user may also have local direc­
tories as drives E through z . Only one user at a time will have access
to diskette drives.
In a multiuser environment, if you have to kill pcsim sessions from
AIX, remember that they are using shared memory that must be
freed. Look for x4 9 5 0 4 3 in the ipcs list. Remove each entry, last to
first, using the ipcrm -m command. Remember to consider the pcsim
resource requirements on your system when planning a multiuser
1 9.4.3
Running pcslm
You can tailor your pcsim environment using command line flags at
each invocation, or using a static configuration profile called s improf .
Example pcsim command line:
% pc sim -A 3
-C /usr/ lpp /pc s im/ Cdrive
-D / u s r / lpp/pcs im/ Drive
-E /home /user / DOS / Edrive
-dmode V
-lptl lp
-mous e coml
-refresh 5 0
Example s impro f profile:
Adi skette
: 3
/usr/ lpp /pcsim/Cdrive
/usr/ lpp /pcsim/ Ddrive
/home /user / Ddrive / DOS / Edrive
Note that you can't use shell environment variables in the profile.
System Services and Resources
You can create a s impro f profile based on the command line flags
by adding the - s ave flag when invoking pcsim. A default system pro­
file is located in / u s r / lpp / pc s im/ s ampl e s directory. When pcsim
is started, it will look for s impr o f profiles in the current directory,
your home directory, and the system default directory. Options in
each of these profiles will be accumulated for the session. To exit
pcsim, type < ESC>pc s im.
1 9.4.4
pcsim features
1 Display. pcsim emulates both monochrome and VGA dis­
plays. Monochrome emulation of Code Page 437 is available for HFT,
aixterm, and TTY sessions. VGA is supported from and
may be sized to full screen. Default VGA resolution is 720x480 with
256 colors. IBM Xstations must be configured for 256 colors for full
VGA compatibility. The display type is selected using the &node com­
mand line flag or profile parameter.
Most of the performance problems experienced under pcsim are
related to refreshing the display. Each screen update requires a com­
plete refresh of the display. You can set the screen refresh rate using
the refresh flag or profile parameter. Refresh rate may range from 20
to 500 ms. When pcsim is updating a remote session, net­
work performance can be a bottleneck. Each screen refresh will result
in a burst of screen data based on the following formula. Monochrome
mode will provide better performance if graphics are required.
Screen attributes for a given terminal type are the result of a com­
bination of terminfo and pcsim I TTY definitions. I'll cover pcsim ter­
minal attributes further in the next section. If your terminal defini­
tion does not support a 25-line screen, you can use the F12 key to
shift the display between the first and 25th screen lines.
1 Keyboard. Like terminal screen attributes, keyboard maps
are based on information in the / u s r / l ib / t erminfo and / u s r / lpp
/ pc s im/ t ty configuration files. pcsim TTY definition files are named
like their terminfo counterparts identifying the desired emulation.
Custom key definitions can be set up by editing the section labeled
HARDCMD in the appropriate pcsim TTY file. If you aren't certain
what sequence a particular key on your terminal transmits, use vi in
input mode and enter the sequence c t r l -V your-key. You should see
the sequence of characters sent by your-key displayed on the screen.
Remember that some keys transmit a C R / NL sequence. Make sure
you include this in your definition. The following commands are use­
ful when setting and verifying your key map definition.
DOS Services
/usr/ lpp /p c s im/ samples / s imXkeymap
Set key maps
/usr/bin / setmaps
Check syntax
/usr/bin/ed i t ty
1 Mouse. Mouse support under AIXwindows is available using
grab mode or free mode. Grab mode attaches the mouse to the pcsim
window and is no longer available to other AIXwindows clients. To
select grab mode, define the mouse using Coml or Com2 Note that cap­
ital letters are significant in the ComN identifiers. Free mode allows you
to share the mouse with other AIXwindows clients. The mouse is only
active under pcsim when it is within the window. Configure free mode
using c oml or c om2 For best results use the Microsoft or PS/2 mouse
drivers, and a screen refresh rate of 50. To keep AIXwindows and
pcsim mouse acceleration in synch, specify -wrap when starting X.
1 Disk. DOS disks may be emulated within an A.IX file, or
provided via access standard A.IX file system directories. The latter
facilitates sharing files between A.IX and DOS and will work in NFS
and AFS environments. When accessing an A.IX directory as a hard
disk, remember to create a do s l abel file if you intend to label the
disk with the DOS LABEL command. To access lowercase file names
in the A.IX directories, specify the c a s e command line flag or profile
parameter. Emulated disks are created within an A.IX file using the
DOS FDISK command. Multiple logical drives may be created within
a single emulation file. Drive letters are mapped to files, directories,
or devices using command line flags or profile parameters. Standard
convention is to use letters c and D for emulated disks and E through
z for A.IX directories.
RS/6000 diskette drives may be shared between A.IX and one pcsim
session. The diskette drives are identified using drive letters A and B
The dt ime command line flag indicates idle time when the diskette
drive is available to one side or the other. CD-ROM is also accessible
as a DOS disk as long as it formatted in High Sierra or 1809660.
1 Printers. Printer support is provided by mapping the DOS
LPTl, LPT2, and LPT3 print devices to standard A.IX print queues.
Specify the A.IX queue name after each of the LPTn command line
flags or profile parameters, where n represents device 1, 2, or 3. DOS
print jobs are passed to A.IX as files and then passed to the appropri­
ate qdaemon queue using enq -q. Since pcsim and A.IX must commu­
nicate when an individual print job file should be closed and printed,
the p t ime flag is provided to indicate device idle state.
1 COM devices. Access to RS/6000 serial ports is defined using
c omN to / dev / t tyP mapping from command line flags or profile
entries. N indicates the com port number and P the TTY device .
31 0
System Services and Resources
Applications that are timing-dependent on com port control may exhib­
it unpredictable results due to AIX device buffering. To make RS/6000
serial ports available to pcsim, complete the following procedure.
% cp pcs im/ l ib/pcs imdd / e tc / t ty/pcs imdd
% ln / e t c / tyy/pcs imdd / e tc / drivers /pcs imdd
Configure the serial port us ing SMIT
Add " / et c / t ty / t tyconf -1 p c s im• to / e t c / re
1 Memory. Conventional and extended memory are supported
by pcsim. Expanded memory is not supported. Conventional memory
is the first 640 KB of DOS memory. The Intel 80286 processor intro­
duced the ability to address memory beyond 640 KB. DOS did not
have this capability, so expanded memory managers were developed
to open a small window in conventional memory, within which to
address the upper memory blocks. Extended memory managers came
along later that allowed direct addressing of the upper regions of
memory. Use the xmemory parameter to define from 1 MB to 15,875
MB of extended memory. Allocation units are in 1-KB units. For per­
formance reasons, you should note that pcsim is designed to stay resi­
dent in memory and not be paged out. Remember that you are basi­
cally dedicating memory to each pcsim session to support DOS
conventional, extended, and video memory requirements.
1 Coprocessor. Intel 80287 coprocessor emulation is available
using the i 2 8 7 command line flag. I have heard reports that the 287
emulation is either faster or slower under pcsim than the real McCoy.
You'll have to decide this one for yourself. One thing to watch out for
is that floating-point numbers are represented in 80-bit format in
memory and 64-bit IEEE format when expressed in registers.
1 9.4.5
pcslm AIX communication
pcsim does not provide any default communications mechanism
between DOS and AIX . You can hack a communication channel by
using print queues with a custom backend to trap and interpret
incoming commands from pcsim. It will work, but it is NOT elegant.
A cleaner solution can be found in the / u s r / lpp / p c s im/ s amp l e s
files. Example applications are provided which allow you to send com­
mands and signals to AIX processes from within pcsim. An AIX
process may also attach to the simulator's shared memory to provide
a communications channel.
1 9.5
Binary Interfaces
To improve response and device support, vendors like Insignia and
Sun Microsystems SunSelect division are implementing application
DOS Services
31 1
binary interfaces on top of the UNIX kernel. The Windows Application
Binary Interface (WABI) from SunSelect is getting the most press in
this area.
WABI is a reverse-engineered set of Windows application subrou­
tines. These routines provide the interface glue between a Windows
application and the base X l l and UNIX kernel routine s . This
removes some of the emulation overhead and improves response.
WABI delivers 486 response under current RISC platforms.
Layer 4
Layer 3
Layer 2
Layer 1
RS/6000 Hardware
IBM has endorsed WABI and will be supporting it on the PowerPC
and RS/6000 platforms. Sun would like to see other UNIX vendors
bundle WABI with their base operating system offerings. This work
has been done without the blessing or assistance of Microsoft.
1 9.5.1
Microkernel personalities
Further improvements in speed, device support, portability, and
available OS personalities are being realized using microkernel tech­
nology. Microkernel operating systems like Carnegie Mellon's Mach
modularize many traditional kernel functions and move them outside
the kernel into user space. What's left is a very small streamlined
kernel with standard interfaces to portable file system, device driver,
scheduler, and pager modules.
IBM has been working with microkernel technology in the design of
their WorkplaceOS operating system. WorkplaceOS packages virtual
memory management, task and thread management, interprocess com­
munication, I/O processing, interrupt handling, and hardware inter­
faces into a base kernel. At the next level, modular Personality Neutral
Services (PNS) like file system support, naming services, device dri­
vers, scheduler, pager, and network services are added. Operating sys­
tem personalities are layered on top of the PNS layer. This architecture
defines a standard open interface for layering operating system person­
alities like UNIX, DOS, Macintosh, Taligent, etc. Since some layered
services may not fit the PNS model, a dominant personality is used to
manage non-PNS services in a multipersonality environment.
OS layer
UNIX, DOS, Mac, etc.
PNS layer
File system, device, naming, pager, scheduler, network
Kernel layer
VMM, IPC, Threads, I/O, Interrupt, Hardware
Hardware layer
Intel, PowerPC
See Fig. 19. 1 for a microkernel block diagram.
31 2
System Services and Resources
Operating System Personalities
Personality N eutral S ervices
File System, Device, Naming, Pager, Sched uler, Network
M icrokernel
VMM , I PC , Th reads, 1/0, I nterrupt, Hardware
Hardware Architectures
Figure 1 9.1
Microkernel layers.
The microkernel design provides additional functionality, such as
parallelism, not normally associated with personal computers and
workstations. Multiple OS personalities will allow the user to mix
and match applications and share data. WorkplaceOS will be avail­
able on Intel and PowerPC architectures.
1 9.6
Remote DOS Services
In the near term, most of us are going to get the best DOS response
running native on real Intel or clone architectures. An AIX server can
be used to enhance the native DOS environment by providing file sys­
tem, application, and printing services. The good news is that two com­
mon remote DOS file system and print server packages are provided as
part of the base AIX operating system, the PC NFS authenticator pen f sd and the AIX Access for DOS (AADU) server pci (see Fig. 19.2).
1 9.6.1
PC NFS server support is provided by the standard AIX NFS services
with the addition of authentication and spooling services provided by
/ u s r I s b i n / rpc . p cn f s d. Authentication services provide a login
mechanism allowing PC NFS users to gain privileges by identifying
themselves to the AIX server. Users may access NFS file systems with­
out authentication, but their privileges are mapped to user nobody.
NFS services may be accessed over Ethernet, token-ring, or slip con­
nections. If you are using slip, you will want to use error-correcting
modems, as NFS is based on UDP, which does not provide any error­
checking or checksum support.
pcnf s d may be run as a subserver under the inetd subsystem or
as a stand-alone server. To run pcn f s d as a subserver under inetd,
add the following entry to the I etc I inetd . c on f file:
DOS Services
31 3
PCI Server
Figure 1 9.2 Remote DOS services.
pcnfsd sunrpc_udp udp wai t root /usr/ sbin / rpc . pcnfsd pcnf sd 1 5 0 0 0 1 1
You may want to run pcnf sd as a stand-alone daemon to alter the
location of the spooling directory. Remove any existing p c n f s d
entries from / e t c / i n e t d . c o n f , and add the following lines to
/ et c / rc . tcpip :
i f [ - f /us r / sbin/rpc . pcnfsd ] ; then
/usr/ sbin/rpc . pcnfsd -s <SpoolDirPath> ; echo ' pcnfsd\n '
1 9.6.2
DOS server for AADU
File system, print spooling, and UNIX application access are also pro­
vided by Locus Computing Corporation's PC-Interface (PCI), more
commonly known to the AIX community as AADU. PCI uses a propri­
etary protocol to provide access to these services over Ethernet,
token-ring, and dial-up connections.
The AIX p c i server is started by invoking the / e t c / re . pc i script
from an / et c / ini t tab entry. The ini t t ab entry should read:
rcpc i : 2 : wai t : / e t c / rc . pc i > / dev/cons o l e 2 >& 1
p c i supports print spooling via the / u s r / p c i / b i n / p c ipr i n t
script. You can direct default LPTl spooling to a particular AIX print
queue by editing pc iprint and specifying the default queue name.
For example:
exec /bin/ enq -P Las erJet
31 4
System Services and Resources
1 9. 7
Info Explorer Keywords
1 9.8
s imXkeymap
do s format
s etmaps
edi t ty
dos read
doswr i t e
t tyconf
do sde l
pcn f s d
p c s im
/ e t c / inetd . c onf
s improf
/ u s r / sbin / rpc . pcnf s d
/usr / l ib / termin f o
/ e t c / ini t tab
/ u s r / lpp / p c s im/ t ty
/ u s r / p c i / b i n / p c iprint
pc i
dos format
Format a diskette
Display disketted dir
dosread [ - a ] <DOS F i l e > <AIXF i l e >
Copy a DOS file to AIX
doswr i t e [ -a l <AIXF i l e > <DOSFile>
Copy an AIX file to DOS
dosdel <DOSFi le>
Delete a DOS file
Personal Computer Simulator/6000:
/usr/ lpp / p c s irn
Product and config dir
$USER / s irnprof
Start up profile
/ et c / t ty/ t tyconf -1 p c s irn
Add serial port access
/usr/ lpp / p c s irn/ sarnples / s irnXkeyrnap
Set key maps
edi tty
Edit key map
/usr/ lpp / p c s irn/ sarnples
Sample programs
ipcrm -rn
Remove shared mem segment from failed
Remote PC services:
rpc . pcnfsd
PC NFS daemon
PC Interconnect (AADU)
X1 1 Ad m i n istration
Windows on the World
Using almost any operating system from a single-window ASCII dis­
play is becoming a thing of the past. Why is this so? Windowing sys­
tems like X Windows, Microsoft Windows, and the OS/2 Presentation
Manager are springing up everywhere and redefining the overall
human interface to computing. Once you have windows, you can't live
without them!
AIXwindows Overview
The AIXwindows I 6000 system is the IBM variant of the Xll release
4 and release 5 distribution. The X Windows System was developed
by a group of vendors and researchers at MIT collectively known as
the X Consortium. The consortium was formed in January of 1988 to
build upon the windowing system developed by the MIT computer sci­
ence department and MIT Project Athena. Consortium membership is
open to any organization as either an affiliate or member-at-large. For
more information contact:
MIT X Consortium
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
X Windows uses a reverse client/server mechanism based on Widget
and toolkit libraries to manage a display either locally or over a net­
work connection using RPC. The reason I call it "reverse client/server"
is that commonly in the X environment, the clients are the remote
entities that are communicating with the local X server which controls
the local display. The X Consortium code is freely available and will
build on most UNIX architectures, including AIX.
System Services and Resources
Like most windowing systems, X Windows incorporates the use of a
mouse and cursor to provide point-and-click management of clients
displayed on the screen. Window managers provide the ability to drag
and drop displayed clients to any location on the screen. The window
manager also provides customization of the display environment,
including menu interfaces used to invoke X clients.
Common X Windows components:
Server controlling a local display device.
Motif window manager. One of many that assist in managing the
screen environment.
xterm , aixterm
Emulated terminal connection to a system using master slave
PTY devices.
xc lock
Analog or digtal clock icon.
xbi f f
Icon alert for electronic mail delivery.
Icon used to watch your screen cursor position.
Manage X resources like color map, font paths, and client attributes.
X display manager primarily used with X Stations.
The AIXwindows base product includes:
X Windows Version 1 1 Release 4 or 5
OSF/MotifVersion 1 Release 1 or 2
National language support
24-bit color
AIXwindows Desktop Environment
Display Postscript for HFT devices
Additional products are available to provide SGI Graphics Library,
PHIGS, Graphical Kernel System (GKS), and PEX support.
X Windows Administration
There are more than enough texts available concerning generic X
Windows administration under the X Consortium code. I would rec­
ommend the "X Window System" texts by O'Reilly & Associates. For
the sake of this discussion, I'll focus on defining the default X start-up
configuration, window manager defaults and X Station management
using the AIX X Station Manager I 6000.
Product Locations
The AIXwindows product is installed and resides in / u s r / lpp / X l l .
Symbolic links are used to map access to the programs and libraries
stored in the lpp directory to the standard paths, / u s r /bin/X1 1 and
/ u s r I l ib / Xl l .
X1 1 Administration
31 7
X Windows paths:
/usr /bin/Xl l -> /usr/ lpp / X l l /bin
/usr / l ib / X l l -> /usr/ lpp /Xl l / l ib
Libs and Defaults
/usr / l ib/ <Xlibs> -> / u s r / lpp / l ib/Xl l / <Xl ibs>
Tool and Widget libs
/usr/ lpp /Xl l /Xamples
Contributed X tools
/usr/ include / Xl l
Include files and bit maps
/ us r / l ib/Xl l / font s - > /usr/ lpp / Xl l / l ib / Xl l / fonts
X fonts
Resource defaults
/usr / l ib/Xl l / app-defau l t s
Start-up Defaults
You may want to tailor the start-up files used by the X server, xdm,
and the window managers. Default start-up files are supplied in the
/ u s r I lpp / Xl l I cus t om and /usr I lpp / X l l I l ib directories.
Sys tem . xinitrc
Default xini t s tart -up f i l e .
Sys tem . mwm
Default Motif Window Manager start- up file
In most cases, you will have to provide a number of different window
managers for your user base. Window managers like editors and
shells are a religious matter whose choice is best left up to the practi­
tioner. The following sections describe some of the common window
managers with sample configuration files.
Default AIXwindows fonts are located in the / u s r / lpp / X l l / l ib
/ Xl l / fonts directory. A symbolic link is provided so that they may
be accessed using the standard font path, / u s r / l ib / Xl l / f ont s .
Display Postscript fonts fo r HFT devices are located i n / u s r I lpp
/ DP S / f ont s / a fro . Bit-map distribution format ( * . bdf) and server
normal format ( * . snf) are available with the X1 1R4 format. The con­
version programs bdf t o s n f and s n f t obdf can be used to inter­
change formats. Note that the snf fonts are compressed due to size.
The AIXwindows X11R5 distribution uses the portable compiled font
( * pc f) format. The pc f fonts take up less space and are readable
across different machine architectures.
Both l O O dp i and 7 5dp i font sets are provided in subdirectories by
the same name, font s / l O O dp i and font s / 7 5 dp i . Each of these sub­
directories contain two index files, fonts . di r and al ias . dir, that
are referenced by X clients and servers to locate particular font names.
These index files are built by invoking the mkfontdi r command.
# cd / us r / l ib / Xl l / fonts / 1 0 0dpi
# mkfontdir
Create fonts . dir and al ias . dir for 100-dpi
# cd /usr/ l ib / Xl l / f onts / 7 5dpi
# mkfontdir
Create fonts . dir and al ias . dir for 75-dpi
System Services a n d Resources
The a l i a s . dir file is used to reference long logical font names
using a short alias. The logical font name is created from the font
attributes, which include, foundary, font family, weight, slant, width,
style, pixels, points, horizontal dpi, vertical dpi, spacing, average
width, owner, and code set.
Example logical name mapping:
Logical name
Font file
B l d 1 7 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - ibm- 8 5 0
B l d l 7 . i s o l . sn f . Z
- ibm-bo l d- r -b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 1
B l d l 7 . i s o 2 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 2
B l d 1 7 . i s o 3 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 3
B l d l 7 . i s o 4 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 4
B l d l 7 . i s o 5 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 5
B l d l 7 . i s o 7 . sn f . Z
- ibm-bo l d- r -b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 7
B l d 1 7 . i s o 9 . sn f . Z
- ibm-bo l d - r - b l o c k - - 2 3 - 1 6 - 1 0 0 - 1 0 0 - c - 1 1 0 - i s o 8 8 5 9 - 9
B l d 1 4 . snf . Z
- ibm-bo l d - r -bo l d- - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - ibm- 8 5 0
B l d 1 4 . i s o l . snf . Z
- ibm-bo l d- r -bold- - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 1
B l d l 4 . i s o 2 . sn f . Z
- ibm-bo l d - r -bo ld- - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 2
B l d 1 4 . i s o 3 . sn f . Z
- ibm-bo l d- r -bold- - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 3
Bld1 4 . i s o 4 . snf . Z
- ibm-bo l d - r -b o l d - - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 4
B l d 1 4 . i s o 5 . sn f . Z
- ibm-bo l d - r -b o l d - - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 5
Bld14 . i so7 . snf . Z
- ibm-bo l d - r -b o l d - - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 7
B l d 1 4 . i s o 9 . sn f . Z
- ibm-bo l d - r - b o l d - - 2 0 - 1 4 - 1 0 0 - 1 0 0 - c - 9 0 - i s o 8 8 5 9 - 9
Window Managers-Take Your Pick
What does a window manager do for you? As the name implies, you
use a window manager to dynamically arrange the layout of windows
and objects on your display. It stylizes frame and title decoration,
imparting a common look and feel to all the objects displayed. It is
the window manager that allows you to click and drag objects on the
screen, shuffle windows up and down, and customize pull-down
menus. Without a window manager you don't have any way to manip­
ulate or move overlapping objects or alter their size. It is quite easy to
see just how much you depend on your window manager by trying to
run your X environment without using one.
Although I won't cover each of the window managers in Table 20. 1,
it is worthwhile listing a FEW of them to give you a feel for the vari­
ety that is available. They are not listed in any particular order, since
the development history tends to be very blurry due to the interbreed­
ing and building on previous work that is common with popular appli­
cations. It seems that just when I think I have heard of them all,
someone mentions a new one. I do want to mention some of the
X1 1 Administration
TABLE 20.1
31 9
Window Managers
Ardent Window Manager
A Window Manager for X
Solbourne Window Manager
DECwindows Window Manager
Tab Window Manager
Tom's Virtual Tab Window Manager
AlX 1.2 Window Manager
OSF Motif Window Manager
Open Look Window Manager
Tektronix Window Manager
Sigma Window Manager
Generic Window Manager
unique features available in a couple of these. The first is Tom's
Virtual Tab Window Manager-tvtwm. This window manager pro­
vides a virtual root window which may be defined larger than the
physical screen size. This allows users with a small display to move
windows and objects that are not in use out of the field of view. A
small map of your virtual root window is displayed to map where
obj ects are located on the virtual root window. You can use your
mouse to drag the root window around to move objects in and out of
the field of view. The second one worth noting is the Generic Window
Manager-gwm. This is a lisp-based system which may be used to
prototype new window managers or emulate existing ones. It also has
a nice interface to emacs. On the down side, gwm is quite large, which
is often the case with many lisp-based applications.
Window manager configuration
The window manager is usually started last in your X start-up config­
uration file. It may either be started in foreground or background,
depending on the particular window manager. Starting the window
manager last allows you to configure your environment such that you
can exit the X server when you exit the window manager. If you start
your X session with the xini t or s tartx commands, then the win­
dow manager is usually the last entry in your . xini trc file. If you
are using xdm, then it will be last in your . xs e s s i on file.
Window managers, like all well-behaved X clients, provide a mech­
anism to allow users to customize the appearance, interaction, and
behavior via resource files. A start-up re configuration file used in
conj unction with the X res ource information defined in the
Xde f au l t s file can be modified to tailor the window manager to
meet your needs. For the purpose of limiting the scope of this discus­
sion, I will focus on the start-up re configuration files. If you are inter­
ested in the options supported in . Xde faul t s , these are listed in the
man page for the particular window manager.
System Services and Resources
TABLE 20.2
Window Manager Functions
f . exec
f . ki l l
f . menu
f . title
f . s eparator
f . raise
f . res i z e
f . move
f . minimi z e
f . maximi z e
f . restart
Start a command or shell script
Kill the selected client
Display a menu
Display a menu title
Display a separator bar in menus
Bring client to the front
Resize a client
Move a client
Reduce client to an icon
Restore icon to an open client
Restart the window manager
The configuration file will generally allow you to define actions and
menus, which are bound to a mouse button or key for activation.
Although formats do differ for . each window manager, they tend to fol­
low the following format:
# Def ine Menus and Act i ons
# Bind Keys / Buttons to Ac t i ons
The CONTEXT describes where the button or key action is active. For
example, you may want to use a button to display a menu only when
the cursor is on the root window. Window manager functions are
called by defining the f . func t i on - name in the configuration file
entry. Common function names include those listed in Table 20.2.
You may also define default background and foreground colors and
default fonts to be used for title bars, menus, and icons. However, it
may be more convenient to define these kind of resources in the
. Xde f aul ts file along with resource definitions for other X clients. A
good place to start your window manager configuration testing is to
make a copy of the system default configuration file and modify it to
your liking. These are most commonly found in the /us r / l ib / Xl l /
subdirectories. Consult the window manager man page for the exact
location. Since you may be overwhelmed by the bulk of information in
the system default configuration file, I will provide some simple
example re files for the more commonly used window managers.
Motif Window Manager
We will begin our brief foray into the world of window managers with
the Motif Window Ma n ager mwm. mwm is the window manager
most of us are familiar with ala AIXwindows . The Motif Window
Manager was the first technology to hit the streets from the Open
Software Foundation. Its 3-D look and feel is based on the develop­
ment work done by Hewlett-Packard and Microsoft. It is quite similar
in look and feel to the Microsoft Presentation Manager and Microsoft
X1 1 Administration
Windows. The default configuration file used by mwm is / u s r / l ib
/ Xl l / sys tem . mwmrc. Your local copy is called . mwmrc. In the exam­
ple that follows, I have defined a primary menu called Roo tMenu
which will be displayed when button 1 on the mouse or the SHIFT­
ESC key sequence is pressed with the cursor on the root window. I
can also restart or quit mwm from the menu, or select a submenu
called Applications. From the Applications menu I can start an AIX
PC Simulator window.
# SAMPLE . rnwmrc
# Menus and Func t ions
Menu Roo tMenu
" Root Menu "
no- label
"Appls "
" Res tart ... "
" Exi t mwrn"
f . title
f . separator
f . rnenu Applications
f . restart
f . qui t_rnwm
Menu App l i c a t i ons
"App l i c a t i ons "
no - l abel
'' Dos Window"
f . title
f . separator
f . exec " pc s im -&node v & "
# Key and But t on Bindings
Keys Defaul tKeyBindings
Shi f t<Key>Escape
But tons Defaul tButtonBindings
f . rnenu
f . menu
Roo tMenu
I lied when I said I wasn't going to discuss resource entries for the
Xde faul ts file. Since mwm is being used by many AIX users, it is
worth diverting a moment to describe a short example. In the exam­
ple listed, I have specified the use of the icon box, defined menus to
use black lettering on a light blue background and to use rom14 as
my default font.
# Samp l e . Xdefaul t s Mwm Resources
Mwm*usei conBox : true
Mwm*rnenu* foreground : black
Mwm*rnenu*background : l ightblue
Mwm* fontLi s t : rorn1 4
OPEN LOOK Window Manager
Next on the list of window managers is Motifs rival, the OPEN
L O OK Window Ma nager-olwm . olwm was develop e d by Sun
Microsystems and AT&T. OPEN LOOK tends to dictate much of the
look and feel provided by the window manager, and thus has a very
System Services and Resources
simple configuration file, . o lwmmenu, for defining menus. One nice
aspect of OPEN LOOK is its ability to pin a menu to the display.
This means you don't have to hold the mouse button down to keep
the menu displayed on the screen. The example configuration file
defines a menu called root menu with a subtitle WINDOWS that will
allow the user to start an xterm or tn3270 connection to a remote
host and query the uptime information for a system using the rsh
# Samp l e . o lwmmenu
TITLE " root menu "
" C l ients "
"mi l ton "
" o ly"
" byron "
"xterm -display $DISPLAY -sb - tn xterms - t i t le mi l ton &"
" TN3 2 7 0 "
" xterm -display $ D I SPLAY - t i t l e o ly - e tn3 2 7 0 oly & "
" rsh byron upt ime & "
" Exi t "
20.7.4 Tab Window Manager
Probably the most commonly used public domain window manager is
what was called Tom's Window Manager in X11V3, and is now the
Tab Window Manager-twm. twm does not have the 3-D look and feel
that are the signatures of Motif and OPEN LOOK. twm goes much
further to allow you to define resource information like color and font
options in the . twmrc configuration file. In the example that follows
there are some default resource definitions for title bars, icons, and
menus. It defines the menu and key/button bindings in a fashion sim­
ilar to the window managers previously listed. It also demonstrates
defining a user function called de- raise-n-focus, which is activated by
the F l key. This user function is built using the window manager
functions f.deiconify, f.raise, and f.focus. The default configuration file
is / us r / l ib / Xl l / twm/ sys t em . twmrc .
# Samp l e . twmrc
# Resources
BorderColor "MidnightBlue "
BorderT i l eForeground " Black"
" xterm" " Cornf l owerBlue "
MenuForeground "whi t e "
I conForeground "black"
T i t l eFont " 8x13 "
I conManagerDontShow
X1 1 Administration
" xdspc lock"
# Menus and Func t i ons
menu "App l s "
"App l i cations " f . t i t l e
"byron " ( "Wheat " : " S lateGray " )
" l ock"
"move "
! "xterm -e rlogin byron & "
! "xlock -mode qix -nice 5 & "
f . move
# But ton and Key Bindings
But tonl
"Fl " =
f . menu " S tu f f "
f . func t i on " de -rai s e - n - f ocus "
: frame
: frame
Func t i on " de-raise-n- focus "
f . dei coni fy
f . ra i se
f . f ocus
A Window Manager for X
No discussion of window managers would be complete without including
A Window Manager for X-uwm. uwm is basically a no-frills window
manager held over from the XlO days and is included with most vendor
and MIT Consortium X distributions. Note that the initial sequence,
resetbindings, resetvariables, and resetmenus listed in the example
uwmrc is the common practice for configuring uwm. Like twm, you can
define window manager and client resources in the configuration file.
The default configuration file is / usr / l ib / Xl l / uwm/ sys tem . uwmrc.
# Samp l e . uwmrc
# Resource
background = Wheat
bordercolor = Red
menufont = f ixed
# Menus
menu = "WindowOps •
RefreshScreen :
Redraw :
Move :
Exi t :
f . refresh
f . redraw
f . move
f . ex i t
# But ton and Key Bindings
f . menu =
: roo t :
middle down
"WindowOps •
Tools and Tips
If you don't have executable versions of these window managers built,
but do have the MIT X Consortium source code, you can find the some
of the public domain window managers in the following locations:
System Services and Resources
X1 1R4
X1 1R5
. /mi t / c l i ents
. / contrib/windowmgrs
. / contrib / c l i ents
There are also some X clients that make it much easier choosing
font and color combinations for your environment. xfontsel allows you
to dynamically select font options in a window and display an example
character set using the font on your screen. For color selection, there is
an X11R5 contrib client called xcolors that will display a color p alette
on your screen and allow you to select foreground and background
color combinations. xwininfo can be used to select initial positioning
geometry for a client at start-up. Using xwininfo, you can position and
click on a client to display its positional information on the screen.
IBM Xstation Administration
Xstations provide a very cost effective alternative to providing fully
equipped workstations as platforms for X Windows. Using one or
more workstations as servers, Xstations provide all the functionality
of a complete X Windows-based workstation. Xstations also reduce
many of the administration headaches for both the system adminis­
trator and end user.
Most environments support a number of different vendor Xstations
and would like to manage them as a group from central servers under
xdm. At EPROM level + 1.5 for the Xstation 120 and using the IBM
Xstation Manager at version 1 . 3 or above, all models of the IBM
Xstation can be supported alongside the rest of your Xstation
menagerie under xdm. You can also obtain boot server code from
Advanced Graphics Engineering (AGE) which will allow the use of
UNIX systems other than an RS/6000 or PS/2 as a boot server. Take a
look at the IBM Red Book IBM Xstation 120 I 130, GG24-3695 for
more details. This book is a little dated; however, most of the informa­
tion is still relevant.
20.1 O
Xstation Hardware
For those of you who might not remember the IBM Xstation 120, it
was IBM's entry offering in the Xstation market. The IBM Xstation
120 is configured with two processors. An 8-Mhz Intel 80 186 is used
for 1/0 and communications, and a 50-Mhz Texas Instruments 340 10
processor handles video graphics. It supports 512 KB to 8.5 MB of
system memory, DRAM, and 5 12 KB to 2 MB of video memory,
VRAM. There is 5 12 KB of RAM and two 128-KB ROM sections used
for the I/O subsystem, diagnostics, and boot support. Ethernet,
10base5 (thick), and 10base2 (thin) are supported along with a token­
ring adapter slot. Serial and parallel slots are standard for a local
printer and/or plotter. If you are using X11R4 and the IBM Xstation
X1 1 Administration
Manager 1.2 or 1.3, you will need a minimum of 1.5 MB of system
memory for the X server code, fonts, etc. The amount of video memory
required will be dependent on the resolution and color bits of the
monitor. You can select from a variety of monitors. A keyboard and
mouse are included.
The IBM Xstation 130 is similar to the model 120, but is beefier.
Webster's defines beefier as ''heavily and powerfully built, substantial,
sturdy, full of beef." I like the part about "full of beef." The model 130
comes with a 12.5-MHz Intel 80C 186 and a 32-MHz Texas Instruments
34020. Thus, 32-bit graphics capability is available over the 16-bit sup­
port in the model 120. You may select from 1 to 16 MB DRAM and 1 to
2 MB VRAM. Two ROM sections have been upgraded to 256 KB each.
A PS/2 dual-port asynch adapter may be included to bring the total
number of serial ports up to four. A second Ethernet or token-ring
adapter may be added. Finally, an optional 30-MB hard disk may be
used to store portions of the X server code, backing store pixmaps,
fonts, etc. This disk space is not accessible for standard applications.
The extra disk space may be thought of as additional system memory.
The Xstation 150 tops the IBM Xstation line, delivering a very
impressive 115,000 Xstones. The 150 incorporates 64-bit RISC using a
Motorola 88110 processor. The system comes with 6 MB of system
memory that can be expanded to 22 MB. 2 MB of video memory is stan­
dard, along with 2 MB of flash memory containing Xl 1R5 server code
and diagnostics. Flash memory can be upgraded to 4 MB. lOBaseT
Ethernet support has been added to 10Base5, 10base2, token ring, and
SLIP. Four serial ports at up to 38.4 Kbps may be configured into the
system. The IBM Xstation 150 supports local Xl l clients . Simple
Network Management Protocol (SNMP) agent code is available.
20.1 0.1
Configuration and boot
When you flip on the power switch, the Xstation performs a power-on
self-test (POST). Once POST is passed, it will optionally direct or
broadcast a bootp request packet attempting to find a boot server.
Once contact is made, the information received determines the IP
addresses of the Xstation and the server, and the name of the boot
configuration file. Since this information can be configured into the
Xstation, you may opt to bypass the bootp step for normal operation.
To configure address information into the Xstation, access the net­
work configuration menu by pressing the F12 key after POST has
completed. These configuration screens allow you to set the IP
address information for the terminal, server, and gateway, and dis­
able the boo tp process. Similar information may be configured for
token-ring connections. The model 130 and 150 also support IP over a
serial link using SLIP. To configure the model 130 or 150 for a serial
TTY connection, press the Fll key after POST has completed.
System Services and Resources
Once the boot server has been contacted, the Xstation will tftp a
copy of the bootfile / u s r / lpp / x_s t_mgr / b i n / bo o t f i l e from the
server. The bootfile and configuration file downloaded, inform the
Xstation which fonts, key map, rgb database, and server code should
be requested from the server.
During the boo tp and t f tp steps, the Xstation display provides
some diagnostic information concerning the terminal/server packet
exchanges. The two lines of interest are:
BOOTP 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
TFTP 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The first column o f numbers indicates the number o f packets sent
from the Xstation. The second column indicates the number of pack­
ets received from the server. The third column is the count of bad
packets received. The fourth column displays the number of timeouts
that have occurred. The fifth column on the TFTP line displays the
final error code for the transaction. You may access further diagnostic
and test information by simultaneously pressing CTRL-bre ak after
POST has completed.
20.1 1
AIX Xstation Manager/6000 Configuration
The AIX Xstation Manager/6000 program product provides the boot
services for IBM Xstations. As I mentioned earlier, you may also get
the Xoftware product from AGE, if you wish to provide boot support
from other than an RS/6000 or PS/2. Once the Xstation Manager is
installed, verify that its services are defined in the following tables:
/etc / rc . tcpip
/usr / lpp / x_s t_mgr /bin/x_s t_mgrd -b \
/usr/ lpp /x_s t_mgr /bin/x_s t_mgrd . c f -s x_s t_mg
/etc/ services
6 7 /udp
6 8 / udp
bo o tpc
7 0 0 0 / tcp
* bootp server port
# bootp c l ient port
hbm X termina l
/etc/ inetd . conf
bootps dgram udp wai t root / e t c / bootpd boo tpd / et c / bootptab
You may then define your network type, bootfile, and bootfile directo­
ry via the Xstation selection from the SMIT Devices menu. You may
also specify whether the server is a primary or secondary server. It is
a good idea to support two boot servers if possible. The Xstations may
then be configured to try each server in sequence at start-up time.
Once you have defined your network type, you may define each of
the Xstations being supported. You need to identify each Xstation's
network type, the hardware address of the adapter, whether xdm ser-
X1 1 Administration
vices will be used, and the initial application to be started. You may
also define local printer support for Xstations equipped with printers
via the SMIT Printer/Plotter menu.
20. 1 2
X Windows Display Manager-xdm
As of release 1.2 of the AIX Xstation Manager/6000, the XDM Control
Protocol (XDMCP) is supported at the Xl 1R4 level. This means you
can use the full s ervices provided by xdm (X Windows Display
Manager) to manage your start-up clients and restrict access to your
Xstation. You can tailor your initial Xl l environment by editing
entries in your $ HOME / . Xs e s s ion file, much the same way you do
with $ HOME / . xini trc. Default parameters for xdm are defined in
/ us r / l ib / Xl l / xdm/X s e s s i on. You will also want to define some of
your shell environment variables in your $ HOME / . X s e s s i on file,
since xdm circumvents standard shell start-up procedures.
One of the main advantages of using xdm is that it provides user­
based authentication for access to your Xstation. It is common prac­
tice-or should be-to restrict access to your Xl 1 environment by
using the xho s t command. However, xhos t only authenticates at the
host level. Anyone on a time-shared host that you have permitted via
xho s t has access to your Xl l server. xdm uses an access control
mechanism called the MIT-MAGIC-COOKIE, which is controlled by
file access permission. Basically xdm writes a random number code
(the magic cookie) into your $ HOME / . Xautho r i ty file, and shares
this number with your Xll server. Xl l clients must then authenti­
cate themselves to the server by presenting the code when connecting
to the server. You may share this magic cookie with other machines,
from which you may start clients using the xauth program. A combi­
nation of xho s t and xauth mechanisms will go a long way to secur­
ing your Xstation. Xl 1R5 adds two more authentication protocols
called XDM-A UTHORIZATION- 1 and S UN-DES- 1, respectively.
These are both based on the Data Encryption Standard (DES).
It is possible to use magic cookies with the standard xini t start-up
used by AIXwindows. Basically, you need to generate some kind of
random number from your $ HOME / . xini trc file and store it in your
$ HOME / . Xauthor i ty using xau th . I haven't tried this with IBM
Xstations, but it will work with standard servers.
20.1 3
lnfoExplorer Keywords
t f tp
xini t
/ et c / inetd . c on f
20.1 4
System Services and Resources
Xl l
/ e t c / s ervi c e s
. Xs e s s i on
xho s t
a ixt erm
xc lock
xbi f f
bdf tosnf
snf tobdf
mkf ontdir
AIXwindows, Xl 1 components:
/usr/bin / X l l
Xll programs
/usr / l ib/ Xl l / fonts
Font directory
/usr / l ib / Xl l / app- de f aul t s
Application defaults
/usr / l ib
XU libraries
/usr/ lpp / X l l
/usr/ lpp / Xl l / Xamples
Samples and contribs
Clients and server:
X server
. Xdef au l t s
Application defaults
X display manager
$HOME / . Xauthori ty
xdm magic cookie
Motif window manager
aixterm , xterm
X terminal emulator
. xinitrc
Start-up file
Sys tem . xinitrc
Xll system defaults
. mwmrc
mwm configuration
Sys tem . mwmrc
mwm defaults
. Xs e s s i on
xdm start-up file
Create fonts directory and alias files
AIX Xstation Manager I 6000:
/usr/ lpp /x_s t_mgr
AIX Xstation Manager
Xstation daemon
Users and Sec u rity
Manag i ng the User
E nvi ron ment
21 .1
User Administration Policy
"User" i s a four-letter word! If you administer multiuser systems and
haven't taken care to define default environment policies or to
streamline account management, there are likely many other four-let­
ter words in our vocabulary. A large user base can dominate a system
administrator's time with trivial tasks like adding and expiring
accounts, setting passwords, juggling home directories, fixing UID
collisions, etc. The list goes on and on, and so do the requests. Just
remember that it's users that keep us employed!
The default environment policies can be thought of as a contract for
basic services and resources. Whether it is formally stated or implied,
your user base assumes some level of support. There will be less confu­
sion for both your users and user support communities if the basic
rules of the road are formally stated and documented. A simple way to
disseminate this type of information is to make it available as a man
page or help file. You can also provide a default policy statement as a
rnsg file that is displayed the first time a user logs on to the system.
First you need to define what the policies are and how they will be
implemented. What are the requirements for establishing an account?
What basic resources are provided with an account? What does the
default shell environment look like? How long does an account last?
Resource policies:
Physical resources
Resource limits
Account access rights
Account environment
Users and Security
21 .2
Physical Resources
Let's start out by making sure we don't promise more than we can
deliver. What are the workload characteristics of your user base? How
much disk, tape, memory, and CPU resources will be required to sup­
port your expected total number of users and the expected concurrent
user sessions? In an existing environment, you can construct a fairly
good profile by sifting through old accounting information. It's also
worthwhile to benchmark your application mix. Push the system to
the limit. Stress the CPU, paging, and I/O subsystems. This will give
you a feel for what to expect during spikes in load.
21 .2.1
User file systems
After you have determined the resource level you can offer, structure
the physical resources such that they can be managed easily under
software control. Begin by segregating user home directory file sys­
tems from the rest of the operating system. This isolates these file
systems from operating system upgrades and maintenance. Set up
user file systems on different physical disks and volume groups. This
will facilitate moving them between machines if circumstances
require. Use a naming convention for user file system mount points
that are easy to remember and easy to identify. A possible method
would be to use the / u<number> scheme on AIX. In a distributed or
clustered environment you might use the first character of the
machine name which owns the file system followed by an integer.
Don't make them too long!
To reduce the impact of managing user home directories in multiple
user file systems, use symbolic links to link the top-level user directo­
ries in each file system to a common / home directory. No matter
where a particular user's home directory physically resides, it can be
accessed via the / home / <user name> path. Specify the symbolic link
path name for the home directory field in the / et c /pas swd file. This
will allow you to move user directories around in your user file sys­
tems to balance utilization without requiring each user to learn a new
home directory path.
# ln -s /u6 / st impy / home / s t impy
s t impy : ! : 1 2 3 4 : 3 0 : S t impson Cat : /home / s timpy : /bin/ ksh
You will also need to size your user file systems. If large files are
not heavily used, then multiple small file systems may be preferred.
Small file systems (less than 1 GB ) reduce backup and restore
times. They can be easily moved and will partition your user com­
munity such that a file system catastrophe won't effect your entire
user base.
Managing the User Environment
21 .3
UID Space and Groups
User account names are, in fact, a matter of human convenience in
identifying users under UNIX. The AIX operating system identifies
a particular user by an unsigned long integer called the UID. The
DID is mapped to the user name in the / e t c / pa s swd file. UIDs are
used on other UNIX systems, but may be represented under other
integer formats. Traditionally, the DID space was limited to 32 k,
but this has proved to be too small for large time-sharing UNIX sys­
It's a good idea to segregate your user DID space from the UIDs
used by system daemons administrative accounts. This simplifies the
task of identifying privileged accounts for accounting and security
applications. Pick a number like 1000 to define the bottom of your
user DID space for allocation. In a distributed environment where
users may have accounts on different systems, or if you are using
Network File System (NFS), you will want to ensure that UIDs are
unique across systems. By "unique," I mean that if user "stimpy" is
DID 1234 on host A, then the same DID is reserved for stimpy on any
other system. Ownership and permission problems can arise if the
same DID represents different users in distributed environments.
Remember, the operating system identifies users by DID.
While you define your UID space, it's also a good idea to plan your
Group ID (GID) space. Groups provide a coarse mechanism for shar­
ing information between users. In Chap. 22, file and directory permis­
sions are described which permit read, write, and execute permissions
for world, group, and owner. AIX and other UNIXs assume a limited
group set to implement access privileges. What needs to be decided is
whether you want to implement other GID sets for specific work
groups or collaborators. If your user base is small, this can be done
relatively easily. For large numbers of users, managing GID sets can
be a big chore.
AIX provides a much better solution to sharing information
through access control lists (ACLs). ACLs supply a finer granularity
of control and user management. ACLs will be discussed in Chap. 22.
21 .3.1
/etc /group and /etc / security/group
GID mapping is maintained in the / e tc / group and / e tc / s ecur i ­
t y I group files. The I e t c I group file lists each group name and GID
followed by the list of members. The / et c / s ecuri ty/ group file con­
tains a stanza for each group name in the / et c / group file and indi­
cates whether the group may be administered by users other than
root and identifies the administrators by user name. Groups and their
associated attributes are managed via SMIT or from a series of group
management commands.
Users and Security
Create a new group
Change group attributes
List groups and attributes
Change administrators or members of a group
Reset the current group set for a user
Set the group ID for session
Remove a group
Example I etc I group :
sys t em : ! : O : root , ops
daemon : ! : 1 :
bin : ! : 2 : root , bin
sys : ! : 3 : root , bin , sys
adm : ! : 4 : bin , adm, kenm , root
uucp : ! : 5 : uucp
mai l : ! : 6 :
s ecur i ty : ! : 7 : root
cron : ! : S : root
s taf f : ! : l O : root , ren , s t impy , daf fy , huey , dewey
: us er : ! : 3 0 : luge , acadmus , gwyneira , bungi
Example I etc I s ecuri ty I group :
sys tem :
daemon :
bin :
sys :
admin = true
adm :
uucp :
mai l :
s ecur i ty :
cron :
staf f :
adms = ren , s t impy
user :
admin = false
21 .4
Resource Limits
How much of the pie are you going to give each user? How you do
make sure each user gets no more than his or her fair share? Profiling
the application mix with estimated concurrent users will give you
some ballpark figures. AIX provides the capability to enforce limits on
each user's slice of the available system resources through operating
system controls. Limits can be defined for CPU, memory, and disk
utiliz ation on a per-process basis. Total number of concurrent
Managing the User Environment
processes per user is capped by kernel configuration parameter.
Aggregate file system usage can be governed through activating disk
quotas at user and group levels.
21 .4.1
/ etc / security/ limits
The kernel manages per-process limits using the s e t r l imi t ( ) ,
g e t r l imi t ( ) , and vl imi t ( ) system calls. Each process has an
associated r 1 imi t structure that indicates soft and hard ceilings for
each res ource typ e . The r l i m i t structure is defined in
/ u s r / include / sys / r e s ource . h . Default and resource limits for
the system and users are specified in the / e t c / s ecur i ty / l imi t s
file. Each user defined to the system is represented by a stanza iden­
tified by user name. System defaults are active for each user that
does not have an overriding parameter under the user's stanza. When
a process exceeds one of the specified limits, it is killed.
/ et c / secur i ty / l imi t s :
l imi t s
S i zes are in mul t iples of blocks , CPU t ime is in seconds
f s i z e - maximum f i le s i z e in blocks
core - maximum core f i l e s i z e in blocks
cpu - per process CPU t ime l imi t in seconds
data - maximum data segment s i z e in blocks
s tack - maximum s tack segment s i z e in bl ocks
rss - maximum real memory usage in blocks
NOTE : a value l ess than or equal to z ero impl i e s " unl imi ted"
de faul t :
fsize = 2097151
core = 2 0 4 8
cpu = - 1
data = 2 6 2 1 4 4
rss = 6553 6
s tack = 6 5 5 3 6
root :
s t impy :
fsize = 10240
cpu = 3 6 0 0
The kernel limits the maximum number of processes per user as
specified by the kernel configuration parameter maxuproc. The
default value of 40 indicates that up to 40 processes may be running
concurrently for a given user. The value may not be exceeded by log­
ging into the system multiple times. The maxuproc value may be
altered via SMIT or with the chdev command. (See Fig. 2 1 . 1 . )
It chgdev - 1 sys O - a maxuproc
It smi t chgsys
Users and Security
Change I Show Charac teri s t i c s of Operating Sys t em
Type or select values in entry f ields .
Press Enter AFTER making a l l des i red changes .
Maximum number o f PROCESSES a l l owed per user
Maximum number o f pages in block I / 0 BUFFER CACHE
Maximum Kbytes of real memory allowed for MBUFS
Automa t i cally REBOOT sys t em after a crash
Cont inuous ly maintain DISK I / O his tory
HIGH water mark for pending wr i t e I / Os per f i l e
LOW water mark f o r pending wri te I / Os p e r f i le
Enable memory SCRUBBING
Amount o f usable phys ical memory in Kbytes
Primary dump device
Sec ondary dump device
Error log f i l e s i z e
State o f sys t em keyl ock at boo t time
S i z e of data cache in bytes
Size o f instruc t i on cache in bytes
F l = Help
F 5 = Undo
F9 = She l l
Figure 21 .1
F2 = Refresh
F 6 = Command
F l O = Exit
F3 = Canc el
F7 = Edi t
Enter = Do
[ Entry Fields ]
[33 )
5242 88
/ dev/hd7
/ dev/ sysdumpnul l
+ II
+ II
+ II
+ II
+ II
F4 = L i s t
F8 = Image
SMIT operating system parameter panel.
Disk quotas limit the maximum number of blocks a user or group
may consume on participating file systems. The AIX implementation
of disk quotas is based on BSD quotas. User and group quota limit
are set by the system administrator using the edquota command.
Quota limits for disk blocks and inodes are specified by three parame­
ters: soft limit, hard limit, and grace period.
The value of the soft limit indicates at what point the user or group
begins receiving warnings that their soft limit has been exceeded and
that they are approaching the hard limit. Warnings are delivered at
login time and at each close that exceeds the specified limit. The hard
limit specifies at what point the user or group Will no longer be able
to allocate additional disk space or inodes. The grace period defines a
period of time that the user or group has to reduce their utilization
below the soft limit value. If utilization is not reduced before the
grace period expires, the soft limit is enforced as a hard limit.
To implement disk quotas on a file system, edit the stanza entry in
/ e tc / f i l e sys tems associated with file system name. Add the para­
< u s erquo t a > , <groupquot a> to the stanza. The
meter quo t a
u s erquota and groupquota values indicate the quota types to be
enforced. The quota limits for each user or group are recorded in files
in the top-level directory named quo t a . u s e r and quo t a . group ,
respectively. You may override these file names with your own by
including us erquo ta
<pathname> and groupquota
name> parameters in the file system stanza.
Managing the User Environment
/ et c / f i l e sys t ems :
/ul :
dev = / dev/ lv4 3
vfs = j f s
log = / dev / l oglvO O
mount = true
check = true
opt i ons = rw
quota = userquota
userquota = Jul / user . quota
If the quota limit files do not exist on the file system, you can create
them using touch .
# touch Jul / quota . user
Use the edquota command to create a user quota for one of the
users on the system. These values will be used as a template for set­
ting the limits for other users on the system. The edquo ta command
will invoke the default editor and display the quota values for update.
# edquota s t impy
Quotas for user s t impy :
/ul : blocks in use : 5 0 ,
inodes in use : 1 1 ,
/u2 : blocks in use : 0 ,
inodes in use : 0 ,
l imits
l imi t s
l imi t s
l imi t s
( so f t = 8 0 ,
( soft = 12 0 ,
( so f t = 8 0 ,
( so f t = 1 2 0 ,
hard = 1 0 0 )
hard = 1 5 0 )
hard = 1 0 0 )
hard = 1 5 0 )
After setting the soft and hard limits for the default user, invoke
-p < de faul t -u s er> <new- user> to set the default
limits for each additional user in the system.
# edquo ta -p s t impy ren
Enable the quota system by executing the quo taon command. As
part of the nightly system housekeeping, update the information in
the quota files by running the quo t acheck command. You can use
the -a flag to indicate all quota file systems.
Quota update commands:
quo tao f f -a
quo tacheck -a
quotaon -a
The quota limits for a user or a summary can be displayed using
the quo ta and repquota commands, respectively.
# quo ta ren
Disk quotas for user ren (uid 4084):
F i l esys tem
# repquota
l imi t
3 63
l imi t
Users and Security
bi lbro
21 .5
Block l imi t s
F i l e l imi ts
User Account Access Rights
Who gets an account and how long can they keep it? Access and expi­
ration policies might not seem like a big deal for small work groups;
however, the less ambiguity the better. There are also legal implica­
tions that can be avoided if these policies are formalized and made
public. Expiring and cleaning up accounts on large user base systems
can be automated easily if expiration policies are clearly defined. AIX
provides a mechanism for expiring accounts and performing the
cleanup housekeeping. By providing both facilities, AIX allows you to
implement grace periods between when an account expires and when
it is actually removed from the system. This can be incorporated into
a last-use policy. Chapter 22 covers expiration procedures.
21 .6
User Account Environment
What face will the system present to new users? As system adminis­
trator, you are charged with setting up the default environment for
each new account. You want to maintain some level of control over
environment parameters, yet allow users the freedom of tailoring their
own work spaces. Shells, editors, terminal definitions, and the like,
are religious issues best left to the faithful! You can't keep everyone
from shooting themselves in the foot. You also don't want to open the
flood gates to more shell environments than you can support. You can
provide a simple, modular login environment that simplifies recovery
for the adventurous user when shell experimentation goes awry.
Begin by defining the default environment variables which will be
set for all users (see Table 21. 1). Environment variables are name
value pairs that are read by shells and commands to set values or
determine behavior. For example, the environment variable EDITOR
indicates what editor is to be invoked by applications like ma i 1 or
rn . Environment variables may be command- or shell-specific, and
they may be modified by the end user.
21 .6.1
/etc/environment and / etc /profile
AIX provides two files which are used to set default environment
variables for the system. The / e t c / env i ronment file contains
default variables set for each process by the exec ( ) system calls. The
/ e t c / p ro f i l e file contains the set of environment variables and
Managing the User Environment
TABLE 21 .1
Common Environment Variables
List of directory paths to search for commands and files
List of library paths to search for binding
Default full screen pager
Default editor
Time zone
Terminal type
Incoming mail path
Message text prompt when new mail arrives
Locale name in effect for NLS
Directory containing locale file
Full path to NLS catalogs
User name (csh)
User name
Telnet escape key sequence
Home directory path
commands that will be invoked when a user logs into the system. The
contents of these files are read before local shell start-up files and
they are best kept non-shell-specific. The AIX-supplied / etc / envi ­
ronment and / et c /pro f i l e files provide a good boilerplate for tai­
loring your own defaults.
System / et c / environment variables:
PATH = /usr /bin : / e t c : /usr/ sbin : /usr / ucb : /usr /bin / X l l : / sbin
LOCPATH = /usr / l ib / nl s / loc
NLSPATH = /usr I l ib/nls /msg / % L / %N : /usr I l ib/nls /msg /prime / %N
ODMDIR = /etc / obj repos
/ e t c /pro f i l e :
# ( C ) COPYRIGHT Interna t i onal Bus iness Machines Corp . 1 9 8 9 , 1 9 9 0
# All Rights Reserved
# Licensed Material s-Property of IBM
# US Government Users Res t r i c ted Rights - Use , duplication or
# d i s c losure restricte d by GSA ADP Schedule Contrac t wi th IBM Corp .
# Sys tem wide pro f i l e . Al l vari abl es s e t here may b e overri dden by
# a user ' s personal . pro f i l e f i l e in the i r $HOME directory . Howeve r ,
# a l l commands here wi l l be executed at login regardless .
trap • • 1 2 3
readonly LOGNAME
# Automatic l ogout , include in export l ine i f uncommented
# TMOUT = 1 2 0
# The MAILMSG wi l l be printed by the she l l every MAILCHECK seconds
# ( de faul t 6 0 0 ) if there is mai l in the MAIL sys tem mai lbox .
MAIL = /usr/ spool /mai 1 / $LOGNAME
Users and Security
# I f termde f command re turns terminal type ( i . e . a non NULL value ) ,
# set TERM to the returned value , e l s e set TERM to de fau l t hft .
TERM = ' termde f '
trap 1 2 3
21 .6.2
I etc/ security I environ
Individual user environment variables may also be defined in the
/ e t c / s ecur i ty/ envi ron file. This file contains a stanza for each
user in the system, identified by user name followed by a list of envi­
ronment variables and the associated value. The environment variable
value pairs are separated by commas. Those variables specified as
usrenv are set at login. To protect environment variables from being
reset by unprivileged applications, use the sys env specification.
Example I etc / s e curi ty I envi ron stanza:
s t impy :
usrenv = " TNESC = 3 5 , PAGER = /bin/more , EDITOR = /bin/vi •
sysenv = "HOME = /home / s t impy •
Next, define the default shell and shell environment variables. The
default shell and start-up files are set by the / e t c / s e c u r i ty
/mk.user . sys script and / et c / s ecuri ty/mk.u s er . de faul t file. The
mk.user . sys script reads the mk.user . de fau l t file and creates the
home directory, sets permissions, and copies the default shell start-up
file fro m / e t c / s e c u r i ty into the n e w home directory. The
mk.user . sys script is invoked each time the mk.user command is exe­
cuted by SMIT or from the command line to add a new account.
/ etc / s ecur i ty / mk.u s er . de f aul t :
General user defaults
prog = /bin/ ksh
/ u / $USER
# Administrative
group = system
/bin/ ksh
home = / u / $USER
Shell start-up files:
user defaults
Managing the User Environment
. pro f i l e
. pro f i l e ,
c sh ,
. l ogin ,
. kshrc
. c shrc ,
(If indicated by ENV)
. l ogout
The default behavior of mku s e r . sys is to copy a complete shell
start-up file into the user's home directory. This can be a problem
should you decide to change some part of the default shell environ­
ment later on. You will need to incorporate the change into each
user's start-up files without destroying any customizations added by
the user.
A simple solution is to create a skeleton shell start-up file that con­
tains a single line which sources or invokes a read-only system
default shell start-up file. The skeleton file is copied to the user's
home directory at account creation time. Users may append lines to
their local copy of the skeleton file which overrides or adds to the
environment variables, commands, and aliases specified in the sys­
tem default start-up file. The system administrator maintains the
shell environment data in the system defaults files. Default start-up
would include things like displaying the message of the day file ,
/ e t c / mo t d , or invoking the m s g s command to display system
update information at login time . Skeleton and associated system
defaults start-up files are created for each supported shell. The skele­
ton shell files should be available for copy should a user decide to
change their default shell.
Example skeleton and system c sh start-up files:
# /usr / l ocal / skel / . cshrc
# Skeleton . c shrc f i l e copied to the users home
# directory at account crea t i on .
# Source sys t em csh de faul ts
source /usr/ local / l ib / s td . cshrc
# Local user changes are added af ter this line .
# /usr/ local / skel / . login
# Skeleton . l ogin f i l e copied to the users home
# directory at account crea t i on .
# Source sys tem csh de fau l t s
s ource /usr/ local / l ib/ std . login
# Local user changes are added after thi s l ine .
# /usr/ local / l ib / s t d . cshrc
# Sys tem defau l t csh s t artup environment .
i f ! ( $ ?promp t ) goto NOPROMPT
set prompt = • _ ' hos tname ' % "
set history = 3 0
( read only )
Users and Security
set savehi s t = 3 0
al ias a alias
al ias h h i s tory
umask 0 2 2
# /usr / l ocal / l ib / s td . login
s e t ignoreeof
setenv PATH " /usr/ local /bin : /usr/bin/Xl l : /usr/ucb : /usr/bin : /bin : •
setenv EXINIT • s e t she l l = /bin / c sh "
s t ty dee crt
s t ty - tabs f f l
setenv TNESC 3 5
msgs - f
You can further break the system start-up file hierarchy down to
support a start-up file which sets the PATH environment for all shells.
That way, modifications to search path only involves updating one
file. You might also want to separate aliases from environment vari­
ables, or TTY settings.
Depending on the shell, you will also need to be aware of how the
start-up files are handled by other commands. For example, the
remote shell command, rsh , does not invoke $ HOME / . l ogin for c sh
users. Thus, important c sh environment information should be main­
tained in the s td . c shrc file rather than the s td . l ogin file.
21 .6.3
/etc/ security/ login . c fg
Even with simple schemes like this, many of us don't want to have to
support every shell that might be built by a user. You can restrict the
shells supported on the system by specifying the shell path in the
/ e t c / s ecur i ty/ l ogin . c fg file. Edit the usw : stanza and list the
path name of each supported shell, separated by commas after the
she l l
I etc / s ecur i ty I l ogin . c fg supported shells:
usw :
shel l s = /bin / sh , /bin/bsh , /bin / c s h , /bin/ ksh , /bin / tsh , /usr/bin / s h ,
/usr/bin/bsh , / usr/bin / c s h , /usr/bin/ksh , /usr/bin / tsh ,
/usr/mbin / sh , / usr /mbin/bsh , / usr/mbin / c sh , / us r /mbin/ ksh ,
/usr/mbin / t s h , /usr/ local /bin / t c sh
The I e t c / s ecuri ty / l ogin . c fg file also defines the default login
heralds , alternate authorization programs , and passwd profile.
Stanzas associated with these facilities will be discussed in Chap. 22.
21 .7
Managing User Accounts
System administrators can't escape the ongoing stream of account
management requests that come from an active user community. The
Managing the User Environment
good news is that AIX automates the task of adding, updating, and
removing user accounts by providing a set of tools that take care of
updating all the appropriate tables and file systems. It's not the per­
fect world, but it beats doing it by hand!
21 .7.1
Adding a user account
To add a new user to the system, execute the mkuser command either
from the command line or by using SMIT. Due to the number of para­
meters involved, I suggest using SMIT unless you are accepting sys­
tem defaults. In the event that you are adding a large number of
users, you can add the first using SMIT, then duplicate the mkuser
command in the smi t . s cript file for each subsequent account to be
created. (See Fig. 2 1.2.)
Create User
Type or select values in entry f ie l ds .
Press Enter AFTER making a l l desired changes .
[ TO P ]
* User NAME
User ID
LOGIN user ?
Group SET
SU groups
HOME directory
Another user can SU to user?
User can RLOGIN?
User can RLOGIN?
Val id TTYs
AUDIT c lasses
PRIMARY authent icat ion method
SECONDARY authentication method
Max FILE s i z e
Max CPU t ime
Max DATA s egment
Max STACK s i z e
Max CORE f i l e s i z e
Max phys ical MEMORY
F i l e creat i on UMASK
EXPIRATION dat e (MMDDhhmmyy )
F l = Help
F 5 = Undo
F9 = She l l
Figure 21 .2
F2 = Re f resh
F 6 = Command
F l O = Exi t
SMIT create user panel.
[ Entry Fields ]
[ ALL ]
[ ALL ]
[ NONE )
[ 2 09 7 1 5 1 ]
( 2 62 1 4 4 ]
( 6553 6 ]
( 6553 6 ]
( 022 )
F 3 = Cancel
F7 = Edi t
Enter = Do
F4 = L i s t
FB = Image
Users and Security
TABLE 21 .2
Up to 8-character user name. Should not be upper case or
use special characters.
Administrative privileges.
User ID
Unique integer. May need to be altered if you are using
unique UIDs across multiple systems.
Can the user login to the system?
Default group at login.
Group SET
Other group membership.
User is an administrator of these groups.
SU Groups
Groups that may issue the su command.
HOME Directory
Home directory path / u / <user name> .
Login shell program.
User full name, phone, etc. for GECOS field in / et c / pas swd
Another user can SU to user
Can this UID be accessed with su?
User can RLOGIN
Can the user use rlogin to access the system?
Trusted path status.
Valid TTYs
TTY ports that may be used to login to this UID.
AUDIT Classes
Audit classes representing this UID.
PRIMARY Authentication Method
Authentication program used to validate this user to the
system. Default SYSTEM represents standard user name
and passwd.
SECONDARY Authentication Method
Secondary authentication program. If it fails, it does not
deny access.
Max FILE size
Max CPU time
Max DATA segment
Max STACK size
Max CORE file size
Max physical MEMORY
Resource limits for the user.
File creation MASK
Default urnask for the user.
Expiration date and time for this account.
# smi t mkuser
For most general user accounts, you can select a user name and
accept the supplied defaults. (See Table 2 1.2.)
See the following Chap. 22 on Security for more information con­
cerning primary and secondary authentication methods as well as
passwd support.
21 .7.2
Updating user accounts
You can modify existing user accounts by invoking the chuser com­
mand from the command line or via SMIT. In most cases, only a
Managing the User Environment
small number of fields are changed, so using chuser from the com­
mand line does not involve a large number of arguments. You may
also update system account tables directly with an editor in some
cases. Care should be taken that stanza format and permissions are
not compromised.
# smi t chuser
You can list the current set of attributes defined for a user using
the l su s er command.
# l suser s t impy
s timpy id = 4 0 8 4 pgrp = sys tem groups = system, secur i ty , staf f , user , bi tnet
home = / u / s t impy shell = /bin/ksh gecos = S t impson Cat login = true
su = true rlogin = true daemon = true admin = true sugroups = ALL
admgroups = ALL tpath = nosak t tys = ALL expires = 0 authl = SYSTEM
auth2 = NONE umask = 22 f s i z e = -1 cpu = -1 data = -1 s tack = -1 core = - 1
rss = - 1 t ime _last_login = 7 4 4 3 8 7 0 1 6
t ime_las t_unsuccess ful_login = 7 4 3 9 8 0 3 2 4 t ty_l ast_login = p ts / 6
t ty_las t_unsuccess ful_login = pts / 3 4 hos t_last_login = daffy . foo . bar . erg
host_last_unsuccessful_login = csl l . foo . bar . org unsuccessful_login_count = 0
21 .7.3
Removing user accounts
To remove users from the system, use the rmuser command (see Fig.
21.3). It can be invoked from the command line or using SMIT. The
rmuser command takes care of removing the user from the system
tables and deleting the home directory from the file system. You also
have the option of retaining user data in the I e t c I s e c u r i ty
/pas swd file.
# rmuser -p s t impy
# smi t rmuser
To automate the process of removing accounts from the system, you
can use c ron to run a nightly process that looks for expired accounts
and invokes rmu s er. See Chap. 16 concerning using cron.
Remove a User from the Sys tem
Type or select values in entry f i e lds .
Press Enter AFTER making a l l des i red changes .
* User NAME
Remove AUTHENTICATION inf ormation?
F l = Help
F5 = Undo
F9 = She l l
Figure 21 .3
F2 = Refresh
F 6 = Command
F l O = Exi t
SMIT remove user panel.
[ Entry Fi elds ]
[ s t impy]
F3 = Canc el
F7 = Edit
Enter = Do
F4 = Li s t
F 8 = Image
21 .7.4
Users and Security
Restricting access
If it is necessary to restrict access to the system for a particular user,
you may deny access from a number of mechanisms, depending on the
situation. Login access can be restricted by setting the LOGIN User
and User c an RLOGIN fields to false. You may also restrict access
by resetting the date in the EXP IRATI ON field. If you wish to send the
user an informative message concerning account status to the user,
create a script or program to write the message to stdout and add the
program name to the Ini t i a l PROGRAM field for the user. After the
user supplies a user name and passwd at login time, the message is
displayed and the user is logged off. Use the chu s e r command to
enable the desired level of access restriction.
21 .8
Password Files
All the information inj ected by the AIX account management tools end
up as entries in a number of account support tables. I have discussed
the structure that some of these files provide in the previous sections.
There are three other files that are primarily responsible for identify­
ing an account to the operating system and application set. These are
the / e t c /pas swd, / e t c / s ecuri ty /pas swd, and / e t c / secur i ty
/user files.
21 .8.1
/ etc /passwd
The / et c / pas swd file uses the standard password file format avail­
able on most UNIX systems, the only exception being the use of a
shadow p a s sword file . Shado w password support removes the
encrypted password from the world-readable / e t c / pas swd file and
places it into another file with restricted access. A place holder, ! , is
inserted into the password field in I e t c / p a s swd. Each field in the
/ e tc /pas swd file is separated by a colon.
I etc /pas swd fields:
roo t : ! : O : O : System overseer : / : /bin / ksh
daemon : ! : 1 : 1 : : / etc :
bin : ! : 2 : 2 : : /bin :
sys : ! : 3 : 3 : : / usr/ sys :
adm : ! : 4 : 4 : : / usr / adm :
uucp : ! : 5 : 5 : : / us r / l ib /uucp :
s t impy : ! : 4 0 8 4 : 3 0 : S t impson Cat : /ul / s t impy : /bin/ ksh
AIX commands and applications that must resolve user information
query / etc /pas swd through the use of library calls like getpwnam ( ) .
Parsing large password files can cause significant delays in command
response time. To improve response time, AIX supports building a
structured dbrn database from the / e t c / p a s swd information. The
Managing the User Environment
mkpas swd command reads / et c / pas swd and creates a keyed directo­
ry file, / e t c / p a s swd . d i r , and a data file, / e t c / p a s swd . pag.
Password dbm support is not required, but is provided as
sites with large user communities.
# rnkpasswd / et c / pas swd
21 .8.2
option for
Create new passwd dbm database
/etc/ security/passwd
Shadow password support is provided by the / e tc / s ecur i ty / pas s ­
wd file. Each user account i s represented by a user name stanza. The
stanza contains the encrypted password, time of last update, and the
update flag. The update flag is either NULL or one of the following
Only root may change this password
A member of the security group reset this password so it must be changed
at next login
None of restrictions set in the I etc / s ecuri ty I login . c f g file are
enforced for this account
Example I etc I s ecur i ty /pas swd stanza:
s t impy :
pas sword = dWe 3 a s f ZpuoJ6
las tupdate = 7 2 2 2 8 7 8 6 7
f lags = NO_CHECK
21 .8.3
/etc / security/user
The / e t c / s e c ur i ty / u s e r file contains the extended attributes
defined for the user. Each user is identified by a user name stanza
followed by each attribute and value. A de faul t : attribute set fol­
lows the header comments in the file. Each user entry may override a
default attribute by specifying a local value.
Example / et c / s ecur i ty / user stanzas:
defaul t :
admin = false
login = true
su = true
daemon = true
rlogin = true
sugroups = ALL
t tys = ALL
authl = SYSTEM
auth2 = NONE
tpath = nosak
umask = 0 2 2
expires = 0
s t impy :
login = false
rlogin = false
Users and Security
21 .9
lnfoExplorer Keywords
t ouch
/ etc /pas swd
/ et c / group
quo tacheck
/ e tc / s ecur i ty/pas swd
/ e tc / s ecur i ty / group
/ e tc / environment
/ e tc /pro f i l e
/ e tc / s ecur i ty/ envi ron
l s group
/ et c / s ecur i ty/mkus er . sys
/ e t c / s ecur i ty/mkus er . de fau l t mkuser
s e tgroup
/ e tc / motd
ms gs
/ et c / s ecur i ty / l ogin . c fg
/ et c / s ecur i ty / l imi t s
rl imi t
/ e tc / f i l e sys t ems
c ron
quo t a
mkpas swd
/ etc / s ecur i ty / u s er
us erquo ta
21 .1 0
User Administration
/ e t c / s ecur i ty/pas swd
Secure passwd entries
/ et c / pas swd
Unsecure passwd entries
/ e t c /pas swd . { pag dir }
DBM passwd files
Create DBM files
/ e t c / group
Group numbers and lists
/ e t c / secur i ty/ group
Group configuration
mkgroup , chgroup , l sgoup
Manage groups
Change administrators or members of a group
Reset the current group set for a user
Set the group ID for session
Managing the User Environment
System defaults:
Resource limits
/ e t c / secur i ty/ l imi ts
/ etc / s ecur i ty/user
User authorization and configuration
/ e t c / secur i ty/ login . c fg
System authorization, heralds, shells
chgdev -1 sys O -a <attribute>
Set kernel attributes
smi t chgsys
Set kernel attributes
Disk quotas:
/ < f i l e - sys t em> > / quota . user
User quota/file system
/ < f i le - sys tem> / quota . group
Group quota/file system
/ e tc / f i leqys tems
Set quota attributes
Edit user quota limits
quo taon /quo tao f f
Enable/disable quotas
quo tacheck
Set quotas/file system
quo ta , repquota
Report quota, usage
User environment:
/ e t c / environment
System environ defaults
/ etc /pro f i l e
System login defaults
/ e t c / s ecur i ty/ environ
User environ defaults
/ e t c / s ecur i ty/mkus er . defua l t
User environ defaults
/ e t c / s ecurity/mkuser . sys
System environ defaults
smi t mkuser , chuser , lsuser , rmuser
Manage user accounts
$HOME / . login
User login defaults
$HOME/ . pro f i l e
User profile defaults
$HOME / . <she l l >rc
Shell start-up defaults
Aud iti n g and Sec u rity
Security Overview
This age of worldwide communications is bringing us all closer
together. Its also means a world of new and unsuspecting targets for
the cracker community. It doesn't matter whether your system is
stand-alone or tapped into a large network superhighway, it doesn't
pay to leave the key under the mat. Sadly enough, this is true for
friends as well as enemies. Loose lips sink ships! Corny but true!
Consider that the standard login security based solely on user
name and password is in need of improvement. Password expiration
is unpopular with users and is rarely enforced. Passwords are often
easily guessable words that are quickly cracked, given the processing
speed that is widely available at a modest cost. In many cases, it
doesn't even require the use of sophisticated cracking programs.
Users tend to write passwords down and share them with colleagues.
In some cases, additional levels of security are required that are not
easily compromised by user insensitivity to security.
Even if you don't think you have anything that anyone would want,
your system could be a stepping stone to others. Useful information to
system hackers comes in forms like network address tables, e-mail
addresses, and modem dial-up numbers. Physical resources like tape,
disk, and CPU time can be exploited to store information or crack
passwords. System intruders may be curiosity seekers just poking
around or they might be professionals up to serious mischief. Hackers
make their way through the back roads of the network, exploiting
numerous known security holes because administrators are not stay­
ing informed. What do you do?
Defining a Security Policy
Before you pack up your computer and store it in a bank vault, con­
sider the benefits of defining and implementing a formal security poli351
Users and Security
cy. By setting down and enforcing some simple rules and implement­
ing regular system auditing, you can protect yourself from the majori­
ty of attacks. It may not be perfect, but it can go a long way toward
peace of mind.
When defining your security policy, keep in mind that there is a
tradeoff between level of security and level of usability. Unless you're
charged with securing national secrets, try to remember that AIX is
an open syste m-open, as in ease-of-use rather than no-locks-supplied.
Make sure that the policy is distributed to your user community and
that they understand that their responsibility is protecting resources.
The policy should consider maintaining:
User privacy
System integrity
Authorized availability
Ease of use
Auditing and accountability
What m akes a good password? It has to be easy to remember, but not
a plain text word or phrase like your mother's name or words from
the dictionary. It MUST NOT be shared among users. Who has access
to privileged passwords like the root password? Who has access to the
table of encrypted passwords?
These are questions and policies that must be implemented to
ensure a basic level of security. AIX provides tools that address some
of these issues. Others simply require changes in the way we use the
system. Sometimes old dogs have to learn new tricks or someone will
take all the bones!
Shadow password files
One of the biggest problems with traditional UNIX password imple­
mentations is that the I e t c /pas swd contains the encrypted pass­
word for each user and it is world-readable. Although the pas swd
command uses one-way encryption, crack programs can encrypt com­
mon strings and compare the results against the encrypted password
in / e t c /passwd. In the 1960s, this was deemed to be an algorithm
that would take hundreds or thousands of years of CPU time to com­
pare all the possibilities. By using dictionaries and common password
patterns, faster c rypt ( ) routines, and the higher-speed processors
available today, you can crack most common passwords in reasonable
periods of time.
How do you fix this problem? You move the encrypted passwords into
a secure table and directory and require the use of secure setuid sub-
Auditing and Security
routines to access the information. This is what IBM has implemented
on AIX V3. A place-holder character, " ! " , is inserted in the pas swd
field of the / et c /pas swd file. A secure shadow password file, / e t c
I s ecur i ty /pas swd, contains the encrypted passwd for each user.
/ e t c /pas swd-mode 644:
root : ! : O : O : Almighty Overseer : / : /bin / ksh
/ et c / s ecur i ty/pas swd-mode 600:
root :
pas sword = asldf i 0 2 3 7xa0
las tupdate = 7 2 8 7 0 7 3 0 6
f l ags =
Password restrictions
Users are not inclined to use esoteric passwords and they do not
like to change their password more than once a lifetime. Unfortu­
nately, this breaks the first law of account security. AIX allows the
system administrator to remind them somewhat forcefully that it's
time for a change, and that they need to be somewhat imaginative
in what they choose. You don't want to be a nag, so don't require
changes too often and don't require them to be so cryptic that they
have to write them down. Tailor password aging and character
restrictions in the pw_r e s t r i c t i ons stanza in the / e t c / s ecuri ­
ty / l ogin . c fg file. Restrictions are applied systemwide. Once the
maxage limit is passed, users are required to select a new password
at next login.
Password restrictions-/ e t c / secur i ty/ l ogin . c fg:
Def Max Rec
pw_re s t r i c t i ons :
maxage =
minage =
minalpha =
mino ther =
mindi f f =
maxrepeat s =
weeks before update enforced
weeks before update allowed
number of alpha charac ters
number of nonalpha charac ters
chars di f f erent from old pas sword
number of repeat s for any character
Resetting users' passwords
It doesn't seem to matter whether a password is cryptic or a common
word. Users always seem to forget them. A common complaint from
system administrators is that AIX requires root's password to reset a
user password. In fact, AIX does require root's password if you are not
a member of the security group, and if you don't use the pwdadm com­
mand or SMIT to update passwords. As a member of the security
group, you are required to enter your own password to validate who
you are.
Users and Security
# pwdadm sleepy
<your> Pas sword :
Changing pas sword for " s leepy"
s leepy ' s New pas sword :
Re-enter s l eepy ' s new pas sword :
Superuser access
Care should be taken on who has access to root's password and how it
is used. Users with access to privileged accounts should log in using
their own nonprivileged account and use the su command to setuid to
privileged accounts. The su command logs all invocations to the
/ var I adm/ sulog file. This provides an audit trail on who, when, and
success of access.
Shell aliases mapping su to the full path name, /bin/ su, will limit
the possibility of a trojan horse su command from being used on a
compromised account. A trojan horse copy of su will usually act as
you would expect, except that it will record passwords in a file moni­
tored by the perpetrator.
AIX provides an additional level of su security by defining whether
an account can be accessed via su, and which groups are permitted
su access to the account. These restrictions are applied on a per-user
basis in the / e tc / s ecur i ty / us e r file.
su restrictions-/ e t c / s ecur i ty / user:
robin :
su = < t rue / false>
<ALL l l i s t >
Users may su to this account
Groups that may su to this account
Auditing passwords
Even when you are enforcing password controls, it is a good idea to
periodically audit passwords on your system. It is often a good idea to
keep abreast of password cracking tools used by the hacker community.
Check out anonymous ftp archives like wuarchive . wu s t l . edu and
f tp . uu . net for password cracking tools like Crack and killer cracker.
The COPS package available from CERT contains various security
tools along with password crackers. The COPS package and Crack
are available via anonymous ftp from cert . org.
AIX provides its own set of password validation tools. These tools
are part of the larger security system called the Trusted Computing
Base (TCB). An important piece of the TCB system is the table valida­
tion tools. These tools may be invoked individually or as part of the
overall system validation from the tcbck command.
TCB password validation commands:
Checks consistency of the / e t c /passwd and / e t c / s ecurity/pas swd files
Checks consistency of the / e t c / group and / et c / s ecur i ty/ group files
Validates entries in the / e t c / secur i ty/user file
Auditing and Security
Converting password files from other sources
If you are moving a large user community from another UNIX plat­
form onto AIX, fear not, AIX provides a means for converting stan­
dard UNIX / e t c /pas swd files into the various AIX password files.
The same tools used to audit password file consistency can be used to
convert password files from other systems.
First, copy the password file into the AIX / et c /pas swd path. Once
the password file is available, execute the pwdck command to create
I etc I s e curi ty /pas swd entries.
# pwdck -y ALL
Next, create user stanza entries for each user in the / e t c / s e curi ­
ty/ l imi t s file and / e t c / s e cur i ty / u s er files, using the u s r c k
# usrck
Finally, update / e t c / group with any GIDs and group members that
existed on the old system. Once updates have been completed, execute
the grpck command to create / e tc / s ecur i ty / group entries.
# grpck
Trusted Computing Base
AIX V3 has an integrated s ecurity system called the Trusted
Computing Base (TCB). TCB validates and audits both hardware and
software components of the RISC System/6000 and AIX V3. TCB is
made up of kernel interfaces, configuration tables, and trusted setu­
id / setgid programs, which monitor system consistency.
tcbck command
The system administrator may add trusted applications to the TCB
system using the t cbck command. It is the administrator's responsi­
bility to guarantee the security of any new application added to TCB.
# tcbck - a <pathname> [ a t trib = value ]
Mark application as trusted
# tcbck -d <pathname>
Remove trusted status
The attributes of trusted components of the TCB system are recorded
in the / e tc / secur i ty/ sysck . c fg table. The tcbck command reads
the information recorded in sys ck . c fg when auditing the security
state of the system. The tcbck command can be run periodically using
cron, or interactively from the command line. The latter is useful when
you suspect the possibility of the system having been compromised.
Users and Security
# tcbck -p ALL
You can use tcbck to check the integrity of all file system files in
the event that they may have been compromised. During a file system
scan, t cbck validates that files with setuid root and administrative
setgid bits preexist in the I e t c I s ecuri ty I sys ck . c fg file. If they
do not exist, then the privileged bits are cleared. The same is true for
device special files, links to trusted file s , and files with the tcb
attribute. Note that this can take a significant amount of time.
# tcbck -t tree
Invoke file system check.
I etc/ security I sysck . cfg
Tru sted applications are identified by stanza e ntrie s in the
/ e t c / s e cur i ty/ sys ck . c fg file bearing the path names. Each stan­
za is followed by a set of parameters defining the attributes of the
trusted application. Refer to Table 22. 1.
Example / et c / s ecur i ty/ sys ck . cfg stanza:
/usr/bin/ac ledit :
owner = bin
group = bin
mode = TCB , 5 5 5
type = FILE
o l dpath = /bin / ac l edi t
class = apply , inventory , bo s . obj
size = 5 0 1 0
checksum = " 4 4 9 0 4 5 "
Trusted communication path
For applications that require a secure interface between the applica­
tion and the user's terminal, AIX provides the concept of a trusted
TABLE 22.1
/etc/security/sysck . cfg
Identifier that is used to group a set of applications. Applications identified by a class may
be checked as a unit by tcbck. Multiple class names may be specified for an application.
File owning user name. Must match directory owner value.
File group name. Must match directory group value.
Specifies one of SUID, SGID, SVTX, or TCB followed by the file permissions. Permissions
may be specified as an octal value (ex 644) or a 9-character value (ex. rw-r-r-).
List of path names that are hard links to this file. Entries in the list are separated by
List of path names that are symbolic links to this file. Entries in the list are separated by
Program path name and arguments that may be invoked to check the application.
The access control list value for the file. If the ACL value does not match that of the file,
tcbck applies the value listed in stanza ACL parameter. The value must be consistent
with the SUID, SGID, and SVTX value listed in the mode parameter.
The source file name that is to be copied for checking.
Auditing and Security
communication path. Trusted communication paths allow only TCB
trusted programs and devices to interact with the user's terminal.
This limits the possibility of trojan horse or eavesdropping applica­
tions from opening file descriptors associated with a TTY port.
A trusted communication path is invoked by pressing a secure atten­
tion key (SAK). The SAK key sequence, c tr l -x c t r l - r, is enabled by
the system administrator in the / e t c / s e cur i ty / l ogin . c f g file.
SAK support may be set for individual TTY ports.
A secure login session begins by pressing the SAK prior to typing in
your user name and password. After the SAK sequence has been
entered, ini t revokes all previous opens on the port. A g e t ty is
started on the port and a new login herald is displayed. After entering
your user name and password, TTY port permissions are restricted to
your account and the trusted shell (tsh) is invoked. The t s h shell is
akin to the Korn shell (ksh), and will only allow execution of trusted
applications (those marked with the tcb bit). It is a good idea to initi­
ate a trusted path when working as root or setting passwords.
Access Control
Access control defines the who and how of access to system resources.
Traditional UNIX access control is based on user and group owner­
ship of a resource and associated mode bits that define read, write,
execute, setuid, and setgid access. Read, write, and execute permis­
sions are set individually for the resource owner, group, and other
(everyone). The setuid mode bit indicates that, when the resource is
invoked, the resulting process takes on the effective UID permissions
of the resource owner. The setgid mode bit indicates that effective
GID permissions will be enabled for the process.
The c hown, chgrp, and chmod commands are used to set the
owner, group, and mode for a resource. A three-digit octal mask called
the umask may be set by each user to set the default mode bits auto­
matically when new files are created.
# chown <user name> <path name>
Set user ownership
# chgrp <group name> <path name>
Set group ownership
# chmod <mode> <path name>
Set mode permissions
# umask <mask>
Set creation mask
To list the ownership and mode permissions for a file use the 1 s
# l s -alF /home / deroest
total 8 8 0
drwx- - deroes t
- rw- - - deroest
- rw- - - deroest
- rw- - - 1
sys tem
sys t em
sys tem
sys tem
0 8 : 02
22 : 00
. .I
. fo rward*
. kshr c *
. l ogin*
Users and Security
- rw- - - -
drwx - - drwx- - drwxr-x- drwxr-xr-x
sys t em
sys tem
sys tem
sys tem
sys tem
sys tem
sys t em
sys t em
sys tem
09 : 07
0 9 : 14
13 : 2 2
22 : 08
09 : 58
10 : 48
. news rc
. pro f i l e *
. rhos t s *
Mai l /
News /
doc /
src /
Using entries in I e t c I group to support file sharing does not scale
well in large multiuser environments. Discretionary access rights
should be controlled by the owner of the resource and not require
intervention by the system administrator.
Access control lists
To address the requirement for extra discretionary access privacy
under users' control, AIX V3 provides access control lists (ACL). ACLs
have been used on a number of other operating systems for many
years. ACLs work in conjunction with AIX groups and group lists. They
provide a finer granularity of control over access rights within groups.
ACLs are made up of sets of access control entries (ACE), which
define the access rights to system objects. There are three sections to
an ACL. The first defines the file attributes, for example, SUID per­
mission. The second section defines the traditional UNIX base per­
missions: owner, group and other ids, and modes. The third section
defines the extended permissions for the file. This section provides
finer control over access rights to the file.
Example ACL:
attributes :
base permi s s i ons
owner ( gi lbert ) :
group ( u s er ) :
o thers :
extended permi s s i ons
permi t
spec i fy
Section 1
Sec t i on 2
Sec t i on 3
u : j ill
g : staff
g : user , g : ops
Extended permission ACE s use the format action access-mode
users Igroups. The ACE action field must be one of the following:
permi t, deny, or spe c i fy. The permi t and deny actions add to or
remove the access mode from the standard mode value. The spe c i fy
action means to use the exact access mode for the user/group set that
follows. This overrides the standard modes defined for the file .
Multiple user/group sets specified by u : u s er name and g : group
name, respectively, indicate that a particular user must be identified
by each value in the list before the access mode applies to the user.
Auditing and Security
Access rights or restrictions are based on the logical union of the
representative ACEs for a particular user or group and the tradition­
al UNIX access modes. You have to be very careful managing both
ACLs and traditional UNIX permissions. AIX will resolve contradic­
tions between multiple ACLs and standard permissions. Note that
using the chmod command with octal permission arguments will
remove any ACL associated with a file. This can be a problem if
you're like me and prefer to use the numbers (sigh).
To create an ACL use the ac l edi t command. A default ACL is
opened for update in the editor specified by the EDITOR environment
variable. Tailor the ACL to fit the access rights you have in mind. Set
the di s abled field to enabled and save the file. The application will
ask you whether you want to apply the ACL on exit.
# acledit
Use the a c l g e t and a c lput commands to display or apply ACL
information for a file.
# ac lput acl-name f i l e-name
Apply an ACL to a file
# aclget f i l e-name
Display ACL information
In cases where you want to define a set of ACLs which are to be
applied to a set of files, use ac l edi t to create and save the ACLs to
generic file names. You can then use ac lput to apply each ACL type
to the desired files.
Authentication Methods
The designers of the AIX TCB system thought about these issues and
provided an interface that allows you to add to, replace, and apply
system authentication mechanisms on an individual basis. What's
more, it doesn't require modifications to the default authentication
code, /bin/ l ogin@ - > / u s r I sbin / t sm, or alteration of the pass­
word file format as understood by the command set. Sounds real nice?
It is real nice!
The facility is simple to understand and easy to use. The TCB sys­
tem passes the user name to be authenticated to your local applica­
tion as an argument. Your code takes whatever action is appropriate
to authenticate the user and returns 0 if authentication is successful
or 1 if it has failed. Login processing will proceed or abort based on
this return code.
Authentication tables
Defining your authentication code to the system requires an entry in
the / e t c / secur i ty / l ogin . c f g file. As superuser and using your
Users and Security
favorite editor, edit the l og in . c fg file and look for the comment line
that contains auth_me thod : . For each authentication program you
want to add, enter a stanza of the form:
method_name :
program = your__program
Example 1:
TOKcheck :
program = /usr / loca l / etc /validateTOK
The method name you choose will be used to identify the authentica­
tion program in the / et c / s ecur i ty / u s er file. Supply a stanza for
each authentication method you intend to use.
Next, you identify which user names will use these methods in the
/ et c / s ecuri ty / u s er file. As superuser, edit the user file. The user
file header explains the use of the two authorization parameters,
authl and auth2 . The authl stanza identifies the primary authenti­
cation methods to be employed for each user. If this method set fails,
login is denied. The auth2 stanza defines a secondary set of methods
that is invoked after the au thl methods are run. If these methods
fail, login is not denied. These secondary methods could be used to
provide extra authorization to access secure system resources.
The format of the au th parameters is:
authl = method< , method.. > < ; username>
au th2 = me thod< , method .. > < ; username>
Supply each method name to be invoked delimited by commas. The
default action is to pass the invoking user name to the method. You
can override this by providing the user name to be used after the
method list, delimited by a semicolon. The special method names,
SYSTEM and NONE, specify that either the standard password check or
no authentication method is to be run, respectively.
To indicate that a method set is to be run for all users unless it is
specifically overridden, use the de fau l t : stanza located after the
header in the / e tc / s ecuri ty/ u s er file. In Example 2, the TOKcheck
method that we identified earlier in the / etc / secur i ty/ login . c fg
file will be run after the standard password check for all users.
Example 2:
defaul t :
adrnin = false
login = true
su = true
daemon = true
rlogin = true
sugroups = ALL
t tys = ALL
Auditing and Security
authl =
auth2 =
tpath =
umask =
= 0
In the case that we want to override the default authentication for
a particular user, include local authl and auth2 parameters after
the stanza identifying the user name.
Example 3:
operator :
authl = SYSTEM , TOKcheck
auth2 = OPScheck; operator
ops l :
OPScheck; operator
ops2 :
authl = SYSTEM , TOKcheck
auth2 = OPScheck ; operator
opsmgr :
authl = SYSTEM , TOKcheck
auth2 = OPScheck ; operator
In Example 3, we have identified a secondary method called
OPScheck that might give access to a particular set of commands or
resources to system operators. Note also that the user name operator
is passed to the method program. This will allow the addition of new
operator account names without having to identify each one explicitly
in the OPScheck source code.
Smart card authentication
In the previous section, the examples referred to a sample method
called TOKcheck. In addition to requiring a user name and password
for authorization, add a token that uniquely identifies each user.
There are a number of smart cards and key cards on the market that
can be used to provide unique authentication tokens. A token card is
given to each user and is identified by a unique string that is stored
with the user name in a secure central database.
An application called TOKcheck can now be installed, which will
generate a random string and display it as output. The user keys the
string into the personal token card, which then DES encrypts the
string and outputs it to the cards display. The user types this
encrypted string back into the TOKcheck application on the terminal.
TOKcheck also encrypts the original string using the unique DES key
associated with the user's token card in the database. It compares the
result with that supplied by the user.
There are automated smart cards available that periodically cycle
through encryption strings on both a server and the smart cards. The
Users and Security
cards and the server are synchronized by clocks. Using automated
smart cards, the user need only enter the current string displayed on
the smart card display when the token is requested by an application.
This scheme ensures that the user must be in possession of the cor­
rect token card, as well as the correct user name and password.
What's more, the encryption string is only valid for a short period of
time and cannot be reused by anyone eavesdropping on the wire.
Kerberos-trusted third party
Another authentication mechanism that is used in the Open Software
Foundation's Distributed C o mp uting E nvironment ( D C E ) and
Distribut e d Management E nvironment (DME) i s the Kerberos
authentication system. Kerberos was originally developed at M.I.T.
and is based on the trusted third party model. The original design is
described in a series of papers presented at the 1988 USENIX Winter
Kerberos assumes that everything is untrustworthy except the
authentication server itself. The authentication server acts as an
intermediary between the client and the desired services. The client
must authenticate itself to the Kerberos authentication server to gain
a ticket, which grants the rights to access distributed services. You
only need validate yourself once to the server rather than once for
each service you wish to access. The access rights tickets are also
valid for a given period of time. The Kerberos ticket mechanism elimi­
nates the need to transmit passwords over network in clear text.
Client and server passwords are known by the authentication server.
Refer to Fig 22. 1.
Whenever access to services is requested by an unauthenticated
client, a message is sent to the authentication server that contains
client name and the Kerberos ticket-granting service name. The
authentication server looks up the names and obtains the encryption
key for the client and the ticket server. The encryption key is known
only to the owning agent and the authentication server. The encryp­
tion key can be a one-way DES encrypted password. A message is
constructed by the authentication server containing the client and
ticket server names , address, and a random session key, which it
encrypts using the client's encryption key. The message is called a
ticket and is sent to the client. The client uses its encryption key to
decrypt the the ticket and stores the ticket for the duration for which
it is valid. The session key is used to encrypt ticket communication
with the Kerberos ticket service to gain access to other services and
When access to a service is requested, the ticket service provides a
new ses sion key along with a ticket encrypted with the service's
encryption key from the authentication server's database. The client
Auditing and Security
Auth DB
Ticket Server
' .
., '· 2
., '·
1 ., '·
1 . Request authentication for user and service
2. Return TS session key and identifiers
3. Request ticket using sealed authenticator
4. Return ticket for requested service
5. Connect to service with authenticator ticket
Figure 22.1
Kerberos ticket flow.
uses the new session key to create an authenticator ticket, which
identifies the client, and sends it along with the encrypted service
ticket to the new service. The service decrypts the ticket using its
encryption key. The service ticket contains the session key, which is
then used to decrypt the authenticator ticket. Now the client and ser­
vice know about each other and real work can begin.
It may seem like a lot of hand waving to inhibit clear text pass­
words and authentication information from being broadcast over the
network. On the other hand, it is extremely easy to eavesdrop on the
wire. All this negotiation is taking place under the covers, so it is not
visible to the end user. Kerberos won't restrict access to someone who
has already compromised another user's login ID and password.
22. 7
Network Security
AIX TCB also encompasses network interfaces and applications. The
network component of TCB is called the Network Trusted Computing
Base ( NT CB ) . Security issues related to the various network inter­
faces and protocols are covered in detail in the chapters related to
networking. Refer to these chapters for specific information.
Users and Security
System Auditing
When talking about security breaches, it is often not sufficient to
periodically check to see if someone left the barn door open. It's much
better to be informed when the door is opened. AIX TCB provides an
auditing system that supports event detection, data collection, and
report processing. TCB event detection code is integrated in the ker­
nel and trusted programs. Event detection may be enabled for the
entire system or for local processes only.
Audit logging
The TCB event detection code reports event information to an audit
logger. The audit logger constructs the audit trail for events. The
audit trail includes the type of event, responsible UID, date, time,
status, and any event-specific information. Audit logging can be done
in either user state or kernel state. The audit records are logged in
one of two types of log modes:
Audit information is logged to a series of files (bins). Data may
be compressed and filtered.
Audit records are written to a circular buffer that is read syn­
chronously through a pseudodevice. STREAM mode provides
real-time event monitoring.
Event types
The AIX audit system allows you to configure both event detection
and audit trail recording. Event detection can be selected on a per­
user basis. Care should be taken to audit those events that are of
most interest for your environment. Auditing too many event types
can cause significant threats to be lost in the noise. Too few event
types may miss important events. Event selection may be per-process
or per-object.
Event types.
Security policy events:
Subject events
process creation
process deletion
process attribute changes
Object events
object creation
object deletion
Auditing and Security
object open
object close
object attribute changes
Import/export events
importing/exporting an object
Accountability events
updating password tables
updating group tables
user login
user logoff
updating use authentication data
updating trusted path configuration
authentication configuration
auditing configuration and updates
General system administration events
privilege use
file system configuration
device configuration
system parameter configuration
boot and shutdown
RAS configuration
other system configuration
Security violation events
access permission refusals
privilege failures
diagnostic detected system errors
attempted alteration of TCB
Audit configuration
To configure the AIX TCB auditing system, begin by selecting the
event types to be collected. Event types are defined in the I e t c
/ s e c ur i ty / audi t / event s file. Using a n editor, add o r remove
event types and the associated output formats.
Users and Security
Group related event types into audit classes. Audit classes are one
of three types:
Alterations in the authentication and access controls of the system
Account modifications and installation
!nit process events, login, cron, etc.
Record each audit class in the / e t c / s e cur i ty / audi t / c o n f i g
file. I f the audit class i s to b e assigned t o individual users, add the
class to the u s ers stanza.
/ e t c / s ecur i ty / audi t / config:
s tart :
s treammode
bin :
trai l =
binl =
bin2 =
bins i z e
cmds =
s tream :
cmds =
classes :
obj ects
f i l es
mai l =
cron =
tcpip =
users :
roo t =
/ audi t / tra i l
/ audi t /binl
/ audi t / bin2
/ e t c / security/ audi t /bincmds
/ e t c / s ecuri ty/ audi t / s treamcmds
USER_SU , PASSWORD_Change , FI LE_Unl ink , FILE_Link , FILE_Rename
SRC_S tart , SRC_Stop , SRC_Adds sys , SRC_Chs sys , SRC_De l s sys ,
SRC_Addserver , SRC_Chserver , SRC_Delserver
PROC_Create , PROC_Delete , PROC_Execut e , PROC_RealUI D ,
PROC_AuditID, PROC_RealGID , PROC_AuditState , PROC_AuditClass
, PROC_Environ , PROC_SetS ignal , PROC_Limi ts , PROC_SetPri ,
PROC_Setpri , PROC_Privi lege
FILE_Open , FILE_Read , F ILE_Wr i t e , F ILE_C l o s e , F ILE_L ink ,
F ILE_Unl ink , F ILE_Rename , FI LE_Owner , FILE_Mode , FILE_Ac l ,
FILE_Privi l ege , DEV_Create
MSG_Crea te , MSG_Read , MSG_Wr i te , MSG_De lete , MSG_Owner ,
MSG_Mode , SEM_Create , SEM_Op , SEM_De lete , SEM_Owner , SEM_Mode
, SHM_Create , SHM_Open , SHM_C l o s e , SHM_Owner , SHM_.Mode
SENDMAIL_Conf i g , SENDMAIL_ToF i l e
AT_JobAdd , AT_JobRemove , CRON_JobAdd , CRON_JobRemove
TCP I P_config , TCP I P_hos t_i d , TCPI P_route , TCP I P_conne c t ,
TCP I P_data_ou t , TCPI P_data_in , TC P I P_acces s , TCPIP_set_
t ime , TCP I P_kconf i g , TCPI P_kroute , TCP I P_kconnec t , TCP I P_
kdata_out , TC PI P_kdata_in , TCPI P_kcreate
Audit classes assigned to obj ects must be configured into the
/ e tc / s ecur i ty / audi t / obj e c t s file. Log mode, BIN, or STREAM is
also defined in this file. Tailor the binmode or s trearomode stanzas to
enable data collection. Any programs used to filter audit records must
be defined in / et c / s ecur i ty/ audi t / { bincmds , s treamcmds } .
/ e tc / s ecur i ty / audi t / obj e c t s :
/etc / s ecuri ty/ environ :
Auditing and Security
/ e t c / secur i ty / group :
/ e t c / s ecur i ty/ l imi t s :
/ e t c / s ecuri ty/ login . c fg :
/ e t c / s ecurity/pas swd :
r = • s_PASSWD_READ "
/ e t c / secur i ty/user :
/ e t c / s ecur i ty/ audi t / config :
/ et c / s ecur i ty / audi t / { bincmds , s treamcmds } :
audi t , audi tpr , audi tselec t , audi t s tream
Security Tools and Information
I've talked about setting security policies, enforcing access controls,
and auditing different aspects of system authentication and autho­
rization. Is this enough to protect your system? The problem is that
hackers are busy bees that won't stop prying and testing just because
you have put a few acce s s controls in plac e . You have to keep
informed and continue looking for problem areas in the system.
AIX provides a virus-scanning application called vi r s c an. The
v i r s c an command reads a set of know virus signatures from the
/ et c / s e cur i ty / s can/ { v i r s i g . 1 s t , addenda . 1 s t } files. The sig­
natures are known virus bit strings that may be found in system files
and executables. You can add new signatures to the addenda . 1 s t
file. If virscan finds a signature in a file, it records it to the po s i ­
t ive . v i r file.
# virscan < PathName>
Invoke virs can on a directory tree
In the previous section concerning password cracking, I mentioned
the COPS packages from the Computer Emergency Response Team
(CERT) at Carnegie Mellon University. COPS will audit system files,
look for setuid/setgid programs , writable device files, etc. You can
obtain a copy of the COPS package via anonymous ftp to cert . s e i .
cmu . edu.
Users and Security
Information sources
CERT regularly posts security advisory memos to the Usenet group,
c omp . unix . s ecur i ty. The memos are also available in their anony­
mous ftp archive. Report any security problems to CERT. They can be
reached at:
Computer Emergency Response Team/Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
anonymous ftp:
22. 1 0
22.1 1
lnfoExplorer Keywords
/ e t c / pas swd
/ e t c / s e c ur i ty / sys c k . c f g
pas swd
c ryp t
/ e t c / s ecur i ty/pas swd
/ e t c / s e cur i ty / l o g i n . c fgq
s ecuri ty
/ var / adm / sulog
/ et c / security/user
ac l edi t
t cbck
ac lput
aud i t
audi tpr
audi t s e l e c t
/ e t c / group
audi t s tream
/ e t c / s e c ur i ty / group
vi r s can
User passwords:
/ e tc / securi ty/pas swd
Secure passwd file.
/ et c / secur i ty / l ogin . c fg
Set passwd restrictions.
Reset user passwords. Should be a member of security
Auditing and Security
Superuser access:
Set user command.
/var / adm/ sulog
Log of su activity.
/ e t c / secur i ty / user
Set su restrictions.
Password auditing:
Checks / e t c /pas swd ,
Checks / e t c / group ,
/ e t c / s ecurity/pas swd consistency.
Validate entries in / e t c / s ecuri ty/user .
/ e t c / security/ group consistency.
System auditing:
Manage auditing system.
/ e t c / secur i ty / sysck . c fg
System audit config.
/ e t c / s ecur i ty / audi t / event s
Audit event types.
/ e t c / security/audi t / config
Audit class config.
/ etc / secur i ty / audi t / obj ects
Audit object config.
audi t , audi tpr , audi tselec t , audi ts tream
Manage audit system.
Authorization and access:
Secure attention key.
Trusted shell.
/ e t c / securi t / user : authl auth2
Define alternate login authorization routines.
chown , chgrp , clunod
Set standard UNIX access permissions.
umask <mask>
File creation mask.
acledi t
Edit access control lists.
aclget , aclput
Assign ACLs.
Virus detection:
virscan <PathName>
Invoke virscan .
/ e t c / securi ty/ scan / { virsig . l s t , addenda . l s t }
Virus signatures.
/ e t c / s ecuri ty/ s can/pos i t ive . vi r
Virus found log.
System Acco u nt i n g
Accounting Overview
Let's see, that's 22 minutes of CPU, 3 MB of disk space, and 9 hours
of connect time. Will you be putting this on a credit card, cash, or
check? Nothing in life is free ! Especially computer resources.
Even if you don't chargeback for system resources, it's a good idea
to regularly monitor utilization. By collecting accounting data, you
get a reasonable profile of how your system is being used. Who are
the big resource hitters? How soon are you going to need that extra 2
GB of disk space? Maybe you need to justify the resources to a higher
The AIX. accounting system is very SYSV in flavor. For those of you
with a BSD inclination, there is a set of the standard BSD accounting
system management commands bolted onto the SYSV environment.
Sites that write their own accounting programs and scripts will find
that AIX. provides the tools and accounting data formats that will
facilitate porting an existing system from other UNIX environments.
For the less adventurous, AIX. supplies all the commands and scripts
required to manage system accounting data. The accounting system
is based on a set of three components:
Data collection
Management and reporting commands
Periodic data management scripts
D ata collection takes place automatically when accounting is
enabled. Management and commands allow you to start and stop the
accounting system, manage the data files, and generate reports. The
data management scripts are invoked through cron to automate clos­
ing out data and generating general summary information.
Users and Security
Data Collection
Data collection begins when system accounting is turned on and stops
when it is turned off. A.IX samples and records process utilization and
session data for each user in the system. The collected information
represents connect time, process resources, commands, disk usage,
and print queuing utilization.
Connect time
C onnect time data is accumulated in the / va r I a dm / wtmp and
/ e t c / utmp files. Each time you log in to A.IX, the l ogin process
writes a record to wtmp and utmp. The data indicates the user name,
date, time, port, and connecting address. A similar record is written
by the ini t process when you exit the system. This data represents
the duration of your connection to the system.
Combinations of rsh and Xl l clients make connection data a bit
fuzzy in environments where there is heavy Xl l usage. The xterm
terminal emulation client provides a flag indicating whether or not an
/ etc / utmp record should be written. xterm also has a nasty habit of
trashing the / e t c / utmp file. You'll notice the latter problem when
your upt ime statistics look too good to be true.
The a c c twtmp command records system boot and shutdown times
in the / var I adm/wtmp file. This data provides an audit trail concern­
ing the comings and goings of users on your system.
Process resource usage
Resource utilization information for each process run by the operating
system is recorded in the / var I adm/pac c t file at process exit. The
bad news is that no information is run for processes that don't exit! A
process accounting record indicates the UID, GID, user name, elapsed
wall clock time, CPU time, memory use, character 1/0 total, and disk
block 1/0 totals.
Command usage
A nice side effect of process data is an audit trail of command and
application usage. This data provides a profile of application use and
may assist in tracking security problems. Be aware that experienced
hackers tend to fix up accounting information before leaving the
scene. See Chap. 22 for secure system auditing details.
Disk usage
You can periodically collect disk usage information for the system and
store it in the / var I adm/ dtmp file. Collecting disk usage data can
cause a bit of a load on the system, so it's a good idea to run it during
System Accounting
an off-hour shift. AIX assigns disk usage data to users based on the
files they own in the file system and any links to files they may have
created. The usage statistics for a file are distributed evenly among
the users with links to the file.
It is also possible to track disk usage and regulate limits on usage
by user and/or group. This is done through the disk quota system. See
Chap. 2 1 concerning details on the disk quota system.
Print usage
Print queuing system utilization statistics are recorded by the enq
command and the qdaemon process. enq writes a record for each
print job it handles. The record indicates the print job owner, job
number, and the file name. When the file is printed, qdaemon writes
another record that includes this information plus the number of
pages that were printed. There are public domain backends for post­
script queues that will supply accounting records for postscript con­
version and attributes.
Accounting files
Accounting records are stored in a set of files located in the / var I adm
/ var I adm accounting files:
pac c t
Active process data
Spacc t . <mmdd>
Daily active process data ( runacct )
qacc t
Print usage data
c tmp
Connect session data
Disk usage data
Active process data
Accounting Configuration
To configure the accounting system, begin by creating file name stubs
with the correct permissions for each of the data collection files. This
must be done with adm authority. The file name stubs can be created
by touching the file name or running the nul l adm command. nul ­
l adm creates the file names supplied as arguments and sets the cor­
rect permissions.
Setup collection files
touch /var / adm/ ( wtmp , pac c t }
chown adm /var / adm/ { wtmp , pacc t }
chgrp adm /var / adm/ {wtmp , pacc t }
chmod 6 4 4 /var / adm/ { wtmp , pacc t }
/usr / sbin/acc t / nul ladm wtmp pacct
Users and Security
Identifying shifts
Configure the / e t c / ac c t / ho l i days file to reflect your prime time
shift and scheduled holidays. The first line in the file indicates the
year and the starting and ending times for prime shift. Subsequent
lines indicate the date and description of each holiday scheduled over
the year. Each holiday entry indicates:
Integer day of the year
Three-character month name
Integer day of the month
Text string holiday description
/ e tc / ac c t / ho l idays :
* ( C ) COPYRIGHT Interna t i onal Bus iness Machines Corp . 1 9 8 9 *
All Rights Res erved
* Licensed Material - Property of IBM
* Prime /Nonprime Table for AIX Acc ount ing Sys tem
* Curr Prime Non-Prime
* Year S tart Start
1990 0800 1700
Jan 1
Feb 1 9
May 2 8
Jul 4
Sep 3
Nov 2 2
Nov 2 3
Dec 2 5
Dec 3 1
New Year ' s Day
Washington ' s Birthday ( Obsvd . )
Memorial Day ( Obsvd . )
Independence Day
Labor Day
Thanksgiving Day
Day a f ter Thanksgiving
Chr i s tmas Day
New Years Eve
Disk accounting-/etc / f i lesystems
If you will be collecting disk usage information, add an acc ount =
true entry in the stanza for each file system you intend to monitor in
the / e tc / f i l esys t ems table.
Sample f i l esys t ems entry:
/home :
/ dev/hdl
j fs
/ dev/hd8
System Accounting
Print accounting-/etc/qconfig
Print usage records will be saved if an account file destination path is
identified by the ac c t f i l e
file-name parameter for each queue
Sample / et c / qc onf i g entry:
ac c t f i l e = /var / adm/ qac c t
Rebuild the I etc I qc onf i g . bin file by r e f r e shing the qdaemon
# refresh -s qdaemon
Report directories
Make sure the report summary subdirectories, n i t e , f i s c a l , and
sum exist with adm permissions in /var I adm/ ac c t .
c d /var / adm / a c c t
mkdi r nite f i scal sum
chown adm nite f i s cal sum
chgrp adm nite f i s cal sum
chmod .6 4 4 nite f i scal sllllllt
crontab entries
Remove the comments from the a dm and r o o t crontab files. Edit the
crontab files using c rontab - e .
adm c rontab:
# = = = = = = = = = = = = = =
# runacct at 1 1 : 1 0 every night
# dodisk at 1 1 : 0 0 every night
# ckpacct every hour on the hour
# monthly account ing 4 : 1 5 the f i rst of every month
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
1 0 2 3 * * 0 - 6 /usr / l ib/acc t / runacct 2 > / u s r / adm/ a c c t / n i t e / acc t err >
/ dev/ nu l l
0 2 3 * * 0 - 6 /usr / l ib / ac c t / dodisk > / dev/ nu l l 2 > & 1
0 * * * * /usr / l ib/acc t / ckpacct > / dev/nu l l 2 > & 1
1 5 4 1 * * /us r / l ib / acct /monacct > / dev/ nu l l 2 > & 1
= = = =
# = = = = = = = = = = = = = = = = = = = = = =
Work unit fees
The charge f e e command can be used to add work unit entries for
each user on the system into the / var I adm/ f e e file. This data is
later merged with other accounting files by a c c tmerg. charge fee
can be incorporated into the system accounting scripts to implement a
chargeback system.
Users and Security
Accounting Commands
As I mentioned in the introduction, AIX offers both SYSV and a sub­
set of the BSD accounting commands. These commands allow you to
display, manage, generate reports, and record charge fees from the
collected accounting information.
Starting and stopping accounting
Start the accounting system by invoking one of the s tartup, runac ­
c t , turnac c t , or ace t on commands.
# s tartup
# runac c t 2 > / var / adm/ ac c t / ni t e / ac c terr &
# turnac c t on/ o f f
# acc ton /var / adm/pac c t
Stop system accounting b y using the s hu t a c c t , turna c c t , or
acc ton commands.
# shutac c t
# turnac c t o f f
# a c c t on
Add a command entry to the / e t c / re script to start accounting at
boot time.
Displaying statistics
At any time , you can take the pulse of your system or look back
through accounting history from the command line. You can also cre­
ate ad hoc reports by directing stdout to a file.
A general summary of data stored in the / var / adm/pac c t can be
displayed using the s a command. The sa command supports a num­
ber of flags that can be used to filter and restrict the output. Two of
the most useful flags are the m flag, which summarizes by user, and
the - s flag, which summarizes by command. The - s flag can also be
used to merge the summary with an existing history file.
# sa -m
# sa - s
2 2 9 5 . 4 7 re
2 0 6 9 . 4lre
2 5 1 . 8 1 re
0 . 9 7 cpu
0 . 0 6cpu
O . O l cpu
O . O O cpu
3 0 . 6 5 cpu
2 8 . l l cpu
3 . 4 0 cpu
2 . 1 7 cpu
86889 04tio
1 0 0 5 4 5 5 tio
7 7 68811tio
8 8 5 4 4 avio
9 2 0 8 8 8 3 2 avio
3 0 3 9 9 2 avio
94125 63k*sec
6 4 9 4k * s e c
2 6 2 6k* sec
1 2 0 0 2 1 8 4 5 3 3 k * sec
1 0 6k
System Accounting
0 . 4 3 cpu
0 . 2 4 cpu
0 . 2 l cpu
0 . 1 6 cpu
0 . 1 5 cpu
0 . 1 5 cpu
0 . 1 3 cpu
0 . 1 2 cpu
0 . l l cpu
1 1 5 . 2 8re
1 6 2 . 8 8re
6 6 . 9 l re
0 . 2 6 re
l . 5 6 re
3 5 5 3 . 8 9 re
1 2 . 7 9 re
2 2 . 6 0 re
1 4 8 0 . 5 8re
2 1 8k
3 0k
l lk
4 6k
1 2 8k
2 3 4 6 8 8avio
1 9 1 4 8avio
4 3 5 0 0 8avio
2 9 2 7 avio
1 0 4 1 2 avio
1 5 2 avio
2 3 1 9 4avio
7 1 4 6 7avio
2 2 1 6 8 0avio
sendmai *
Connection histories can be displayed using the BSD ac and las t
commands or the SYSV a c c t c onl and l a s t l og ( SYSV ) commands.
The ac and a c c t c onl commands can tally connection times by day
or for the interval of time covered by the /var I adm/wtmp file. The
l a s t and l a s t log commands can be used to display the login times
for all users or an individual user.
JI ac -p
dero e s t
0 . 46
264 . 16
487 . 54
9961 . 55
1453 . 22
5 . 45
0 . 09
JI ac -d
Sep 0 1
Sep 0 2
Sep 0 3
Sep 0 4
Sep 0 5
Sep 0 6
Sep 0 7
Sep 0 8
Sep 0 9
jl l a s t - 2 0
pts / 9 2
pts / 8 6
pts / 7 5
pts / 5 6
269 . 68
613 . 75
914 . 32
1110 . 79
1103 . 98
1058 . 19
1060 . 23
933 . 98
944 . 53
xtreme . sar . washi
xceed . brm . washin
redy . aal . washing
10 : 41
10 : 07
10 : 00
08 : 23
s t i l l logged i n
s t i l l logged in
- 10 : 22 ( 00 : 21 )
s t i l l l ogged i n
Exhaustive command usage information can be generated using the
BSD l a s t c omm command. Like sa, this command supports a large
number of flags to filter the output. Be aware that it will also use sig­
nificant system resources when invoked!
jl lastcomm
s endma i l
s endi t
s endma i l
s endma i l
sendma i l
deroe s t
dero e s t
c sandahl
0 . 01
0 . 02
0 . 02
0 . 01
0 . 01
0 . 08
0 . 05
0 . 11
0 . 01
10 : 58
10 : 58
10 : 57
10 : 57
10 : 58
10 : 58
10 : 58
10 : 58
10 : 58
Users and Security
sendma i l
gr cm
0 . 03
0 . 16
0 . 02
0 . 02
0 . 01
0 . 01
10 : 58
10 : 58
10 : 58
10 : 58
10 : 58
10 : 58
Summary reports
A standard set of reports is produced at intervals by the runac c t and
mona c c t commands. These commands are run by the default adm
and root crontabs. The summaries and reports are recorded in the
following / var I adm subdirectories:
Daily files used by runacct
Daily summaries created by runacct
f i scal
Monthly summaries created by monacct
Reports and data files of interest include:
n i te / l ineuse
Line usage statistics for serial ports
n i t e / dacct
Daily disk accounting records
nite/ reboots
List of system reboot times
sum/ tacct
Total accounting summary
sum/ ems
Command use summary
sum/ loginlog
Last use time for user accounts
sum/ rprt<mmdd>
Daily summary report
f i scal / cms<n>
Fiscal command summary
f i scal / tacct<n>
Fiscal total accounting summary
Periodic House Clean ing
Turning on system accounting is a little like opening the flood gates.
On an active multiuser system, accounting can generate a large
amount of data that must be filtered and archived as part of your reg­
ular housecleaning activities. The default accounting procedures spec­
ified in the adm and r o o t crontabs periodically close and rename
accounting files to assist in managing the data. It is left up to the sys­
tem administrator to implement procedures to archive and clean up
the old data files. It is a good idea to restart the accounting system
daily to keep accounting files from becoming to large to manage.
What information should be saved for posterity? You can take the
conservative approach and save everything, reports and data files, or
throw caution to the wind and delete the files on a daily basis.
Moderation suggests that it might be wise to periodically compress
and archive the summary files and keep a copy of the previous day's
data files on-line for short-term history queries.
System Accounting
lnfoExplorer Keywords
ini t
pac c t
up t ime
nul l adm
a c c twtmp
s t artup
runa c c t
turnac c t
ac c t on
/ e t c / ac c t / ho l i days
shutac c t
/ e t c / f i l e sys t ems
c ron
c rontab
charge f e e
l a s t c omm
/ var / adm/ f e e
acc tmerg
mona c c t
Data collection and configuration files:
/ var / adm/wtmp
User, system events
/ e t c / utmp
User access times
/ var/ adm/pacc t
Process account file
/ var/ adm/ dtmp
Disk usage
/ var/ adm/ Spacct . <mmdd>
Daily active process data from runacct
/var / adm/qacct
Print usage data
/var / adm/ c tmp
Connect session data
/ et c / ho l i days
Define accounting shifts
/ var / adm/ acc t / { nite f i s cal sum}
Accounting summaries
/ var / spoo l / cron / c rontabs / adm
Accounting crontab
Collection and reporting:
runacct , turnac c t on , accton
Start system accounting
shutac c t , turnac c t o f f , accto f f
Stop system accounting
Filter account data
ac , las t ,
History data
System Tu n i n g
and Recovery
Backu p and Copy Uti l ities
System Backups
How much is your time and your data worth to you? How many times
have you erased what you thought was an unnecessary file only to
discover a week later that it contained some vital piece of informa­
tion? Even the most meticulously maintained system will be subject
to disk failures. A regular schedule for system backups will signifi­
cantly reduce the cost and frustration related to data loss problems.
Believe me, you will rest easier each night!
Backup Strategies
When defining a backup strategy, tradeoffs must be made between
the time and cost of performing the backups and the level of data
recovery that is required. For single-user workstations, the worksta­
tion owner has a good idea when a backup should be made to protect
critical data. Even in the single-user environment, it's a good idea to
develop a discipline for performing regular backups. Large multiuser
systems have very dynamic file update characteristics which make it
difficult to perform backups on an as-needed basis. Careful thought
must be devoted to implementing backup policies that meet the needs
of a large and diverse user base.
Backup policy considerations:
Which file systems are backed up and how often
Backup while file systems are mounted or unmounted
Full and incremental dump schedules
Size of file systems
Media types
Media rotation schedule
System Tuning and Recovery
Backup verification schedule
Off-site storage
Bandwidth considerations for network-based backups
Backup program and format to be used
Restore procedures
Data protection and privileges
What and when
With the price of storage at one dollar a megabyte and falling, it is
awfully easy to keep throwing disk packs at storage bottlenecks. The
problem is that you end up spending all your time backing up this
proliferation of disks. Vendors don't want you to stop buying disks, so
you need to take a harder look at which file systems actually need to
be dumped.
Root file systems, like / u s r and I , tend to be static in nature and
may be replicated on a number of machines . Thus, they may not
require dumping as often as dynamic file systems, such as those con­
taining user home directories and work areas.
Mounted or unmounted
To guarantee data integrity, a file system should be sync ' d and
unmounted during backup. Environments that require 24-hour by 7day-a-week availability may find this procedure difficult to live with.
You can perform dumps while a file system is mounted and in use;
however, you run the risk of missing data block updates in progress
during the dump. A number of shops, including my own, run dumps
on live file systems. For the most part, we have not experienced a
large number of problems. As a rule, it is not a good practice to dump
a live file system if you can avoid it. There are some commercial back­
up packages available that perform a checksum on each file during a
live backup to ensure data integrity. Fancier storage servers, like the
IBM 705 1 Dataserver, also allow you to copy or mirror a file system,
take the copy off-line, then back it up. High file system availability
requirements mean that you either spend a little more money for
duplicate storage or you cross your fingers and hope that a missed
block isn't yours.
Tune your file system sizes to match the backup media and time con­
straints. Very large file systems require frequent manual interven­
tion to mount new media and thus more time to dump. It also means
more media must be scanned when doing a restore. You know, the
Backup and Copy Utilities
file you wanted restored is always the very last one of a 20-reel back­
up set.
Consider using devices that provide hardware data compression or
use a compression program like c ompre s s or pack to compact data
on the media. Software compression will take additional time, but the
additional time may be offset by media utilization costs.
Full and incremental dumps
Time and money always being the deciding factor, it's not practical to
run a full file system dump every day. What you really want is to run
a periodic full dump followed by daily incremental dumps of the
changes made against the full dump. Most UNIX backup commands
implement this feature using a set of dump levels, 0 through 9. A
level 0 dump represents a full dump. Levels 1 through 9 are the incre­
mental dumps that represent file system changes against the previ­
ous less-than or equal-to dump level.
Level 0
Full dump
Level 1-9
Incremental dumps
Backup schedules and rotation
There are many strategies you can use to rotate between full and
incremental dumps to optimize media utilization and dump wall clock
time. The tradeoff here is media utilization and complexity. On the
simple side, a weekly level 0 full dump can be followed by daily level 1
dumps. When a restore operation is requested, the level 0 is consult­
ed, followed by the most recent level 1. Simple, but not very elegant.
To optimize media utilization and dump time, one of the more com­
plex rotation strategies like the Towers of Hanoi sequence may be
u s e d . I must admit , I have always hated the Towers of H anoi
sequence after having to sweat over the algorithm in Computer
Science 101. Nevertheless, it provides a very good rotation mecha­
nism, and it saves on tapes.
The Towers of Hanoi sequence involves a new level 0 dump for each
file system, followed by five sequences of level 1 through 9. Four sets
of level one tapes are used for each file system. Tapes for levels 2
through 9 are reused and it is assumed that levels 2 through 9 will fit
on one tape.
Towers of Hanoi dump level sequence:
Dump type
Dump level number sequence
Complex dump sequences can be tracked through the use of the
/ e t c / dumpda t e s file. The dumpda t e s file records the file system,
System Tuning and Recovery
dump level, and time stamp. The -u flag provided by the backup and
rdump commands will update the time stamp each time a backup is
run .
/ e tc / dumpdates :
/ dev/ rhdl
/ dev/ rhd2
/ dev/ rhdl
/ dev/ rhd2
/ dev/ rhd4
/ dev/ rhd9var
/ dev/ rhd4
/ dev/ rhd9var
/ dev/ rlvO O
/ dev/ rlvO O
30 02 : 10 : 56
3 0 02 : 04 : 2 5
3 03 : 2 5 : 15
1 03 : 23 : 12
2 0 02 : 00 : 04
2 1 02 : 3 0 : 59
30 02 : 00 : 04
30 02 : 09 : 33
1 04 : 24 : 41
3 0 02 : 17 : 2 5
The sequence o f dump levels can b e automated using cron.
Backup-level crontab:
/ e t c / backup
/ etc /backup
/ e t c /backup
/ e tc /backup
/ e t c /backup
/ etc /backup
/ e tc /backup
-uf / dev/ rmt O . 1
-uf / dev / rmt 0 . 1
-uf / dev/ rmt 0 . 1
-u f / dev/ rmtO . 1
-uf / dev/ rmt 0 . 1
-uf / dev/ rmt 0 . 1
-uf / dev / rmt 0 . 1
Disaster recovery and validation
It follows that while you are safeguarding your file systems, you will
also want to safeguard the backups themselves. First and foremost,
you should periodically test your backup sets by performing a restore
operation. Verify that the backup media is good and that the data is
valid. This will eliminate the problem of backing up bad data.
Periodically rotate a full set of backup media off-site. Disasters can
range from the file level to the building and city level.
Regularly cycle the media through a physical cleaning and valida­
tion check. This will include periodic maintenance and cleaning of the
backup devices.
24.2. 7
Backup media
Choose backup media that fit your environment. I think we all agree
that it doesn't make much sense to back up 500 MB of file system
space using diskettes. Careful consideration must be given, weighing
media cost, transfer rate, and storage capacity. Larger shops might
opt for optical storage or robotic jukeboxes. See Chap. 7 for informa­
tion on the various tape media characteristics.
Backing Up a File System
The AIX backup / r e s tore commands are very similar to their BSD
dump / r e s t ore counterparts. backup can be used to dump entire file
Backup and Copy Utilities
systems, as well as to support a backup by name for dumping subdi­
rectory trees. The following examples demonstrate a file system full
dump and backing up a subdirectory tree by name:
# backup -0 -u - f / dev/ rmt 0 . 1 /usr
# f ind /usr/ local -print I backup - i -f / dev/ rmt 0 . 1
Restoring Files and File Systems
The res tore command options are similar to those used by backup.
If you have problems remembering the path name of a particular file
you wish to restore, you can use the t flag to output an index of the
files on the tape. You can also use the - i flag to run res tore in an
interactive mode for file system inode dumps. This allows you to move
around the directories stored on the tape similar to the way you
would with directories on a disk.
# res tore -T - f / dev/ rmt 0 . 1
Display media index
# restore - r - f / dev/ rmt O . l
Restore full file system
# res tore - f / dev/ rmt0 . 1 -xdv bin
Restore file in bin directory
# restore -i - f / dev/rmt O . l
Start interactive restore
Other Dump Utilities
The tar and cpi o utilities can be used when portability is an issue.
Both tar and cpi o will allow you to copy files and directory trees
between systems, preserving uids and permissions. In some cases, tar
will not span multiple volumes. Use cpio on SYSV UNIX machines
where tar is not available.
# tar - cvf / dev/ rmt 0 . 1 . / source
Copy to tape
# tar -xvf / dev/ rmt 0 . 1
Restore tar archive
# f ind . -print
cpio - ov > / dev/rmtO
# cpi o - ipdmv < / dev/ rmt 0 . 1
Copy to tape
Restore cpi o archive
If you have the disk space to spare, you can copy a logical volume
using the cpl v command. This mechanism could be used to create a
file system copy for backup, leaving the primary copy on-line.
# cplv -e <Exi s t i ngLV> <SourceLV
Copy a logical volume
Operating System Dumps
To backup AIX rootvg filesystems, consider using the mksysb com­
mand. mksysb creates a tar image of root file systems, complete with
file system descriptions that can be used to restore from the stand­
alone maintenance system. Invoke the mks z f i l e to create a f s . s i z e
table that describes the rootvg file systems. Edit f s . s i z e to include
System Tuning and Recovery
only those file systems to be used for restore purposes. Run the mksysb
command to create the backup image.
Create mksysb image:
1. mks z f i l e
2. Edit . f s . s i z e
3. mksysb / dev / rmt O
A series of documents is available, via anonymous ftp from the
University of Virginia, that describe a number of problems encountered
when creating roo tvg dumps. See pub / rs 6 0 0 0 / roo tvg . restores
on uvaarpa . virginia . edu.
Network Backups
What about using the network to back up remote workstations onto
machines equipped with high-capacity tape drives? You can do this by
using the rdump and rre s tore commands. rdump and rre s t ore are
very similar to the b a c kup and r e s t o r e commands previously
described. They share many of the same flags and parameters. The
primary difference is that they use a remo t e_ho s t : devi c e argu­
ment to the - f flag, which designates the host name of the machine
equipped with the backup device.
# rdump -u - 0 -f daf fy : / dev/ rmt 0 . 1 /home
# rres tore -x -f daf fy : / dev/ rmtO /home
Another network-based option is to use the remote shell command,
rsh, with one of the local backup or copy commands. You can use rsh
with pipes and redirection to obtain results similar to rdump and
rre s tore.
tar cvf - . /home I rsh j udy " dd o f = / dev / rmtO obs = 1 0 2 4 "
rsh j udy " dd i f = / dev / rmtO ibs = 1 0 2 4 " I ( cd /home ; tar xvf -
In either of these cases, if you do not wish to be prompted for a
password on the remote system, create a . rhos t s file in the $ HOME
directory of the remote user ID being used for the remote shell. On
each line of the . rho s ts file, enter the name of each machine and
user ID that are allowed to connect without providing a password.
The Whole Nine Yards
The preceding information, combined with Chap. 7, describes the tra­
ditional tools used to manage UNIX tapes and backups. These are a
long way from the features supported by the mature proprietary
backup packages available on other operating systems . The vendor
community is quickly filling this gap. A number of very good packages
Backup and Copy Utilities
are available, complete with features like label validation, multivol­
ume support, and tape librarian interfaces. See "Taming the Backup
Beast," RS / Magazine, vol. 2 , no. 2, Feb. 1993 , for details on a number
of vendor packages which are supported under AIX .
24.1 O
lnfoExplorer Keywords
c omp r e s s
/ e t c / dumpda t e s
bac kup
cp i o
r dump
c ron
r e s t ore
mks z f i l e
rre s t ore
. ts . s i z e
f ind
. rho s t s
System backups
Backup and restore:
Set file system dump
dates and levels
/ e t c / dumpdat e s
backup - < l evel > -u - f <media> < f i l e - system>
Back up file system
where l evel
Full dump
Incremental dumps
1 -9
f ind /usr/ local -print
backup -i - f <media>
Back up by name
res tore -T -f <media>
Display media index
restore -r -f <media>
Restore file system
res tore - f <media> -xdv < f i l e J dir>
Restore file/directory
restore - i -f <media>
Interactive restore
tar , cpio
Archive commands
cplv - e <Exi s t ingLV> <SourceLV
Copy a logical volume
roo tvg backup:
mks z f i l e
roo tvg backup
fs . s i z e f i l e for mksysb
Network backup:
rdump -u < l evel > -f <ho s t > : <media> < f i l e - sys >
Network dump
rrestore -x - f <hos t> : <media> < f i le- sys>
Network restore
System Mon itori n g
and Tu n i ng
Know Your Workload
You've heard the following advice many times. Before you can begin
to tune your system or recommend adding resources, you have to
know what the workload profile is and what level of response is
expected. You have to accurately define the performance goals in
order to achieve them!
Begin with a good understanding of how the operating system man­
ages its resources . Document the throughput limits of the physical
resources (hardware, peripherals, network). Next, characterize the
workload as single- user workstation, m ultiuser time sharing, or
batch I network server. Identify and prioritize critical applications and
the resources they require. Look for areas of contention. It may be
that partitioning workloads by shift or by machine will solve particu­
lar resource bottlenecks. Now begin monitoring the system under real
and modeled workloads. This requires some knowledge of the tools
available and their characteristics. Gather and review all the data to
determine where adjustments or additional resources are required.
Sounds easy doesn't it?
Since it's your workload, applications, resources, and performance
expectations, I'll concentrate on AIX OS characteristics and the avail­
able tool sets . Hardware characteristics are described in chapters
related to the particular devices.
AIX Operating System Characteristics
CPU scheduling
A good deal of CPU resources can be saved by painstakingly profiling
and tuning application code. Even though you may not have the luxu391
System Tuning and Recovery
ry or source code, the AIX tpro f profiler can give you a very good
idea of where the application is spending its time.
As described in Chap. 16, the AIX scheduler uses a set of 128 run
queues to prioritize active processes. Lower-numbered queues are
scheduled more often than those with higher numbers; thus, they
receive a larger share of CPU resources. Processes in a common prior­
ity queue are scheduled round robin. After execution, the process
returns to the end of the line.
Process priorities are based on the sum of the short-term CPU usage
(O to + 100), process nice value (O to 40), and the minimum user
process level. At each reschedule time quantum, the short CPU usage
is updated and new priorities computed for processes in the ready-to­
run state. Processes burning higher CPU usage levels will have their
priority number increased, dropping their relative priority to other
processes. Any process with a priority value greater than 120 will only
be run when no other process in the system requires the CPU.
Process rescheduling can occur at every clock tick. Unless a process
is preempted, blocked, or terminates, it will consume its CPU quan­
tum (up to 10 ms) and be rescheduled at the next clock interrupt.
Proce s s e s tend to spend their time in either the runnab l e or
b l ocked state.
Because priorities tend to float up and down, the ni c e command
doesn't provide an adequate hammer to control process priorities.
Some degree of success can be accomplished by implementing a dae­
mon that periodically checks CPU usage and scheduler priority, then
reni c e s jobs to favor critical applications. AIX also provides a s e t ­
p r i ( ) system call that can be used t o fi x the priority level o f a
process. This is especially useful for real-time applications. Care must
be taken in multiuser workloads that fixing a process priority above
60 (lower number) does not adversely effect interactive response.
25.2.2 Virtual memory management
The virtual memory manager's (VMM) job is to allocate memory for
process active working sets and recover stale or unused memory
pages. The latter requires that some process pages be moved from
memory to secondary storage (paging space). Even in well-tuned sys­
tems, some amount of paging activity will usually be taking place.
The VMM in AIX 3 . 2 has been enhanced with the addition of
process swap support. AIX 3.2 uses a lazy swapping technique that
keeps the system from swapping processes when memory is not con­
strained. If a thrashing situation is detected, AIX suspends the
processes that are responsible. The offending process pages become
stale and are paged out. If thrashing continues, new processes are
suspended as well. When the memory becomes available, the sus­
pended processes are reactivated.
System Monitoring and Tuning
The ADC 3.2 VMM enhancements also include the differentiation of
computational memory and file memory. As you would expect, compu­
tational memory defines those pages that belong to a program's work­
ing set, and file memory makes up the rest. The VMM maintains a
repage fault history for each of these memory types, which is then
used to determine if a thrashing condition exists. A repage fault rep­
resents a recently read page from disk that has been referenced and
is not found in memory. The VMM looks at the computational and file
repage rates to determine which type of page should be stolen in a
constrained situation.
You may tune the following set of memory load parameters to rep­
resent your workload's computational and file memory requirements.
An example application for tuning these parameters called s ched­
tune is available in / u s r / lpp / bos / examp l e s . Care must be taken
when modifying these parameters . Use s chedtune in conjunction
with rms s to model memory loading. The rms s command allows you
to simulate real memory configurations on the running system.
h-Memory commitment high water mark
w-Wait time before reactivating suspended procs
p-Process memory high water mark
m-Minimum active processes
e-Time exempt from suspension
Memory is overcommitted when:
# page writes in last second 1
# page steals in last second
> -
A process is considered to be thrashing when:
# repages in last second
# page faults in last second
Make sure you have adequate paging space available. The actual
amount required is going to depend on your workload. I generally use
a 3-to- 1 ratio of paging space to real memory. Paging space should be
distributed across multiple volumes if possible.
Disk 1/0
You may recognize the situation on many UNIX systems when a
process creating large write queues holds up processes attempting to
read. These large write queues can exhaust the file system free lists
and hold up the reads required to replenish the free list, making the
problem worse. ADC 3.2 provides a facility to control file output queue
System Tuning and Recovery
contention through the use of high and low water marks, maxpou t ,
and minpout. When a process writing t o a file hits its high water
mark, that process is suspended until the queue drops to or below the
low water mark. This facility is called I I 0 pacing. IIO pacing will
allow you to manage the tradeoff between interactive response and
I/O throughput. The default maxpout and minpout values of " O " dis­
able I/O p acing. You can set the se parameters using the SMIT
chgsys fast path. (See Fig. 25. 1).
II smi t chgsys
The AIX asynchronous I I 0 facility can be used to improve I/O per­
formance for applications that are heavily I/O bound. Asynchronous
I/O routines must be added to the application source code and the
application rebuilt. These routines allow the application to continue
proces sing rather than being blo cke d during 1/0 o p e r ati o n s .
Notification o f 1/0 completion is posted as a n event b ack t o the
process. The application can poll for these events to keep track of data
written to disk.
Network performance
If you have spent any time administering large networked multiuser
or application server systems, then you have experienced the dead­
end situation of no more mbu f s . mbuf structures are used to store
Change I Show Charac ter i s t i c s of Operat ing Sys tem
Type or select values in entry f i elds .
Press Enter AFTER making a l l des i red changes .
Maximum number of PROCESSES a l l owed per user
Maximum number o f pages in block I/O BUFFER CACHE
Maximum Kbytes of real memory a l l owed for MBUFS
Automati cally REBOOT sys t em a f ter a crash
Continuous ly maintain DISK I / O history
HIGH water mark for pending wri t e I / Os per f i l e
LOW water mark f o r pending wri t e I / Os p e r f i le
Enable memory SCRUBBING
Amount of usable phys ical memory in Kbytes
Primary dump device
Secondary dump devi ce
Error log f i l e s i z e
State o f sys tem keylock at boo t time
S i z e of data cache in bytes
Size o f ins truc t i on cache in bytes
F l = Help
Esc + 5 = Undo
Esc + 9 = Shel l
Figure 25.1
F2 = Re f resh
Esc + 6 = Command
Esc + 0 = Exi t
F3 = Cance l
E s c + 7 = Edi t
Enter = Do
SMIT operating system parameters panel.
[ 2 048 ]
/ dev/hd7
/ dev/ sysdumpnul l
F4 = L i s t
Esc + 8 = Image
+ II
+ II
+ II
+ II
System Monitoring and Tuning
data moving between the network and the operating system. In most
cases, when you hit the mbuf wall, you had to increase the kernel
parameter for mbufs and/or mbclusters , rebuild the kernel, and
reboot. This is real bad news for your up-time statistics.
AIX provides an mbuf management facility that dynamically con­
trols the allocation and use of mbufs and mbclusters. The default allo­
cation is based on a low to medium packet rate and is somewhat
dependent on the number of adapters. The mbuf management facility
netm uses a set of parameters to control the minimum and maximum
available free space in the pools, and the maximum amount of memo­
ry that may be used for the pools. Note that the mbuf and mbcluster
pools are pinned in memory. netm increases the pool sizes as network
load increases. The mbcluster pool is reduced as load decreases; how­
ever, the mbuf pool is never decreased. Each mbuf is 256 bytes in size
and each mbcluster is 4096 bytes.
You don't want netm to be dispatched unnecessarily, and you don't
want to overcommit memory to mbuf pools. What you need to do is
monitor your packet rates under normal loads and adjust the mbuf
parameters at boot time to pin as much memory as you will need and
no more. You can modify the following mbuf parameters with the no
command. Build a script which is run at boot time to set the parame­
ters and execute a packet spray program or ping in a loop to generate
enough network traffic to pin the memory required.
l owrnbu f
Free mbuf low water mark
lowc lus t
Free mbcluster low water mark
mb_c l_hiwat
Max number of free clusters
thewa l l
Max memory available mbufs and clusters
Some network environments require modification of other kernel
network parameters like time to live and keep alive values. The no
command can be used to display and set a number of these kernel
network parameters.
II no -a
dog_t i cks
l owrnbu f
thewa l l
mb_c l_hiwat
compat_4 3
maxt t l
ipfrag t t l
ipsendredirec t s
tcp_t t l
arpt_ki l l c
System Tuning and Recovery
tcp_s endspace
udp_s endspace
l oop_check_sum
r fc l l 2 2 addrchk
nonlocs rcroute
1 6 3 84
AIX Monitoring and Tuning Tools
UNIX tools
uptime and rup provide system load averages and the current number of
users. These are quick, one-stop commands to get a brief picture of system
ps displays process table statistics. Don't underestimate the information
you can get from ps . AIX supports both SYSV and BSD options. You can
easily set up shell aliases with ps to get quick information on the top CPU
and storage users on your system. Use it to check for defunct processes
which may be tying up memory.
sar is the system activity recorder. Along with sadc , sal , and sa2 , it can
be used to snapshot system activity for all or specific system resources at
specified intervals. Use cron to regularly execute sar at specific times
based on your workload profile, and the sal, sal scripts to maintain a
report history of system usage.
vms tat
vms tat provides statistics on process queues, memory, paging, interrupts,
and CPU usage. You can run vms tat at specified intervals and repetitions
to take a quick look at memory and CPU usage.
ios tat is similar to vms tat in that it can be run for specified intervals and
a number of repetitions. It provides usage statistics on CPU, and the I/O
subsystem. Using the -d flag will display a snapshot of disk I/O activity.
pstat is similar to crash in that it allows you to display the contents of var­
nets tat
nets tat provides various information on network activity. The -m flag can
ious systems tables. It is not interactive.
be used to review mbuf allocation. There are options to display routing
tables and current connections statistics.
acct ems
t ime
nfsstat displays information concerning NFS and RPC interfaces. You
may distinguish between client and server information, and between NFS
and RPC traffic.
ace tcom and ace terns process and display system accounting information
from the /usr I adm/pac c t file. acctcom provides a detailed process
chronology by user. ace t erns combines identical process information to give
you overall system totals.
If you have tracked down resource untilization problems to a specific applica­
tion, these tools provide a means of profiling and tuning the code. t ime and
timex can be used to snapshot the user, system, and wall clock execution
times. gprof will provide CPU usage by subroutine and a call graph profile
of the application. Note that you must compile the code with the -pg option.
System Monitoring and Tuning
AIX 3.2 tools
trcrp t
trace and trcrpt allow you to record and report on system events at a
finer granularity than any of the other performance tools in this set.
System events are time stamped such that the sequence and context of
execution is maintained. The trace facility does not cause significant
additional overhead to the running system. System tracing is started and
stopped using the trcon and trc s t op commands.
rmap is run against the log data produced by trace and trcrpt to
extend the analysis of processes and 110 activity. rmap requires a cus­
tomized configuration file that specifies the input data and report options.
f i l emon
f i l emon is also run against trace data to provide statistics on file system
performance. It provides detailed information on the most active files,
logical volumes, and physical volumes in the system.
f i l eplace
f i l eplace maps the placement of file blocks within logical and physical
volumes. It indicates the level of fragmentation for files in a file system.
rms s
rms s is a tool that will allow you to simulate reductions in available real
memory on the RS/6000. This tool is quite useful when monitoring the
behavior of an application in a memory-constrained situation.
svmon displays a snapshot of virtual memory. Note that it is not entirely
accurate because it is run in user state with interrupts enabled.
netpmon also uses trace data to monitor network activity. netpmon is a
new version of what was formally known as netmon in older versions of
AIX. It gathers statistics on CPU usage, device driver queue lengths and
utilization, socket calls, and NFS 110 calls.
l s lv
lved i t
tpro f
l s lv, lvmake, lvedi t, lvextend, and reorgvg provide finer-grained
control over the definition and allocation of logical and physical volumes
in the system. They are quite useful when tuning the placement of data­
tpro f , like its predecessor gpro f , is used to profile CPU usage by sub­
routine in an application. tprof does not require that the application be
recompiled, but will provide additional information if the application is
compiled with the - ql i s t option.
Performance Tool Box/6000 and Performance Aide/6000
To augment the base AIX tuning and monitoring tools, Performance
Tool Box I 6000 (PTX/6000) and Performance Aide I 6000 (PAIDE/6000)
can be installed on the RS/6000. The PTX/6000 Motif GUI is used to
adjust and graphically display monitor data provided by PTX/6000
tools, AIX tuning and monitoring commands, PAIDE/6000 data, and
SNMP data. PTX/6000 can be used to tune a networked cluster of
machines through a real-time 3-D graphical display of configuration
and performance data.
PAIDE/6000 is a prerequisite product to PTX/6000 that provides
additional local performance data, filters, alerts threshold manage­
ment, and an API for retrieving raw system statistics. PAIDE/6000 can
also be configured as an SNMP subagent in a networked environment.
System Tuning and Recovery
AIX Capacity Planner-BEST/1 for U NIX
The AIX Capacity Planner, based on the BGS System's BEST I 1 for
UNIX product, can be used to collect and partition performance data
for capacity planning purposes. The tool can be used to collect statis­
tics from networked systems, analyze the performance and workload
information, then model and predict growth trends. Like PTX/6000,
the BEST/1 product uses a Motif-based GUI to configure and display
data collection and results. It provides an excellent facility for devel­
oping and testing what-if scenarios. BE ST/1 is also available for
AS/400 environments.
Public domain monitor package
If you're on a budget, take a look at the public domain monitor pack­
age written by Jussi Maki. The package provides pseudo-real-time
statistics on CPU, memory, and 1/0 utilization and rates. An ASCII­
based interface allows it to be used with most display types. The mon­
itor system may be downloaded via anonymous ftp from a i x ­
pds l ib . seas . uc l a . edu. (See Fig. 25.2.)
# mon i t o r
Sys tem moni tor vl . a 6 . 1 : da f fy
Tue Sep 1 4 l a : 3 5 : 5 3 1 9 9 3
Refresh : 1 a . a 6 s
Sys 3 1 . 3 % Wai t a . 1 % User 6 . 8 % Idle 6 1 . 8 %
= = = = = = = = = = >>>> . . . . . . . . . . . . • .
Runnabl e processes 1 . 4 9 load average : 4 . a ? ,
Swap- in processes a . a a
1 . 6 MB
1 2 8 . a MB
Di skIO
hdi ska
hdi skl
hdi sk2
a . 65 ,
a% a
a% a
a% a
Monitor panel.
a . a pgsin
a . a pgsout
Process event s
2 1 3 pswi tch
1 6 8 a sys c a l l
4 3 read
34 wri t e
a fork
a mdmint
Figure 25.2
a . 21
Paging ( 4 kB )
4 . 3 pgfau l t s
a . a pgin
a . 2 pgout
2 a 2 . 6 MB
4 8 a . a MB
wri t e
a . 8 kB / s
a . a kB / s
a . a kB / s
F i l e / TTY- I O
3 iget
1 namei
a dirblk
11 . 2
wri tech
wri t e
a . a kB / s
a . a kB / s
System Monitoring and Tuning
Additional Help and Documentation
Take a look at the AIX 3 . 2 Performance Monitoring and Tuning
Guide, SC23-2365. This document contains a wealth of information
and examples. Your IBM SE can also assist in tuning and capacity
planning activities.
lnfoExplorer Keywords
tpr o f
t imex
reni c e
s adc
trcrp t
s e tpri
f i l emon
s chedtune
rms s
vms tat
f i l ep l a c e
i o s tat
ne tpmon
chg sys
n e t s tat
l s lv
n f s s tat
p ing
ac c t c om
lvedi t
rnbu f
ac c t cms
up t ime
gpr o f
t ime
System monitoring and tuning
Kernel parameters:
/usr/ lpp / bos / examples / s chedtune
Sample program to set kernel parameters
getpri ( J , setpri ( )
Set/query process queue priority
Simulate real memory
maxpout/ maxpin
Limit 1/0 pacing levels for writes
smi t chgsys
Set kernel parameters
Display/set kernel network paramters
More tools-see Sec. 25.3 . 1.
P roblem Ana lysis
and Recovery
When Things Go Bump in the Night
Do you ever wonder if there isn't a little gremlin lurking just behind
the front cover of your RS/6000? From time to time you just catch a
glimpse of two beady little eyes peering out of the diskette slot. You
do a double take, and nothing is blinking except one of the tape or
diskette lights. With a nervous shrug, you go ahead and fire up that
high-priority application you have put off until the very last minute.
Just at the critical point in your time line you notice an eerie flicker­
ing in the room. With a sinking feeling in your stomach, you look at
the front panel and there it is, the dreaded flashing 8 8 8 . Fingers
trembling, you press the reset button and stare at the play of glowing
numbers after each touch. Your luck continues to fail as the dump
LED reads O c 5 Sys tem dump attemp ted and f a i l ed. You power
down, pause to wipe the sweat off your brow and power cycle back up.
The numbers dance across the LED window. Is that a malevolent gig­
gling you hear? It can't be. You tell yourself that it's only too many
hours of overtime or one too many lattes. With bloodshot eyes you
wince at the glare from the LEDs and they pound into your head,
8 8 8 , 8 8 8, 8 8 8 . . .
Gruesome, isn't it? The only thing missing is "It was a dark and
stormy night." Don't get me wrong, I'm not insinuating that system
failures and panics are particularly commonplace on the RS/6000. As
a matter of fact, we have been using a model 530 on a 7-by-24 sched­
ule with very few outages for nearly four years. System failures do
happen, however, and they usually occur at the most inopportune
times. The trick is to make sure that you have your system logging
and recovery homework done before the gremlins begin playing with
your sanity.
System Tuning and Recovery
Backups and Bootable Media
Backups-If you don't have them, then none of the rest of this infor­
mation is going to do you much good. It's surprising how many calls I
get from users who are hoping for a miracle, one that will recover a
bad disk because they never took the time to do backups. See Chap.
24 for details on system backups.
Next, make sure you have multiple copies of stand-alone bootable
media that reflect your systems maintenance level. Notice I said mul­
tiple copies. I must admit that I have been bitten more than once by
having only a single copy of some crucial bit of data. Let's start with
the BOSboot diskettes. If you carefully read the AIX Installation
Guide, SC23-2341-05, there is a chapter on creating boot diskettes.
Note that the procedure is version-dependent, so make sure you have
the right documentation in hand. Basically you will create a set of
diskettes that contain a small bootable kernel, code to set your con­
sole display type, and the ADC installation/maintenance code.
Boot diskette
bosbo o t - a - d fdO
Display diskette
mkdi spdskt
Display extension diskette
BOS install/maint diskette
mki n s t dskt
Make certain that you test the diskettes after creating them. It will
bring you peace of mind and familiarize you with the stand-alone boot
Stand-alone Boot Procedure
1. Insert the boot diskette/tape and power on/reset.
2. At LED c 0 7 , insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select Maintenance option from the menu.
6. Select S t andal one Maint enanc e option from the menu.
7. Access the root volume group: getroo t f s hdi skO .
You can also create a bootable tape that contains a tar'd copy of
your r o o tvg with the mksysb command. The tape can be used to
recover from a disk failure or it can be used to install other machines.
Begin by using the mks z f i l e command to create a I . f s . s i z e file
which contains descriptive information about the file systems in the
roo tvg. You may edit this file so that it contains only those file sys­
tems you wish to recover. Next, run mksysb device to create the
bootable tape. When booting from the stand-alone tape, the AIX
Problem Analysis and Recovery
install/maint menus are displayed. These will guide you through
restoring the roo tvg file systems.
r o o tvg
Boot tape and
roo tvg
mks z f i l e
mksysb / dev / rmt O
LED Status
The story always begins with the dreaded flashing 8 8 8 on the LED
front panel. Before deciding to punt and hitting the power switch,
press the reset button to cycle through the set of four halt status
numbers. These numbers indicate the current system state, reason
for the halt, and the dump state. Write them down. You're going to
need them later in the analysis processes.
LED halt status sequence:
The first number following "888" on the LED display, represented by
bbb in the example, indicates the hardware built-in self-test (BIST)
status. In most cases the BIST status will read 102, which indicates
that BIST has started following a system reset. Other values may
indicate a hardware problem. The next number, represented by eee,
indicates the cause of the system halt. See Table 26. 1 . The last num­
ber in the sequence indicates the status of any dump associated with
the failure. (See Table 26.2.)
When a system fault occurs, an automatic dump of selected kernel
address regions are recorded on the dump device as defined in the
master dump table. The primary dump device is a dedicated storage
area for holding dumps. A shared secondary device may be defined,
which requires operator intervention. The default primary dump
device is / dev/ hd7 and the secondary device is sysdumpnu l l . Dump
devices are defined and managed using the sys dumpdev command.
TABLE 26.1
LED Halt Reason Code
Machine checks
Storage interrupt: processor
Storage interrupt: 1/0 channel controller
Storage interrupt: serial link adapter
Storage interrupt: instruction
External interrupt: DMA, bus error
External interrupt: IOCC checks/timeout
External interrupt: IOCC timeout
Program interrupt
Floating point unavailable
System Tuning and Recovery
LED Dump Status Codes
Dump successful
User dump in progress
Partial dump successful
Dump device not accessible
Prompt for secondary dump device
Remote dump in progress
No dump device defined
Dump in progress
Make certain that your dump device is assigned and is large enough
to contain at least one full dump.
# sysdumpdev - L
List current dump status
# sysdumpdev -1
List primary dump device location
# sysdumpdev
Assign dump device
Although it is acceptable to interrogate kernel dumps residing in
the primary dump area, it's a good idea to copy them onto an AIX file
system or removable media type. This will secure the data and free
up the dump area for problems lurking in your future. Use dd to read
from the raw dump device, or mount the dump device and use cp or
backup to copy the dump to alternate storage.
dd i f = / dev/ rhd7 o f = / dev / rmt 0 . 1
mkdi r / tmp/ dumpdev
mount / dev/ hd7 / tmp / dumpdev
cp / tmp / dump-dev/ dump-name / tmp / dump-name
ls / tmp / dumpdev I backup - i fv
You can force a system panic dump by using the sysdump s tart
command or by turning the key to the service position and pressing
the left-cntrl + alt + 1 keys simultaneously.
System Logs
Now that your disaster recovery media is in place, it's always nice to be
able to determine why you crashed in the first place. Start by looking
at the system error log. The error log file, /var / adm/ ras / errlog, is
updated by /usr / l ib / errdemon, which is exec'd at system start-up.
The error daemon reads system exception data from I dev I error and
creates entries in the log file based on templates from / var / adm / ras
/ errtmp l t and the message catalog / u s r / lpp / ms g / $ LANG / c ode ­
po int . cat. You can produce a report of entries in the error log by run­
ning the errpt command or via smi t errpt. Make sure that you save
and clean out error log data periodically so that problem information
doesn't get lost in the noise. You can accomplish both of these tasks by
Problem Analysis and Recovery
having cron regularly back-up the error log, and then clearing out old
information using the errc l ear command. There are also commands
that allow you to add your own error templates and messages to the
system for custom applications.
Create error log report
Clear error log
Stop errdemon
errs t op
Update templates
Add/display msg catalog
Modify msg catalog
err ins tall
Individual events in the error log report are identified by error type
labels. The labels are listed in the AIX Problem Solving Guide and
Reference, SC23-2204. Each error event is time stamped and contains
summary information by type. For example, suppose the LED halt
reason code was "700," indicating that a program interrupt caused the
crash. The error log should contain an entry labeled PROGRAM_INT,
time stamped with the date and time of the failure. The associated
detail data lists the segment, status, and state registers ( SRRs)
entries that point to the subroutine and instruction involved in the
failure. This information will be used when analyzing the dump.
Example error log entry:
Dat e / T ime :
Sequence Number :
Machine Id :
Node Id :
Class :
Typ e :
Resource Name :
Wed Dec 8 1 1 : 4 6 : 0 8
Error Descrip t i on
Program Interrupt
Probable Caus es
Fai lure Causes
Recommended Ac t i ons
Deta i l Data
Segment Regi s ter , SEGREG
0000 0000
Machine Status Save /Restore Register 0
0 0 0 5 3AC4
Machine Status Save /Restore Register 1
0002 0000
Machine State Regis ter , MSR
0 0 0 2 9 0 BO
System Tuning and Recovery
The next place to look is at messages created by sys l ogd. The
sys l ogd daemon receives messages via datagram sockets created by
applications which use the sys l o g subroutine. sys l ogd directs the
incoming messages to files or other systems as described by entries in
the / e t c / sys l og . c onf file. This file is read each time sys l ogd is
started or receives a HUP signal . Due to the application-specific
nature of sys l ogd, AIX provides an example / e t c / sys l o g . c onf
template which must be configured to your application requirements.
Each line in I e t c / sys log . conf contains message selectors separat­
ed by semicolons, followed by a field indicating where the message is
to be sent. Incoming messages specify a facility code that represents
one of the selectors. See / us r / inc lude / sys / sys log . h for a list of
codes and selectors. In the following example, mail messages are sent
to a central repository on another system called da f fy, all debug
messages to / var I adm/ debug . l og, kernel-critical and emergency
messages to /var / adm/ kerne l . l og, and alert messages are sent to
the op s user ID.
/ * * * * * * * * * * * Example / e tc / sys . l og . conf * * * * * * * * * * * * * /
@da f fy
mai l
/var / adm/ debug . l og
* . debug
/var / adm/ kerne l . log
kern . cr i t ; kern . emerg
op s
* . alert
Remember that for real-time debugging, you can always use the
system trace for even finer detail.
Start trace
tr con
Stop trace
trcs top
Generate trace report
AIX Kernel Structure
With the error log and LED status information in hand, we are ready
to examine the dump. First let's lay a little groundwork concerning
the characteristics of the AIX kernel. AIX is based on a preemptible
kernel. The kernel is divided into pinned and pageable regions. The
pinned low region of the kernel contains the interrupt handler, kernel
text and data areas, the process table, and page map. Pageable kernel
regions include the file table; vnode, gnode, and inode structures, and
kernel extensions. It is important to remember that activities and
services in the pageable kernel region are synchronous, whereas the
pinned region activities are asynchronous. For example, an external
1/0 interrupt may be serviced by the pinned region long after the
process initiating the request has completed its time slice and has
been paged out.
Interrupts are divided into processor and external interrupt class­
es. All 1/0 type interrupts are multiplexed into one external inter-
Problem Analysls and Recovery
TABLE 26.3
AIX Address Segments
Kernel segment (data and extensions)
Text segment
Private process segment (data, u-block, and stack)
VMM data
Shared libraries
1/0 support
rupt. External interrupts include 1/0 bus and system board devices.
External interrupts are the only interrupt class that can be masked.
Processor interrupts include system reset, machine check, storage,
program, alignment, floating-point, and SVC interrupts.
Memory addresses on the RS/6000 are based on a 32-bit effective
address and a 24-bit segment address. The first four most significant
bits of the effective address represent one of 16 segment registers.
The remaining 28 bits of the effective address are used along with the
24-bit segment address to indicate a position in virtual memory. See
Table 26.3.
Kernel and application address spaces are somewhat similar. For
debugging purposes, it is important to understand the general layout
of kernel regions. The exact addresses of kernel boundaries will be
dependent on the AIX release you are running.
Kernel symbols and addresses (3.2. 5):
Beginning of kernel
End of pinned kernel
Table of contents
End of kernel
Kernel extensions
Process table offset
It's a good idea to generate a complete listing of kernel symbols and
addresses for use when analyzing a dump. Use the run command on
the kernel object file associated with the dump.
-vfx /unix
Using crash
crash can be run in interactive or batch mode. Batch mode is useful
when you need to send a formatted dump to IBM Support. Use the
c r a s h - a option directed to a file to produce a formatted crash
dump. For an interactive session, invoke crash, specifying the dump
file or device and kernel file as arguments.
System Tuning and Recovery
# crash / dev /hd7 /unix
Interactive mode
# crash -a / dev/ hd7 / unix > / tmp / crash . MMDD
Batch mode
Useful c rash subcommands:
Display process blocks of all processes or a particular process.
Display u-block or u-area. If no process ID is given, the running process at the
time of the dump is displayed.
Offset to the nearest kernel symbol.
Display address of a symbol.
Display hexidecimal dump of memory.
Display traceback of stack.
Dump information.
Now you are ready to get down to business. Display the u-area of
the process running at the time of the dump by entering the u sub­
command without an argument (or nasty comments). A formatted dis­
play of the process private u-area is displayed. The first line of the
. display indicates the process name and process table address. Each
process table entry on the RS/6000 is OxlOO bytes in length. Subtract
the process table offset, OxE3000000 from the process slot address.
Ignore the lower two digits of the answer, and you have the process
slot number of the last running process. The u-block and process table
data will provide you with the process state, executing program, open
files, locks, controlling TTY, etc.
# crash / dev/ hd7
Using /unix as the defau l t name l i s t f i l e .
Reading in Symbo l s . . . . . . . . . . . . . . . . . . . . . .
Display u-block
USER AREA FOR xperfmon ( ProcTable Address OxE3 0 0 1 2 0 0 )
D o the arithmetic . . . . . . . . . . . . . . . . . . . . .
Process s l o t address
Process table off set
Ignore l ower 2 digits
Dec imal Process S l o t ID
>p - 1 8
OxE3 0 0 1 2 0 0
- OxE3 0 0 0 0 0 0
Oxl2 0 0
Di splay Process Table Entry
The trac e, nm, and ds subcommands are very helpful when diag­
nosing kernel problems. The trace subcommand provides a look back­
wards through the kernel stack. The nm and ds commands display
the address for a symbol or the symbol associated with an address
range, respectively. Error log and LED information may be more
helpful with kernel problems than the current running process infor-
Problem Analysis and Recovery
mation. For example, in the case of exceptions caused by an interrupt,
the process which requested the service related to the interrupt may
have been paged out while the request was being serviced.
In the event of a system hang, you may not have error log or LED
data to assist. The hang may be the result of a resource deadlock or a
looping process. If deadlock is suspected, check the proc_l ock and
ke rne l_l o c k symbols. Look at the RW values displayed by nm. A
value of "fftfffi'f" indicates that the lock is free, otherwise the value is
the PID of the process holding the lock. If a high-priority process loop
is responsible for the hang, then it is likely to be the last process exe­
cuting (if you're lucky).
For an addressing exception, use nm to locate the vmme rrlog struc­
ture. Check the vmm return code and fault address at offsets Ox20
and OxlC, respectively. Next, use trace to display the failing routine,
followed by ds to locate the offset within the failing routine. If the
exception was in a kernel extension, you may have to walk the kernel
load list, as kernel extensions are pageable.
Running down the culprit in a crash caused by an interrupt can be
a bit tricky. As mentioned earlier, the requesting process may have
been paged out. If segment register data was logged in the error log,
the address in SRRO will indicate the return address of the routine
that caused or is waiting for a program interrupt to be serviced.
External interrupt conditions will likely log the IOCC bus number
and interrupt level.
26. 7
Hardware Diagnostics
The RS/6000 is very good about checking its hardware during the
built-in self-test (BIST) at power-up time. Keeping track of the LED
information during system power up will assist you in debugging
hardware problems. If you suspect hardware problems or the system
won't boot, use the RS I 6000 Diagnostic Programs to assist in deter­
mining the failure. The diagnostic programs may be run in stand­
alone mode from diskettes, or in concurrent mode with AIX on-line,
using the diag command. For concurrent mode operation, as supe­
ruser, enter the diag command and follow the menu instructions.
Stand-alone mode is similar to booting from diskette as previously,
described. There are two different boot diskette s depending on
whether you have 8 MB of memory or greater than 16 MB. There is a
console display definition diskette, and several diagnostic diskettes
for testing and configuring adapters.
Diagnostic stand-alone mode:
1. With the system powered down, turn the key to service.
2. Insert either the 8-MB or 16-MB boot diskette per your config.
3. Turn the power switch on.
41 0
System Tuning and Recovery
4. At each c 0 7 LED prompt, insert the next diskette #.
5 . At the c 3 1 LED prompt, select the console.
6. Follow the diagnostic instructions displayed on the console.
While loading the diagnostic diskettes, if a c 0 2 or c 0 3 LED status
is displayed, you have either loaded the diskettes out of sequence or
inserted the wrong diskette, respectively.
Cal l i n g for Help
Once you have determined that a software or hardware problem
exists , collect all the pertinent log, dump , and LED information
before contacting IBM Support. You might also want to run the snap
and l s lpp -hBc > f i l ename commands to snapshot the mainte­
nance level and configuration of your system. If you have AIXtra
IBMLink access, review the problem and service information to deter­
mine if this is a previously reported and known bug. The more infor­
mation you gather, the faster your problem is going to be resolved.
You are now ready to contact IBM Support. If you don't like playing
telephone tag and have Internet or uucp access, I would suggest you
look into using the aixs erv facility. aixs erv is a problem-reporting
and feedback facility that is based on electronic mail. Initial problem
reporting is done via the aixs erv shell script that comes as part of
the facility. The script prompts you for problem description informa­
tion and then mails the information to AIX Problem Support. If you
would like more information on aixs erv, contact your local IBM
Support Engineer. You can also direct questions and comments to:
s ervi ces @aus tin . ibm . com
Those of you with IBM customer numbers can report problems the
old-fashioned way by using the telephone.
Software supp ort
Hardware supp ort
It's always a good plan of action to read the required texts as part
of the homework. Take a look at RISC System I 6000 Diagnostic
Programs: Operators Guide, SA2 3 -2 6 3 1 - 0 5 ; RISC System / 6000
Problem Solving Guide, SC23-2204-02; and AIX Version 3.2 for RISC
System / 6000 Installation Guide, SC23-2341-05.
l nfoExplorer Keywords
bosbo o t
mkdi spdskt
errc l ear
pan i c
Problem Analysis and Recovery
26.1 O
41 1
errs t op
mk ins t dskt
errupda t e
sys dump s t a r t
g e t ro o t f s
err ins t a l l
mks z f i l e
sys l ogd
. fs . size
/ e t c / sys l o g . conf
t r c on
/ var / adm/ ras / errlog
t r c s t op
Problem determination
Stand-alone boot diskettes:
bosboot -a -d fdO
Create boot diskette
mkdi spdskt
Create display diskette
Display extensions
Install/maint diskette
Stand-alone boot procedure:
1. Insert the boot diskette/tape and power on/reset.
2. At LED c 0 7 , insert the display diskette.
3. When prompted, select the console display.
4. Insert the BOS install/maint diskette and press ENTER.
5. Select Maintenanc e option from the menu.
6. Select S t and- a l one Maintenance option from the menu.
7. Access the root volume group: getroo t f s hdi s k O .
roo tvg backup:
mks z f i l e
mksysb <media>
Back up roo tvg
f s . s i z e file for mksysb
System error logs:
Error daemon
Error log report
errcl ear
Clear error log
err s t op
Stop error daemon
errupdate , errmsg , errins tall
Update error message catalogs and tem­
/var / adm / ras / errtmp l t
Error message templates
/usr/ lpp /msg / $ LANG / codepo int . cat
Error message catalog
System Tuning and Recovery
System trace:
trcon ,
trcs top
Start/stop tracing
Gererate trace report
System dumps:
Set/display dump device
sysdumps tart
Force a panic dump
Retrieve I dev I error
Format/review a dump
Display symbol table
D i stri b uted System s
C l usteri n g
Cluster Overview
What do you get when you couple a bunch of RS/6000s together?
Answer: a network-based multiprocessor capable of supporting batch,
parallel, and multiuser workloads at a fraction of the cost of a high­
end mainframe. Workstations like the RS/6000 are already exceeding
the CPU performance and addressing range of all but the technoelite
of mainframe engines . Innovations in networking bandwidth are
rapidly approaching and surpassing the 1/0 bandwidth of traditional
storage devices. All that's required is the software glue to make the
group function under a single system image.
Clustering systems is certainly not a new idea. The scientific and
research communities have been experimenting with arrays of proces­
sors in networked configurations for a number of years. Although much
of this work was directed at the needs of specialized parallel applica­
tions and pushing the boundaries of computer science, it laid the
ground work required to establish practical workstation clusters today
(see Fig. 27. 1). We still don't have all the big-iron software infrastruc­
ture common in the glass-house computing centers. But hey, it's only
software! There are already a number of highly polished batch cluster
packages available from software vendors and in the public domain.
Single System Image
What defines a single system image? B a sically, the cluster of
machines should present themselves as a single machine to the user
community. Resources available on any individual machine must be
accessible, yet hide any notion of locale outside a single cluster domain
name. Some level of process queuing must be available to distribute
load evenly among the processors . A common view of file system
resources must be available from any machine in the cluster. This
includes a uniform UID and GID name space, uniform file permis41 5
Distributed Systems
41 6
--- · -- ·
,,,,,,.,. . -- ·
- · - · - - -� - - - · - · -
. ..... . ._.,
..... . ..... ·
-- · - · - · - · - ·
· -·-·-·
--:- -
-- · ,,.... . --
. ..... . , •
Figure 27.1
Cluster topology.
sions, and file locking. Lastly, the cluster must support centralized
operations and administration. The list goes on, but you get the idea.
Cluster domain name
Standard tcp-based services provide the foundation for building the
cluster. Name service based on BSD Bind can be modified to respond
with any one of a set of IP addresses for a single cluster domain
name. A Time To Live (TTL) value of 0 is passed back to the querying
system with the chosen IP address. If the system making the query
does not cache the information, then this IP address will be used for
this query only. There is a feature in Bind such that any TTL value
less than five minutes is reset to five minutes by the resolver. In prac­
tice, this five-minute window does not cause significant problems.
Without resolver caching, each name service query to resolve the clus­
ter domain name to an IP number will result in a new call to the
name service daemon.
The trick is to select an IP number from the available set of
machines that maintains some equitable distribution of connections
across the cluster. The groupd name server developed at UCLA uses
a scheme based on a loads database that contains the load average of
each machine in the cluster. The groupd name server responds to "A"
record queries with the IP address of the least-loaded machine. The
selected machine's load average entry is temporarily incremented to
41 7
represent the additional load caused by the new connection. Other
algorithms use random or round robin mechanisms for selecting an IP
Common file system
A single view of the cluster file system hierarchy from any machine in
the cluster can be realized through the use of Network File System
(NFS). End-user file systems are exported from a cluster NFS server
to each machine. Each machine maintains a local copy of the operating
system and application set based on a reference system. This allows
each machine to function independently should the NFS server fail.
The reliability of the server can be improved through the use of High­
Availability Network File System / 6000 (see Chap. 13) If scalability is
a problem, then other distributed file systems may be used. For exam­
ple, the Andrew File System (AFS) from Transarc/Carnegie-Mellon.
Along with NFS support, Network Information System (NIS) can be
configured to maintain a uniform UID and GID space, as well as
manage common configuration files. The BSD rdi st command can be
used to distribute file sets not managed under NIS. Cluster machines
can be cloned from a single reference system mksysb image to main­
tain operating system consistency.
The AIX qdaemon and lpd daemons can be configured to manage
print distribution and queuing both inside and outside the cluster.
Electronic mail can be managed by a single s endma i l daemon for the
cluster. Command wrappers based on the BSD r-commands (r sh,
rdump, rmt, r l ogin, etc,) can be used to smooth access to distributed
resources and assist users in managing distributed processes. The
/ e t c / ho s t s . equiv and / et c / ho s t s . lpd can be used to identify
cluster machines , making individual rho s ts files unnecessary.
Cluster Batch Queuing
To distribute batch workloads among cluster sites, you could imple­
ment a few scripts that take advantage of at, cron, rsh, and the like.
However, there are packages available that perform this function
with all the bells and whistles we have come to expect from more
mature mainframe batch systems.
Most distributed UNIX batch queuing systems are loosely based on
the Network Queuing System (NQS) model developed for the NASA
Ames NPSN complex. A user submits a job to a master scheduler dae-
41 8
Distributed Systems
mon, which in turn hands the job off to local or remote queues for exe­
cution. UNIX kernel limits like CPU time, stack and data size, work­
ing set size, and file size are used to govern the resources consumed
by individual jobs. In most implementations, electronic mail notifica­
tion of job boundary status is available, as well as distributed spool­
ing of job output.
One of the areas of primary interest and development is in the
queuing scheduler. Early systems like NQS had no mechanism to
load balance j obs among multiple batch queues. The result is that
jobs end up waiting in busy queues while other queues stand empty.
Load-balancing schedulers were then introduced that would allocate
jobs among queues based on a system load feedback mechanism. Jobs
were evenly distributed among machines, but the single scheduler
proved to be a single point of failure. The next stage in scheduler
development involves redundant schedulers and the ability for sched­
ulers to pass jobs among themselves.
Multiple device queuing system
The Multiple Device Queuing System (MDQS) is a batch and device
queuing system similar to the base NQS model. A central daemon
schedules jobs in a round robin or table order algorithm among the
individual batch queues. A mapping table identifies routing informa­
tion, using a vector of queue, devi ce, server data. Queuing is initi­
ated by enqueuer clients, which are analogous to UNIX lpr and at
commands. Queued jobs are then dispatched by dequeuer clients, anal­
ogous to the UNIX lpd and atrun. MDQS is available from a number
of anonymous ftp sites. Use archie to find the site nearest you.
Network queuing system
The general Network Queuing System (NQS) model was described in
the preceding queuing overview. NQS uses a central scheduling dae­
mon to route jobs among any of three queue types: batch queues (desti­
nations for job execution) pipe queues (route jobs between queues), and
device queues (destination for hardcopy output). NQS uses a system
called shell strategies which allow the system administrator to tailor
which shell is used for job execution. The fixed strategy defines a sin­
gle default shell. The free strategy allows end users to define the shell
to be used in their job submission scripts. Finally, the login strategy
uses the user's login shell as defined in the / et c /pas swd file.
Network Queuing System Version 2 (NQSN2) builds on the Version
1 base by providing an enhanced queuing model called queue complex­
es. Queue complexes provide a mechanism enabling a j ob to be sched­
uled on one of a number of queues based on resource limits and avail­
ability. NQS V2 also includes device limits. NQS Vl is available from
41 9
a number of anonymous ftp archives . Use archi e to find the site
nearest you. NQS V2 is available from COSMIC, (706) 542-3265.
Monsanto CERN/NQS
Christian Boissat of CERN retrofitted the queue complex capabilities of
NQS V2 into NQS Vl. A load-based scheduler, as well as a number of
other enhancements and bug fixe s , are also included . Monsanto
CERNI NQS is available via anonymous ftp to wuarchi ve . wus t l . edu
in the packages /nqs / unix directory.
NQSExec is yet another add-on to facilities provided by NQS. The
Exec option provides a load-bas e d s cheduler develope d by the
Cummings Group called the Network Computing Executive. NQSExec
is available from Sterling Federal Systems, Inc. , (415) 964-9900.
27 .3.5
Other NQS·based batch systems
There are a number of other NQS-based batch systems implemented
by many operating system vendors. Examples include NQS/MVS from
IBM, which provides an NQS-like interface to JES , and the Cray
UNICOS version of NQS. COSMIC also has an NQS successor called
Portable Batch System (PBS) in the works. Contact the vendors for
more information.
Distributed job manager
The Minnesota Super Computer Center has developed a system for
their connection machine called Distributed Job Manager (DJM).
DJM is a drop-in replacement for NQS, supporting the NQS com­
mand set. DJM supports a load-balancing scheduler and provides
both batch and interactive sessions. Interactive sessions allow discon­
nect and reconnect capability. DJM also makes use of the connection
machine checkpoint/restart facility. DJM licensing is covered by the
GNU General Public Licensing. It is available via anonymous ftp to
ec . ms c . edu in directory pub / L IGHTNING.
Distributed network queuing system
The Distributed Network Queuing System (DNQS), originally devel­
oped at the Florida State University Supercomputer Computations
Research Institute (FSU SCRI), was designed to provide a dynamic
mechanism for adding and deleting queues from a distributed batch
topology. This capability, along with a mechanism for suspending a
local batch queue when keystrokes or mouse interrupts were detected
on a workstation, allowed centers to make use of idle cycles on end-
Distributed Systems
user workstations. Users could be enticed into participating in the
batch system by allowing them access to the larger cycle base and
ensuring that their workstation would be available for their personal
u s e when n e e d e d . McGill University and Livermore N ational
Laboratory have enhanced DNQS by implementing improved local
administrative controls, multiple queues per workstation, load statis­
tics, and architecture queue classes. DNQS is available via anony­
mous ftp to f tp . phys i c s . mcgi l l . ca.
Distributed queuing system-Codine
The folks at FSU SCRI enhanced their original DNQS design and
introduced the Distributed Queuing System (DQS). Like DNQS, DQS
supports dedicated and nondedicated workstation queues and archi­
tecture queue clas s e s . DQS enhancements include a load-based
scheduler, PVM support , group queues , NFS/AFS support, user
access controls, interactive sessions, and an Xl l and Motif GUI.
The SCRI staff have been joined by collaborators from Pittsburgh
Super Computer Center and the University of Texas Center for High
Performance Computing to continue development of DQS and eventu­
ally replace it with the Scalable Q u e u i ng System ( S Q S ) . D Q S
improvements over the next year will incorporate Kerberos 4 . 0 and
AFS Inter-Cell support, additional parallel toolkits, POSIX 1003 . 15
compliance, redundant schedulers, and additional resource defini­
tions. The SQS follow-on to DQS is scheduled for 1994 and will be
based on OSF technologies. This will include DCE client/server, DME
authentication, DFS support, and a multithreaded scheduler. DQS is
available via anonymous ftp to f tp . s c r i . f su . edu.
27.3.9 Condor
The University of Wisconsin's Condor distributed batch system is
designed to reclaim idle cycles on workstations like DQS and DNQS.
Condor goes one step further by guaranteeing that once a job enters
the Condor queuing system, it will finish. Condor does this by provid­
ing a checkpoint/restart and migration capability. Using a custom
RPC, Condor ties each batch job to a shadow process running on the
initiating system. The shadow process maintains a link to the batch
job as it moves throughout the queuing system. There are restrictions
on the type of job that can be checkpointed. The job cannot fork new
processes, cannot use IPC mechanisms, cannot trap or handle signals,
and cannot have concurrent read/write access to open files. Condor
supports a load-based scheduling system that also takes into account
the job priority and date queued.
Future enhancements for Condor include support for PVM 3 . 0 ,
variable node parallel sessions, and access t o remote Condor pools
called flocking. Portability streamlining of the checkpoint/restart code
and an implementation in C++ are also in the works. You can obtain
Condor via anonymous ftp to f tp . c s . wi s e . edu.
27.3.1 0
IBM, working with the University of Wisconsin, has enhanced the
Condor base system to include support for redundant schedulers. The
IBM LoadLeveler implementation allows configuration of abstract
resource types. A Motif-based GUI and AFS support are also avail­
able. LoadLeveler may be used with the 9076 POWER Parallel
System ( SP l ) to distribute work between nodes in the system. A
statement of direction to support LoadLeveler on other UNIX archi­
tectures has also been announced.
27.3.1 1
Load-sharing facility-Utopia
Platform Computing Systems and the University of Toronto have
developed a distributed queuing system for both batch and interactive
work. The system is being marketed by Platform Computing Systems
under the name Utopia. Utopia uses a load-based scheduling algo­
rithm that goes far beyond the standard kernel load average used
more commonly by other systems. Utopia's load daemons track CPU
queue lengths, memory utilization, paging rate, block 1/0 rate, num­
ber of logins, system idle time, I tmp utilization, and network packet
rates in determining system load aggregates. Utopia supports redun­
dant schedulers and abstract resource typ e s . A distributed API
library is available for developing your own applications. Utopia is
claimed to be scalable to thousands of nodes.
27.3.1 2
There's still more
If this doesn't seem like enough, there are still a few systems I'd like
to mention before closing. The Vienna Queuing System (VQS), devel­
oped at University of Vienna, Austria, is a queuing system similar to
DNQS that provides a fair-share scheduler to balance the load among
users. VQS also tracks the aggregate resource usage among multi­
process jobs. The Fermilab Cooperative Process Farm is built from a
scheduling system and API library for developing distributed and
parallel applications. The Hewlett-Packard Task Broker uses a unique
algorithm, where nodes in the batch system bid for additional work.
Finally, the Cummings Group have a number of products to facilitate
distributed applications. These include NCE, NCLOGIN, NCADMIN,
27.3.1 3
POSIX 1 003. 1 5 Batch Standard
With all these batch systems in the works, what is the chance that
they will support some level of interoperability? Most of the product
Distributed Systems
development plans listed include compliance with the POSIX 1003 . 15
Batch Standard. The scope of the 1003. 15 standard includes the defi­
nition of distributed batch terminology, concepts, and variables. It
will identify application environments, define command syntax, and
incorporate rationale for external interfaces. Draft 12 of this standard
will have been voted on by the time this book is in your hands. Future
work will define a network protocol, administration commands, a pro­
gramming interface, and resource controls. The 1003. 15 group is not
addressing issues like security, directory services, authentication,
account mapping, and network administration, as these are under the
auspices of other groups .
I f you are interested i n the work being done by the POSIX batch
committee or any of the other committees, please make it a point to
get involved. You can contact the IEEE at the following address, or
acce ss their no-charge dial-up bulletin board. The bbs supports
speeds up to 2400 bps, no-parity, 8 data bits, and 1 stop bit. Download
the bbsgui<le. txt Users Guide for more information.
IEEE Standard Office
P.O. Box 1331
Piscataway, NJ 08855-1331
Telephone (908) 562-3809
Fax: (908) 562-1571
IEEE bbs: (908) 981-0290
Cluster Futures
With the OSF technologies just around the corner, tools like DCE
( D i stribute d C o mp uting E nvironment ) , DME ( D i stributed
Management E nvironment) , and AND F (Architecture Neutral
Distribution Format) promise to extend the capabilities of worksta­
tion clusters. X 500 directory services will provide enhanced access to
users, applications, and services. POSIX is actively working on a
standard for distributed batch systems. The result of all this is a uni­
fied and standard mechanism for supporting distributed resources vs.
resorting to piecing together the odds and ends listed this chapter.
Network Arch ivi n g
Storage Management
It seems like every time I want to build a new software package, I
spend most of the time trying to reclaim sufficient disk space to per­
form the build. I do make a half-hearted attempt to keep things
cleaned up. I keep telling myself that I'm going to need those old test
programs and e-mail messages someday. Let's not forget all those Xll
background images I've collected and just have to keep on-line. One
gigabyte of disk space just doesn't seem to go as far as it used to. I
remember when I got my first IBM PC/XT and thought that 10 MB
was disk heaven. Sigh!
Does this sound familiar? Even the glass-house computer centers
with large operations staffs are finding that they are spending nearly
all their time running system backups. Exponential growth in CPU
and network bandwidth, along with expanding connectivity, are
resulting in mountains of data looking for a home. You can't keep
throwing cheap disks at the problem and hope it will go away. How
much of this data really needs to be saved? Many centers find that 80
percent of their backup data is never accessed again. Some applica­
tions require more immediate access to data than human-managed
tape restore allows.
What is needed is a software-controlled hierarchical storage man­
agement system. This system would automatically move inactive files
onto lower-cost storage media, yet present a single view of the data to
the end user regardless of where it resides in the physical hierarchy.
Users must be able to interact with the system to control where data
resides in the hierarchy to meet their access requirements. The sys­
tem must also be able to manage the physical storage devices to
ensure free space and availability.
Distributed Systems
IEEE Mass Storage Reference Model
The IEEE Mass Storage Systems Technology Committee (MSSTC)
has been working for over 15 years to define a standard storage refer­
ence model. The model describes a modular system for small-to-large,
stand-alone, and distributed heterogeneous environments. Although
parts of the model are still being formulated, it provides an excellent
foundati o n for implementation of software to meet the n e e d s
described here. The user interface hides the storage architecture and
hierarchy from the users , yet allows them to control what data
requires archiving, for how long, the number of copies, versions, and
access security. It recommends a separation of data and control mes­
s age path s , but does not define a particular network protocol to
ensure open connectivity. Rather than dictate a single access method
for interacting with data storage, it describes three options which
may be used to develop clients: operating system traps (similar to
NFS trapping of 1/0 system calls), application level processes (for
example, ftp), or a callable program library of routines . It also pro­
vides an open interface to support various storage media.
In a nutshell, the components and interaction of the reference model
are as shown in Fig. 28. 1 . Files are called bitfiles and are represented
Data Path
Control Path
Figure 28.1
IEEE mass storage reference model.
Network Archiving
as bitstreams with an associated unique bitfile ID and header. There
is no modification of the data itself. A name server maps the operating­
system-dependent file names to the unique bitfile IDs. Bitfile servers
manage bitfile attributes maintained in the headers . This includes
things like file size, access control information, logical location, etc.
Bitfile movers are used to transfer bitfiles between client systems and
the storage servers. The storage servers track the location of bitfiles on
the physical volume repositories. There is also a migration manager
that is responsible for maintaining free space on the storage media by
migrating bitfiles between devices as needed. The modular nature of
this model provides flexibility in distributing and replicating functions
among many nodes in a network environment.
Development history
You may be familiar with a number of mass storage implementations
that may or may not follow the IEEE reference model. Examples are
IBM's MVS System Managed Storage (DFSMS), and VM Workstation
D ata Save Facility (WDSF). The MVS-based Common File System,
developed by Los Alamos National Laboratory, has been in produc­
tion for over 13 years and is now marketed by the DISCOS division of
General Atomics under the name DataTree. Lawrence Livermore
National Laboratory developed a UNIX-based mass storage system
called LINGS and it has been in production there since 1988. The
Livermore Lab is a test bed for software and hardware integration
under the IEEE reference model. The LINCS system is now marketed
by many vendors as a product called Unitree. The Livermore National
Storage Laboratory has since developed an enhanced version of
Unitree called NSL- Unitree. NSL-Unitree moves further into the
realm of distributed storage servers and storage hierarchies. Unitree
has been ported to AIX, and is conformal to the IEEE mass storage
reference model. For the sake of this discussion, I'll focus on Unitree,
since it is representative of the IEEE reference model and is the most
commonly known implementation.
Unitree Central File Manager
The Unitree Central File Manager (UCFM) provides a hierarchical
data storage facility in single-system or distributed computer envi­
ronments. In its most common incarnation, Unitree uses a two-tier
storage hierarchy consisting of disk as a first-level archival staging
area, and tape as the second level. Users move files into and out of
the storage system via NFS, FTP, or Unitree provided DFTP clients.
A migration process in the central server copies files from the disk
staging area to tape after aging or to maintain free space. Eventually,
the disk copy of the file may be purged. When a user accesses a par-
Distributed Systems
ticular file, Unitree will retrieve the data from the current level of
storage on which it resides transparent to the user. This is where a
robotic tape system comes in handy for files that have been migrated
to tape. You can easily run your operations staff ragged in a fairly
active system without the use of some kind of robot.
File system view
The user's view of the archive system is what appears to be a stan­
dard UNIX file system. Under NFS, you may operate on files in your
archive directory with standard UNIX commands just as if they were
located in your home directory. Remember that if a file has been
migrated to tape, that tar or make you just issued might take a little
longer than you expect. I should note that Unitree replaces the NFS
and FTP code on the central file server, so it may be advantageous to
make the central server a dedicated system. Since Unitree isolates
data from control messages, you can move some of the logical opera­
tions onto lower-cost computers.
Client access
To enable some of the NFS file management capabilities in the FTP
environment, Unitree provides some additional commands that can
be quoted using standard FTP client access. The GTRSH and STRSH
commands allow you to display and set the trashcan timeout interval.
Trashcans are a safety feature that allow you to recover files you
have inadvertently deleted. The NMDUP command lets you control how
many copies of a file may be stored in the system. Standard UNIX file
access commands chgrp, chown, chmod, umas k, and ln are support­
ed. You can use the s t age and wa i t commands to control waiting for
a file you wish to retrieve that has been migrated to tape. Finally,
there is a byte-size option to the standard FTP h a s h command.
Unitree also offers its own file transfer protocol called dftp. dftp is
used just like ftp , but it offers better performance and contains a
superset of ftp commands. You must install the dftp client code on
your local machine.
Media architecture
There are few architectural limits in the Unitree system. There are
no maximum limits in the code for number of files, number of directo­
ries, file size, or file names. Granted, there may be limits imposed by
the operating system. A single file may span multiple physical vol­
umes. Thus, terabyte files and file systems may be configured. At
Livermore National Laboratory, Unitree is tracking over 50,000 3480
cartridges of data in StorageTek silos. Unitree also operates in raw
mode on the media assigned to it. Raw access allows for moving very
Network Archiving
large blocks of data, making the most of interface bandwidth and
optimizing use of devices like raid disk arrays . Compression and
encryption routines can also assist in making the most use of system
interfaces and media, and provide an additional level of data security.
As your space requirements grow, you can dynamically add new
media into the system.
e-mai l Lists and ftp S ites
There are some fringe benefits available to the UNIX user community
that are a direct result of the openness and growth of UNIX over the
years. These are the collections and archives of public domain soft­
ware, and the public help and discussion lists available on the inter­
national networks. Here is a wealth of software, "hard knocks" sto­
ries, shoulders to cry on, and general information that can make life
with UNIX much easier. But before you can take advantage of these
benefits, you have to know where they exist, and how you access
them. I'll address these issues with emphasis on archives and lists of
interest to the AIX community, and (here comes the pitch) the OPEN
Electronic Mail Lists
Probably the first and easiest of these facilities to try to use are the
electronic mail lists. If you are familiar with using e-mail facilities,
and have some type of network access to the Internet, then interact­
ing with the discussion lists will be little different than sending mail
to a colleague. To begin using a list, you must first subscribe. Most e­
mail discussion lists are either managed by real humans, or are auto­
mated to support commands like subscription requests. With the for­
mer, once you know the list name and address, you can send mail to:
l i s tname -request@someho s t . domain . address
You replace "listname" with the appropriate name and the host
address in "somehost.domain.address." In the mail body text, simply
ask to be added as a subscriber. Then, to participate in the discus­
sions, address your mail to:
l i s tname@someho s t . domain . address
Appendix A
In the case of automated servers, you send your subscription
request to the servers' e-mail address, supplying specific commands
to activate your subscription. To subscribe to the following lists,
address your mail to:
l i s ts erv@vm . i ts . rp i . edu
l i s t serv@uwavm . u . washington . edu
l i s t s erv@uga . bi tnet
In the mail body text type the command:
SUBSCRIBE l i s tname Your Ful l Name
where "listname" is one of those listed as follows, and "Your Full
Name" is your given name. listserv will locate your e-mail address in
the mail header it receives with the request. Make sure you do not
make this command a part of the "Subject:" line, as it will be ignored
by the server. If at some time in the future you wish to unsubscribe,
use the command:
UNSUBSCRIBE l i s tname
e-mail lists of interest via listserv:
Discussion topic
AIX/ESA on large systems
AIX Vl.2 on large systems
RISC System 6000 AIX V3
General AIX topics
Distributed Queuing System-Batch
Load Leveler discussion
Power Parallel SPl discussion
Power Personal PC discussion
UNIX Wizards Usenet redistribution
SHARE UNIX group information
Once you have received notification that you have been added to
the list of subscribers, you may then participate in list discussions by
sending mail to the list name and address. For example, mail to:
AIXESA-L@vm . i ts . rpi . edu
will be distributed to all subscribers of AIXESA-L.
Usenet News
Another discussion list facility is Usenet News. This is somewhat simi­
lar to e-mail, but requires access to a site which acts as a server and
e-mail Lists and ftp Sites
receives news feeds from other sites on the network. Usenet News is
accessible by a number of user interface programs, one of the more
popular of which is "rn. " Discussions are divided into newsgroups with
a limited classification hierarchy that groups topics of interest. To par­
ticipate in a newsgroup, you must first subscribe. Here I will point you
to the man page for the particular interface program you use. Like
most mail systems, there are facilities to browse, save, reply, sub­
scribe, and post to newsgroups. Newsgroups of interest include:
c omp . unix . aix
General AIX leans to AIX V3
b i t . l i s t s erv . aix- 1
Redistribution of AIX-L
c omp . unix
General UNIX topics
c omp . unix . wi z ards
UNIX sys admin, internals, etc.
c omp . unix . internal s
UNIX internals, programming
c omp . archive s
Software via anonymous ftp
c omp . s ourc e s . want ed
Requests for software all OS
There is also a newsgroup being formed for the AIX users group.
Watch for it at a news feed near you.
Anonymous FTP Archives
A number of sites on the network provide public access to software
archives via anonymous ftp. Instead of requiring that you have an
account on the given site, you may log in in as user ID "anonymous,"
and supply a password that is either your user ID or e-mail address.
This allows these sites to keep track of who is using their service.
After logging in, you are free to browse the directories and download
anything that may be of use to you.
FTP sites:
aixpds l ib . seas . ucla . edu
AIX/ 6 0 0 0 pub l i c domain s o f tware
ibminet . awdpa . ibm . com
IBM announcements , OEM hardware l i s t
f tp . egr . duke . edu
A I X archive
s t rayl ight . ac s . nc su . edu
AIX archive
alpha . gnu . ai . mi t . edu
AIX archive
f tp . ans . net
wai s s t u f f
wuarchive . wus t l . edu
Public Internet archive s i t e
Anonymous FTP by e-mail
If you don't have ftp access, but do have e-mail access, you may obtain
access to anonymous ftp archives via a server at Princeton. The serv­
er will retrieve files for you via e-mail. You may request access by
sending mail to:
Appendix A
b i t f tp@pucc . princeton . edu
On your first attempt to use the server, include the commands HELP
and FTPL I S T on separate lines in the mail text. These will prompt
the server to send you a help file and anonymous ftp site list. There is
also information on encoding techniques supported for transferring
files to you via e-mail.
Sam ple Code
The following set o f sample code i s provided for illustration purposes
only. No warranties or guarantees are implied. These are just a few
tools I use from time to time that you might find useful. I'm not going
to try to defend my coding practices, so please don't write!
Set RTS on a TTY Port:
Set RTS on a TTY line and don ' t block .
# inc lude < s tdio . h>
# inc lude < f cnt l . h>
# inc lude <t ermi o s . h>
# inc lude < sys / i o c t l . h>
main ( argc , argv )
int argc ;
char * argv [ J ;
union txname t tytx ;
( argc < 2 )
fprint f ( s tderr , • usage :
% s / dev/ t ty? " , argv [ O J ) ;
( ( fd = open ( argv [ l ] , O_J'lONBLOCK ) )
fpr int f ( s tderr , • Can ' t open device % s \ n • , argv [ l ] ) ;
exi t ( l ) ;
s trcpy ( t tytx . tx_name ,
"rts • ) ;
i f ( i o c t l ( fd , TXADDCD , & t tytx )
fprint f ( s tderr , " Add rts fai led % s \ n • , argv [ l ] ) ;
pe rror ( argv [ l J ) ;
exi t ( l ) ;
exi t ( O ) ;
Clean corrupted UTMP file:
* * C l ean dead proces from UTMP f i l e .
Appendix B
# inc lude < sys / types . h>
# inc lude <utmp . h>
# inc lude < fcnt l . h>
main ( )
int f d ;
s truc t utmp utmp ;
i f ( ( fd = open ( " / et c / utmp • , O_RDWR ) ) < 0 )
exi t ( 1 ) ;
whi l e ( read ( fd , &utmp , s i z e o f utmp ) = = s i z e o f utmp ) {
if ( utmp . ut_type = = USER,_PROCESS && ki ll (utmp . ut_pid, 0 )
l s eek ( fd , - ( long ) s i zeof utmp , 1 ) ;
utmp . ut_type = DEAD_PROCESS ;
write ( fd , &utmp , s i z e o f utmp ) ;
c l o s e ( fd ) ;
print f ( " UTMP c l ean c omplete \ n " ) ;
exi t ( 0 ) ;
Open a PTY master I slave pair:
* * Open a mas ter / s lave p ty pair on AIX and print the names . * /
# inc lude < s tdio . h>
main ( argc , argv )
int argc ;
char * argv [ l ;
char *ptsname ;
int number ;
int f d ;
i f ( ( fd = open ( " / dev/ptc • ,
perror ( " / dev/ptc " ) ;
exi t ( 1 ) ;
0 ) ) < 0)
p tsname = t tyname ( fd ) ;
print f ( " Slave : % s \ n • , ptsname ) ;
s scanf ( ptsname , " / dev/pts / %d " , &number ) ;
print f ( "Master : / dev/ ptc / %d\ n " , number ) ;
exi t ( O ) ;
Get and set process queue priority:
* * getpri : Get process queue priori ty .
# inc lude
# inc lude
# inc lude
# inc lude
< s tdio . h>
< sys / types . h>
< sys /pri . h>
< sys / errno . h>
Sample Code
main ( argc , argv )
int argc ;
char * argv [ J ;
int p i d ;
i n t pri ;
( argc < = 1 ) {
print f ( "Usage : getpri p i d \ n • ) ;
exit ( l ) ;
pid = a t o i ( argv [ l ) ) ;
pri = getpri ( p i d ) ;
- 1) {
i f ( pri = =
perror ( " Getpri f a i l ed " ) ;
exi t ( l ) ;
printf ( " Pr i o r i ty for p i d :
%d -- > % d \ n • , pi d , pri ) ;
* * setpri : S e t process queue prior i ty .
# include < s t di o . h>
# include <sys / types . h>
# include <sys /pri . h>
# inc lude <sys / s ched . h>
# inc lude <sys / errno . h>
main ( argc , argv )
int argc ;
char * argv [ J ;
int p i d ;
i n t opri , npri ;
i f ( argc ! = 3 ) {
print f ( "Usage : s e tpri p i d pri o r i ty \n " ) ;
p r i o r i ty = %d ( high ) thru %d
printf ( •
( low ) \ n • ,
exi t ( l ) ;
pid = atoi ( argv [ l ) ) ;
npr i = a t o i ( argv [ 2 ) ) ;
i f ( npri < PRIORITY_MIN I npri > PRIORITY_MAX ) {
print f ( " Pr i o r i ty %d out of range ! \n • , npri ) ;
print f ( "Usage : s e tpri p i d pri o r i ty \n " ) ;
p r i o r i ty = %d ( high ) thru %d
prin t f ( •
exi t ( l ) ;
print f ( " se t priority f o r p i d : %d \ n • , p i d ) ;
opri = setpri ( p i d , npr i ) ;
i f ( opri = =
- 1 )
perror ( • setpri ( ) f a i l ed " ) ;
exi t ( l ) ;
printf ( " o l d %d new %d\n • , opri , npri ) ;
Attempt to reset a hung tape drive:
* * rmtreset - Clear hung tape device .
( low ) \n • ,
Appendix B
* * Use openx ( ) c a l l t o force a Bus Device Reset ( BDR ) regardl ess o f
* * device res erva t i on by another initiator . See InfoExplorer rmt
* * S C S I Device Driver for more informa t i on .
# inc lude
# inc lude
# inc lude
# inc lude
# inc lude
< s tdio . h>
<sys / devin f o . h>
<sys / sc s i . h>
< sys / tape . h>
< fcnt l . h>
int main ( argc ,
int argc ;
char * argv [ ] ;
argv )
( argc ! = 2 ) {
fprint f ( s t derr ,
exi t ( l ) ;
" Usage : rmtreset / dev/ < rmt ? > \ n • ) ;
( openx ( argv [ l ] , O_RDONLY , 0 ,
perror ( " openx ( ) failed : " ) ;
exi t ( 1 ) ;
exi t ( O ) ;
< 0)
B i b l i og raphy
AIX for RISC System I 6000 Installation Guide, SC23-2341 .
AIX Version 3 for RISC System / 6000 Communication Concepts a n d Procedures,
Volumes 1 and 2, GC23-2203.
AIX Version 3.1 Additional Authorization: An Example," IBM International Technical
Support Centers Redhook. 0024-3750.
AIX Version 3.2 Problem Solving Guide and Reference, SC23-2204.
AIX Version 3.2 System Management Guide, SC23-2457.
AIX Version 3.2 System User's Guide, GC23-2377.
Andleigh, Prabhat K, UNIX System Architecture, Prentice Hall, Englewood Cliffs, N.J .,
Cox, D aniel, "High Availability Cluster Multi-Processing/6 000," /AIXtra 3 ( 3 )
(May/June 1993).
Darwin, Ian, "PC-NFS," SunExpert 3( 11) (November 1992).
DeRoest, Jim, "AIX and DOS-A Marriage Made for the RS/6000," RS /Magazine 1(5)
(May 1992).
DeRoest, Jim, "AIX and DOS-A Marriage Made for the RS/6000," RS /Magazine 1(6)
(June 1993).
DeRoest, Jim, AIX V3 tty and Modem Support," RS I Magazine charter issue, Fall 1991.
DeRoest, Jim, "Bump in the Night: AIX Debugging and Recovery," RS /Magazine 1( 12)
(December 1992).
DeRoest, Jim, "Down on the Farm," RS I Magazine 1(1) (January 1992).
DeRoest, Jim, "Everything in its Place-UNIX Archiving," RS /Magazine 1(8) (August
DeRoest, Jim, "Glass Menageries of X: IBM Xstations," RS I Magazine 2(4) (April 1993).
DeRoest, Jim, "Highly Available UNIX," RS I Magazine 1( 10) (October 1992).
DeRoest, Jim, "Highways and Byways," RS I Magazine 1(9) (September 1992).
DeRoest, Jim, "Home Away from Home," RS I Magazine 2(2) (February 1993).
DeRoest, Jim, "Orthodox Window Managers," RS /Magazine 1(6) (June 1992).
DeRoest, Jim, "Red Hot Chili Servers," RS / Magazine 2(5) (May 1993).
DeRoest, Jim, "Share and Share Alike-UNIX Batch Processing," RS I Magazine 1(7)
(July 1992).
DeRoest, Jim, "Taming the Beast--AIX Tuning," RS I Magazine 1(11) (November 1992).
DeRoest, Jim, "UNIX Batch Queuing Revisited," RS I Magazine 1(7) (July 1993).
DeRoest, Jim, "Who Did You Say You Are ?-AIX Alternate Authentication , "
RS I Magazine 1(8) (August 1993).
Dowd, Kevin, "Programming in Parallel," RS I Magazine 2(3) (March 1993).
Eargle, John, Handbook ofRecording Engineering, Van Nostrand Reinhold, New York,
Frisch, Aeleen, "Boosting Performance on the RS/6000," RS I Magazine 2(5) (May 1993).
Frisch, Aeleen, Essential System Administration, O'Reilly & Associates, Inc.
Frisch, Aeleen, "Writing it Down," RS I Magazine 2(6) (June 1993).
Gibbs, G. Benton, "Demystifying the Object Data Manager-Part 1 ," /A!Xtra 2(2)
(April 1992).
Gibbs, G. Benton, "Demystifying the Object Data Manager-Part 2," /AIXtra 2(3) (July
Gibbs, G. Benton, "Demystifying the Object Data Manager-Part 3," /A!Xtra 2(4)
(October 1992).
Heise, Russel A. , "Performance Tuning: A Continuing Series-The vmstat Tool,"
IAIXtra 3(5) (September/October 1993).
"IBM RISC System/6000 Processor," IBM Journal of Research and Development 34( 1)
(January 1990).
IBM RISC System / 6000 Technology, SA23-2619.
Lewis, Elizabeth "Performance Tuning: Theory and Practi c e , " /AIXtra 3 ( 2 )
(March/April 1993).
Linthicum, David S., "NFS Explained," RS /Magazine 2(4) (April 1993).
Linthicum, David S., "Using UUCP: The Basics," RS I Magazine 1(7) (July 1993).
Loukides, Mike, "System Performance Tuning," O'Reilly & Associates, Inc., Sebastopol,
Calif. , 1990.
Majkiewicz, Jane, "Taming the Backup Beast," RS I Magazine 2(2) (February 1993).
Martin, Paul, and Dinah McNutt, "Customizing SMIT," RS I Magazine 1(5) (May 1992).
Mullender, Sape, Distributed Systems, ACM Press, Addison-Wesley, Reading, Mass. ,
Nemeth, Evi, Garth Snyder, and Scott SeeBass, UNIX System Administration
Handbook, Prentice Hall Software Series, Englewood Cliffs, N.J., 1989.
Onie, Elmer, "Setting Up OSIMF/6000," IAIXtra 2(3) (July 1992).
Peek, Jerry, Mike Loukides, and Tim O'Reilly, UNIX Power Tools, Bantam Books,
Sebastopol, Calif. , 1990 . .
POWERstation and POWERserver Common Diagnostics and Service Guide, SA23-2687.
"Printing for Fun and Profit Under AIX V3," IBM International Technical Support
Centers Red Book, GG24-3570.
Stevens, W. Richard, Advanced Programming in the UNIX Environment, Addison­
Wesley, Reading, Mass. , 1992.
Stevens, W. Richard, UNIX Network Programming, Prentice Hall Software Series,
Englewood Cliffs, N.J. , 1990.
Stoessel, Doris , "The IBM 7 0 5 1 POWER Network D ataserve r , " /AIXtra 3 ( 5 )
(September/October 1993).
Stokes, Dawn C., "A Comparison of DCE DFS and AFS," /AIXtra 2(4) (October 1992).
Tanenbaum, Andrew S., Computer Networks, Prentice-Hall, Englewood Cliffs, N.J., 1981.
"TCP/IP Tutorial and Technical Overview," IBM International Technical Support
Centers Red Book, GG24-3376.
Wise, Mary Vicknair, "High Availability for Network File System," /AIXtra 3 ( 1 )
(January 1993).
I ndex
601 Architecture,
603 Architecture,
604 Architecture,
620 Architecture,
801 Architecture,
ACL (see Security ACL)
Accounting, 37 1-379
/etc/holidays, 374, 379
/etc/utmp, 372, 379
/var/adm/ctmp, 373, 379
/var/adm/dtmp, 372, 373, 379
/var/adm/pacct, 372, 373, 376, 379
/var/adm/qacct, 373, 379
/var/adm/Spacct.mmdd, 373, 379
/var/adm/wtmp, 372, 373, 379
acctmerg, 375
acctwtmp, 372
chargeback, 371
/var/adm/fee, 375
chargefee, 375
nulladm, 373
print (see Printing)
reports, 375
/var/adm/acct/fiscal, 375, 379
/var/adm/acct/nite, 375, 379
/var/adm/acct/sum, 375, 379
starting/stopping accounting, 376
accton, 376, 379
runacct, 376, 379
shutacct, 376, 379
startup, 376, 379
turnacct, 376, 379
statistics, 376
ac, 377,379
last, 377, 379
lastcomm, 377, 379
sa, 376, 379
AIX Technical Library/6000, 11, 14, 39
AIXwindows (see Xll)
Andrew File System (AFS), 246
Application Environment Specification
(AES), 7
Archie, 99, 284
Archive (see Distributed systems)
Backups, 383-389
/etc/dumpdates, 385-386, 389
/.fs.size, 52, 53, 124, 387, 388, 402
backup, 52, 95, 99, 101, 386, 387, 389
cpio, 95, 99, 101, 387, 389
cplv, 387, 389
dd, 95, 96, 99, 101
full/incremental dumps, 385
mksysb, 52, 53, 58, 125, 387, 388, 389,
mkszfile, 52, 53, 58, 125, 387, 388, 389,
rdump, 388, 389
restore, 95, 99, 101, 125, 386, 387, 389
rrestore, 388, 389
strategies, 383-386
tar, 95, 96, 99, 101, 387, 389
towers of hanoi sequence, 385
Basic Operating Systems (BOS), 41
hos.obj , 37, 49
bsdadm, 19, 21
oslevel, 36, 58
Bibliography, 437--438
Boot, 61
/etc/re.boot, 70, 72, 76
boot device, 62, 89, 90
boot diskettes, 5 1
boot image, 62
boot init, 70
boot kernel, 62, 68
boot lists, 62
boot media, 62
boot record, 62
bootlist, 63, 76
bootmask, 70
bootstrapping, 61
bosboot, 5 1 , 63, 76, 402
getrootfs, 5 1
init_tbl, 6 9
mkdispdskt, 51, 402
mkextdskt, 5 1 , 402
mkinstdskt, 51, 402
multi-user, 62, 74, 75
network boot, 62
normal boot, 61, 63
phase 1 base device config phase, 70
Boot (Cont. ):
phase 2, 72
phase 3 , 73
previous boot, 63
proclrestart, 73
Read Only Storage (ROS), 6 1 , 62
runtime, 74
service boot, 63
single-user, 62, 74
ssh, 70
stand-alone boot, 61
stand-alone mode, 75
stand-alone procedure, 51, 76, 402
BOS extended services, 215
Built-In Self-Test (BIST), 66, 75, 403
cat, 155, 163, 171
CD-ROM (see Devices, file systems)
Clustering (see Distributed systems)
Common On-Chip Processor (COP), 66
Common Open Software Environment
(COSE), 7
comp.unix.aix, 39
Core Sequence Controller (CSC), 67
cron, 216, 276-278, 281
/usr/adm/cron/at. (allow, deny), 277
/usr/adm/cron/cron. (allow, deny), 277
/usr/adm/cron/queuedefs, 278, 281
/var/spool/cron/crontabs, 276, 281, 292,
/var/spool/cron/log, 276
at, 277
atq, 277
crontab, 20, 224, 276
dbm, 81
Devices, 86-90
CD-ROM, 12
cfgbus, 7 1
cfgmgr, 70, 74, 86, 88, 90, 92, 105, 126
cfgscsi, 71
cfgsys, 71
chdev, 86, 96, 101, 106, 124
Config_Rules, 70
customized attributes, CuAT, 71, 87
customized connections, CuCn, 87
customized devices CuDv, 71, 87
descriptors, 88, 89
device location code, 9 1
devswadd, 7 1
ioctl, 96
Devices (Cont. ):
lsattr, 86
lsdev, 42 , 86, 9 1 , 107
mkdev, 86, 105, 127, 133
nvload, 63
predefined attributes, PdAt, 7 1 , 87
predefined connections, PdCn, 87
predefined devices PdDv, 71, 87
rmdev, 86
states, 71, 89
sysO, 7 1
sysconfig, 7 1
topology update procedure, 91-92
Diagnostics (see Problem Analysis)
Disks and diskettes, 103-105
architecture, 104
chpv, 109
format, 5 1
hdisk, 6 3 , 105, 107
Integrated Drive Electronics (IDE ) ,
installation, 104-105
lspv, 107
physical volume, 71, 105
Physical Volume Id PVID, 71, 106, 107,
Dispatcher, 69
Distributed systems, 415-427
archiving, 423-427
IEEE Mass Storage Model, 424
Unitree, 425-427
clustering, 415-422
batch, 417-421
file system, 417
name service, 416
r-commands, 417
single system image, 415
rsh, 372, 388, 417
DME (see Open Systems Foundation)
DOS, 305-314
AIX Access for DOS (AADU), 3 12
/etc/rc.pci, 313
pci, 3 12, 3 14
pciprint, 313
dosdel, 305, 3 14
dosdir, 305, 3 14
dosformat, 305, 3 14
dosread, 305, 3 14
doswrite, 305, 314
PC NFS, 3 12
/usr/sbin/rpc.pcnfsd, 3 12, 314
pcnfsd, 312
personal computer simulator/6000
pcsim, 147, 306, 3 14
/usr/lpp/pcsim, 306
DOS, personal computer simulator/6000
pcsim (Cont. ):
/usr/lpp/pcsim/samples, 308, 314
/usr/lpp/pcsim/tty, 308, 3 14
.doslabel, 309
editty, 309, 3 14
pcsimdd, 3 10
scan code, 147
setmaps, 309
simprof, 306, 3 14
ttyconf, 147, 149, 3 10, 312
xmemory, 3 10
SoftPC , 306
Windows Application Binary Interface
(WABI), 3 1 1
WorkplaceOS, 3 1 1
/etc/environment, 19, 82, 338, 339
/etc/profile, 294, 338, 339
/etc/security/environment, 340
.login, 135, 341, 348
.profile, 135, 341, 348
.re scripts, 135, 341
std. login, 342
variables, 338, 339
File systems, 1 14-121
/etc/filesystems, 12, 109, 1 17-1 18, 120,
127, 233, 237, 249, 336, 374
cdrfs, 12, 21, 116, 229
data block, 1 14
df, 120
du, 295
find, 42, 53, 115, 124
fsck, 74, 1 16
fuser, 120, 127
incore inode structure, 115
indirect block, 115
inode, 1 14, 115, 229
istat, 115
JFS (see Journaled file system)
link, 1 14
ls, 1 14, 115
lsof, 120, 127
mkfs, 68
newroot, 72, 73, 75
mount, 12, 13, 2 1 , 1 19-120, 124, 127,
mount point, 1 19
mountfs, 120
root file system, 73, 1 19
root file system tree, 121
File systems (Cont. ):
rootfs, 73
super block, 1 14
umount, 13, 1 19-120, 124, 127, 234
VFS (see Virtual file system)
ftp sites, 429-432
help (see InfoExplorer, and Manual
HOME, 85
HOWTO help, 148
aixserv, 58, 410
Informatin Design and Development,
Software Manufacturing, 38
Support, 38, 58
InfoExplorer, info, 7, 8, 11, 14, 21
bookmark, 18
ispaths, 12
hypertext, 14
mergenote, 18
note, 18
init, 69, 73, 269
/etc/inittab, 74, 75, 76, 133, 139, 148,
165, 169, 279, 3 13
boot init (see Boot)
init state, 75
runtime init, 73
telinit, 40, 76
Initial Program Load (IPL), 6 1
Initial Sequence Controller (ISC), 6 7
Input/Output Channel Controller (IOCC), 69
Installation and maintenance, 35
apply, 39
bffcreate, 46
cleanup, 50
commit, 39
coreq, 48
install_all, 46, 59
install_latest, 46, 59
install/maintenance diskett, 43
install_update, 46, 59
installp, 39, 45, 48, 50, 59
network install server (see Network
install server)
overwrite install, 43
preloaded software, 41
prereq, 48
preservation install, 42, 43
Preventative Maintenance Package
(PMP), 48
Installation and maintenance (Cont. ):
Preventative Service Planning (PSP), 36
Program Temporary Fix (PTF), 38
reject, 39
selective fix, 48
sinstallp, 41, 49
IPL Controller (!PLC), 67
Journaled File System (JFS), 116-1 19,
229, 241
chfs, 116
crfs, 1 16, 124
crjfs, 53, 1 16, 127
JFS log, 116
moving file systems, 123
resizing file systems, 124
rmfs, 1 19, 124
rmjfs, 119
Key mode switch, 43, 6 1 , 64, 73, 91
normal, 64, 74
secure, 64
service, 64, 65, 73, 74
Kernel (see Problem Analysis)
LED (see Problem Analysis)
Licensed Program Product (LPP), 45
lslpp, 37, 49, 58
/usr/lpp directory, 45
/usr/local directory, 47
Logical Volume Manager ( LVM),
105-1 14
/etc/vg, 108
deflvm, 71
exportvg, 42, 109, 123, 124, 127
extendvg, 107, 108, 127
getlvodm, 126, 127
importvg, 42, 51, 109, 123, 125, 127
interdisk policy, 110
intradisk policy, 1 1 1
ipl_varyon, 42
label, 106
logical partition (LP), 105, 110
logical volume (LV), 105, 109
logical volume group (LVG), 105
lslv, 123, 127
lsvg, 42, 108, 1 1 1 , 1 12, 127
lvdd, 71
mapping, 105-106
migratepv, 123
mirror, 106, 1 12-114
mklv, 112, 124, 127
Logical Volume Manager (LVM) (Cont. ):
mklvcopy, 1 14
mkvg, 107, 108, 127
moving volume groups, 123
partition, 109
physical partition (PP), 105
physical volume (PV), 105
putlvodm, 126, 127
quorum, 108
rootvg, 41, 72, 108, 109, 1 12, 387
size, 110
types, 110
unlocking volume groups, 126
varyoftVg, 109, 127
varyonvg, 108, 127
Volume Group Descriptor Area
(VGDA), 108, 110
Volume Group Identifier (VGID), 108
Volume Group Status Area (VGSA),
108, 110
Macintosh, 305
Mail, 283-297
/bin/mail, 283, 297
!etc/aliases, 286, 291, 292, 297
/etc/, 286-290, 296, 297
/etc/, 286, 290, 297
/etc/, 286, 297
/etc/, 286, 297
/usr/bin/mail, 293
/usr/lib/Mail.rc, 284, 297
/usr/lib/smdaemon.cleanu, 292
/usr/ucb/mail, 283
/var/spool/mail, 297
/var/spool/mqueue, 297
/var/spool/mqueue/syslog, 292, 297
.mailrc, 284, 297
addressing, 285
comsat, 294, 295
debugging, 293
edconfig, 287
elm, 384
headers, 285
inbox, 286
Mail Transfer Agent (MTA), 283, 284,
285, 296
MAILMSG, 294, 295
mailq, 294, 297
mailstats, 294, 297
mhs, 284
mmdf, 284
newaliases, 291
pine, 284
RFC 821, RFC 822, 285
Mail (Cont. ):
sendinail, 283, 284, 291, 292, 293, 297
small, 284
smtp, 178, 285, 300
User Agent (UA), 283, 284
x.400, OSIMF/6000, 295-296
/etc/rc.osimf, 296
makemhs, 296
Mail lists, 429-432
Manual pages:
apropos, 19, 20
catman, 18, 20, 2 1
man, 11, 1 8
nroff, 20
whatis, 19, 20
Maintenance (see Installation and maintenance)
Micro-Channel Adapter (MCA), 72
Microchannel bus, 69, 86, 179
Microcode, 7 1
Modem (see Terminals and modems)
Monitoring and tuning, 391-399
disk i/o, 393-394
asynchronous i/o, 394
i/o pacing, 394
maxpout/minpout, 394
network, 394-396
mbclusters, 395
mbuf, 394-396
no, 395, 399
profiling, 391
tprof, 392
scheduler, scheduling, 69, 73, 272,
getpri/setpri, 399
schedtune, 393, 399
tools and commands, 396-399
AlX, 397
Best/1, 398
monitor, 398
Performance Tool Box/6000, 397
UNIX, 396
virtual memory manager (VMM) ,
computational memory, 393
file memory, 393
lazy swapping, 392
repage fault history, 69, 393
rmss, 397, 399
thrashing, 397, 399
workload profile, 391
Motif (see Xll)
MS/DOS (see DOS)
msg, 331
National Language System (NLS), 12
LANG, 12, 21, 25, 41
LOCALE, 44, 141
ndbm, 235
Network Computing System (NCS),
25 1-255
/etc/rc.ncs, 253, 254, 255
Global Location Broker (GLB), 253
Local Location Broker (LLB), 253
location broker, 251, 252
Network Computing Kernel (NCK), 251
Network Interface Definition Language
(NIDL), 251, 252
Resource License Manager (RLM),
node lock, 253, 254
rlm, 254, 255
rlmadmin, 254, 255
rlmd, 254, 255
rlmrpt, 254, 255
rlmstat, 254, 255
site license, 253, 254
stub, 251
Universal Unique Identifier (UUID ) ,
Network File System (NFS), 53, 57, 178,
229-250, 333
7051 POWER Network Dataserver,
/etc/exports, 13, 230, 232, 237, 249
/etc/rc.nfs, 230, 238
/etc/xtab, 238-239
biod, 230, 231, 232, 233, 249
exportfs, 230, 232, 233
external data representation (XDR),
High Availability Cluster
Multiprocessor (HACMP), 243-244
High Availability Network File System
(HANFS), 230, 231, 240-243
/etc/exports.hanfs, 243
alive messages, 241
hanfs_chgdev, 242
hanfs_chgenet, 242, 250
hanfs_chgtok, 242, 250
hanfs_chscsi, 243, 250
hanfs_mktcpip__prm, 242, 250
hanfs_mktcpip_sec, 242, 250
hanfs_mktcpip_ter, 242, 250
hanfs_starthansfs, 243, 250
mknfsexp, 54, 232, 233
mknfsmnt, 233
nfsd, 230, 231, 249
nfsstat, 239, 250
nfswatch, 239
Network File System (NFS) (Cont. ):
nobody, 232
PC NFS (see DOS)
portinap, 231, 232, 233, 238, 249
Prestoserv, 244
rpc.lockd, 230, 232, 242, 249
rpc.mountd, 232, 250
rpc.statd, 230, 232, 242, 250
showmount, 238-239, 250
Network Information Service (NIS), 230,
/etc/.rootkey, 237, 250
/etclkeystore, 237, 250
/etc/netgroups, 235, 250
/etc/publickey, 236-237
/etc/yp, 235, 250
/etc/yp/publickey.byname, 237
/etc/yp/yppasswd, 236, 250
automount, 238
domainname, 235, 250
keyserv, 237, 238, 250
makedbm, 235
mkclient, 236, 250
mkkeyserv, 237, 250
mkmaster, 236, 250
mkslave, 236
public key encryption, 236
Yellow Page (YP), 234-238
YP map, 235
ypbind, 238
ypinit, 236, 250
ypmake, 235
yppasswd, 236
yppasswdd, 238
yppush, 235
ypupdated, 238
ypserv, 238
ypxfr, 235
Network install server, 35, 53, 54
data.less, 55
diskless, 55, 56, 57
diskless_instupdt, 58
dwm_platform, 55
inst.images directory, 41, 45, 51, 53,
instsrv, 54
lsdclient, 57
lsspot, 56, 59
mkdclient, 57
mkspot, 56, 59
netinst, 53
reference system, 52
Shared Product Object Trees (SPOT),
36, 54, 55
superclient, 55
News, 299-303
/usr/spooVnews, 300, 303
/usr/lib/news/ nntp.access, 300, 303
.newsrc, 301, 303
.signature, 302
Network News Transfer Protocol
(NNTP), 300, 303
news feed, 299
news groups, 301, 302
news readers, 301
nntplink, 301, 303
nntpxmit, 301, 303
Nonvolitile RAM (NVRAM), 63, 67, 68, 74
Object Data Manager (ODM), 8, 68, 70,
72, 74, 8 1-85, 89, 187
/usr/lib/methods, 7 1
cfgmgr (see Devices)
defsys, 71
descriptors, 83
method, 83
object, 83
object class, 83, 88
objrepos directory, 30, 37, 70, 82, 87, 92
ODMDIR, 82, 85, 92
odm_run_method, 70, 84
odmadd, 3 1
odmcreate, 83, 85
odmdelete, 31
odme ODM editor, 84, 92
odmget, 31
odmshow, 31, 88
On-Card Sequence (OCS), 66
Open Software Foundation (OSF), 3, 7, 23
OSF/1, 7, 106
DCE Local File System Episode,
Distributed File System (DFS),
Distributed Management Environment
(DME), 3, 23, 3 1
Palladium, 170
MIT Project Athena, 170
draft commands, 170
Paging and swapping, 121-123
/etc/swapspaces, 122
chps, 122
lsps, 122, 123, 127
mkps, 122, 127
pager, 72
paging spa�, 121-123
rmps, 122
Paging and swapping (Cont. ):
Printing, qdaemon (Cont. ):
digest, 164
qpri, 168
Slibclean, 123
qstatus, 167
swapon, 122, 127
terminal printers, 168
VMM (see Monitoring and tuning)
pcsim (see DOS)
Performance Optimized with Enhanced
Perl, 23
/etc/tty/stty-lion, 168, 171
/usr/lib/INed/termcap/terms.bin pass­
through mode, 168
prtty, 169, 171
tdigest, 169, 171
POSIX, 7, 42 1
virtual printer, 151, 162
Power-On Self-Test (POST), 67, 325
chviprt, 162
PowerPC, 5, 3 12
lsviprt, 162, 171
Printing, 151-172
enq, 166, 1 7 1
lpd, 1 5 2 , 1 5 8 , 169
/etrlhosts.lpd, 165
mkviprt, 162, 169
X station printers, 169
/usr/lpp/x_st_mgr/bin/lpx, 170
Problem Analysis, 401-412
/ect/lpd/locks, 165
backup (see Backups)
writesrv, 165
boot media (see Boot)
print device, 151, 153-156
chgprt, 156
mkprt, 154, 171
crash, 407-408, 412
exceptions, 409
diagnostics, 409-410
parallel, 153
diag, 75, 104, 105, 125, 126, 409
lptest, 156, 163, 171
diagnostic diskettes, 75, 104, 409
serial, 153
splp, 155, 171
print queue/queue devices, 151,
backend, 158-159
dumps, 403-404
/dev/hd7, 403
dump status code LED, 404
master dump table, 403
primary/secondary device, 403
code conversion, 160
sysdumpdev, 404, 412
custom, 162
sysdumpnull, 403
ddi, 162
piobe, 158-159, 171
sysdumpstart, 404, 412
help, 410
piodigest, 162
aixserv, 58, 410
postscript, 160
IBM Support, 410
rembak, 158-159, 171
transcript, 160
/usr/lib/libqb.a, 161
banners, 157-16 1
/usr/lpd/pio/burst, 160, 161, 171
header, trailer, 160
chque, 163
local/remote, 157
aixshort, aixlong, 160
aix2short, aix2long, 160
attshort, attlong, 161
bsdshort, bsdlong, 161, 171
IBMLink, 39, 58, 410
kernel, 406-407
addressing, 407
chgsys, 335, 348, 394
nm, 407, 408, 412
symbols, 407
Light Emitting Diode status (LED), 64,
7 1 , 73, 75, 76, 403
logs, 404-406
/dev/error, 404
lsque, 163
/etc/syslog.conf, 292, 406
mkque, 157, 163
/usr/include/sys/syslog.h, 406
qadm, 166
/var/adm/ras/errlog, 404
qcan, 168
/var/adm/ras/errtmplt, 404
qchk, 167
errclear, 405, 4 1 1
qdaemon, 151, 161, 163, 309, 373
/etc/qconfig, 151, 152, 163-165, 169,
170, 171, 375
errdemon, 404, 411
errinstall, 405
errmsg, 405
Problem Analysis, logs (Cont. ):
Sample code, 433-436
(see Monitoring and tuning)
errpt, 405, 411
errstop, 405, 411
Security and auditing, 351-369
errupdate, 405
access control, 357
syslogd, 292, 406
trace, 264, 406
access control entry (ACE), 358
access control list (ACL), 235, 333,
traceoff, 198, 264, 412
traceon, 198, 264, 412
acledit, 359, 369
trcrpt, 264, 412
aclget, 359, 369
trcstop, 264
aclput, 359, 369
Process management, 269-281
/usr/include/sys/proc.h, 269, 281
at (see cron)
batch queuing
(see Distributed sys-
extended permissions, 358
chgrp, 357, 369
chmod, 357, 369
chown, 357, 369
child, 269
control terminal, 271
base permissions, 358
(see cron)
set um sum, 358
umask, 357, 369
auditing, 354, 364-367
effective, EUID/EGID, 271, 357
/etc/security/audit/config, 366, 368
exec(), 273
/etc/security/audit/events, 366, 368
fork(), 273
/etc/security/audit/objects, 366, 368
(see TCP/IP)
kill, 199, 273, 281, 292
CERT cops
killall, 274, 281
audit, 367, 369
kproc, 271
auditpr, 367, 369
nice, 272, 281
auditselect, 367, 369
nohup, 276, 281
auditstream, 367, 369
grpck, 354, 355, 368
parent, PPID, 269, 271
priority, 272
process group, PGID, 269, 271, 274
process id PID, 69, 269
process table, 69
pwdck, 354, 355, 368
usrck, 354, 355, 368
authentication, 359
alternate authentication, 360
ps, 165, 270, 281
auth_method (login.cfg), 360
real, RUID/RGID, 271
kerberos, 206, 246, 362-363
renice, 272, 281
login, 359
run queue, 272
smart card, 361
tsm, 359
signals, 274-275
state, 272-273
Profile (see Environment)
crypt, 352
passwords, 352
/etc/group, 204, 348, 358
/ect/passwd, 204, 236, 332, 346, 348,
RAM file system, 68, 70, 74
352, 353, 355, 368
rcmd, 98
/etc/security/group, 333, 348
Read Only Storage (ROS), 6 1 , 62
/etc/security/login.cfg, 342, 348, 353,
359, 360, 368
Reboot, 66, 75, 76
Reduced Instruction Set Computer
(RISC), 5
353, 355
Reliability, Availability, and
/etc/security/passwd, 346, 347, 348,
(RAS), 240
Remote File System (RFS), 229
Remote Procedure Call (RPC), 229, 231,
233, 235, 237, 239, 251
rpcinfo, 240, 250
/etc/security/user, 347, 348
pwdadm 353, 368
restrictions, 353
shadow password, 346, 352
policy, 35 1-352
superuser, 7, 354
rexec, 98
/var/adm/sulog, 354, 368
RT/PC, 130
su, 354, 368
Security and auditing (Cont. ):
Trusted Computing Base (TCB), 204,
354, 355-357
System Network Architecture (SNA)
(Cont. ):
/lib/libsna.a, 259, 264
/etc/security/sysck.cfg, 368
/var/sna/snalog.•, 264
Advanced Peer-to-Peer Communication
(see TCP/IP)
tcbck, 355, 356, 368
trusted path, 205, 357
(APPC), 258
boundary node, 257
trusted shell tsh, 205, 357, 368
chsnaobj , 263, 265
Secure Attention Key (SAK), 205,
chsnapw, 263
357, 368
virscan, 367, 369
Shared memory, 307
connection, 259
Control Point (CP), 257
conversation, 259
ipcrm, 307
genkey, 263, 265
ipcs, 307
link, 257
Logical Unit (LU), 257, 258, 259
Shells, 341
csh, 341
mksnapw, 262, 265
ksh, 341, 357
NetView/6000, 263
.re scripts, 135, 348
Network Addressable Unit (NAU), 257,
.cshrc, 341
258, 259
.kshrc, 341
node, 257
std.cshrc, 342
peripheral node, 257
(see Security login.cfg)
(see Security TCB)
peu, 261, 265
Physical Unit (PU), 257, 258, 259
Shutdown, 75, 76, 124
profile, 260
Simple Computer System Interface
rmsnapw, 262, 265
(SCSI), 7 1 , 90-9 1, 103, 107
differential, 90
hscsidd, 72
session, 259
Synchronous Data Link Control
(SDLC), 260
identifier ID, 9 1 , 104, 125
System Resource Manager (SRM), 259
logical unit number (LUN), 71, 91, 104
System Services Control Point (SSCP),
pass through terminator (PTT) , 90, 242
SCSI-1, SCSI-2, 90
single ended, 90
257, 258, 263
verifysna, 261, 265
System Resource Controller (SRC),
swapon, 72
lssrc, 198, 239, 263, 279
System Management Interface Tool
srcmstr, 73, 75, 146, 198, 230, 279,
Syslog (see Problem Analysis)
(SMIT), 7, 23, 25
smit command, 24, 32
smit dialog, 30
smit fast path, 29, 32
emit.log, 28, 32, 46
refresh, 163, 198, 199, 279, 292
startsrc, 163, 165, 198, 208, 2 12 , 230,
238, 254, 262, 279, 28 1
stopsrc, 40, 163, 198, 208, 2 12, 230,
238, 254, 262, 279, 281
subserver, 40, 279
smit menu, 30
subsystem, 40, 75, 278
smit object classes, 30
traceon/traceoff, 198, 279
smit panel, 30
emit.script, 24, 29, 32, 133
smit selector, 30
smitty, 24, 32
System Network Architecture (SNA),
Tape, 93-101
4-mm, 93, 100
8-mm, 93, 95, 100
9-track, 93, 100
/dev/sna, 259, 265
18-track, 100
/etc/objrepos/sna, 260
ansitape, 99
/etc/rc.sna, 262
beginning of tape (BOT), 94, 97
Tape (Cont. ):
block, 94
cmstape, 99
Terminals and modems (Cont. ):
Data Communications Equipment
(DCE), 129, 130
conversion, 96
Data Terminal Equipment (DTE), 129
copytape, 99
DB9, 129, 153
dectp, 99
DB25, 129, 153
density, 96, 97
DTE to DCE pin out, 131
device names, 97
DTE to DTE pin out, 131
digital audio tape (DAT), 93
EIA-CCITT signals, 129-130
end of file (EOF), 97
flow control, 140
end of tape (EOT), 94, 97
High-Function Terminal (HFT), 141-146
exatoc, 99
color palette, 141
file mark, 94
dials, 145
fixed block, 94
display, 144-145
fixed head, 94
/usr/lpp/fonts, 144
helical scan, 94
backforg, 145
ibmtape, 99
chcursor, 145
chfont, 144, 149
inter-record gap, 94
label, 94
chfontpl, 144
magnetophons, 93
lsfont, 144
magtapetools, 100
mkfont, 144
mt, 96
permissions, 98-99
palettevalues, 144
keyboard, 142-143
positioning, 97-98
chhwkbd, 143, 149
print through, 93
chsound, 143, 145, 149
QIC, 93, 100, 101
code-set, locale, 142
rmt, 98
genxlt, 142
rmtlib2, 100
lskbd, 142
short read, 95
mkkbd, 142
tape mark, 94
setmaps, 142, 149
tape ioctl map, 98
tapechk, 99
tapemap, 100
tcopy, 99, 101
tctl, 98, 101
tprobe, 100
swkbd, 142
Light Programmable Function (LPF),
virtual terminals, 145
chnumvt, 146, 149
open shell, 145, 149
variable block, 94
infocmp, 136, 149
with, 100
line discipline, 137
Terminals and modems, 129-149
/etc/gettytab, 133
/etc/ttys, 133
login states:
DELAY, 138, 148
/etc/ttytype, 133
maktty, 133, 148
autobaud, 134
modu 10-pin connector, 130, 153
BAUD rate, 134
clear to send (CTS), 130, 153
cable length, 132
data carrier detect (DCD), 130, 139
captoinfo, 136, 149
data set ready (DSR), 130
Cathode Ray Tube (CRT), 129
data terminal ready (DTR), 130
chgtty, 133, 148
frame ground (FG), 130
clocal, 131
receive data
console, 146
request to send (RTS), 130, 140
chcons, 146, 149
ring indicator (RI), 130
lscons, 146, 149
signal ground (SG), 130
reset procedure, 146
transmit data (TxD), 130
swcons, 146, 149
control characters, 137
modulator/demodulator (modem), 129,
185, 202, 219, 220, 222
Terminals and modems, modulator/de­
modulator (modem) (Cont. ):
Transmission Control Protocol/Internet
Protocol (TCP/IP) (Cont. ):
ate, 141
CREN (Corporation for Research and
carrier, 140
Education Network), 177
ct, 221
Because Its Time Network (BITNET),
cu, 141, 148, 221
kermit, 141, 169
Computer Science Network (CSNET),
settings, 139-140
tip, 140, 221
daemons, subsystems, subservers,
null-modem, 131
parity, 135
domain name service (DNS), 190-194
(see DOS)
/etc/hosts, 189, 190, 2 12, 236
pseudo-TTY PTY, 129, 146
/etc/named.boot, 191, 212
/dev/ptc, 147, 149
/etc/, 192, 212
/dev/pty, 147
/etc/resolv.conf, 194, 212
chgpty, 147, 149
addrs.awk, 192
RJ1 1/RJ45, 132
bind, 190
RS-232C, RS-232D, 129
caching only server, 194
short haul modem, 132
domain address, 189-190
soft carrier, 1 3 1
hosts.awk, 192
stty, 137-138, 140, 146, 149
name server, 190
TERM, 136
named, 191
termcap, 135-137, 149, 193, 212
terminal/printer interposer, 1 3 1
named.rev, 194, 212
terminal type, 135-136
resolver, 194
terminfo, 135-136, 149, 308
resource records
termio, 137
Ethernet, 179-182
tic, 136, 149
bridge, 181
tput, 146, 149
chgenet, 181, 212
tset, 135-136
CSMA/CD, 179
TTY, 129
drop cable, 180
TTY location addressing, 132
IEEE 802.3, 179
untie, 136, 149
repeater, 180
(see Problem Analysis)
router, 181
Translation Lookaside Buffer (TLB),
tap, 180
transceiver, 180
Transmission Control Protocol/Internet
Protocol (TCP/IP), 175-213, 225
/etc/, 187, 201, 202, 212
Fiber Channel Standard (FCS), 187
Fiber Distributed Data Interface
(FDDI), 183-185
/etc/rc.tcpip, 195, 201, 292, 3 13
chgfddi, 185, 212
anonymous ftp, 203-204
dual attach station (DAU), 184
ARPANET (Advanced Research Project
media access control (MAC), 184
Agency Network), 176
Internet Activity Board
single attach station (SAU), 184
Request for Comment (RFC), 176
asynchronous transmission mode
(ATM), 177
bootp, 55, 325, 326
token, 183
ftp, 178
hardware address, 188
High-Performance Parallel Interface
Protocol (HPPI), 186-187
/etc/bootptab, 56, 326
HSX Channel, 186
bootpd, 56
ifconfig, 197, 198
broadcast, 197
cell, 176
chgeth, 197
Copper Distributed Data Interface
(CDDI), 183
inetd, 198-201 , 205, 224, 278
/etc/inetd.conf, 54, 56, 85, 199, 2 12,
3 12, 313
/etc/services, 54, 56, 85, 200, 207,
2 12, 224, 232
Transmission Control Protocol/Internet
Protocol (TCP/IP), inetd (Cont. ):
InetServ, 199
inetexp, 85, 92, 199, 2 12
inetimp, 85, 92, 199, 212
well known ports, 200
International Standards Organization
(ISO), 175
IP number, 188
ipreport, 209, 2 12
iptrace, 209, 212
mbclusters, 210
mbuf, 2 10
netm, 210
netstat, 165, 175, 209, 212
network management, 206-208
/etc/mib_desc, 207
/etc/snmpd_conf, 207
CMOT, 206
Common Management Information
Protocol (CMIP), 206
Management Information Base
CMIB), 206
Network Management Station
(NMS), 206
Netview/6000, 207
Simple Network Management
Protocol (SNMP), 196, 206, 207,
snmpd, 208
NSFNET (National Science Foundation
Network), 176
nslookup, 210, 212
packet, 176
Open Systems Interconnect model
(OSI), 175
ping, 209, 212
Point-to-Point Protocol (PPP), 185-186,
Registration, IP and domain address,
189, 189
routing, 194-197
/etc/gateways, 196, 212
/etc/networks, 196, 212, 236
dynamic routes, 196
EGP, 196
gated, 196
gateways, 194
Hello, 196
netmask, 196, 197
RIP, 196
route, 195, 212
routed, 196, 212
routers, 194
Transmission Control Protocol/Internet
Protocol (TCP/IP), routing (Cont. ):
static routes, 195
subnet, 196
security, 204-206
/etc/hosts.equiv, 205, 235
.rhosts, 205, 388, 206
Computer Emergency Response
Team (CERT), 205-206, 212
cops, 206, 212, 354, 367
kerberos (see Security)
Network Trusted Computing Base
CNTCB), 204-205, 363
RFC 1038, 205
securetcpip, 205
tcpd, 205
Serial Line Internet Protocol (SLIP),
185-186, 202-203, 325
Link Control Protocol CLCP), 186
Network Control Protocol CNCP),
slattach, 203
Serial Optical Channel Converter
(SOCC), 186
opschange, 186, 212
sniffers, 209
TCP/IP stack, 178
telnet, 178, 210
tftp, 55, 62, 326
tftpd, 56
token ring, 182-183
chgtok, 183, 212
IEEE 802.5, 182
lobe, 182, 183
Multistation Access Unit (MAU), 182,
ring, 182, 183
token, 182, 183
wiring closet, 183
User Datagram Protocol (UDP), 178,
230, 231
troff, 18
Users and accounts, 321-349
/etc/group, 204, 348, 358
/etc/motd, 341
/etc/passwd, 204, 236, 332, 346, 348,
352, 353, 355, 368
/etc/security/group, 333, 348
/etc/security/limits, 335, 348
/etc/security/login.cfg, 342, 348, 353,
359, 360, 368
/etc/security/mkuser.default, 340, 348
UNIX-to-UNIX copy program (UUCP)
Users and accounts (Cont):
/etdsecurity/mkuser.sys, 340, 341
/etdsecurity/passwd, 346, 347, 348, 353,
(Cont. ):
Basic Networking Utilities (BNU), 2 15,
commands, 225
/etc/security/user, 347, 348
/home, /u, 332
daemons, 223
adding accounts, 343-344
HoneyDanBer UUCP, 215
hop address, 215, 216
mkuser, 344, 348
uucheck, 2 18, 222
changing accounts, 344-345
uucico, 215, 217, 224, 225, 226
chuser, 345, 346, 348
uucp, 2 16, 224
chgrpmem, 334
chgroup, 334
uucpadm, 217, 226
disk quotas, 336, 373
uucpd, 223, 224, 226
uudaemon.cleanu, 224
edquota, 337, 348
groupquota, 336
uuname, 217
quota, 337, 348
UUNET, 2 16, 217, 226
quota.user, 337
uusched, 2 16, 224, 226
quotacheck, 337, 348
uuxqt, 217, 224, 226
quotaoff, 337, 348
quotaon, 337, 348
Virtual File System (VFS), 73, 115, 229,
repquota, 337, 348
userquota, 336
environment, profile (see Environment)
!etdvfs, 115, 229, 23 1 , 249
getrlimit() , 335
gnode, 115, 229
group identifier (GID), 1 14, 216, 234, 333
vfsops, 115, 229
lsgroup, 334, 348
vnode, 115, 229
vnodeops, 229
mkgroup, 334, 348
Virtual Memory Manager
mkpasswd, 34 7, 348
newgrp, 334, 348
passwords, shadow passwords
(see Monitoring
and tuning)
rmgroup, 334, 348
Vital Product Data (VPD), 69, 7 1 , 72
restbase, 70, 89-90
savebase, 74, 75, 89-90
setgrpmem, 334
setrlimit(), 335
((see Shells)
Wait, 69
nologin, 40
removing users, 345-346
rmuser, 345, 348
user identifier (UID), 1 14, 216, 232,
234, 333
Xl l , 178, 315-328
/usr/bin/Xl l , 3 16, 327
/usr/lib/Xl l , 3 16, 327
uname, 36, 58
/usr/lib/Xl l/fonts, 3 17, 327
UNIX-to-UNIX copy program (UUCP),
/usr/lpp/Xl l , 3 16, 327
215-227, 299
/usr/spooVuucp, 217, 226
/usr/lpp/Xl l/Xamples, 327
.Xauthority, 327
/usr/spool/uucp/.Admin/Foreign, 222
.Xdefaults, 319, 327
/usr/lib/uucp/Devices, 215, 218,
.xi.nitre, 3 19, 327
220-22 1, 226
/usr/lib/uucp/Dialcodes, 218, 219, 221,
223, 226
/usr/lib/uucp/Dialers, 218, 222-223, 226
/usr/lib/uucp/Permissions, 218,
22 1-222, 226
/usr/lib/uucp/Systems, 2 15, 2 18-219,
221, 223, 226
/usr/spool/uucppublic, 216, 226
.Xsession, 319, 327, 328
display postscript, 3 1 7
fonts, 317
Bitmap Distribution Format (BDG),
fonts.alias, 3 1 7
fonts.dir, 3 1 7
mkfontdir, 3 1 7 , 327
Portable Compiled Fonts (PCF), 3 17
XU, fonts (Cont. ):
Server Normal Format (SNF), 317
snftobdf, 317
IBM X Station, 324-327
/usr/lpp/x_st_mgr, 326, 327
/usr/lpp/x_st_mgr/bin/x_st_mgrd, 326,
/usr/lpp/x_st_mgr/bin/, 326
Xll, window manager (Cont. ):
window manager for X uwm, 323
X, Xibm, 3 19, 326
xcolors, 324
xdm, 324, 326, 327
magic cookie, 327
xauth, 327
xhost, 327
MIT X Consortium, 315
xfontsel, 324
startx, 3 19
xinit, 319
System.mwmrc, 317
xterm, aixterm, 3 16, 322, 327, 372
System.xinitrc, 317
xwininfo , 324
widget, 315
window manger, 318-323
motif window manager mwm,
320--32 1, 327
Yellow Pages
open look window manager olwm,
tab window manager twm, 322-323
(YP) (see Network informa­
tion service)
Zombie, 73
James W. DeRoest manages the Advanced Systems
Technology Group at the University of Washington. He
writes the monthly "AIXtensions" column for RS I Magazine
on technical applications for the RS/6000, and is also past
AIX project manager for SHARE Inc., IBM User Group. He
has been involved in IBM AIX development for more than
eight years.
Download PDF
Similar pages