AIX V5.3 system administration best practices

luweinet

AIX V5.3 system administration best practices
A Service Level Agreement provides very important guidance in determining how a server should be configured and managed and, consequently, the best practices to be implemented to configure and manage it. A Service Level Agreement (SLA) is the contract between an IT provider and business users, often established within an ITIL  framework or the like. (Within ITIL, Incident, Problem, and Change Management processes are particularly important. IBM offers services to help optimize IT investments, improve performance, achieve availability objectives, and avoid costly problems. See the Integrated Technology Services  Infrastructure and systems management  web page.) An SLA clearly states the level of IT services which users require. The SLA for a departmental file server is likely to be quite different than that for an enterprise data base server. This page attempts to document best practices which are appropriate across a broad spectrum of servers. Every best practice documented here will not be applicable to every AIX server.
This web page is meant to supplement, not replace, other related best practices which have been published:
·    Service and support best practices for UNIX servers
·    Paging Space Policies and Practice  white paper
·    Best practices for implementing Oracle on AIX:
1.    Oracle 9i & 10g on IBM AIX 5L: Tips & Considerations
2.    Oracle DB & RAC 10gR2 on IBM AIX 5L: Tips and Considerations
3.    Implementing Oracle 10g RAC with ASM on AIX  white paper
4.    Oracle Architecture and Tuning on AIX  white paper
5.    Tuning IBM AIX 5L for an Oracle Database  white paper
·    IBM System p Advanced POWER Virtualization Best Practices  Redpaper
·    IBM eServer Security Planner  and the Strengthening AIX Security: A System-Hardening Approach  white paper
·    Learn 10 good UNIX usage habits  web page
This web page is intended to build upon (not replace) basic UNIX system administration 101:
·    When installing AIX for the first time (or upgrading to a new release level), be sure to install available fixes. See the AIX V5.3 installation best practices web page for more information. When installing AIX on a LUN on a Storage Area Network (SAN), be aware of considerations unique to that environment. See AIX V5.3 boot from SAN for more information.
·    Capture bootable backups periodically (monthly/quarterly?). See AIX V5.3 backup and restore for more information regarding AIX backups.
·    Store some bootable backups off site for recovery if the data center is destroyed.
·    Test the restore process periodically (yearly?) by restoring the most recent bootable backup. Wouldn't want to discover that a backup can not be successfully restored while in the middle of disaster recovery, would we? Doh! It is best for the restore to be tested by someone other than the person who captured the backup, to confirm that restore procedure documentation is adequate.
·    Capture application data backups (volume groups other than rootvg and filesystems not mounted when mksysb is captured).
·    Test application data restore process periodically (yearly?) by restoring the most recent backup. It is best for the restore to be tested by someone other than the person who captured the backup, to confirm that restore procedure documentation is adequate.
·    Monitor the system for errors. Attempt to discover the root cause of every error and to address the cause to minimize the number of errors which occur, while acknowledging that getting a failed system back in operation must sometimes take precedence over collecting the diagnostic information required to determine failure root cause. The primary AIX error log can be displayed using the errpt  command. Please note that an AIX Error Notification  exit can be used to take action (eg, send an email) if a particular error occurs. The primary HMC error log can be displayed from the HMC GUI using Service Applications -> Service Focal Point -> Manage Serviceable Events. Please note that Service Applications -> Service Agent -> Customer Notification can be used to configure an HMC to send an email when a new serviceable event is logged. Please note that alog -t console -o will display messages which have appeared on the AIX system console and alog -t boot -o will display messages which were generated as AIX booted up.
·    Conduct a post mortem after each application outage. Attempt to answer the following questions and then act upon the answers: (1) Was there any warning of this outage? If so, why was the warning not acted upon in time to prevent the outage? (2) What changes can be made to prevent the outage in the future? (3) Are other servers exposed to similar outages?
·    Test operating system, middleware, and application changes on a test server before implementing them in production. The test server's configuration should be as close as possible to the production server's. This is especially important when service level agreements impose availability and/or performance requirements on the production server.
·    Implement procedures to protect servers from intrusion (eg, implement and enforce password standards, force passwords to be changed periodically, enable AIX system auditing and implement procedures to review audit logs regularly, etc). See the AIX Security Expert , the AIX Security checklist , and the Install OpenSSH best practice below.
·    Run commands, applications, cron jobs, etc as root only when absolutely necessary. (Please note that AIX allows sysadmins to define administrative roles which grant non-root users access to functions which normally require root access. For more information, please see the Administrative roles article  in the AIX V5.3 Security manual. And please note that sudo  for AIX is available for download from the AIX Toolbox for Linux Applications  web site.)
·    Install middleware and application software in filesystem(s) dedicated to that purpose. (That is, don't install middleware and applications in /home, /, /usr, /tmp, or /var. Any new filesystem must, of course, have a mount point (eg, /appl) in some existing filesystem.) Even when a vendor packages software in AIX installp format , it is possible to allocate a dedicated filesystem for the software before installing it, if desired. For example, the IBM C compiler for AIX (XL C Enterprise Edition for AIX) is packaged to install in /usr/vac. If a /usr/vac filesystem is allocated and mounted before the C compiler is installed, when installing the compiler the AIX installp command will check the /usr/vac filesystem (rather than the /usr filesystem) for required free space, will allocate more space to the /usr/vac filesystem if free space is insufficient, and will install the compiler's filesets in the directory tree below{{/usr/vac}}.
·    Implement procedures to collect and archive server performance information for capacity planning purposes.
·    Implement procedures to regularly prune files which may grow without limit  (eg, /smit.log, /var/adm/wtmp, and /etc/security/failedlogin) and remove stale files from /tmp (AIX does not remove all files from /tmp at boot time - consider implementing skulker  by uncommenting the line in root's crontab which invokes it, after first reviewing the skulker shell script to understand what it does).
·    Maintain a change control log which documents changes and the date & time they were made. Use this change control log when a new problem crops up to identify changes which may have led to the problem. (Please note that the smit and smitty commands log every action in the /smit.log, which can therefore provide useful supplementary detail to a change management log.)
·    If appropriate, implement an accounting and charge back system which is fair to all users. To this end, please see the Accounting and Auditing on AIX 5L Redbook  and please note that the IBM Tivoli Usage and Accounting Manager  supports AIX Advanced Accounting .
The contents of this web page solely reflect the personal views of the authors and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management. Please use the  Add Comment link at the bottom of the page to provide feedback. Note: Until you sign up and log in (using links in the upper right corner of this web page), you will not see the  Add Comment link and you can not add a comment.

Best Practice:     Don't store local files in / and /usr. (Mount points are okay, though.) And minimize custom changes to executable AIX files in / and /usr (eg, /sbin/rc.boot). And if changes must be made in / and /usr, make sure those changes are documented for the benefit of others who might assume responsibility for administration of the AIX image at some future time.        
Why:     1.    AIX system maintenance updates files in / and /usr. Local customization to executable AIX files in / and /usr may be wiped out when maintenance is applied.
2.    During an version upgrade, it is sometimes desirable to use a Preservation reinstall , which discards the /, /usr, /var, and /tmp filesystems and rebuilds them from scratch. Local files stored in / and /usr will be lost during such a reinstall. (However, please note that in many cases a Migration reinstall  can be used which, unlike a Preservation reinstall, preserves most file systems, including the root volume group, logical volumes, and system configuration files. But even during a Migration reinstall, local files stored in / and /usr may be lost.)
3.    It is best to minimize the amount of space used in / and /usr because the only way to recover unused disk space that has been allocated to / and /usr is to create a bootable backup of rootvg and restore the backup. To understand why, one must understand where AIX stores information about filesystems:
The / and /usr filesystems contain objrepos files, which are containers for the AIX Object Data Manager (ODM) . Among many other things, the ODM contains information about filesystems. It is, therefore, impossible to allocate a temporary new file system, copy the contents of /usr to the new filesystem, unmount the old /usr, rename the old /usr, rename the temporary filesystem to /usr, and mount it as the new /usr. That's because the ODM containers (including the objrepos file in /usr) must be updated when /usr is renamed and the rename operations must occur while both the old and new copies of /usr are not mounted, meaning that the objrepos file in /usr is not accessible.
And the / filesystem can not be unmounted because it contains the mount point for /usr.
The only way to make / and /usr smaller is to create a bootable backup of the entire system and restore the backup, requesting that a smaller /usr be allocated during restore.
It is no longer the case that the only way to recover unused disk space in / and /usr is mksysb backup/restore. New in AIX V5.3, JFS2 file systems can be reduced in size. Reduction is initiated with the chfs command in much the same way that a file system is increased in size. For details, see the information about the -a size attribute in the chfs command article  in the AIX V5.3 documentation. And on 64-bit hardware, the AIX V5.3 installation process will, by default, allocate rootvg filesystems (/, /usr, /home, etc) as JFS2 (rather than JFS). And according to the BOS installation options  article in the AIX V5.3 Installation guide and reference , JFS filesystems in rootvg can be converted to JFS2 during a Preservation reinstall  on 64-bit hardware. And the IBM Tivoli Storage Manager for System Backup and Recovery  product can be used to convert rootvg JFS filesystems to JFS2 while restoring a Sysback backup .        
How:     Before putting installation images in /usr/sys/inst.images, create a /usr/sys/inst.images filesystem and mount it.        
How:     Create a filesystem with a name such as /usr/local in rootvg. Put all local files (eg, /usr/local/bin/ptree) in subdirectories under /usr/local (eg, /usr/local/bin). Add directories containing local executables (eg, /usr/local/bin) to PATH= in /etc/environment so all users have access to local executables.        
How:     If you want to move everything from an existing directory to a filesystem with that directory as its mount point, use the following procedure:
·    Use the smitty crjfsbf fast path to create a large-file enabled filesystem in rootvg that mounts automatically at boot time with a mount point of /mnt.
·    Mount the new filesystem. (Don't forget this step. Ugly things happen if you do!)
·    Use the commands cd  ; find . -print | cpio -lpdm /mnt to copy all existing files from the  directory tree to the new filesystem. Optionally, remove all files from  after verifying that all files have been successfully copied to /mnt.
·    Unmount /mnt.
·    Use the smitty chfs fast path to change the mount point of the new filesystem to .
·    Use ls -ald  to display ownership and permissions of the existing directory.
·    Mount the new  filesystem, which mounts over the old directory. (Best to cd out of  first.)
·    Use ls -ald  again to confirm that ownership and permissions of the filesystem mount point are the same as the directory had and, if not, change ownership & permissions to make it so.      
How:     If/when changes are made in / and /usr, document those changes in a file (eg, /usr/local/README) and update /etc/motd to make all system administrators aware of /usr/local/README (follow links to see examples of /usr/local/README and new /etc/motd content). (You will remember to save /etc/motd as /etc/motd.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.)      
  
Best Practice:     Configure /etc/rc.d/rc2.d/Src.local and /etc/rc.d/rc2.d/Krc.local shell scripts which AIX will run at boot and shutdown, respectively.        
Why:     For reasons described above, it is best not to update any files in / or /usr (such as /sbin/rc.boot) which are shipped in AIX. But sysadmins will certainly want to configure the system to run commands at boot time. Such commands can be placed in /etc/rc.d/rc2.d/Src.local.        
How:     Create /etc/rc.d/rc2.d/Src.local and /etc/rc.d/rc2.d/Krc.local shell scripts owned by root.system with 550 permissions. Src.local will be invoked by AIX just after AIX boots up and Krc.local will be invoked by AIX just before AIX shuts down. Write the scripts carefully and test them thoroughly to make sure they will not hang under any circumstances.
See the Run level script execution  article in the AIX V5.3 Operating system and device management manual for more information regarding run level scripts.
Note: This is one of the few exceptions to the Don't add local files to / and /usr best practice, which should be documented in /usr/local/README or equivalent, as suggested in the best practice.
Note: Execution of run level scripts is driven by the l2:2:wait:/etc/rc.d/rc 2 line in /etc/inittab . If run level scripts do not get invoked at AIX boot time, confirm that the line is still there. And please note that if a run level script hangs, the AIX boot process will hang at that line in /etc/inittab  waiting for the run level script to finish.      
  
Best Practice:     Make sure adequate system dump space is allocated.        
Why:     So that if AIX crashes, diagnostic information is captured to determine the cause of the crash, which usually allows remedial action to be taken to prevent a reoccurrence.        
How:     When AIX V5.3 is first installed, run the /usr/lib/ras/dumpcheck command to make sure adequate dump space has been allocated. If there are issues with dump space, dumpcheck adds an entry to the AIX error log, so use errpt to check for a new error log entry after running dumpcheck. Since the dump space requirement tends to grow as the system gets busier, configure dumpcheck to run regularly at a time when the system is likely to be fairly heavily loaded.
Use crontab -l to confirm that root's crontab is configured to run dumpcheck regularly at an appropriate time and, if not, use crontab -e to update root's crontab.      
  
Best Practice:     Prepare the system so you can initiate a stand-alone dump if AIX hangs (won't allow logins - might or might not respond to a ping).        
Why:     It is too late for preparation when AIX is hung. If AIX hangs and you have no way of initiating a standalone dump, you have no way of collecting diagnostic information to determine why AIX hung.        
How:     If the system is in a secure area (where unauthorized personnel can not gain physical access to it), invoke the AIX command sysdumpdev -K. A standalone dump can then be initiated at any time (even if AIX is hung) using any of the methods described in the System Dump Facility  article in the AIX V5.3 Kernel Extensions and Device Support Programming Concepts manual. Be sure to follow links from the main article to other articles (eg, Start a System Dump).
And there are other ways to initiate a system dump not mentioned in the System Dump Facility article.
On POWER5 LPARs managed by a Hardware Management Console, the Dump option of the Restart Partition function can be used to initiate an AIX stand-alone dump, as documented in the Using the Hardware Management Console to restart AIX logical partitions  article in the POWER5 Partitioning for AIX with an HMC manual.
A system dump can be initiated remotely via a modem or terminal server after enabling the remote reboot facility using the smitty rrbtty fast path. But according to PMR 24881,L6Q, the AIX remote reboot facility does not work for a system (integrated serial) port on a POWER5 system. One should instead enable serial port snoop (see the Enabling serial port snoop  article).
While an LPAR is dumping, dump progress indicators (0c0, 0c2, 0c9, etc) will appear on the HMC and/or in the LCD display. The various possible indicator values are documented the "Dump progress indicators (dump status codes)" section of the AIX IPL progress codes  article in the System p Reference codes manual.      
  
Best Practice:     Never edit /etc/filesystems to define or modify a filesystem definition.        
Why:     AIX keeps information regarding each JFS filesystem not only in /etc/filesystems but also in the LVCB of the logical volume on which the filesystem is defined. (The LVCB (logical volume control block) is in the first 512 bytes of a logical volume. Search the AIX V5.3 Information Center  for more information about the LVCB.)
When a volume group is imported, AIX reads the LVCB of every logical volume in the volume group and adds filesystem definitions to /etc/filesystems. And when a volume group is exported, AIX deletes from /etc/filesystems the definition of filesystems in the volume group.
So if you edit /etc/filesystems to change a filesystem definition, the definition will revert to its original state if/when you export and re-import the volume group. Not a good thing.        
How:     Use smitty manfs or the AIX chfs command to change a filesystem definition. Use smitty manfs to remove a filesystem. (There is a documented AIX rmfs command , but be very careful with it. Like the UNIX rm command, rmfs does not prompt for confirmation. It immediately destroys the specified filesystem!)      
  
Best Practice:     Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file.        
Why:     A prime directive of system administration is, "Always be able to get back where you were before." If you save a copy before changing a file for the first time, it is easy to determine what changes have been made to the file since the system was first installed. And if you save a copy of a file each time you edit it, you can always restore the saved copy to get back where you were.        
How:     Use the command cp -ip  .orig to save a copy of the file in the same directory where the original file resides (eg, cd /etc ; cp -ip hosts hosts.orig). (The cp -i flag warns you if you are about to overwrite an .orig which was saved earlier. Very important to avoid overwriting a previously saved copy of the file! The cp -p flag preserves the date & time last modified - that is, the copy has the same date & time as the original.)
Note: Saving individual files in this way does not obviate the requirement for regularly scheduled system backups.
Note: You might consider saving a copy of /etc/rc, /etc/rc.nfs, /etc/rc.net, /etc/rc.tcpip, /etc/profile,
/etc/inittab, /etc/environment, /etc/passwd, /etc/group, /etc/security/limits, /etc/security/login.cfg,
/etc/security/passwd, /etc/security/user, /etc/security/group, /etc/services, /etc/inetd.conf,
/etc/netsvc.conf, /etc/syslog.conf, /etc/motd, and /etc/filesystems before tailoring the base AIX installation. Most of these files can be updated in the process of tailoring AIX through the smit interface. A copy of these files will be saved by the installbp shell script if/when it is run to install files in the tarball which can be downloaded.     
  
Best Practice:     Configure the root user so you always know which system you are on and which directory you are in.        
Why:     If you are managing systems over a network, it is very important to know what system you are on. It is, therefore, important that root's shell prompt always remind you where you are. (The odd print command in /.profile will set the text in the title bar of an xterm or aixterm window to hostname:username when you log in through an xterm or aixterm window on another system.)        
How:     Assuming you configure the root user to run ksh at login, add files /.profile and /.kshrc (follow links to see file contents). Set ownership & permissions to root.system & rw-r-----.
Note: After logging in to the root userid through CDE (GUI Desktop) on a graphics console for the first time, edit /.dtprofile to uncomment the last line (# DTSOURCEPROFILE=true) so that /.profile will get executed every time root logs in. (You did remember to save /.dtprofile as /.dtprofile.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.)      
  
Best Practice:     After installing base AIX, install optional components by installing bundles rather than filesets.        
Why:     Easier to select one or a few bundles rather than selecting hundreds of filesets.        
How:     Use the smit Install Software Bundle menu (accessed via the smitty install_bundle fast path) to install bundles from the AIX installation media.      
  
Best Practice:     Install a few individual filesets in addition to bundles.        
Why:     The filesets are not part of every bundle and provide the following valuable functions:
·    bos.dosutil (support for AIX dosdir, dosread, and doswrite commands to read and write DOS-format diskettes - only useful if System p server hardware includes a 3.5-inch diskette drive)
·    bos.adt.samples (the vmtune command and other performance tools, but please note that most vmtune command functions have been replaced by the vmo, ioo, and noo commands in AIX V5.3)
·    X11.apps.config (needed for SSH X11 forwarding to work)
·    bos.adt.base (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    bos.adt.lib (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    bos.adt.libm (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    bos.perf.perfstat (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    bos.perf.libperfstat (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    bos.perf.proctools (required by Oracle according to the Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit) )
·    Java14.sdk (required by AIX Security Expert  and other software)
·    sysmgt.websm.rte (required by AIX Security Expert )
·    sysmgt.websm.apps (required by AIX Security Expert )
·    sysmgt.websm.icons (required by AIX Security Expert )
·    sysmgt.websm.framework (required by AIX Security Expert )
·    sysmgtlib.framework.core (required by AIX Security Expert )
·    sysmgt.sguide.rte (required by AIX Security Expert )
·    bos.games (the UNIX fortune command)      
How:     Use the smit Install and Update from ALL Available Software menu (accessed via the smitty install_all fast path) to install additional filesets from the AIX installation media.      
  
Best Practice:     After installing any new optional AIX filesets, always reinstall the current AIX Technology Level and Service Pack.        
Why:     It is important to keep all system components at a consistent fix level. When an AIX Technology Level or Service Pack is installed, updates are applied only to filesets installed on the system when Technology Level or Service Pack installation occurs. When new optional AIX filesets are installed, they are installed at the fix level available on the base AIX installation media, which is likely below the AIX Technology Level and Service Pack at which the system is currently running.        
How:     Use the smit Update Installed Software to Latest Level (Update All) menu (accessed via the smitty update_all fast path) to reinstall AIX Technology Level media.
Caution: Use smitty update_all only against AIX Technology Level media, not against other media received from the IBM Support Center  which contains miscellaneous fixes, unless instructed to do so by the Support Center .      
  
Best Practice:     Before creating any userids for which /bin/ksh is the default shell, update the /usr/lib/security/mkuser.sys file shipped with AIX to install a profile other than the system default when a new userid is created.        
Why:     The system default user profile (/etc/security/.profile) assigns an absolute $PATH, which defeats any attempt to introduce a new directory into all users' $PATHs by updating the PATH= statement in /etc/environment.        
How:     Replace /usr/lib/security/mkuser.sys (follow link to see new mkuser.sys content). (You did remember to save /usr/lib/security/mkuser.sys as /usr/lib/security/mkuser.sys.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.) Verify that mkuser.sys.orig is as expected (follow link to see old mkuser.sys content).
Add files /etc/security/.profile.ksh and /etc/security/.kshrc (follow links to see file contents). Make sure .profile.ksh & .kshrc have the same ownership & permissions as /etc/security/.profile (root.security & rw-rw----).
If you wish to create a user with a default shell other than /bin/ksh, you should make appropriate changes to /usr/lib/security/mkuser.sys for other default shell(s) and add the other default profile(s) to /etc/security.
Note: This is one of the few exceptions to the Don't add local files to / and /usr best practice, which should be documented in /usr/local/README or equivalent, as suggested in the best practice.      
  
Best Practice:     Install OpenSSH.        
Why:     To avoid use of unsecure protocols such as FTP and telnet, which send unencrypted passwords (including root's password) over TCP/IP networks. See the OpenSSH  web page for details.        
How:     The OpenSSH is now bundled with AIX  web page has detailed instructions for installing OpenSSH on AIX, although the web page is now somewhat out of date. Here is a summary of the current suggested approach:
1.    Download the latest OpenSSL filesets from the AIX Web Download Pack Programs web page . (An IBM ID is required for access. Registering for an IBM ID is quick and easy - just follow the register now link. If you don't want to register for an IBM ID, OpenSSL is shipped with AIX on the AIX Toolbox for Linux Applications CD, although the version on that CD might not have all available patches.) When installing using smit or smitty, answer Yes to ACCEPT new license agreements?
2.    Use the smitty install fast path to install the OpenSSH filesets from the AIX 5L V5.3 Expansion Pack CD . Or to get a version with latest available patches, download the latest OpenSSH filesets in installp format from the OpenSSH on AIX  web page on SourceForge. Select the latest version of Open Secure Shell (Openssh-4.5p1-r2 as of 12/19/2007). When installing using smit or smitty, answer Yes to ACCEPT new license agreements?      
      As of 3/19/2008, a file named openssh-4.5p1-r2.tar.z is delivered by the OpenSSH on AIX web page on SourceForge, but AIX zcat does not cleanly handle files with a .z suffix:
# zcat openssh-4.5p1-r2.tar.z \| tar -tvf-
openssh-4.5p1-r2.tar.z.Z: A file or directory in the path name does not exist.
tar: Unexpected end-of-file while reading from the storage media.
#
The best way to handle a .z file is to use GNU zcat, which is now installed with base AIX: /opt/freeware/bin/zcat openssh-4.5p1-r2.tar.z | tar -tvf-. Another option is to change the file suffix to .Z so AIX zcat can handle it: mv -i openssh-4.5p1-r2.tar.z openssh-4.5p1-r2.tar.Z; /opt/freeware/bin/zcat openssh-4.5p1-r2.tar.Z | tar -tvf-
Note: If you need an SSH client for Windows XP, PuTTY  is free and seems to work well. If you have experience with PuTTY on Microsoft Vista, please use the  Add Comment link at the bottom of the page to document that experience here. Note: Until you sign up and log in (using links in the upper right corner of this web page), you will not see the  Add Comment link and you can not add a comment.
Note: If you prefer to build SSH from open source rather than download executables, the Deploying OpenSSH on AIX  web page has instructions for doing so.      
  
Best Practice:     Update $MANPATH for all users so that the man  command can find man pages installed by AIX Toolbox for Linux Applications  software.        
Why:     Useability.        
How:     Add the line MANPATH=/opt/freeware/man to /etc/environment. (You did remember to save /etc/environment as /etc/environment.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.)
Note: It may be appropriate to add more directories to MANPATH. For example, if you install the IBM XL C/C++ Compiler Man Pages--U.S. English, you should add :/usr/vacpp/man/en_US to MANPATH. If you download and install Apache from the AIX Toolbox for Linux Applications  web site, you should add :/opt/freeware/apache/man to MANPATH.
There is no need to add the /usr/share/man directory to MANPATH, since the man  command searches /usr/share/man before searching the directories listed in $MANPATH. And directories such as /opt/csm/man are not needed in MANPATH since csm filesets (eg, csm.dsh) add soft links to the /usr/share/man directory tree pointing to the man pages in the /opt/csm/man directory tree.
Note: Bull freeware installation instructions  suggest that an export MANPATH command must be added to /etc/profile, but this is not necessary because ksh exports MANPATH by default if it is set. To confirm that MANPATH is exported by default after adding MANPATH to /etc/environment, login, issue the command export, and observe that MANPATH is displayed (among many other environment variables).      
  
Best Practice:     Configure TCP/IP to search local /etc/hosts to resolve a host name before trying DNS.        
Why:     If your network folks hose up DNS, you want to be able to circumvent the problem locally and minimize impact on your servers while they are fixing the problem.        
How:     There are two options for name resolution tuning :
1.    Add a line containing hosts=local,bind to /etc/netsvc.conf. (You did remember to save /etc/netsvc.conf as /etc/netsvc.conf.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.) This update takes effect as soon as the change is made.
2.    Add a line containing NSORDER=local,bind to /etc/environment. (You did remember to save /etc/environment as /etc/environment.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.) This update takes effect only as each daemon is stopped & restarted and as users logoff & log back in. The easiest way to restart all daemons is to reboot AIX.
It is not necessary to add an export NSORDER command to /etc/profile for ksh users, since ksh exports NSORDER by default if it is set.        
     Note: Leave the loopback/localhost entry in /etc/hosts and add only an entry for your local hostname unless, of course, it becomes necessary to add entries to circumvent a DNS problem.
Note: Before and after making this change, issue the command host  for every  defined in /etc/hosts. Update entries in /etc/hosts so that the host  command generates the same output with and without the new line in /etc/netsvc.conf. That is, make sure your /etc/hosts is consistent with DNS.      
  
Best Practice:     Configure AIX Workload Manager (WLM) to reserve CPU for root.        
Why:     So that if/when many application processes are consuming all available CPU, it will still be possible to log in to the server as root and take action quickly.        
How:     Here are instructions cribbed from the Setting up AIX Workload Manager in 30 minutes  article on the IBM developerWorks  web site:
# wlmcntrl -q    # Confirm that WLM is not yet running
1495-054 WLM is stopped
# lsclass -f    # Confirm that default WLM class config has not been changed
System:
        memorymin = 1
Default:
Shared:
#
# wlmcntrl -p    # Start WLM in passive mode
#
# # Make sure root users are in System class and all other users are in Default class
# ps -e -o class,pid,tag,user,group,comm,args | sort | more
CLASS          PID TAG                 USER    GROUP COMMAND  COMMAND
Default      12680 -                 daemon      sys rpc.statd /usr/sbin/rpc.statd -d 0 -t 50
Default      16980 -                  guest      usr sleep    sleep 30
Default      17972 -                  guest      usr bsh      -bsh
Default      18408 -                  guest      usr sshd     sshd: guest@pts/1
System              1 -                   root   system init     /etc/init
System        3658 -                   root   system dtlogin  dtlogin         -daemon
System        4922 -                   root   system dtlogin  /usr/dt/bin/dtlogin -daemon
System        5300 -                   root   system syncd    /usr/sbin/syncd 60
...
System       19488 -                   root   system sshd     sshd: root@pts/0
System       20836 -                   root   system inetd    /usr/sbin/inetd
#
# # Move Default class down to tier one, so it is below the System class, which gives
# # root users first crack at CPU resources
# chclass -a tier=1 Default
#
# wlmcntrl -u    # Tell WLM to pick up the configuration change
# lsclass -f    # Confirm that Default tier change happened
System:
        memorymin = 1
Default:
        tier   = 1
Shared:
#
# topas -w 2    # Start topas and display top two busiest WLM classes
...
#
# wlmcntrl -a    # Start WLM in active mode
Use
# smitty wlmstart
...
#
to configure WLM so it gets started at AIX boot time.
If issues with WLM are suspected, use
# wlmcntrl -p
to put WLM back in passive mode or use
# wlmcntrl -o
to disable WLM completely.
Please note that this best practice has a down side - root can consume all available CPU time if enough work is lauched. While WLM remains enabled, any root process which uses lots of CPU time will have a much greater impact on server performance than before.      
  
Best Practice:     When configuring an ASCII console/terminal, configure AIX to set the TERM= shell environment variable correctly during login from that terminal.        
Why:     Ease of use.        
How:     When defining an ASCII console/terminal, always set the tty's TERMINAL type field (on the Change / Show Characteristics of a TTY menu accessed via the smitty chgtty fast path) to the appropriate terminal type. For example, if the terminal is a VT100, set the TERMINAL type field to vt100}. When defining a serial port for a modem, leave the {{TERMINAL type field set to dumb. Discourage users from setting TERM= in their .profile except as a conditional statement (eg, if [ "$TERM" = "dumb" ] ; then TERM=vt100 ; fi)      
  
Best Practice:     Add useful shell scripts to /usr/local/bin and make them available to all users.        
Why:     Ease of use.        
How:     As described in the Don't add local files to / and /usr best practice above, create a /usr/local filesystem. Create a /usr/local/bin directory in the filesystem. Add files /usr/local/bin/ptree and /usr/local/bin/stopcmd (follow links to see file contents) with ownership & permissions of bin.bin & r-xr-xr-x.
Add /usr/local/bin near the end of PATH= in /etc/environment. (You did remember to save /etc/environment as /etc/environment.orig first, right? - See the Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file best practice.) If you implemented the Update the /usr/lib/security/mkuser.sys file shipped with AIX to install a profile other than the system default when a new userid is created best practice, the $PATH set in /etc/environment will be inherited by all users.
Note: Updating PATH= in /etc/environment is completely effective only if the /usr/lib/security/mkuser.sys file was updated before any userids were created with /bin/ksh as the default shell and if root's profile has been changed so that it does not set an absolute $PATH.
Note: Because these files are added to the /usr/local filesystem in rootvg, this is not an exception to the Don't add local files to / and /usr best practice.      
  
Best Practice:     Install lsof  (LiSt Open Files) utility.        
Why:     Useful in diagnosing a variety of functional and performance problems. For example, when a filesystem can not be unmounted because files in it are open, lsof can be used to identify the files which are open and the processes which are holding them open.        
How:     Download the lsof  installation image (and Readme) from the AIX Web Download Pack Programs web page . Follow installation instructions in the Readme.
When first installed, lsof  might fail with:
ibm:/ # lsof /home
lsof: FATAL: compiled for a kernel of 32 bit size.
      The bit size of this kernel is 64.
ibm:/ #
The README.txt file included in lsof-4.7.tar.Z says:
The lsof fileset contains two lsof binaries "lsof" and "lsof64".
So use the appropriate binaries depending on the type of your kernel bits.
i.e use lsof for 32-bit kernel and lsof64 for 64 bit kernel.
So:
ibm:/ # lslpp -f lsof.base
  Fileset               File
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  lsof.base 4.7.0.0     /usr/sbin/lsof
                        /usr/sbin/lsof64
ibm:/ # bootinfo -K
64                # Note: This says the AIX kernel is 64-bit
ibm:/ # cd /usr/sbin
ibm:/usr/sbin # mv -i lsof lsof32
ibm:/usr/sbin # mv -i lsof64 lsof
ibm:/usr/sbin # lsof /home
lsof: WARNING: access /.lsof_ibm: No such file or directory
lsof: WARNING: created device cache file: /.lsof_ibm
ibm:/usr/sbin #     
  
Best Practice:     Install a web browser.        
Why:     A web browser is an important end-user and sysadmin tool.        
How:     Install the Mozilla browser from the Mozilla V1.7.3 Web Browser and Application Suite for AIX CD (or download the latest Mozilla or Firefox browser from the Web browsers for AIX download site ).
See the Installing Mozilla on AIX  Technote for Mozilla installation instructions.
Please note that root's mozilla cache is placed in /.mozilla by default. To preserve space in / and to avoid filling it up, after installing Mozilla consider creating a /home/root/.mozilla directory, creating a symbolic link to it from /.mozilla, and confirming that root's mozilla will run okay with the soft-linked directory.
Use the smitty change_documentation_services to specify Mozilla as the system default browser once Mozilla is installed.      
  
Best Practice:     Install Adobe Acrobat reader.        
Why:     A .PDF reader is an important end-user and sysadmin tool.        
How:     Download the Adobe Acrobat Reader V7.0.8 for IBM AIX from the Adobe Reader download site .
To install Acrobat, run INSTALL in the AdobeReader directory after unpacking the downloaded archive.
See the Don't add local files to / and /usr best practice above, which suggests creating a /usr/local filesystem and installing software such as Adobe Acrobat in that filesystem (in, for example, directory /usr/local/Acrobat7). Add a symbolic link from /usr/local/bin/acroread to the Adobe acroread executable. (If you implemented the Add useful shell scripts to /usr/local/bin and make them available to all users best practice, the /usr/local/bin directory will already exist and all users will have /usr/local/bin in their $PATHs.)      
  
Best Practice:     Use smitty crcdrfs to create a CD-ROM filesystem with a mount point of /cdrom.        
Why:     Sooner or later, you will want to mount a CD. Once you have created the /cdrom filesystem, a CD can be mounted by root user with mount /cdrom. Why wait until you need to mount a CD to figure out how to create the filesystem?
But please note that the installp command (and the smit install menus which use it) assume that a CD is not mounted. Mounting a CD before attempting to install something from it can result in cryptic (that is, difficult to diagnose) behavior from the installp command at some AIX patch levels.        
How:     Use the smitty crcdrfs fast path.      


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/6408/showart_1134677.html