Configuring LVM Filesystems for Maximimum Disk Availability

Audience: Systems Administrators Date: March 1999 The following item was found on an internal IBM web site. It describes how to configure RS/6000 disk drives for the maximum AVAILABILITY. You will note that these settings tradeoff I/O performance for availability. 1. Use 3 copies. 2. Write-verify: YES. Verify each write by performing a follow-up read. 3. INTER-policy: MINIMUM. This specifies that only as many physical volumes as there are copies should be used to 4. contain the logical volume. 5. Scheduling Policy: SEQUENTIAL. This requires the write of each copy to be performed sequentially, increasing the likeliness that at least one copy completes prior to a system failure. (Comment: this setting limits reads from only the primary mirror. In contrast, the PARALLEL option allows reads to occur from any mirror copy, which can improve read performance.) 6. Allocate each logical partition copy on a separate disk: YES. This setting will not allow any two copies of the same data to reside on the same disk.

AIX Tip of the Week: Configuring LVM Filesystems for Optimum Performance
Audience: Systems Administrators Date: March 1999 Last weeks tip involved configuring disks for optimum availability. This tip covers configuring disks for optimum performance. To configure an RS/6000 system for the highest disk I/O performance, create the logical volumes using the following guidelines. 1. 2. 3. 4. Create logical volumes with only 1 copy (do not mirror partitions) Set "write-verify": NO INTRA-policy: CENTER INTER-policy: MAXIMUM

Note the tradeoffs between higher performance and availability. Typical systems are configured somewhere between the two extremes presented in the AIX Tips. The following attachment explains the reasoning behind each of these selections. (From IBM ITEM Q494227)

AIX Tip of the Week: Customizing Modems in AIX with Hayes Commands
Audience: AIX Administrators Date: June 11, 1999

Modem settings often need to be customized using Hayes commands. The following tip demonstrates one method of sending Hayes commands to a modem in AIX. In this example, we assume we want to enable a dial-in line on tty0. Step 1: Configure tty0 via "smit mktty". Set "Enable Login" to "enable". Set the remaining parameters as appropriate. Step 2: Define tty0 to UUCP by adding the following line to the /etc/uucp/Devices file. UUCP is part of the base AIX operating system, which may or may not be installed by default depending on AIX level. Note the characters are case sensitive.
Direct tty0 - 9600 direct

Step 3: Disable the port to allow Hayes commands to be sent to the modem: pdisable tty0. Step 4: Send Hayes commands using the "cu" command. The "cu" command starts an interactive session with the modem. In this case, the Hayes command tells the modem to autoanswer after one ring. The session is terminated with a "tilde" followed by a "period".
cu -ml tty0 ats0=1 ~.

Step 5: Enable the tty0 port: penable tty0

AIX Tip of the Week: Viewing a Remote Screen Using the AIX portmir Command
Audience: AIX Administrators and End Users Date: May 1999 The AIX portmir command can be used to mirror a remote screen on a local terminal. This is a useful diagnostic tool for viewing a remote end user's screen, or possibly mirroring consoles. As a practical matter, both local and remote terminal should be of the same type to avoid screen formatting problems. The portmir command is available in AIX 4.2.1+. See the AIX documentation for more information.

Comment: although the portmir documentation lists "tty's" as the supported terminal type, I've been able to get pseudo-terminals (pts) to work by substituting the appropriate "pts/n" for "ttyn."

Reconfiguring AIX's System Dump

Audience: AIX Administators Date: July 24, 1999

I generally recommend changing the default setup for AIX's system dump facility. The default setting stops the system from rebooting after an unexpected halt. A system dump copies selected areas of the kernel to disk (or tape) if the system halts unexpectedly. The default dump location is the page space. When a system attempts to reboot after an unexpected halt, it stops to warn the operator the page space contains a dump. The reboot stops until the operator tells the system what do to with the dump. The dump facility can be reconfigured to reboot automatically by changing the dump device from the page space to a raw partition on the disk. The procedure for making this change is in the attached HTML file. See your AIX documentation for more information.

Managing System Dump Devices [manage.dump.32-42.cmd]

Managing System Dump Devices ------------------------------------------------------------------------------Contents About this document Related documentation Managing system dump devices Determining proper size for dump device Setting a tape drive as a dump device Extended options in AIX 4.x Dumping a mirrored logical volume Remote dumps over to a network ------------------------------------------------------------------------------About this document This document discusses how to manage storage devices used by AIX to store a system dump in the event of a catastrophic operating system software failure. Its intent is to help the system administrator ensure that a system dump will be complete and usable for troubleshooting purposes. This document applies to AIX versions 3.2 and 4.x. ------------------------------------------------------------------------------Related documentation For more in-depth coverage of this subject, the following IBM documents are recommended: o AIX Version 4.1 Software Problem Debugging and Reporting for the RISC System/6000 (GG24-2513) o Common Diagnostics and Service Guide (SA23-2687) o Diagnostic Information For Micro Channel Bus Systems (SA23-2765) o Diagnostic Information for Multiple Bus Systems (SA38-0509) o Problem Solving Guide and Reference (SA23-2204) (SA23-2606) o System Management Guide, V3.2 (SC23-2457) o System Management Guide, V4 (SC23-2525) -------------------------------------------------------------------------------

Managing system dump devices When an unexpected system halt occurs, the system dump facility automatically copies selected areas of kernel data to the primary dump device. These areas include kernel segment 0 as well as other areas registered in the Master Dump Table by kernel modules or kernel extensions. There are two dumps devices (a primary and secondary). To view information about the current dump devices, enter: sysdumpdev -l Example: # sysdumpdev -l primary secondary /dev/hd7 /dev/sysdumpnull

In this example, the primary dump device is the logical volume hd7. When the operating system is installed, the primary dump device is automatically configured. In AIX 3.2, the default primary dump device is /dev/hd7. This is a logical volume dedicated for system dumps. In AIX 4.x, the default dump device is /dev/hd6. This is the primary paging space logical volume. In both AIX 3.2 and 4.x the default secondary dump device is /dev/sysdumpnull. This is a null device and any dump written to this device is lost. ------------------------------------------------------------------------------Determining proper size for dump device The default dump device created for system use may NOT be large enough for a complete dump. To determine how large the dump device is, first determine what the primary dump device is using the procedure mentioned in this section. If the dump device is not currently set to a tape drive, then this device should be a logical volume. To retrieve information about this logical volume enter: lslv <LOGICAL VOLUME NAME> Example: lslv hd7 This command will return a screen of information. Obtain the values for LPs and PP SIZE. Multiply these two values to get the size of the dump device in megabytes. Next, determine how large the dump device for your machine should be. To view an estimate of how large the dump device should be, enter: sysdumpdev -e Example: # sysdumpdev -e Estimated dump size in bytes: 4526080

NOTE: This value will be what the CURRENT running machine would require. This value can change based on the activity of the machine. It is best to run this command when the machine is under its heaviest work load. This will return a value in bytes. The primary dump device should be a size that is at or greater than the value returned. In this case, the dump space needs to be 4.5 megabytes. A normal system will have a physical partition size of 4 megabytes for rootvg. The dump device has to be increased in multiples of this size. A dump space of 4 megabytes would not be large enough to hold this dump, so the next size would have to be 8 megabytes. At AIX levels prior to 3.2.4, this command option may not be available. If this is the case, a general rule of thumb is to make the dump device 1/4 of the size of your total RAM. To obtain the size of your total RAM, enter: bootinfo -r If the dump device is a standard dump logical volume, such as hd7, then use the command extendlv to increase its size. If it is the primary paging space hd6, use the command chps. ------------------------------------------------------------------------------Setting a tape drive as a dump device If you do not have sufficient space on the system to store a dump, use a tape drive as the dump device. To accomplish this, put a blank tape in the desired tape drive and enter: sysdumpdev -Pp /dev/rmt# In this case, rmt# refers to the specific tape drive you want to use for this (for example, rmt0, rmt1, rmt2, etc.) Be aware that the tape drive will not be usable by any other application until you re-assign the dump device to another location. ------------------------------------------------------------------------------Extended options in AIX 4.x At AIX 4.x, there are three extra attributes that are not available in AIX 3.2. sysdumpdev -l will show these extra options. Example: # sysdumpdev -l primary secondary copy directory forced copy flag always allow dump /dev/hd6 /dev/sysdumpnull /var/adm/ras TRUE TRUE

The copy directory entry specifies a filesystem in the rootvg volume group where the dump will be copied upon reboot after a system dump. This only applies if the primary dump is the primary paging space (hd6). The force copy flag entry specifies if the system will prompt you to copy this dump to external media if there is not enough space in the specified filesystem. If this is set to FALSE and the system cannot copy this dump to the filesystem, then it will discard the contents of the dump. The always allow dump flag is a security measure. If this is set to FALSE, then

the only way to force a system dump would be to turn the service key to Service and then press Reset. It also prevents forcing a dump of any kind on machines with no service key, such as all PCI based machines. If the primary dump device is the primary paging device, the only way it can copy the dump to the filesystem save area is if there is enough free space in that filesystem. The free space in the filesystem can be determined with the df command. If the free space in that filesystem is not at least as large as the space required for the dump (sysdumpdev -e), then either increase the size of that filesystem to have enough free space, remove files in that filesystem until enough free space is available, or move the save area to another filesystem with the required space. The latter can be accomplished with the sysdumpdev command. This filesystem must be in the rootvg volume group. ------------------------------------------------------------------------------Dumping to a mirrored logical volume AIX does not support dumping to a mirrored logical volume. This is because the dump only dumps to one copy of the logical volume. In other words, one of the mirrors will contain the dump. Since the logical volume is not being handled like a mirrored logical volume, the new data written, (for example, the dump) will not be synched with the other mirrors. Thus, when crash tries to read the dump, it can obtain data from both mirrors, only one of which actually contains the dump. That is, crash sees good dump data mixed with garbage data, and will not read the dump. By splitting up the logical volume, creating one logical volume per copy of the original, one of them would contain a good dump. This can be accomplished with the splitlvcopy command. The procedure for splitting the logical volume is: Run lslv to get the LV IDENTIFIER: # lslv hd7 LOGICAL VOLUME: hd7 LV IDENTIFIER: 0000335216021417.12 VG STATE: active/complete TYPE: dump MAX LPs: 128 COPIES: 2 LPs: 4 STALE PPs: 0 INTER-POLICY: minimum INTRA-POLICY: middle MOUNT POINT: N/A MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: no VOLUME GROUP: PERMISSION: LV STATE: WRITE VERIFY: PP SIZE: SCHED POLICY: PPs: BB POLICY: RELOCATABLE: UPPER BOUND: LABEL: rootvg read/write opened/syncd off 4 megabyte(s) parallel 8 relocatable yes 32 None

Notice that there are two copies. This means that there is one mirror. Use the splitlvcopy command to split the logical volume, hd7 in this case, into two logical volumes. # splitlvcopy 0000335216021417.12 1 A message similar to the following may appear: splitlvcopy: WARNING! The logical volume being split, hd7, is open. Splitting an open logical volume may cause data loss or corruption and is not supported by IBM. IBM will not be held responsible for data loss or corruption caused by splitting an open logical volume. Do you wish to continue? y(es) n(o)? lv02 Enter y. The command will complete and show the name of the new logical volume

it created, e.g., lv02. At this point, hd7 contains one copy of the original hd7, and lv02 contains the other. This is exactly what we need. If there had been three copies, shown by lslv, then lv02 would contain two copies of the original hd7. Run crash on /dev/hd7 first to see if that was the right copy. If crash does not give error messages, the correct one has been found. If the dump is unusable, run crash on /dev/lv02, if lv02 has only one copy, that is, if the original hd7 contained two copies. If lv02 has two copies now, because the original hd7 had 3, run lslv /dev/lv02 to get the LV IDENTIFIER. Then run splitlvcopy <LVID> 1 to split lv02 to obtain one copy of each of its mirrors. This may not work for dumps taken to mirrored paging space, because the pager may have already overwritten the dump. ------------------------------------------------------------------------------Remote dumps over a network Currently, the system dump does not handle ARP requests received from the server, or the gateway used, during the dump. If an ARP request is received while taking a dump, this causes the dump to hang. If your system takes a system dump and hangs on 0c7, this is likely the problem. At this point, power the system off and reboot. To avoid this problem, create a permanent ARP entry for the client (the dumping machine) on the server or gateway. The machine that needs the permanent ARP entry is the machine on the same local network or ring as the client. This can be thought of as the logical server, since, if it is not the real server, the dump data must pass through it to get to the real server. NOTE: "Real server" refers to the machine designated in the remote dump specification on the client. Run the following steps on the real server to establish a permanent ARP entry on the server or gateway machine. 1. Ensure an ARP entry exists by pinging the client. Example: ping myclient.xyz.com 2. Use arp -a to see the ARP table. Example: # arp -a The following four lines of text should appear as two full lines. myclient.xyz.com (128.3.56.9) at 10:0:5a:9:e:7d [token ring] myserver.xyz.com(128.3.56.20) at 10:0:5a:8f:12:bf [token ring]| 3. Now use the arp command to make the dumping client's entry permanent. Example: # arp -s 802.5 myclient.xyz.com 10:0:5a:9:e:7d The 802.5 refers to a token-ring network. Valid network types are listed in the ARP documentation of the product documentation, and are currently ether(802.3), fddi, and 802.5. NOTE: If the dump hangs and the client must be rebooted, the partial dump on

the server may still be useful. Techdocs Ref:90605210214768 4FAX Ref:6221

Changing DNS Search Order

Audience: AIX Administrators Date: July 30, 1999 By default, AIX resolves TCP/IP host names and addresses in the following order: 1. DNS 2. NIS 3. /etc/hosts. There are situations where you can improve performance and availability by reordering the search order. Here are two methods for changing the defaul

Early Adopter Experiences with AIX 4.3.3

Audience: AIX Administrators Date: November 5, 1999 As an early adopter of AIX 4.3.3, I've found it to be a solid operating system that works as advertised. However, I encountered three glitches after migrating from AIX 4.3.2 to 4.3.3. I've compiled a list of these issues for other early adopters

"oslevel" command still shows AIX 4.3.2 after the migration The C compiler works only for "root" id "docsearch" for Web based documentation stops working after the upgrade

Most, if not all, of the issues were related to a migration install, rather than a fresh install. If you observe any of these symptoms, see the below for the resolution. Despite the minor glitches, I highly recommend AIX 4.3.3! For more current information, visit the AIX 4.3 Tip page.

AIX 4.3 Installation Tips

October 8, 1999 This document contains the latest tips for successful installation of AIX 4.3, and will be updated as new tips become available. APARs and PTFs mentioned in this document, when available, can be obtained from FixDist. Information on obtaining and using FixDist is available at the following URL.
http://service.software.ibm.com/rs6k/fixes.html

oslevel May Not Indicate 4.3.3.0 ifor_ls.msg Installation Failures bos.loc.utf.ZH_CN Update Failure perfagent.tools Update Failure sysmgt.websm.apps Update Failure Installation Failures from NFS Mounted CD AIX Fast Connect in DCE Environment LED E1DC During Boot on CHRP Systems Firmware Corruption Using feprom_update Exec Format Error Running Netscape Communicator WebSphere V3.0 with AIX JDK 1.1.8 C Compiler Works Only for "root" ID after Upgrade to 4.3.3 Web Based AIX Documentation "docsearch" Failure

oslevel May Not Indicate 4.3.3.0

The oslevel command may not correctly output '4.3.3.0' on systems installed or updated from the AIX 4.3.3 product media because the level of the ifor_ls.compat.cli fileset on the AIX product media is backleveled at the 4.3.2.0. This problem can be corrected by installing the ifor_ls.compat.cli 4.3.3.0 update (PTF U466561), which is available from FixDist. This problem does not occur when updating from the 4.3.3.0 Maintenance Level. The bos.perf.pmr fileset is down level after updating from the AIX 4.3.3 product media. The occurs only when updating AIX 4.3.0 and 4.3.1 systems, which already have the bos.perf.pmr fileset installed. The bos.perf.pmr fileset is obsolete in AIX 4.3.3 and should be removed. The bos.crypto* and sysmgt.security* filesets are not included in the AIX 4.3.3.0 Maintenance Level, since they contain encryption code that is subject to export restrictions. Updates to these filesets are available only on the AIX 4.3.3 Bonus Pack that that is shipped with AIX 4.3.3.

ifor_ls.msg Installation Failures

Some ifor_ls.msg.*.compat.gui filesets may fail to install from the AIX 4.3.3 product media due to a requisite to ifor_ls.compat.gui 4.3.3.0, which does not exist. This problem can be corrected by installing the ifor_ls.compat.gui 4.3.3.0 update (APAR IY04448), when available, from FixDist.

bos.loc.utf.ZH_CN Update Failure

When updating an existing AIX 4.3 system from the AIX 4.3.3.0 Maintenance Level, the bos.loc.utf.ZH_CN 4.3.3.0 update will fail to install if the bos.loc.iso.zh_CN fileset is not installed. To

prevent this problem, install the bos.loc.iso.zh_CN fileset from your existing AIX media prior to updating from the AIX 4.3.3.0 Maintenance Level. This problem does not occur when updating from the AIX 4.3.3 Product Media.

perfagent.tools Update Failure

When updating an existing AIX 4.3 system from the AIX 4.3.3.0 Maintenance Level, the perfagent.tools 2.2.33.0, as well as other requisites, may fail to install. The requisite failure occurs if the perfagent.server fileset is installed without the perfagent.tools fileset. To prevent this problem, install the perfagent.tools fileset from your existing AIX media prior to updating from the AIX 4.3.3.0 Maintenance Level. This problem does not occur when updating from the AIX 4.3.3 Product Media.

sysmgt.websm.apps Update Failure

When updating an existing AIX 4.3 system from the AIX 4.3.3.0 Maintenance Level, the sysmgt.websm.apps 4.3.3.0, as well as other requisites, may fail to install. The requisite failure occurs if the sysmgt.websm.apps fileset is already installed, due to a requisite to perl.rte, which is a new fileset in 4.3.3. To prevent this problem, install the perl.rte fileset, which is included in the AIX 4.3.3.0 Maintenance Level prior to updating from the AIX 4.3.3.0 Maintenance Level. This problem does not occur when updating from the AIX 4.3.3 Product Media.

Installation Failures from NFS Mounted CD

Permissions of some install images on the AIX 4.3.3 product media do not include read permission for others. Although this will not cause problems while installing from a locally mounted CD-ROM, it can cause installation failures from a CD-ROM that is NFS mounted. This problem can be circumvented by copying the images to disk and changing the permissions, or by changing the NFS export parameters to allow root access for the mounting host.

AIX Fast Connect in DCE Environment

AIX Fast Connect configured in a DCE environment to provide access to file shares located in DFS space must be started using the following steps. 1. Login as root. 2. dce_login as a principal (such as cell_admin) that has su rights to the DFS tree being shared.

3. Start AIX Fast Connect using the 'net start /load' command. SMIT or WebSM can also be used as long as the they are started from this shell. The above procedure allows the cifsServer daemon to run with su login context while cifsUserProc runs with users login context. Users login context gets set following DCE authentication.

LED E1DC During Boot on CHRP Systems

CHRP based systems can hang at boot with E1DC in the LEDs after booting down-level diagnostics or AIX CDs. You can determine if your system is CHRP based using the following command: lslpp -L
devices.chrp.base.rte

If the devices.chrp.base.rte filesets is installed, the system architecture is likey CHRP. If this fileset is not installed, this problem cannot occur on your system. To prevent this problem from occurring, install APAR IX79693, which is included in AIX 4.3.2, and also obtain the latest 4.3.2 diagnostics CD-ROM, P/N 08L1427 or 08L1430. Do not attempt to boot the system with earlier level diagnostics CD-ROMs or other media that contains a level of AIX earlier than 4.3.2. Once this problem occurs, the only way to correct the condition is to power the system off, unplug the battery for approximately 10 minutes, plug in the battery and power the system back on.

Firmware Corruption Using feprom_update

The "feprom_update" command fails on AIX 4.3 systems with an error similar to: 1734-009 cannot
write in FEPROM

Once this failure occurs, the system firmware is corrupt, and the system will no longer reboot. This problem affects SMP systems with 604e processors, including SP High Nodes. APAR IX84560 is currently available and should be installed prior to attempting a firmware update..

Exec Format Error Running Netscape Communicator

Netscape Communicator uses a private copy of the AIX C library (libc.a). The libc.a shipped with Netscape Communicator 4.0.4 and earlier may not be compatible with AIX 4.3.1, and may fail to start with an error similar to the following:
Could not load program /usr/local/netscape4/netscape_aix4 Symbol __malloc_postfork_unlock in /usr/lib/libpthreads.a is undefined Symbol __malloc_prefork_lock in /usr/lib/libpthreads.a is undefined Could not load library libC.a[shr.o]

Error was: Exec format error

To correct this problem, refer to the following URL for instructions on downloading and installing the fix.
ftp://aix.software.ibm.com/aix/efixes/netscape/

WebSphere V3.0 with AIX JDK 1.1.8

Use of the AIX Java 1.1.8 JIT (Just-in-Time compiler) with the WebSphere V3.0 Administration Server requires APAR IY04792. Until the APAR is applied, the JIT should be disabled during WebSphere Application Server startup. Disabling the JIT can have negative WebSphere Application Server performance impacts, therefore installation of APAR IY04792 is highly recommended. To disable the AIX JDK 1.1.8 JIT, modify the WebSphere admin.config file and replace the line:
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-mx128m

with the line:

com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-mx128m -Djava.compiler=NONE

Secondly, any Application Server that is created will also require the JIT to be disabled. To accomplish this, through the use of the WebSphere Administrative Console, add the following to the Command line arguments field for the Application Server: -Djava.compiler=NONE The Admin Console DOES NOT require the JIT to be disabled. The procedure is only required for the Adminserver and any Application Servers.

C Compiler Works only for "root" ID after Upgrade

The C compiler may be usable only by root after a migrating install to AIX 4.3.3. The cause of the problem is a permissions change on an iforls directory. To fix the problem run the following command: chmod 1777 /var/ifor

Web Based AIX Documentation "docsearch" Failure After Upgrade

The "docsearch" function of the AIX's web based documentation may fail after upgrading to AIX 4.3.3. To fix, cd /infocd unlinkbasecd linkbasecd

Backing Out AIX Updates

Audience: AIX Administrators Date: November 19, 1999 According to the Wall Street Journal, several recent well publicized web outages were caused by inadequate software change control. Several useful change control features are provided in base AIX. One particularly useful function is the ability to back out software updates. The ability to backout updates requires that they be installed using non-default settings. On the smit install_latest screen, change two of the options as follows: Commit software updates? No Saved replaced files? Yes These settings will save the replaced files when the updates are applied. At some future point, you can either commit the updates (smit commit), or back them out (smit reject). The backout automatically restores the original files. ** Recommendation: To be safe, always make a system backup (mksysb) before applying updates.

Identifying the Serial Number of a Remote RS/6000

Audience: AIX Administrators Date: January 21, 2000 The following AIX commands identify the model and serial number of PCI based RS/6000s Model Number: uname -M Serial Number: lsattr -El sys0 -a systemid These commands can make it easier to inventory remote systems via an rexec command or telnet session. These commands do not work on older Microchannel based systems. On these systems, you can use the "uname -m" command to generate a code that corresponds to the model (but not serial number). See the documentation for the AIX "uname" command for the code-model number correlation. The following Korn shell script uses these and other commands to list the configuration of a RS/6000. The output includes the model, serial number (PCI only), number of CPU's, amount of memory, disk space, TCP/IP address and AIX level.

Example of the Output

Host/IP Address RS/6000 Model Number of CPU's Memory (KB) AIX Level = = = = = dodgers.ibmus2.ibm.com is 9.93.152.173 7009-C10 1 65536 4.3.3.0

Number of hdisks = 5 Volume Groups VG Total(MB) datavg 1000 rootvg 1000 externvg 2356

Free 244 60 1032

USED 756 940 1324

Disks 1 1 3

Korn Shell Script

#!/usr/bin/ksh # Bruce Spencer, IBM # 2/4/99 # Modified 1/20/2000 to add serial number and "uname -M" # This program identifies the Model, serial number (PCI only), memory, CPU' # and disk on a RS/6000 # Hardware Codes for MCA based systems CODE=`uname -m | cut -c9,10 ` case $CODE in 02) MODEL="7015-930";; 10) MODEL="7016-730, 7013-530, 7016-730";; 14) MODEL="7013-540";; 18) MODEL="7013-53H";; 1C) MODEL="7013-550";; 20) MODEL="7015-930";; 2E) MODEL="7015-950";; 30) MODEL="7013-520, 7018-740/741";; 31) MODEL="7012-320";; 34) MODEL="7013-52H";; 35) MODEL="7012-32H";; 37) MODEL="7012-340";; 38) MODEL="7012-350";; 41) MODEL="7011-220";; 42) MODEL="7006-41T/41W";; 43) MODEL="7008-M20";; 46) MODEL="7011-250";; 47) MODEL="7011-230";; 48) MODEL="7009-C10";; 57) MODEL="7012-390, 7030-3BT";; 58) MODEL="7012-380, 7030-3AT";; 59) MODEL="7012-39H, 7030-3CT";; 5C) MODEL="7013-560";; 63) MODEL="7015-970/97B";; 64) MODEL="7015-980/98B";; 66) MODEL="7013-580/58F";; 67) MODEL="7013-570/770/771/R10";; 70) MODEL="7013-590";; 71) MODEL="7013-58H";; 72) MODEL="7013-59H/R12";; 75) MODEL="7012-370/375/37T";; 76) MODEL="7012-360/365/36T";; 77) MODEL="7012-355/55H/55L";; 79) MODEL="7013-590";; 80) MODEL="7015-990";; 82) MODEL="7015-R24";; 89) MODEL="7013-595";; 90) MODEL="7009-C20";; 91) MODEL="7006-42x";; 94) MODEL="7012-397";; A0) MODEL="7013-J30";; A1) MODEL="7013-J40";;

A3) A4) A6) A7) C0) C4) 4C) *)

MODEL="7015-R30";; MODEL="7015-R40";; MODEL="7012-G30";; MODEL="7012-G40";; MODEL="7024-E20";; MODEL="7025-F40";; MODEL=`uname -M`;; MODEL="Unknown";;

# PCI systems

esac # echo "Hostname echo "Host/IP Address echo "RS/6000 Model

= " $(hostname) = " $(host $(hostname) ) = " $MODEL

SN=$(lsattr -El sys0 -a systemid 2>/dev/null) if [ $? -eq 0 ] then echo "Serial Number = " `echo $SN | awk ' { print $2 }'` fi echo "Number of CPU's = " $(lscfg |grep -c "^+ proc") echo "Memory (KB) = " $(lsattr -El sys0 | awk '/realmem/ {print $2 }') echo "AIX Level = " $(oslevel) echo "Number of hdisks = " $(lspv |wc -l) echo "Volume Groups" # list volume groups disk avail/used for i in $(lsvg) do lsvg $i done | awk ' BEGIN { printf("%10s\t%10s\t%10s\t%10s\t%10s\n","VG","Total(MB)","Free","USED","Disks") } /VOLUME GROUP:/ { printf("%10s\t", $3) } /TOTAL PP/ { B=index($0,"(") + 1 E=index($0," megaby") D=E-B printf("%10s\t", substr($0,B,D) ) } /FREE PP/ { B=index($0,"(") + 1 E=index($0," megaby") D=E-B printf("%10s\t", substr($0,B,D) ) } /USED PP/ { B=index($0,"(") + 1 E=index($0," megaby") D=E-B printf("%10s\t", substr($0,B,D) ) } /ACTIVE PV/ { printf("%10s\t\n", $3) } '

Disabling Remote root Login

Audience: AIX Administrators Date: March 24, 2000 When multiple users have root access to a system, a common security question is who logged in as root? One alternative is to disable remote logins for the root id (chuser -rlogin=false root). This forces users to

first login in with their regular user id, then "su -" to root. All "su" activity is captured in /var/adm/sulog, thus answering the question of "who logged in as root." Comment: In general it is a good practice to disable root remote access as it provides two layers of password protection.

ANSI Terminal Support

Audience: System Administrators Date: April 5, 2000 The default AIX installation does not include support for ANSI terminals. ANSI support is important because Win95/98 telnet clients use this terminal emulation. Without ANSI support, full screen applications such as smit or vi, won't work properly. To support ANSI terminals, install bos.terminfo.ansi.data package on the base AIX CD. As an alternative, the ANSI terminfo file is attached below. To install: 1. cp ansi.ti /usr/lib/terminfo 2. tic /usr/lib/terminfo/ansi.ti

ansi.ti
# @(#)18 1.1 src/bos/usr/share/lib/terminfo/ansi.ti, terminfo, bos430, 9737A_430 9/1/93 20:34:12 # # COMPONENT_NAME: (TERMINFO) Terminfo # # FUNCTIONS: ansi.ti # # ORIGINS: 4 # # OBJECT CODE ONLY SOURCE MATERIALS # # ident "@(#)terminfo:ansi.ti 1.12" # ANSI - standards and other nonexistent terminals emulated in software. # # Manufacturer: ANSI - Generic # Class: III # # Info: # This category is used for terminals people "make up" in software # that do not represent a particular piece of hardware. This # includes standards, such as the ANSI standard, as well as # emulator programs that accept a particular set of escape # sequences. # # ANSI capabilities are broken up into pieces, so that a terminal # implementing some ANSI subset can use many of them. # ansi+local, cud=\E[%p1%dB, cub=\E[%p1%dD, cuf=\E[%p1%dC, cuu=\E[%p1%dA, ansi+local1,

cud1=^J, cub1=^H, cuf1=\E[C, cuu1=\E[A, ansi+tabs, ht=^I, cbt=\E[Z, hts=\EH, tbc=\E[2g, ansi+inittabs, it#8, use=ansi+tabs, ansi+erase, ed=\E[J, el=\E[K, clear=\E[H\E[J, ansi+rca, hpa=\E[%p1%{1}%+%dG, vpa=\E[%p1%{1}%+%dd, ansi+cup, cup=\E[%i%p1%d;%p2%dH, home=\E[H, ansi+rep, rep=%p1%c\E[%p2%{1}%-%db, ansi+idl, dl=\E[%p1%dM, il=\E[%p1%dL, ansi+idl1, dl1=\E[M, il1=\E[L, ansi+idc, dch1=\E[P, ich=\E[%p1%d@, ich1=\E[@, # smir=\E6, rmir=\E6, commented out by ehr3 ansi+arrows, kcuu1=\E[A, kcud1=\E[B, kcub1=\E[D, kcuf1=\E[C, khome=\E[H, kbs=^H, ansi+sgr|ansi graphic renditions, rev=\E[7m, blink=\E[5m, invis=\E[8m, sgr0=\E[0m, ansi+sgrso|ansi standout only, rmso=\E[m, smso=\E[7m, ansi+sgrul|ansi underline only, rmul=\E[m, smul=\E[4m, ansi+sgrbold|ansi graphic renditions; assuming terminal has bold; not dim, bold=\E[1m, sgr=\E[%?%p1%t7;%;%?%p2%t4;%;%?%p3%t7;%;%?%p4%t5;%;%?%p6%t1;%;m, use=ansi+sgr, use=ansi+sgrso, use=ansi+sgrul, ansi+sgrdim|ansi graphic renditions; assuming terminal has dim; not bold, dim=\E[2m, sgr=\E[%?%p1%t7;%;%?%p2%t4;%;%?%p3%t7;%;%?%p4%t5;%;%?%p5%t2;%;m, use=ansi+sgr, use=ansi+sgrso, use=ansi+sgrul, ansi+pp|ansi printer port, mc4=\E[4i, mc5=\E[5i, mc0=\E[0i, # Info: # ANSI is a vanilla ANSI terminal. This is assumed to implement # all the normal ANSI stuff with no extensions. It assumes # insert/delete line/char is there, so it won't work with # vt100 clones. It assumes video attributes for bold, blink, # underline, and reverse, which won't matter much if the terminal # can't do some of those. Padding is assumed to be zero, which # shouldn't hurt since xon/xoff is assumed. # # We assume a 24x80 screen. This entry was derived from the # Ann Arbor Ambassador, and is untested. # ansi|generic ansi standard terminal, use=vanilla, am, cols#80, lines#24, xon, use=ansi+cup, use=ansi+rca, use=ansi+erase, use=ansi+tabs, use=ansi+local1, use=ansi+local, use=ansi+idc, use=ansi+idl1, use=ansi+idl, use=ansi+rep, use=ansi+sgrbold, use=ansi+arrows, # Info: # Bare minimum ANSI terminal. This should work on anything, but # beware of screen size problems and memory relative cursor

# addressing. # minansi|minimum ansi standard terminal, am, xon, use=vanilla, cols#80, lines#24, use=ansi+cup, use=ansi+erase, # Info: # This terminal type is for ANSI terminals with ONLY memory # relative cursor addressing and more than one page of memory. # It uses local motions instead of direct cursor addressing, # and makes almost no assumptions. It does assume auto margins, # no padding and/or xon/xoff, and a 24x80 screen. # mransi|mem rel cup ansi, am, use=vanilla, cols#80, lines#24, xon, use=ansi+erase, use=ansi+local1, # Info: # Columbus UNIX virtual terminal. This terminal also appears in # UNIX 4.0 and successors as line discipline 1 (?), but is # undocumented and does not really work quite right. # virtual|cbunix|cb-unix|cb-unix virtual terminal, cr=^M, cud1=^J, ind=^J, bel=^G, cols#80, lines#24, am, clear=\EJ, cub1=^H, cup=\EG%p2%c%p1%c, cuf1=\EC, cuu1=\EA, el=\EK, ed=\EL, il1=\EP, dl1=\EN, ich1=\EO, dch1=\EM, lm#0, da, db, kcub1=\ED, kcuf1=\EC, kcuu1=\EA, kcud1=\EB, khome=\EE, smso=\Ea\004, rmso=\Eb\004, smul=\Ea\001, rmul=\Eb\001, # Info: # This terminal is based on virtual but cleans up a few problems # with control characters in parameter strings. It is implemented # in mrh's window manager. # pty|4bsd pty terminal, smso=\Ea$, rmso=\Eb$, smul=\Ea!, rmul=\Eb!, cup=\EG%p1%' '%+%c%p2%' '%+%c, use=virtual, # Info: # A dumb terminal with 1 line which is a fake status line. # This is useful to run sysline in in a multi-window environment. # 1line|one_line|one line window, cr=^M, ind=^J, cols#80, lines#1, am, ht=^I, cub1=^H, hs, tsl=\n, # Info: # 1linepty is like 1line but the 1 line window is smarter, # with standout, cursor addressing, and clear to eol. # 1linepty|one_linepty|1 line window in a pty, smso=\Ea$, rmso=\Eb$, smul=\Ea!, rmul=\Eb!, cup=\EG%p1%' '%+%c%p2%' '%+%c, tsl=\r\EK\EG %p2%' '%+%c, eslok, use=1line, vanilla, bel=^G, cr=^M, cud1=^J, ind=^J, datakit, am, gn, cols#80, bel=^G, cr=\r, cud1=\n, ind=\n,

Identifying Which Fileset an AIX Command Installs From

Audience: AIX Administrators

Date: October 6, 2000 As is typical of most operating systems today, the default AIX load does not include all software available on the installation CD-ROM. If you are missing a command, you can use the which_fileset to identify which fileset needs to be installed. For example, depending on your AIX level, the which_fileset dbx command might display
/usr/bin/dbx > /usr/ccs/bin/dbx /usr/ccs/bin/dbx bos.adt.debug 4.2.1.0 bos.adt.debug 4.2.1.0

Install the missing fileset and you're back in business. The which_fileset command is itself an optional command, and requires the bos.content_list to be installed. For more information, see http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds6/which_fileset.htm Thanks to Allen Oh for this tip!

AIX Tip of the Week: Centralizing Console Support for RS/6000 Server Farm
Audience: AIX Administrators, Operations Date: November 18, 2000 You can use the RS/6000 128 Port Asynch Adapter to centralize console functions of an entire server farm onto a single PC or workstation. The console functions include "Power On/Off", viewing boot messages and redirecting the console. The central PC can be located anywhere in the network. See the Central Console Setup PDF file for more information.

AIX Tip of the Week: Viewing AIX Boot and Console Logs
Audience: AIX Systems Administrators Date: December 2, 2000 Boot and console messages can be used to identify and fix problems. These messages are automatically stored on disk by AIX. To view the stored messages, use the alog command. Here are a couple examples of the alog command:
alog -L alog -o -t boot alog -o -t console # # # List the defined log types View the boot log View the console log

See the AIX documentation for more information on the alog command, as well as how to define your own log types.

AIX Tip of the Week: Determining Installed AIX Software/Version

Audience: Systems Administrators Date: January 5, 2001 Here are some useful commands for determining which AIX software packages are installed and their version/fix levels.

List all installed filesets with their version level lslpp -L AIX maintenance level oslevel List known AIX maintnenance levels oslevel -q List filesets that are below the AIX 4.3.2.0 maintenance level oslevel -l 4.3.2.0 Determine whether a fix is installed (for example. fixes IX38794 and IX48523), and what it fixes (-a). instfix -iak IX38794 Determine if a maintenance package is installed instfix -ik 433-02_AIX_ML Determine which filesets need updating to reach the 4.3.3.0-02 level instfix -ciqk 4330-02_AIX_ML | grep ":-:"

AIX Tip of the Week: Identifying the Origin of "core" Files

Audience: Systems Administrators Date: January 12, 2001 When an application core dumps, a "core" file is placed in the current directory. Core files are often a symptom of a problem that needs attention. You can determine which application caused the "core" file going to the directory where the core file is located and running the command: $ lquerypv -h core 6b0 64 The name of the application causing the core file is listed in the section on the right. In the sample output below, the "ftpd" application caused the core file.
000006B0 000006C0 000006D0 000006E0 000006F0 00000700 00000710 7FFFFFFF 00000000 00170000 66747064 00000000 00000000 00000000 FFFFFFFF 000007D0 53245A2C 00000000 00000000 00000000 00000020 7FFFFFFF 7FFFFFFF 00000000 00000000 00000000 00000000 00000000 FFFFFFFF FFFFFFFF 00000015 00000000 00000000 000000CF 000000BE |................| |................| |....S$Z,........| |ftpd............| |................| |................| |....... ........|

In addition, AIX can be configured to detect when core files are created and mail a message to root, alerting root that an application has failed. The instructions for setting this up are in a README file in the /usr/samples/findcore directory. These programs are delivered with the bos.sysmgt.serv_aid fileset.

Microcode Discovery Service and VPD Capture Service

Audience: All Date: February 23, 2001 AIX development recently announced two utilities that centralize and simplify configuration management tasks. The utilities are Microcode Discovery Service and VPD Capture Service. Microcode Delivery Service identifies downlevel microcode on a group of RS/6000 or SP systems. (You are keeping your microcode current, aren't you?) VPD Capture Service records hardware configuration information for IBM to insure the correct system upgrade components are shipped. Both services can be run from a centralized PC browser using a Java Applet. The services use a new AIX command and daemon: invscout and invscoutd. Both are included in the 10/00 AIX 4.33 update, and in AIX 5.0. For prior releases and for documentation see: Microcode Discovery Service Users Guide>http://techsupport.services.ibm.com/rs6k/mds.html (=>Users Guide ) VPD Capture Service http://techsupport.services.ibm.com/rs6k/vcs.html

New AIX Support for System V Init

Audience: Systems Administrators Date: March 2, 2001 The AIX 4.3.3.25+ maintenance level adds a new /etc/rc.d directory. This directory supports the System V Init process. It has been added to AIX to make it easier to port System V applications that depend on run level. (AIX still uses the BSD style init.) The purpose of both System V and BSD init is to start processes at boot time. The processes that are started depend on the system "run level" (AIX has "run levels" ranging from 0-9, with level 3 being default.) In the System V init process, the startup scripts are grouped into directories by "run level." The directory names are of the form /etc/rc.d/rc${run_level}.d (For example, /etc/rc.d/rc3.d directory contains scripts for run level 3.) Each directory contains both startup/shutdown scripts. Script names that start with "K" kill processes, and script names that start with "S" start processes. The scripts are run in alphabetical order. In practice, the startup scripts physically reside in the /etc/rc.d/init.d directory. The scripts in the /etc/rc.d/rc${run_level}.d are actually links to back to files in the <>init.d directory. For more information on the AIX init process, see: http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/files/aixfiles/inittab.htm http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/telinit.htm#A15891e19

Using timedc and setclock to Display and Synchronize Clocks

Audience: System Administration Date: March 16, 2001 Clock settings must be synchronized in a client/server architecture to maintain data integrity and to facilitate problem determination. Two common synchronization methods include using a central time server (NTP) or running the timed daemon. The timed daemon creates an average network time by synchronizing clocks with other systems on the LAN who are running timed. Two useful commands for displaying and setting clocks are timedc and setclock. Here are a couple examples of using each command. timedc msite - identifies the location of the current timed server. timedc clockdiff remotehost - display the clock difference between the local host and remotehost. setclock remotehost - synchronizes the local hosts time/date to that of remotehost

IP Aliasing
Audience: System Administration Date: March 30, 2001 The following tip if from Bob Kelly, IBM Austin. IP Aliasing allows a single network interface to have multiple IP addresses. One of the advantages of aliasing is the ability consolidate applications and web pages on one server without changing application code. The commands to add/delete an IP alias are To add an alias to your existing network adapter: ifconfig en1 alias 10.10.10.1 netmask 255.255.255.1 To delete an alias from your network adapter ifconfig en1 delete 10.10.10.1 *For all you smitty folks, smitty inetalias will accomplish the same. Important Notes: Sendmail can still be configured to receive mail to either address. It can be "told" to use the "firstwebsite" address, or you could use the "secondwebsite" address. To the outside world, it will appear that your network has two machines, "firstwebsite" and "secondwebsite", when actually they are one machine, with two TCP/IP addresses. Be aware. There are known issues with AIX 4.3.3 gated and aliases. Gated was not designed to handle aliases implemented in the way AIX implement them. Gated will send a HELLO from each interface, which can confuse the routers.

Restoring a "tar" Backup with Absolute Path Names to a Different Directory

Audience: AIX Users Date: July 30, 2001 A tar backup created using absolute path names can only only be restored to the directory from which it was created. One way to restore it to a different directory is by using the pax command. For example, suppose you receive a tar tape created using absolute path names: tar -cvf /dev/rmt0 /work/* but want to restore it to the /test directory. The pax command would be: pax -rf /dev/rmt0 -s/work/test/p The -s/work/test/p does the directory change. It functions similar to a "vi" search and replace. The pax command has several other uses such as duplicating directories. See the pax man page for more information.

Booting Multiple Versions of AIX

Audience: System Administration Date: April 7, 2001 The AIX "bootlist" command can be used to select the boot disk. This is useful if you want to test different AIX levels on the same system. For example, assume hdisk0 has AIX 4.2.1 installed and hdisk1 AIX 4.3.3 installed. Use one of the following "bootlist" commands** to select which version will come up on the next reboot:
bootlist -m normal hdisk0 # Reboots to AIX421 bootlist -m normal hdisk1 # Reboots to AIX433

The second disk can be installed from CD, a "mksysb" tape, or using AIX 4.3's "alt_disk_install" capability. Both CD and mksysb installs require downtime. The "alt_disk_install" allows you to install the second disk from a "mksysb" or clone your existing OS while the system is running ** Comment: In practice, I recommend the following "bootlist" syntax which specifies that if hdisk0 fails to boot, try booting from hdisk1, then tape, and finally CD ROM.
bootlist -m normal hdisk0 hdisk1 rmt cd

Replacing an AIX Disk Drive

Audience: AIX Administrators Date: August 5, 2001 The procedure to replace an AIX disk drive depends on what is on the disk. The attached PDF file describes how to replace a disk drive in AIX. It is based on the official "Removing and Replacing a Fixed Drive" document that can

be found at http://techsupport.services.ibm.com/rs6k/techbrowse / A few of the additions include

Documenting the disk configuration How to create map file to restore an LV to the exact disk partition. How to replace a JFSLOG. A flowchart for replacing a disk drive

Replacing an AIX Disk

Split Mirror Copy

Audience: AIX System Administrators Date: September 4, 2001 As applications move toward 7x24 uptime, there is less downtime available for backups. This tip describes the split mirror backup technique which reduces downtime for backups to minutes, for even the largest The technique involves mirroring the data, to another disk, splitting off the copy, then backing up the copy in the background while the system is running production. There are two basic ways to split a mirror copy. One way uses hardware commands (Shark Flash Copy or ssa_make_copy). The other uses AIX commands. If using hardware commands, use the recreatevg command to redefine the disk definitions (PVID, LV, filesystem names). This is because a hardware copy duplicates all definitions, which would cause conflicts. The recreatevg command.resolves the conflicts by creating a new volume group with unique PVIDs, LV names and filesystem names. The recreatevg command is available in both AIX 4.3.3 and 5L, but the documentation is found only in AIX 5L: http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds4/recreatevg.htm The AIX alternative to split a mirror copy uses either the splitlvcopy or chfs command. The splitlvcopy is used for raw partitions, and the chfs command is used for filesystems. To illustrate, the following example assumes we want to make a split mirror copy of the "datalv". The copy will be located on hdisk2, with a LV name of "lv_copy"
1. Define a mirror copy of "datalv" on "hdisk2" mklvcopy datalv 2 hdisk2

2. Synchronize (copy) the data to the mirror syncvg -l -P6 datalv

3. Verify copy is complete (ie no "stale" partitions) lslv datalv 5. Stop application/database

Split off the hdisk2 mirror copy. For raw partitions: For JFS filesystems: splitlvcopy -y lv_copy datalv 1 hdisk2 chfs -a splitcopy=/data_copy -a copy=2 If not, you'll see the error: /data

Note: to use "chfs," the JFSLOG must be mirrored.

"jfs_syscall: A system call received a parameter that is not valid " 7. Restart application/database 8. Backup data

The downtime associated with the split mirror copy is in Steps 5-7. Depending on the size of the data, the typical downtime is 5-30 minutes. All other steps can done while running production.

Work Load Manager

Audience: System Administrators Date: September 30, 2001 AIX Workload Manager (WLM) is a "no-charge" operating system component introduced in AIX Version 4.3.3. With WLM you can control the amount of CPU and memory used by users and applications. The benefits of WLM include helping maintain service levels, and reducing the impact of some poorly behaved applications. For more information, see http://www.ibm.com/servers/aix/library (WLM is located under the Technical Publications) http://www.redbooks.ibm.com (Search for sg245522.pdf. Work Load Manager Surveys load balancing in general. WLM is covered in Chapter 5)

Configuring Network Adapters for Redundancy

Audience: System Administrators Date: October 15, 2001 You can protect against network adapter failure using AIX's Etherchannel support. Etherchannel allows you to create a "logical" ethernet adapter out of 2 physical adapters. If the primary network adapter fails, AIX seemlessly moves network traffic to the surviving adapter using the same IP address.

The Etherchannel function is available in AIX 4.3.3+. Documentation is scarce, so here's a quick "how to". In this example, we assume we have two physical adapters (ent1 and ent2) that we want to group as a logical interface: smit => devices => communications => etherchannel =>"Add an Etherchannel" (fastpath "smit etherchannel")
Add An Etherchannel Type or select values in entry fields. Press Enter AFTER making all desired changes. Etherchannel Adapters Enable ALTERNATE ETHERCHANNEL address ALTERNATE ETHERCHANNEL address Mode Internet Address to Ping Number of Retries Retry Timeout (sec) [Entry Fields] ent1 ent2 no [] netif_backup [] [] []

This will create a "logical" interface using the next available adapter name ("ent3"). From here, configure an IP address on the logical interface ent3.

Comments:
ALTERNATE ETHERCHANNEL = yes allows you to specify a "MAC" address. (Not necessary) Mode = round-robin provides higher aggregate bandwidth by distributing outgoing packets over multiple network adapters. However "round-robin" does not distribute incoming packets, nor does it provide adapter failover. Use "netif_backup" if you want failover. Internet Address to Ping: IP address for "keep alive". Optional as most failures detected at link layer Bruce Spencer, baspence@us.ibm.com

EtherChannel Readme File

Etherchannel
Introduction Etherchannel is an aggregation technology that allows you to produce a single large pipe by combining the bandwidth of multiple ethernet adapters. The aggregated pipe appears to be single ethernet interface to the upper layers (IP, etc.). Each of the ethernet adapters will share a single MAC address. There is a single ethernet interface associated with the aggregated pipe, which has a single IP address as well. Hardware The ethernet adapters inside which are members of the etherchannel can be any supported ethernet adapter. The ethernet adapters must be connected to a switch which supports Etherchannel . Configuration

In AIX 4.3.3, a single etherchannel can combine either two or four ethernet adapters in the channel. You can configure multiple etherchannels on a single system. Be aware that each etherchannel constitutes an additional ethernet interface. The "no" option, ifsize (default 8), needs to be increased to include not only the ethernet interfaces for each adapter, but also any etherchannels that are configured. See the "no" command documentation in regards to modifying ifsize. The adapters in an etherchannel need to be configured to the same speed (10 or 100 Mbps) and mode (half or full duplex). I. Configuring Etherchannel

Etherchannel is configured through smit. I will use the following setup to show how etherchannel is configured: there will be 2 ethernet adapters, ent0 and ent1, in the etherchannel and there is no etherchannel alternate address specifed. There are 5 ethernet adapters to choose from. Execute:
#smittyetherchannel

which produces a screen that looks like:

Etherchannel MovecursortodesireditemandpressEnter. ListAllEtherchannels AddAnEtherchannel Change/ShowCharacteristicsofanEtherchannel RemoveAnEtherchannel

Then choose "Add An Etherchannel" selection:

 Etherchannel MovecursortodesireditemandpressEnter.

ListAllEtherchannels AddAnEtherchannel Change/ShowCharacteristicsofanEtherchannel DeleteAnEtherchannel |AvailableNetworkAdapters | |MovecursortodesireditemandpressF7. |ONEORMOREitemscanbeselected. |PressEnterAFTERmakingallselections. | |>ent0 |>ent1 |ent2 |ent3 |ent4 | |F1=HelpF2=RefreshF3=Cancel |F7=SelectF8=ImageF10=Exit F1|Enter=Do/=Findn=FindNext F9

As instructed, select one more more of the listed adapters. The "Available Network Adapters" displays all of the ethernet adapters. If one selects an ethernet adapter that is already being used (i.e. has an interface defined), then one will get an error similar to: NOTE Methoderror(/usr/lib/methods/cfgech):
0514001Systemerror: Methoderror(/usr/lib/methods/chgent): 0514062Cannotperformtherequestedfunctionbecausethe specifieddeviceisbusy.

AddanEtherchannel Typeorselectvaluesinentryfields. PressEnterAFTERmakingalldesiredchanges.

[EntryFields] EtherchannelAdaptersent0ent1 EnableALTERNATEETHERCHANNELaddressno ALTERNATEETHERCHANNELaddress[] Modestandard EnableGIGABITETHERNETJUMBOframesno InternetAddresstoPing[] NumberofRetries[] RetryTimeout(sec)[]

After hitting the enter key:

COMMANDSTATUS Command:OKstdout:yesstderr:no Beforecommandcompletion,additionalinstructionsmayappearbelow. ent5Available

Since an alternate address was not specified, the config method for the etherchannel changed the alternate address of ent1 to the hardware add NOTE ent0. If an alternate address was specified, both ent0 and ent1 would ha alternate address. Then add an interface, en5 for standard ethernet or et5 for IEEE 802.3, through the normal means. The easiest way is to use the "Minimum Configuration & Startup" TCP/IP smit menu. II. Listing Etherchannels

Execute:
#smittyetherchannel

and choose the "List All Etherchannels" selection: III.

Etherchannel MovecursortodesireditemandpressEnter. ListAllEtherchannels AddAnEtherchannel Change/ShowCharacteristicsofanEtherchannel RemoveAnEtherchannel

COMMANDSTATUS Command:OKstdout:yesstderr:no Beforecommandcompletion,additionalinstructionsmayappearbelow. ent5AvailableEtherchannel

Changing the alternate address

Execute:
#smittyetherchannel

Then choose "Change / Show Characteristics of an Etherchannel" selection:

Etherchannel MovecursortodesireditemandpressEnter. ListAllEtherchannels AddAnEtherchannel Change/ShowCharacteristicsofanEtherchannel RemoveAnEtherchannel

|AvailableEtherchannels | |MovecursortodesireditemandpressEnter. | |ent5 | |F1=HelpF2=RefreshF3=Cancel |F8=ImageF10=ExitEnter=Do F1|/=Findn=FindNext F9

To change the Alternate etherchannel address to 1234deadbeef:

Change/ShowCharacteristicsofanEtherchannel Typeorselectvaluesinentryfields. PressEnterAFTERmakingalldesiredchanges.

[EntryFields] Etherchannelent5 EnableALTERNATEETHERCHANNELaddressyes ALTERNATEETHERCHANNELaddress[0x1234deadbeef]

After hitting the enter key:

 COMMANDSTATUS Command:OKstdout:yesstderr:no Beforecommandcompletion,additionalinstructionsmayappearbelow. ent5changed

If one wants to add or delete an ethernet adapter from the etherchannel, one must NOTE use the "Remove an Etherchannel" smit menu selection, then re-add the etherchannel with the "Add An Etherchannel" smit menu selection. Unconfiguring the Etherchannel Execute:
#smittyetherchannel

Then choose "Remove an Etherchannel" selection:

Etherchannel MovecursortodesireditemandpressEnter.

Choose 'ent5', then hit the enter key:

COMMANDSTATUS Command:OKstdout:yesstderr:no Beforecommandcompletion,additionalinstructionsmayappearbelow. ent5deleted ent0changed ent1changed

Troubleshooting tcpdump and trace can be used to troubleshoot the etherchannel. The trace hook id for the transmit packets is 2FA and for other events is 2FB. You cannot trace receive packets on the channel as a whole, but you can trace each of the adapter's receive trace hooks.

The entstat command will give the aggregate statistics of all the adapters in an etherchannel. If entstat is run with the "-d" option, the statistics of each of the individual adapters is printed. Restrictions Remote dump is not supported over an etherchannel. IV. Modes

There are three modes for Etherchannel. Each control the method the channel uses to send and receive packets. Standard In this mode the channel will hash on the destination IP address and use this value to choose which adapter it will send the packet out on. This mode will guarantee packets are sent out over the channel in the order they were sent, but may not make full use of the bandwidth. Round Robin In this mode the channel will rotate through the adapters, giving each adapter one packet before repeating. In this mode packets may be sent out in a slightly different order than they were given to the channel, but the channel will make the best use of its bandwidth. Network Interface Backup In this mode, the channel will only activate one adapter at a time. The intention is that the adapters are plugged into different ethernet switches, each of which is capable of getting to any other machine on the subnet/network. When a problem is detected, either with the direct connection, or through inability to ping a machine, the channel will deactivate the current adapter, and activate a backup adapter. The channel will poll the adapter for Link Status in "Retry Timeout" intervals. If the Link Status is not up (either due to a cable being unplugged, switch down, or device driver problem) , the channel will switch to another adapter. This mode is the only one that makes use of the "Internet Address to Ping", "Number of Retries", and "Retry Timeout" fields. V. Internet Address to Ping The address will be ping'd if the address field has a non-zero address and the mode is set to netif_backup. If the channel is unable to ping the address for the "Number of Retries" times in "Retry Timeout" intervals. The channel will switch adapters. VI. Number of Retries The number of retries is the number of ping response failures before the channel switches adapters. The default is 3 times. VII. Retry Timeout The retry timeout is the interval in seconds between the times when the channel will send out a ping packet and poll the adapter's Link Status. The defauls is 1 sec intervals.

Disabling CPU's in AIX 4.3.3

Audience: System Administrators Date: December 14, 2001 The cpu_deallocate command is useful tool for scaleability testing. This command can be used to dynamically

deactivate CPU's. The cpu_deallocate command is significantly easier to use compared to the alternative of shutting the system down and disabling CPU's via the Service Processor. The command syntax is: cpu_deallocate <.logical CPU number>. where "CPU number" is an integer ranging between 0 and "n-1" where "n" is the number of CPU's. (Comment: the logical CPU number is not necessarily the same number associated with proc## in "lsdev -Cc processor" output. The proc## are often not in sequence.) To verify a processor has been disabled, run lsattr -El proc## Although the deactivation is immediate. To reactivate the CPU's, the system must be rebooted. Prereqs: AIX: bos.mp.4.3.3.21 Enable cpuguard: chdev -l sys0 - a cpuguard=enable See AIX Tip Enabling CPU Deallocation for more information.

Enabling CPU Deallocation

Audience: System Administrators Date: January 7, 2002 AIX's "CPU Deallocation" can enhance SMP availability by dynamically taking a failing CPU offline. However, "CPU Deallocation" is not enabled by default. To enable, use smit or the command chdev -l sys0 -a cpuguard='enable' To verify it has been enabled, run the command: lsattr -El sys0 Note: CPUguard requires a minimum of three CPU's. You can use the cpu_deallocate command to dynamically turn off a processor. See the AIX Tip cpu_deallocate for more information.

splitmirrorvg Shell Script

Audience: All Date: March 8, 2002

Audience Systems Administrators, DBA's. One use for "split mirror copy" is to quickly move large amounts of data between systems on a SSA loop, SAN or equivalent. You simply vary off the volume group containing the copy and vary it on another server. It avoids the congesting the network with large file transfers, and the procedure takes only minutes. The attached "splitmirrorvg" shell script automates the split mirror copy process. The split copy is placed into a new volume group, which can then be exported/imported onto another system on the same SSA loop or SAN. The script illustrates many useful AIX LVM commands. It's worth a look even if you don't have a need for split mirror copy. Acknowledgement: Thanks to Dan Braden for the shell script.

Notes
Steps: 1. create VG mkvg -y -s mkvg -f -y'splitmirrorvg' -s'8' hdisk13 hdisk14 hdisk 15 hdisk17 hdisk18 hdisk19 hdisk20 hdisk21 2. Create LV (original copy) mklv -y -e x -w n mklv -y'lvnum1' -e'x' -w'n' splitmirrorvg 18 hdisk16 hdisk17 hdisk18 3. Create first copy of LV mklvcopy 2 mklvcopy lvnum1 2 hdisk19 hdisk20 hdisk21 4. Create second copy of LV mklvcopy 3 mklvcopy lvnum1 3 hdisk13 hdisk14 hdisk15 5. List out LV map root@f1n3 > lslv -m lvnum1 lvnum1:N/A LP PP1 PV1 0001 0109 hdisk16 0002 0109 hdisk17 0003 0109 hdisk18 0004 0110 hdisk16 0005 0110 hdisk17 0006 0110 hdisk18 0007 0111 hdisk16 0008 0111 hdisk17 0009 0111 hdisk18 0010 0112 hdisk16 0011 0112 hdisk17 0012 0112 hdisk18 0013 0113 hdisk16 0014 0113 hdisk17 0015 0113 hdisk18 0016 0114 hdisk16 0017 0114 hdisk17 0018 0114 hdisk18

PP2 0109 0055 0055 0110 0056 0056 0111 0057 0057 0112 0058 0058 0113 0059 0059 0114 0060 0060

PV2 hdisk19 hdisk20 hdisk21 hdisk19 hdisk20 hdisk21 hdisk19 hdisk20 hdisk21 hdisk19 hdisk20 hdisk21 hdisk19 hdisk20 hdisk21 hdisk19 hdisk20 hdisk21

PP3 0109 0055 0055 0110 0056 0056 0111 0057 0057 0112 0058 0058 0113 0059 0059 0114 0060 0060

PV3 hdisk15 hdisk14 hdisk13 hdisk15 hdisk14 hdisk13 hdisk15 hdisk14 hdisk13 hdisk15 hdisk14 hdisk13 hdisk15 hdisk14 hdisk13 hdisk15 hdisk14 hdisk13

6. Create a filesystem for testing (for raw LVs this wouldn't be necessary) crfs -v jfs -d lvnum1 -m /tmp/fs -A yes Note that this creates a jfslog LV which we also need to mirror 7. Mirror the jfslog to (which will also be split later) mklvcopy loglv00 3 hdisk16 hdisk13 root@f1n3 > lslv -m loglv00 loglv00:N/A LP PP1 PV1 PP2 PV2 PP3 PV3 0001 0121 hdisk19 0115 hdisk16 0061 hdisk13 8. Mount the FS and put some data in there for testing # mount /tmp/fs # cd /tmp/fs # cp -R /etc/ . 9. Unmount the filesystem (i.e. stop I/O) # umount /tmp/fs 10. Split off a copy of the LVs (use hdisk13 so the split LVs are on the same set of hdisks) splitlvcopy -y lvnum2 lvnum1 2 hdisk13 (for the filesystem LV) splitlvcopy -y newloglv00 loglv00 2 hdisk13 (for the jfslog LV) root@f1n3> lslv -m lvnum2 lvnum2:N/A LP PP1 PV1 PP2 0001 0109 hdisk15 0002 0055 hdisk14 0003 0055 hdisk13 0004 0110 hdisk15 0005 0056 hdisk14 0006 0056 hdisk13 0007 0111 hdisk15 0008 0057 hdisk14 0009 0057 hdisk13 0010 0112 hdisk15 0011 0058 hdisk14 0012 0058 hdisk13 0013 0113 hdisk15 0014 0059 hdisk14 0015 0059 hdisk13 0016 0114 hdisk15 0017 0060 hdisk14 0018 0060 hdisk13 root@f1n3> lslv -m newloglv00 newloglv00:N/A LP PP1 PV1 PP2 0001 0061 hdisk13 11. Mount the original LV # mount /tmp/fs 12. Save the LV maps for newloglv00 and lonum2 Using the reformatmap script: #!/bin/ksh # reformap - script to take an LV and get it's map and create a map # that can be used by mklv # input is an LV name, output is a file of name $lvmap lv=$1 cat /dev/null > ${lv}map lslv -m $lv | grep -v ^$lv | grep -v ^LP | while read lpnum ppnum pv

PV2

PP3

PV3

PV2

PP3

PV3

do echo ${pv}:$ppnum >> done

${lv}map

# reformatmap lvnum2 # reformatmap newloglv00 root@f1n3 > pg lvnum2map hdisk15:0109 hdisk14:0055 hdisk13:0055 hdisk15:0110 hdisk14:0056 hdisk13:0056 hdisk15:0111 hdisk14:0057 hdisk13:0057 hdisk15:0112 hdisk14:0058 hdisk13:0058 hdisk15:0113 hdisk14:0059 hdisk13:0059 hdisk15:0114 hdisk14:0060 hdisk13:0060 root@f1n3.dsc.ibm.com (/tmp) > cat newloglv00map hdisk13:0061 13. Add entry to /etc/filesystems for new filesystem /tmp/newfs: dev = /dev/lvnum2 vfs = jfs log = /dev/newloglv00 mount = false options = rw account = false 14. Mount it and see if the data is there (make sure new mount point is there first) # mkdir /tmp/newfs # mount /tmp/newfs # find /tmp/newfs -print 15. Unmount the filesystem and remove the new LVs in preparation for creating them in a new VG on hdisk13, hdisk14 and hdisk15 Unmount # umount /tmp/newfs Remove the LVs # rmlv -f lvnum2 # rmlv -f newloglv00 16. Remove the disks from the VG Remove the disks from the VG # reducevg splitmirrorvg hdisk13 hdisk14 hdisk15 17. Create a new VG with the same partition size # mkvg -y newvg -s 8 hdisk13 hdisk14 hdisk15 18. Make the LVs using the maps we saved earlier mklv -y lvnum2 -m lvnum2map newvg 18 mklv -y newloglv00 -m newloglv00map newvg 1

Note that we used the same LVname (lvnum2) and the number of LPs (18) One can get the number of LPs from the following command: # lslv | grep ^LPs | awk '{print $2}' We also used the same LVname for the jfslog, the mount point doesn't change 19. Mount the filesystem and check it out # mount /tmp/newfs # find /tmp/newfs -print At this time, one could varyoff the VG, then import it on another machine connected to the disk.

splitmirrorvg Shell Script

#!/bin/ksh # splitmirrorvg # Use this script to split off a mirror copy containing all LVs in a VG. # The split off copy is placed into a new VG so that the data can be # exported/imported into another system. # # Usage: splitmirrorvg # where the listed hdisks are a set of disks that have one copy of the LVs on # them and will be put into another VG # # The new VG and LVs will be preceded by the prefix mir to # designate that it is a mirrored VG/LV. Mount points will be # . # # NOTE: NO CHECKING OF THE SETUP IS DONE. IT IS ASSUMED THAT YOUR VG IS SETUP # AND MIRRORED CORRECTLY USING SUPER STRICT COPIES (I.E. EACH COPY OF THE LVS # ARE ON DISTINCT SETS OF DISKS), and that your input is correct. # This also assumes you have 3 copies of the LVs - it won't work for 2 # This also assumes any JFS log you have is of type "jfslog" # This also assumes the VG is synced # Your LV and VG names should not exceed 12 characters # # Standard Disclaimers: backup your data, test first on a development system. #--------------------------------------------# "Are you sure" warning message # You can erase this section between the lines tput clear echo $0 ":This script splits off the LVs in the mirror copy on " $@ echo "into a new volume group." echo "*** Caution *** This script assumes your VG is setup and mirrored " echo "correctly. See comments in this script." echo "\nContinue? (yes/no)" read if [[ ! $REPLY = yes ]] then echo "Exiting" exit fi #--------------------------------------------

# Get a list of LV, mountpoint, #LPs, and hdisk and put them in a file cat /dev/null > /tmp/splitlvdata # First get a list of the LVs in the VG lvs=`lsvg -l $1 | tail -n +3 | awk '{print $1}'` # Now we loop on the LVs for lv in ${lvs} do # determine the mount point if any associated with the LV mountpt=`lslv $lv | grep "MOUNT" | awk '{print $3}'` # Determine the number of LPs lps=`lslv $lv | grep ^LPs | awk '{print $2}'` # Determine one of the input hdisks on which the copy exists for disk in $@ do if [ "$disk" = "$1" ] then continue fi lspv -l $disk | grep ^$lv > /dev/null if [ "$?" = "0" ] then { hdisk=$disk break } fi done echo "$lv $mountpt $lps $hdisk" >> /tmp/splitlvdata done # Now for each LV, we unmount it first print "Starting to umount the filesystems" for lv in ${lvs} do # Do the umount only if it is a filesystem fs=`grep ^$lv /tmp/splitlvdata | cut -f2 -d" "` if [ "$fs" != "N/A" ] then { # Check to see if it is mounted first mount | grep " /dev/$lv " > /dev/null if [ "$?" = "0" ] then { umount $fs if [ "$?" != "0" ] then { print "Error unmounting $fs - script stopping" exit 99 } fi } fi } fi done # Now for each LV, we split it print "Starting to split the LVs" for lv in ${lvs} do hdisk=`grep ^$lv /tmp/splitlvdata | cut -f4 -d" "` splitlvcopy -y mir${lv} $lv 2 $hdisk done

# Now we mount the original filesystems and assure the new mount point exists for lv in ${lvs} do mountpt=`grep ^$lv /tmp/splitlvdata | cut -f2 -d" "` if [ "$mountpt" != "N/A" ] then mount $mountpt mkdir $mountpt/mir fi done print "Application can be restarted now!" # Now we update /etc/filesystems print "Starting to update /etc/filesystems" # To do this first we need to know which is the JFS log lsvg -l $1| grep jfslog > /dev/null if [ "$?" = "0" ] then log=`lsvg -l $1 | grep jfslog | cut -f1 -d" "` fi for lv in ${lvs} do # is this lv a filesystem? mountpt=`grep ^$lv /tmp/splitlvdata | cut -f2 -d" "`/mir if [ "$mountpt" != "N/A/mir" ] then { echo " " >> /etc/filesystems echo "$mountpt:" >> /etc/filesystems echo " dev = /dev/mir${lv}" >> /etc/filesystems echo " vfs = jfs" >> /etc/filesystems echo " log = /dev/mir${log}" >> /etc/filesystems echo " mount = false" >> /etc/filesystems echo " options = rw" >> /etc/filesystems echo " account = false" >> /etc/filesystems } fi done # Now make map files for the LVs print "Starting to make map files" for lv in ${lvs} do cat /dev/null > /tmp/mir${lv}map lslv -m mir$lv | grep -v ^mir$lv: | grep -v ^LP | while read lpnum ppnum pv do echo ${pv}:$ppnum >> /tmp/mir${lv}map done done # Now remove the mirLVs print "Removing the split LVs" for lv in ${lvs} do rmlv -f mir$lv done # Now remove the input disks from the VG print "Removing the disks from the VG" disks=`echo $@ | cut -f 2- -d" "` reducevg $1 $disks # Now create the newVG

print "Starting to make the new VG" # First we need the old partition size ppsize=`lsvg $1 | grep "PP SIZE" | awk '{print $6}'` mkvg -y mir$1 -s $ppsize $disks # Now create the LVs using the maps for lv in ${lvs} do lps=`grep ^$lv /tmp/splitlvdata | cut -f 3 -d" "1` mklv -y mir$lv -m /tmp/mir${lv}map mir$1 $lps done

Sizing Page Space in AIX

Audience: All Date: March 28, 2002 You may be wasting disk and I/O capacity if you have a large paging space. Starting with AIX 4.3.2, the rules for sizing page space changed**. Previous to AIX 4.3.2, paging space needed to be large, typically 2-3 times the size of real memory. This is because page space was preallocated when a program started.....whether it used the page space or not. Starting with AIX 4.3.2, paging space is not allocated until needed ("deferred paging"). In this environment, the system uses page space only if it runs out of real memory. If the memory is sized correctly, there is no paging and the page space can be small. For example, I successfully ran a benchmark last summer on a p680 with 64 GB memory and a 32 MB page space. The application used less than 64 GB of real memory and it never touched the page space. So my rule of thumb is to size page space proportional to the probability of paging. The lower the probability, the smaller the page space. Here are a couple useful ways to determine how much memory and page space is being used by the system. 1. "lsps -a" command lists the amount of page disk that is currently allocated. (This is not to be confused with paging rate. It's only the amount of disk being used. It does not indicate whether the system is paging. See "vmstat"). 2. "vmstat": shows the paging rate. The system is paging when the PI or PO columns are greater than 0. 3. "svmon -G" command reports overall memory use. The output is listen in 4k pages, so multiply by 0.004 to convert to MBytes. 4. "wlmstat" to determine the amount of memory used by application, group, or user. For more information, see http://silcon.silcon.com/~baspence/AIXtip/wlm_memory.htm ** The following URL lists the AIX functional enhancements by release: http://www1.ibm.com/servers/aix/os/aixs2s.pdf

Choosing Between AIX 5 32 and 64 Bit Kernet

Audience: Systems Administrator Date: May 12, 2002 When you install AIX 5, you can choose either a 32 or 64 bit kernel. In most cases, the choice isn't critical. Here's the similarities and differences.

Similarities
Both 32 and 64 bit kernel support 64 bit applications Both support JFS2 (large filesystems)

Differences
The 64 bit kernel supports over 96 GB memory. My recommendation is to install the 32 bit kernel, unless you're using JFS2 or need to support over 96 GB memory. The 32 bit kernel has been around longer, and internal benchmarks show comparable performance to the 64 bit kernel. On the other hand, I understand the 64 bit kernel runs JFS2 better.

Remote Reboot Facility

Audience: Systems Administrator Date: June 1, 2002 The Remote Reboot Facility allows the system to be rebooted through a native (integrated) serial port. The system is rebooted when the reboot string is received at the port, followed by a confirmation response of 1. This facility is useful when the system does not otherwise respond but is capable of servicing serial port interrupts. For more information, see http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprob/prbslvgd/remrebfac.htm

Chapter 13. Remote Reboot Facility

The remote reboot facility allows the system to be rebooted through a native (integrated) serial port. The system is rebooted when the reboot string is received at the port, followed by a confirmation response of 1. This facility is useful when the system does not otherwise respond but is capable of servicing serial port interrupts. Remote reboot can be enabled on only one native serial port at a time. The user is expected to provide their own external security for the port. This facility runs at the highest device interrupt class and a failure of the UART to clear the transmit buffer quickly may have the effect of causing other devices to lose data if their buffers overflow during this time. It is suggested that this facility only be used to reboot a machine that is otherwise "hung" and cannot be remotely logged into. File systems will NOT be sync'd, and a potential for some loss of data which has not been flushed exists. It is strongly suggested that when remote reboot is enabled that the port not be used for any other purpose, especially file transfer, to prevent an inadvertent reboot.

Two native serial port attributes control the operation of remote reboot.

reboot_enable
Indicates whether this port is enabled to reboot the machine on receipt of the REMOTE reboot STRING, and if so, whether or not to take a system dump prior to rebooting.
no - Indicates remote reboot is disabled reboot - Indicates remote reboot is enabled dump - Indicates remote reboot is enabled, and prior to rebooting a system dump will be taken on the primary dump device.

reboot_string
Specifies the remote reboot string that the serial port will scan for when the remote reboot feature is enabled. When the remote reboot feature is enabled and the reboot_string is received on the port, a '>' character is transmitted and the system is ready to reboot. If a '1' character is recieved the system is rebooted; any character other than '1' aborts the reboot process. The reboot string has a maximum length of 16 characters and must not contain a space, colon, equal sign, null, new line, or cntrl-\ character. Remote reboot can be enabled through SMIT, or via the command line. For SMIT the path System Environments -> Manage Remote Reboot Facility may be used for a configured TTY. Alternatively, when configuring a new TTY, remote reboot may be enabled from the Add a TTY or Change/Show Characteristics of a TTY menus. These menus are accessed through the path Devices -> TTY. From the command line, the mkdev or chdev commands are used to enable remote reboot. For example, the following command enables remote reboot (with the dump option) and sets the reboot string to ReBoOtMe on tty1.
chdev -l tty1 -a remreboot=dump -a reboot_string=ReBoOtMe

This example enables remote reboot on tty0 with the current reboot string in the database only (will take effect on the next reboot).
chdev -P -l tty0 -a remreboot=reboot

If the tty is being used as a normal port, then you will have to use the pdisable command before enabling remote reboot. You may use penable to reenable the port afterwards.

Making Backups to DVD

Audience: Systems Administrator Date: June 9, 2002 A DVD can be an inexpensive way to make data or system backups. The current list price of a DVD is $1,000, compared to $2,000-$6,000 for tape. On the down side, the DVD storage capacity is limited to about 4 GB, which is

small compared to 20+GB for tape. Creating a DVD backup is different than making a tape backup. To create a backup, you use the new AIX mkcd command (or smit mkcd). The smit mkcd options are straightforward, with the exception of the "DVD sized image", which should be set to "yes". The mkcd command requires extra disk space, as it stages the backup data on disk. My understanding is the staging size is the size of the backup. So, if the backup size is greater than 2 GB, you'll need to change the ulimit (or fsize=1 in /etc/security/limits) for non-root users. For more information, see: http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds3/mkcd.htm http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixins/aixinsgd/intro_backup_cdrom.htm Finally, the mkcd requires the public domain software package "cdrecord-1.9.0.0" to burn CD's. This software is is available from the following website: http://www.rge.com/pub/systems/aix/bull/aix432 /

mkcd Command
Purpose
Creates a multi-volume CD (or CDs) from a mksysb or savevg backup image.

Syntax
mkcd -d cd_device | -S [ -m mksysb_image | -M mksysb_target | -s savevg_image | -v savevg_volume_group ] [ -C cd_fs_dir ] [ -I cd_image_dir ] [ -V cdfs_volume_group ] [ -G ] [ -B ] [ -p pkg_source_dir ] [ -R | -S ] [ -i image.data ] [ -u bosinst.data ] [ -e ] [ -P ] [ -l package_list ] [ -b bundle_file ] [ -z custom_file ] [ -D ]

Description
The mckd command creates a system backup image (mksysb) to CD-Recordable (CD-R) from the system rootvg or from a previously created mksysb image. It also creates a volume group backup image (savevg) to CD-R from a user-specified volume group or from a previously created savevg image. With mkcd you can create three types of CDs: personal system backup, "generic" backup, and a non-bootable volume group backup. Personal system backup CDs can only boot and install a specific machine and is similar to using mksysb on tape. Generic backup CDs can boot and install any RS/6000 platform (rspc, rs6k, or chrp). This backup requires all the necessary device support, including the MP kernel, to create the boot images for all three platforms. This type of backup also requires a user-supplied and previously created mksysb image. The non-bootable volume group backup contains only the CD image of a volume group. If this backup contains rootvg backup, then you must boot from a product CD before restoring the mksysb image, or use alt_disk_install to install it. If the backup volume group is a non-rootvg volume group, then use restvg to restore the image. Note: The functionality required to create Rock Ridge format CD images and to write the CD image to the CD-R device is not part of the mkcd command. You must supply additional code to mkcd to do these tasks. The code will be called via shell scripts and then linked to /usr/sbin/mkrr_fs (for creating the Rock Ridge format image) and /usr/sbin/burn_cd (for writing to the CD-R device). Both links are called from the mkcd command. Some sample shell scripts are included for different vendor-specific routines. You can find these scripts in /usr/samples/oem_cdwriters. If you do not give any file systems or directories as command parameters, mkcd creates the necessary file systems and removes them when the command finishes executing. File systems you supply are checked for adequate space and write access. Note: If mkcd creates file systems in the backup volume group, they are excluded from the backup. If you need to create multi-volume CDs because the volume group image does not fit on one CD, mkcd gives instructions for CD replacement and removal until all the volumes have been created.

Flags

To Back Up Your System

This section provides instructions for backing up your system, including how to back up the root volume group, verify a backup tape or CD, and back up a user volume group.

Complete the Prerequisites

Be sure you are logged in as root user. Mount all file systems you want to back up. The mksysb command only backs up JFS (Journaled File Systems). Refer to the mount command for details. Note: The mksysb command does not back up file systems mounted across an NFS network.

Unmount any local directories that are mounted over another local directory. Make at least 8.8MB of free disk space available in the /tmp directory. The mksysb command requires this working space for the duration of the backup. Use the df command, which reports in units of 512-byte blocks, to determine the free space in the /tmp directory. Use the chfs command to change the size of the file system, if necessary. For example, the following command adds 12MB of disk space to the /tmp directory of a system with 4MB partitions:
chfs -a size=+24000 /tmp

All hardware must already be installed, including external devices, such as tape and CD-ROM drives. The bos.sysmgt.sysbr fileset in the BOS System Management Tools and Applications software package must be installed. The bos.sysmgt.sysbr fileset is automatically installed in AIX Version 4.3. Enter the following command to determine if the bos.sysmgt.sysbr fileset is installed on your system:
lslpp -l bos.sysmgt.sysbr

If your system has the bos.sysmgt.sysbr fileset installed, continue with either To Back Up the Root Volume Group or To Back Up a User Volume Group. If the lslpp command does not list the bos.sysmgt.sysbr fileset, install it before continuing with the backup procedure. Refer to To Install Software and Service Updates with Custom Install for instructions, or enter the following command:
installp -agqXd device bos.sysmgt.sysbr

where device is the location of the software; for example, /dev/cd0 for CD-ROM drive.

To Back Up the Root Volume Group

Use either the Web-based System Manager Backups application or SMIT to create a system backup stored either to tape or in a file. If you are using AIX Version 4.3.3 or later, the system backup image can be stored on CD. Using Web-based System Manager To use the Web-based System Manager application to back up the root volume group, enter the wsm backup fast

Installing BOS from a System Backup

If you are installing from a backup image you made of your system, follow these steps: 1. Go to Installing BOS from a System Backup . 2. Go to Customizing Your Installation if the installed system requires further configuration.

Installation Guide
Introduction to Backups on CD
Creating a backup CD is new function that has been added to AIX Version 4.3.3. It is similar to making a backup tape for your personal use, but with some noticeable differences. You must obtain the hardware and software necessary to create a CD. IBM does not sell or support the software or hardware that is used to create CD's. The new command for this process, mkcd, requires that you already have the software to create a CD-ROM file system (Rock Ridge) and to "burn" or write the CD. Some of the hardware and software that was tested with this procedure includes: Software Hardware

GNU & Free Software Foundation, Inc. Yamaha CRW4416SX Ricoh MP6201SE 6XR-2X Panasonic Cw-7502-B cdrecord version 1.8a5 mkisofs version 1.5 Jodian Systems and Software, Inc. CDWrite version 1.3 mkcdimg version 2.0 Youngminds, Inc. MakeDisc version 1.3-Beta2 and CD-R creation software, refer to the following file:
/usr/lpp/bos.sysmgt/README.oem_cdwriters

Tested on all of above

CD Studio For more information about CD-R drives

Once you decide what hardware and software you want to use and obtain it, you will need to create the appropriate links to scripts that have been written that will work with the mkcd command. For example, if you are using Jodian software, then you will need to create the following links:
ln -s /usr/samples/oem_cdwriters/mkrr_fs_jodian /usr/sbin/mkrr_fs ln -s /usr/samples/oem_cdwriters/burn_cd_jodian /usr/sbin/burn_cd

In order to run the mkcd mkcd command, you will need extra working space. A separate file system or directory is required for each of the following:

storing a mksysb or savevg image storing the CD file system contents storing the CD images before they are recorded

The mkcd command will create the following file systems if they are not already present, or if alternate file systems or directories have not been given:
/mkcd/mksysb_images /mkcd/cd_fs /mkcd/cd_images

The space used in these file systems will only be temporary (unless the -R or -S flag is specified to save the images). If the mkcd command creates the file systems, it will remove them. Each file system or directory could require over 640 megabytes. The /mkcd/cd_fs directory will need 640 megabytes. The /mkcd/mksysb_images directory's space requirement will depend on the size of the mksysb image that will be created. The mkcd process will attempt to calculate this space and verify that adequate space is available before starting the mksysb image. The /mkcd/cd_image directory will be need at least 640 megabytes of space. If the -R or -S flags are used to specify not removing the images, and there are multiple volumes required, then more space will have to be provided. If you don't have space on your machine, you may want to NFS mount space from another server system, however, the file systems must be writeable. You could create a /mkcd file system that is very large (1.5 gig) and then create subdirectories cd_fs, mksysb_images and cd_images under /mkcd. Then /mkcd could be mounted on to the clients when they wanted to create a backup CD on their systems.

Personal and Generic backup CD's

There are two types of backup CD's that can be created. The first is what we call a "personal" backup CD. This type is similar to a backup tape, in that it will only boot and install the machine on which it was created. The second type of CD is a "generic" backup CD. This type of backup can be used to boot any RS/6000 machine running the AIX operating system. It contains 3 boot images and all the device and kernel packages necessary to install any system. The mksysb image that is stored on the CD does not require that all the devices be installed in it, because the install process will install the needed devices for that machine from the packages on the CD. This type of backup CD might be used to install (clone) a large number of machines in a customer's environment. This is particularly convenient when each machine in the system environment needs to have the same image installed, but may not all have the same hardware configuration. There are SMIT (smit mkcd) and Web-based System Manager Backups (wsm backup) interfaces available for the mkcd command. The Web-based System Manager Back Up to CD TaskGuide will help you through the required steps and will even create the links to the OEM scripts for you. Another option available with the mkcd command is the ability to create a savevg CD. This CD has a copy of a non-rootvg volume group on it, and is useful for volume groups that contain user data. At this time, the mkcd command only supports saving one volume group to a CD at a time. However, if your rootvg image and savevg image were small enough to fit on one CD, then you could save them both by taking advantage of the -l (stacklist) flag. This flag gives a list of images to copy to the CD, and the -z (customization_script) flag. If you make a copy of a non-rootvg volume group ahead of time, and then write a script that calls restvg, then your non-rootvg, would be restored to hdisk2 at the end of the install of rootvg. For example:
restvg -d /SPOT/usr/sys/inst.images/savevg_image hdisk2

This procedure would only be recommended if you knew that you wanted to restore the non-rootvg volume group every time you installed. Otherwise, you might just want to store it on the CD, then use restvg (smit restvg or wsm lvm) to restore it after reboot. The restvg command will be able to restore from CD if the name of the image is savevg_image.

Non-Strict Disk Mirroring

Audience: System Administrators Date: July 22, 2002 The "non-strick" AIX mirroring option can be used to mirror data over fewer disks compared to the traditional "strict" mirroring option. The attached diagram illustrates both options. In both cases, the data is protected from hardware failure as no two mirror copies reside on the same physical disk. In this example, the non-strict option uses half the disk drives of the strict option. However, this can be customized this using the "mklv" command: mklv -y strict_lv -e x -c 2 datavg 3 hdisk2 hdisk3 hdisk4 The view the physical partition layout:
lslv -m strict_lv

LP 0001 0002 0003

PP1

PV1

PP2

PV2

0017 hdisk2 0249 hdisk3 0103 hdisk4

0250 hdisk3 0104 hdisk4 0018 hdisk2

To replace a failed disk, use the "migratepv" command. Here are the steps to recover from a failed disk. 1. 2. 3. 4. 5. 6. 7. 8. Backup the data Pull the failed disk, let's call it hdisk4 Put in a new disk Run: cfgmgr -l <disk adapter> and the new disk will show up, let's call it hdisk5 Run: extendvg <vgname> hdisk5 Run: migratepv hdisk4 hdisk5 Run: reducevg <vgname> hdisk4 Run: rmdev -dl hdisk4

PS Thanks Dan Braden for this tip.

AIX Event Monitoring

Audience: System Administrators Date: August 11, 2002 AIX can be configured to automatically respond to conditions that could adversely affect your system. The responses can include email notifications, a system broadcast, log entries or run a customized script. There are 84 predefined conditions that AIX can monitor. The conditions cover:

Filesystem Disk I/O Network CPU Memory

You must use WebSM to configure AIX's event monitoring. WebSM is the Java based GUI systems administration tool. Once you get it running, it is fairly self-explanatory. WebSM is typically enabled by default. If not, see the follow URL's for instructions.

WebSM Command
http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds6/wsmserver.htm

Setup
http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/websm.htm#BA8E4E0779mart To run WebSM from your PC, you need to install the client application, which is located in the AIX directory. /usr/websm/pc_client directory/setup.exe

wsmserver Command
Purpose
Configures the functionality of the Web-based System Manager servers.

Syntax
/usr/websm/bin/wsmserver -enable /usr/websm/bin/wsmserver -disable /usr/websm/bin/wsmserver -start /usr/websm/bin/wsmserver -enablehttps [port_number] /usr/websm/bin/wsmserver -disablehttps /usr/websm/bin/wsmserver -starthttps /usr/websm/bin/wsmserver -sslalways /usr/websm/bin/wsmserver -ssloptional

Description
The wsmserver command is used to control the server processes used by the Web-based System Manager. The servers are used to enable applet and client-server modes of execution. In addition, if the security functionality is installed, the SMGate utility can be configured. Note: The full pathname of this command, /usr/websm/bin/wsmserver, must be specified.

Flags
-enable Enables the applet and client-server modes. -disable Disable the applet and client-server modes -start Start a session of the Web-based System Manager server. This is normally only used by inetd. security functionality has been installed: -enablehttps [port_number] -disablehttps -starthttps -sslalways -ssloptional The following flags can only be used if the

Starts the SMGate utility. An optional port_number for the SMGate server can be specified. If specified, the SMGate server listens on that port instead of the default of 9092. Disables the SMGate utility. Starts the SMGate utility. This is normally started by the init process. Allows only secure connections. This flag is for a system with security configured. Allows both secure and non-secure connections to the Web-based System Manager.

Examples
1. To enable Web-based System Manager for applet and client-server mode, enter:

Stand-Alone Web-based System Manager

Web-based System Manager applications can be run on an AIX machine with Web-based System Manager installed just like other AIX applications. When Web-based System Manager applications are run in this method, no data is transferred over the network. Running Web-based System Manager applications in stand-alone mode requires a graphics terminal.

Installing Stand-alone Web-based System Manager

Web-based System Manager should be installed with the base operating system. The sysmgt.websm.apps fileset pre-reqs the necessary filesets. If this fileset is installed,then Web-based System Manager will be available. Prerequisites:

bos.rte 4.3.0.0 (base operating system) sysmgt.help.msg.<LANG>.websm (SMIT contextual helps fileset)

Co-requisites:

Java.rte 1.1.2 (Java virtual machine with Java 1.1.2 support) bos.net.tcp.client 4.3.0.0 (TCP/IP Client Support)

Configuring Stand-alone Web-based System Manager

No configuration is necessary for running stand-alone Web-based System Manager applications.

Running Stand-alone Web-based System Manager

From the command line: Web-based System Manager can be started with the command wsm. This will bring up a launch application from which all Web-based System Manager applications can be launched. The following fastpaths are also supported: Application Backups Devices File Systems NIM Network PC Services Printer Queues Fastpath wsm backup wsm devices wsm fs wsm nim wsm network wsm pc wsm printers

Client-Server Web-based System Manager

Web-based System Manager applications can also be run in client-server mode. In this mode, the AIX machine acts as a server to a graphical client located elsewhere on the network. The Web-based System Manager server does not require a graphical terminal.

Installing Client-Server Web-based System Manager

Server Installation The same filesets that allow Web-based System Manager Applications to run in stand-alone mode also allow Webbased System Manager to run in client-server mode. In addition, the Web-based System Manager server must be configured to be started by inetd when a client connects to the Web-based System Manager server. By default, when Web-based System Manager is installed, the Web-based System Manager server will be configured to run in this manner. Client Installation Because Web-based System Manager is written in Java, a Web-based System Manager client can be any machine that has a Java 1.1.2 Virtual Machine installed, including a machine with a browser that supports Java 1.1.2 A Webbased System Manager client could be another AIX machine with a graphics terminal, or a PC. There are two possibilities for Web-based System Manager clients: an applet client in a browser, and an AIX client application.

Applets: A Web-based System Manager client can be run as an applet in a browser, or as a stand-alone Java application. To run a Web-based System Manager client in a browser requires no installation. The Java classes will be downloaded by the browser as needed. AIX client applications: All AIX machines with Web-based System Manager installed can serve as both Web-based System Manager servers and Web-based System Manager clients. No additional installation is necessary.

Configuring Client-Server Web-based System Manager

Configuring the Web-based System Manager Server The Web-based System Manager server will be started by inetd when a Web-based System Manager client connects to the server. By default, the Web-based System Manager server will listen on port 9090 after initialization. Configuring the Web-based System Manager client A remote Web-based System Manager application will prompt the user for a hostname on startup. The port to which the client connects is by default the Web-based System Manager Server default port. The port number can be passed to the client application on the command line, or can be stored in the websm.cfg file. Web-based System Manager Config file The Web-based System Manager config file websm.cfg is kept in the /usr/websm directory on AIX machines for both the Web-based System Manager server and the Web-based System Manager client. On non-AIX machines, this file will be searched for in the directory from which an application is invoked. The Web-based System Manager Config file supports the following parameters:

Web-based System Manager Security

Before installing and configuring Web-based System Manager security be sure that Web-based System Manager for client-server operation has been configured. See Client-Server Web-based System Manager. In Web-based System Manager secure operation, the managed AIX machines are servers, and the managing users are the clients. The communication between the servers and clients is over the SSL protocol which provides server authentication, data encryption, and data integrity. The user manages the AIX machine by Web-based System Manager using an AIX account on that machine, and authenticates to the Web-based System Manager server by sending the user ID and password over the secured SSL protocol. Each Web-based System Manager server has its private key and a certificate of its public key signed by a Certificate Authority (CA) which is trusted by the Web-based System Manager clients. The private key and the server certificate are stored in the server's private key ring file /usr/websm/security/SM.privkr. The Web-based System Manager client has public key ring file which contains the certificates of the CAs it trusts. This file is SMpubkr.class. It is a .class file so that the same file may be used both for application and applet modes. In applet mode (working from the browser), the client must be assured that the applet (.class files) arriving at the browser is coming from the intended server. Moreover, in this mode the public key ring file (SMpubkr.class) resides on the server and is transferred to the client with the rest of the applet .class files (it is done this way because the browser does not allow applets to read local files). For sender authentication and integrity of these files the client must use the SSL capabilities of the browser and contact the server only with the HTTPS protocol (HTTPS://...). For this you can use the SSL capability of the web server on each managed machine or you can use the SMGate daemon installed with Web-based System Manager Security. SMGate serves as an SSL gateway between the client browser and the web server. In this section, the following procedures and processes related to Security are discussed at length:

Installing Web-based System Manager Security Configuring Web-based System Manager Security Enabling Web-based System Manager Security Enabling SMGate Running Web-based System Manager Security Troubleshooting Web-based System Manager Security

Installing Web-based System Manager Security

Web-based System Manager Security's pre-requisite is the Web-based System Manager. The Web-based System Manager Security fileset, sysmgt.websm.security, where available, can be found on the AIX Version 4.3 Bonus Pack. An additional fileset, sysmgt.websm.security-us, with stronger encryption capabilities, is available on the AIX Version 4.3 Bonus Pack that ships only in the U.S. and Canada. This fileset requires that you have sysmgt.websm.security.

Configuring Web-based System Manager Security

Web-based System Manager Security provides both a graphical interface and a command line interface for

AIX 5L Fix Distribution

Audience: System Administrators Date: August 16, 2002 It is important to keep your AIX operating system current because it fixes bugs, adds new functionality, improves performance, and keeps Supportline happy. The fixes to keep your system current are freely available on the internet. However, the location and procedure for downloading AIX 5L fixes is different than AIX 4. The URL for requesting AIX 5L fixes is http://techsupport.services.ibm.com/server/aix.elecptforder To use this facility, a user must obtain an "IBM Common Registration UserID" from http://www.ibm.com/registration/selfreg In addition, the download procedure has changed. Here's how the new procedure works:

You submit a request for the fix The systems generates a tar file containing the fix and its requisites The system places the tar file on an FTP server (generally 5 minutes, but may take as long 2 hours) The system sends you an e-mail with the ftp-link and retrieval instructions (The ftp file is kept on the server for 72 hours, then erased.)

Unlike the web-based FixDist interface, there is no "search" capability. You'll have to use the APAR database to do any searching.

Changing the AIX Login Herald

Audience: System Administrators Date: August 28, 2002 Here are two ways to customize the AIX login prompt. The first way is to add a "herald" in the default stanza in the /etc/security/login.cfg file as follows
default: sak_enabled = false logintimes = logindisable = 0 logininterval = 0 loginreenable = 0 logindelay = 0 herald = "Dodgers\r\nID:"

The second method uses the "chsec" command to modify the same file:

chsec -f /etc/security/login.cfg -s default -a herald="Dodgers\r\nID:" Note: for additional security, I recommend changing the standard Unix "login" prompt to something else like "ID". The "login" prompt almost invariably identifies the system as Unix to hackers.

Switching Between 32 and 64 Bit AIX 5 Kernels

Audience: System Administrators Date: September 12, 2002

Switching From 32 to 64 Bit Mode

To switch from 32-bit mode to 64-bit mode run the following commands, in the given order: 1. 2. 3. 4. 5. ln -sf /usr/lib/boot/unix_64 /unix ln -sf /usr/lib/boot/unix_64 /usr/lib/boot/unix bosboot -ad /dev/ipldevice shutdown -Fr bootinfo -K (should now show 64)

Switching From 64 To 32-Bit Mode

To switch from 64-bit mode to 32-bit mode run the following commands, in the given order: 1. 2. 3. 4. 5. ln -sf /usr/lib/boot/unix_mp /unix ln -sf /usr/lib/boot/unix_mp /usr/lib/boot/unix bosboot -ad /dev/ipldevice shutdown -Fr bootinfo -K (should now show 32)

Mirroring rootvg
Audience: System Administrators Date: September 25, 2002 Mirroring "rootvg" protects the operating system from a disk failure. Mirroring "rootvg" requires a couple extra steps compared to other volume groups. The mirrored rootvg disk must be bootable *and* in the bootlist. Otherwise, if the primary disk fails, you'll continue to run, but you won't be able to reboot. In brief, the procedure to mirror rootvg on hdisk0 to hdisk1 is 1. Add hdisk1 to rootvg: extendvg rootvg hdisk1 2. Mirror rootvg to hdisk1:

mirrorvg rootvg hdisk1 (or smitty mirrorvg) 3. Create boot images on hdisk1: bosboot -ad /dev/hdisk1 4. Add hdisk1 to the bootlist: bootlist -m normal hdisk0 hdisk1 5. Reboot to disable quorum checking on rootvg. The mirrorvg turns off quorum by default, but the system needs to be rebooted for it to take effect. For more information, and a comprehensive procedure see the man page for mirrorvg and http://techsupport.services.ibm.com/server/aix.techTips Set filter for "mirror rootvg". The article you want is "Mirroring rootvg Volume Group for AIX 4 and 5"

Forwarding AIX Error Messages to a Central Host

Audience: Systems Administrators Date: September 27, 2002 System administrators should check AIX's error log daily to look for problems that might cause an outage. The command to check the error log is "errpt" or "smit errpt". Checking the error logs can be time consuming if you support multiple hosts. Here's a procedure to automatically send error log entries to a central host. The procedure involves creating an ODM entry that immediately runs the "logger" command when any error is logged. The "logger" command sends the error message to the local syslog demon , which forwards it to a central host. On each AIX host that you want to monitor the error log: 1. Create an ODM entry to run the "logger" command whenever an error is logged.
# vi /tmp/syslog.add errnotify: en_name="syslog1" en_persistenceflg = 1 en_method = "logger -pnotice Msg from Error Log: $(errpt -a -l $1 | grep -v 'ERROR_ID TIMESTAMP')"

2. Add the entry to ODM

# odmadd /tmp/syslog.add

3. Add a syslog entry to forward "notice" priority messages to remote host "centhost"
# vi /etc/syslog.conf *.notice @centhost

4. Refresh the syslog demon to pick up the new entry

# refresh -s syslogd

On the central host "centhost" where you want to collect error logs: 1. Add a line to the syslog.conf file that saves the messages to a file
# vi /etc/syslog.conf *.notice /var/central_syslog.txt

2. Create an empty log file (file must exist for syslog to use it).
# touch /var/central_syslog.txt

3. Refresh the syslog demon to pick up the new entry

# refresh -s syslogd

There are multiple variations on forwarding error messages. For example, you can email error notifications. To do so, skip the syslog steps, and change the en_method in the errnotify stanza to
en_method = "errpt -a -l $1 | mail -s 'Error Log' joe@xyz.com"

For more information on AIX's Error Notification facility, forwarding specific error messages, and working with the ODM commands used in this example: http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/error_notice.htm

Chapter 4. Error Notification

The Error Notification object class specifies the conditions and actions to be taken when errors are recorded in the system error log. The user specifies these conditions and actions in an Error Notification object. Each time an error is logged, the error notification daemon determines if the error log entry matches the selection criteria of any of the Error Notification objects. If matches exist, the daemon runs the programmed action, also called a notify method, for each matched object. The Error Notification object class is located in the /etc/objrepos/errnotify file. Error Notification objects are added to the object class by using Object Data Manager (ODM) commands. Error Notification objects contain the following descriptors: en_alertflg Identifies whether the error is alertable. This descriptor is provided for use by alert agents associated with network management applications. The valid alert descriptor values are: TRUE alertable FALSE not alertable Identifies the class of the error log entries to match. The valid en_class descriptor values are: H Hardware Error class S Software Error class O Messages from the errlogger command U Undetermined Specifies the error identifier associated with a particular error. Specifies the label associated with a particular error identifier as defined in the output of the errpt -t command. Specifies a user-programmable action, such as a shell script or command string, to be run when an error matching the selection criteria of this Error Notification object is logged. The error notification daemon uses the sh -c command to execute the notify method. The following key words are automatically expanded by the error notification daemon as arguments to the notify method. $1 Sequence number from the error log entry $2 Error ID from the error log entry $3 Class from the error log entry $4 Type from the error log entry $5 Alert flags value from the error log entry $6 Resource name from the error log entry $7 Resource type from the error log entry $8 Resource class from the error log entry $9 Error label from the error log entry en_name Uniquely identifies the object. The creator uses this unique name when removing the object. en_persistenceflg Designates whether the Error Notification object should be automatically removed when the system is restarted. For example, to avoid erroneous signaling, Error Notification objects containing methods which send a signal to another process should not persist across system restarts. This is because the receiving process and its process ID do not persist across system restarts. The creator of the Error Notification object is responsible for removing the Error Notification

en_class

en_crcid en_label en_method

AIX 5 Error Messages and Codes

Audience: All Date: May 6, 2003 Beginning with AIX5L, IBM discontinued the publication of the Messages Guide & Reference whitebook [SC234129]. This info is now available using a web applet that allows you to look up one error message at a time. http://www16.boulder.ibm.com/pseries/en_US/infocenter/base/errorsearch.htm Doug Ranz has put together a PDF file containing all the error codes. It is available on his web site at: http://rainsux.dyndns.org/AIX5L-Messages-Codes.html

Identifying Critical AIX Fixes

Audience: All Date: May 15, 2003 The best way to manage problems is by prevention. One way to prevent problems on an AIX system is by applying the "critical" updates. This tip explains how to identify and download AIX "critical" updates from the web. 1. Start at the following URL: o https://techsupport.services.ibm.com/server/aix.fdc 2. Select "Search and download selective fixes" (default) o Choose appropriate "OS Level" o "Search by" = APAR o "Search string" = critical o Click "Find Fix" 3. On next window o Choose most recent fix (as of today it's IY43242 - CRITICAL FIXES FOR AIX 5.1 AS OF APRIL 2003) o Click "Add to List" o Click "Proceed to Packaging 4. On the next window o Select current "OS level" o Click "Proceed to Download Page" 5. Choose your download preference

Validating Backups
Audience: All Date: June 27, 2003 I've been involved in a couple of situations this month where customers could not restore a mksysb or a backup tape.

To insure you don't get into this situation, I recommend checking your backups by periodically restoring them on a different machine. Here are a few other guidelines.

Backup before and after major changes Periodically test the backup by restoring on a different machine. Cycle backup tapes. Keep several backups tapes in case a tape goes bad. Clean the tape head monthly Replace tapes after they have exceeded the manufacturer's recommended duty cycle (usually 50-100 backups) Check the integrity of filesystems using fsck. You probably won't be able to restore a backup of a damaged filesystem. Choose the right backup command. For example, tar can't backup files larger than 2GB.

Data Recovery Services

When all else fails, here are a sources for data recovery from 4/8mm tapes. Note IBM can not endorse or recommend outside sources.

IBM: contact your local rep. ONTRACK (800) 872-2599, http://www.ontrack.com ACTION FRONT, (800) 563-1167 http://www.actionfront.com/indexng1.html http://www.datarecoveryrichmond.com/ Drive Savers 800-440-1904

Check Your Time Zone Setting for Possible Defect

Audience: All Date: October 15, 2003 Last year a defect prevented some AIX systems from implementing the shift from "daylight savings" to "standard" time. This caused considerable consternation among sysadmins, especially those that changed the system clock when they discovered it was apparently set wrong. With the time change two weeks away, it would be a good idea to verify that your system does not have this problem. The defect causes two commas to be appended to the TZ environment variable when it is set via smit chtz For example, the "echo $TZ" command displays "CST6CDT,,". Check the TZ variable in /etc/environment. If it is corrupted, install the appropriate APAR
AIX V4.3.3 AIX V5.1 AIX V5.2 IY34798 IY34203 IY35629 SMITTY CHTZ APPENDING 2 COMMAS AFTER TZ SMITTY CHTZ APPENDING 2 COMMAS AFTER TZ SMITTY CHTZ APPENDING 2 COMMAS AFTER TZ

and then run the command "smit chtz". Once TZ is set properly, refresh the cron daemon, and restart applications

that are sensitive (like cron) to the current time. (The most cautious approach is to reboot the system, since it is very difficult to identify every process which is sensitive to the current time and which is still running with the old setting of $TZ.)

Configuring Hang Detection and Response

Audience: All Date: November 10, 2003 The "smitty shpriocfg" command configures how AIX 5 responds to system hangs. A hang is where the system becomes unresponsive, most often due to run away applications. The possible responses include

Bring up a high priority console on a RS-232 terminal. Run a script Reboot the system.

For more information, see the "shconf" man page.

Working With Device Settings

Audience: Administrators Date: November 22, 2003 Here are a few commands for working with devices on an AIX system. To list all devices on an AIX system, run the command # lsdev -C To list specific device types, use the "-Cc" flag. For example, this command lists only adapters. # lsdev -Cc adapter To list the attributes of a particular device # lsattr -HEl <device> e.g.:

# lsattr -HEl hdisk1 attribute value description user_settable

pvid queue_depth

000008767ae0ba390000000000000000 Physical volume identifier 3 Queue depth Write queue depth modifier Adapter connection Adapter connection Primary adapter RESERVE device on open SSA Connection Location

False True True False False True True False

write_queue_mod 0 adapter_a adapter_b ssa0 none

primary_adapter adapter_a reserve_lock connwhere_shad max_coalesce size_in_mb location yes 0004AC504D6500D 0x20000 2255

Maximum coalesced operation True Size in Megabytes Location Label False True

The attributes which you can change have a "True" value under the "user_settable column. To display the legal values for an attribute. # lsattr -Rl <device> -a <attribute> # lsattr -Rl hdisk1 -a queue_depth 0...200 (+1) In this case, the queue_depth can be set from 0 to 200 in increments of 1. See the AIX documentation for more information on the meaning of each attribute To change an attribute, use the "chdev" command. Normally you can not change an attribute of a device that is online. The following command changes the attribute in the ODM, and goes into affect after a reboot (or rmdev/mkdev). # chdev -l <device> -a <attribute>=<new value> -P To change an attribute of a device that is offline: # chdev -l <device> -a <attribute>=<new value>

Maximum AIX File/Filesystem Sizes

Audience: Administrators Date: January 23, 2004 The maximum AIX file and filesystem size depends on the kernel type and AIX/JFS versions. Here are the

maximum supported values. Maximum File/Filesystem Sizes in AIX

23-Jan-04

AIX 4.3
JFS AIX Kernel Maximum Supported File Size Filesystem Size JFS 32/64 JFS 32/64

AIX 5.1
JFS2 32 Bit 64 Bit JFS 32/64

AIX 5.2
JFS2 32 Bit 64 Bit

64 GB 1 TB

64 GB 1 TB

1 TB 1 TB

1 TB 1 TB

64 GB 1 TB

1 TB 1 TB

16 TB 16 TB

Subject: AIX Architectural Limits by Version

Audience: Administrators Date: May 7, 2004 Here is a list of architectural limits for AIX 4.1 through 5.2. AIX-Features-Limits"

Notes:
The maximum limits listed in this document are not valid for all configurations. The limits also depend on the kernel (32/64 bit) and JFS/JFS2. For example, the document lists the max memory for AIX 5.2 as 512 GB. This is valid for the 64 bit kernel, but not the 32 bit kernel which supports 96 GB memory. Similarly, as noted in a previous tip, the maximum file size for JFS2 is 16 TB, but the JFS max is 64 GB. This document shows an outdated "end of service" for AIX 5.1 and 5.2. Here is the current plan for AIX as of May 2004.
AIX AIX AIX 5L Base Operating System AIX 5L for POWER 5765-E61 5765-E62 5.1.0 5.2.0 2006-04-01 2007-09-01

As always, plans can change, as evidenced by today's document. You can check the current plan at: http://www-1.ibm.com/services/sl/products /

Subject: Distributed Shell Command dsh

Audience: Administration Date: June 4, 2004 PSSP's distributed shell commands "dsh" and "dshbak" are now standard in AIX 5.2. They run commands in parallel on multiple hosts, and format the output. The dsh commands simplify management of server farms. The set of nodes to which commands are sent can be set on the command line or by the contents of a file named by

the DSH_LIST environment variable. Here are a couple simple examples how these commands can be used. (Assume DSH_LIST has been set to the name of the file containing the list of servers. In this case, just three servers: dodgers, surveyor and pioneer) Check the clock setting on all servers:
# dsh date dodgers: Fri Jun 4 14:46:06 PDT 2004 surveyor: Fri Jun 4 14:16:18 PDT 2004 pioneer: Fri Jun 4 14:32:28 PDT 2004

Identify servers running fix IX37151

# dsh "instfix -ik IX37659" dodgers: There was no data for IX37659 in the fix database surveyor: All filesets for IY37659 were found pioneer: All filesets for IY37659 were found

Check the hardware error logs on all servers starting 6/4/04

# dsh "errpt -s 0604000004"

Or check the OS level on each server:

# dsh "lslpp -L bos.rte | grep bos.rte"

You can also use "dshbak" to group common output from the # dsh command. This makes it easier to identify differences when you have a lot of servers. For example, we can consolidate the output of the above instfix command as follows.
# dsh "lslpp -L bos.rte" | dshbak HOST: dodgers --------------------There was no data for IX37659 in the fix database.

HOST: surveyor, pioneer ---------------------------------All filesets for IY37659 were found

Both commands are located in the /opt/csm/bin directory. They require a little customization. Check the AIX documentation for more information. http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds2/dsh.htm

Subject: How to Mounta Remote CD-ROM Using NFS

Audience: Administration Date: May 21, 2004 LPARs typically do not have a dedicated CD-ROM for installing software and updates. To get around this, I typically mount a remote CD-ROM as a NFS filesystem. The attached "How to" provides instructions for doing so. PS This may be cumbersome or not work at all for multi-volume CD's. In these situations, my first strategy would be to copy the CD's to disk, and NFS mount the filesystem on the client.
How to NFS Mount a cdrom Filesystem

Following are the steps required to mount a CD-ROM as a cdrom filesystem, export the NFS filesystem from the server and NFS mount the filesystem on the client. This document applies to AIX Versions 4.3 and above. On the server On the client Troubleshooting -------------------------------------------------------------------------------

On the server

1. Check the status of portmap and the NFS daemons: o Enter lssrc -s portmap. o Enter lssrc -g nfs. o If they are not active, start them by running startsrc -s portmap and then startsrc -g nfs.

2. Mount the CD-ROM: o Enter mkdir /cdrom to create a mount point, if one does not already exist.

o Load the CD into the CD-ROM drive. o Enter smitty cdrfs. o Select Add a CDROM File System. o Select your device from the F4 list. o Enter the mount point you just created for MOUNT POINT. o Enter names of client servers allowed root access (Req'd if accessing via root id on client) o If you want the filesystem to mount on a reboot, change Mount AUTOMATICALLY at system restart to yes. NOTE: If you specify yes for Mount AUTOMATICALLY at system restart, you must have media in the CD-ROM drive when you reboot or the mount will fail. o Enter mount /cdrom.

3. To add the filesystem for NFS exporting: o Enter smitty mknfsexp. o Enter the PATHNAME of the directory to export (for example, /cdrom). o Change the MODE of export directory to read-only. o Enter the HOSTS & NETGROUPS allowed client access. o Enter HOSTS allowed root access. o Press Enter to export the filesystem. NOTE: If you are going to be installing on the client machine, you MUST enter the client name for HOSTS allowed root access.

4. Verify that the filesystem is exported: o Enter showmount -e and find it in the list.

-------------------------------------------------------------------------------

On the Client

1. Check the status of portmap and the NFS daemons: o Enter lssrc -s portmap. o Enter lssrc -g nfs. o If they are not active, start them by running startsrc -s portmap and then startsrc -g nfs.

2. Verify that the server has the filesystem exported: o Enter showmount -e . NOTE: will be the hostname of the server.

3. Create the directory you will be using to access the software. o Enter mkdir /cdrom.

4. To NFS mount the filesystem on the client: o Enter smitty mknfsmnt. o Enter the PATHNAME of the mount point (for example, /cdrom). o Enter the PATHNAME of the remote directory (for example, /cdrom). o Enter the HOST where the remote directory resides. NOTE: HOST will be the hostname of the server. o Change the MODE for this NFS file system to read-only. o Press enter to NFS mount the filesystem.

On AIX 4.x BOS installation CD-ROMs and most LPP CD-ROMs, the install images

are now located in /cdrom/usr/sys/inst.images. On some LPP CD-ROMs, the install images are located in /cdrom. To check which directory the install images are on, check for the existence of a .toc file in the directory. Once you have determined the directory with the .toc file, use the full pathname of the directory as your in SMIT when you perform your install.

-------------------------------------------------------------------------------

Troubleshooting

Look for the following errors:

mount: 1831-011 access denied for ... mount: 1831-008 giving up on ...

If they occur, try the following suggestions:

1. Make sure that the client's hostname and IP address are resolvable by the server. Also, make sure that the server's hostname and IP address are resolvable by the client. You can do so by running the following:

On the server:

host host

The output of these lines has to match EXACTLY.

On the client: host host

The output of these lines has to match EXACTLY. 2. On the client, enter netstat -in. If there is more than one network interface, make sure all IP addresses of the client are resolvable by the server. You can do this by running (on the server): host Execute this command for each IP address listed in the netstat -in output. 3. If you are still getting errors:

On the server, enter smitty rmnfsexp. o Enter the PATHNAME of the exported directory (for example, /cdrom). o Press Enter to remove the directory from the exports list. o Enter umount /cdrom. o Enter rmdir /cdrom. o Return to step 1 of the section "On the server". If you still cannot get the CD-ROM NFS mounted, contact your AIX support center for further assistance.

Subject: Online Backups

Audience: Administration Date: July 6, 2004 There are two ways to do on-line filesystem backup in AIX, depending on whether it is a JFS or JFS2 filesystem. For JFS filesystems (AIX 5.1, 5.2) use the "chfs" command with the "splitcopy" option**. This splits off one of the mirrored filesystem copies, and mounts it on a separate, static filesystem. The static filesystem is used for the backup, while the primary copy runs production. After backup completes, the split copy is manually reintegrated

with production in the background. For JFS2 (AIX 5.2), use the "backsnap" command (smit backsnap) which does the entire snapshot, backup and reintegration in one command. "backsnap" uses less disk space as it doesn't require a full mirror copy. Instead it uses a small snapshot filesystem (2-15% of the filesystem to be backed up). The snapshot is a "point in time" image of the filesystem, and is the basis for backup. The backup can be either full (by name) or incremental (by inode). In either case, the backup runs in the background. When completed, there is an option to remove the snapshot. For more information, see: http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds1/backsnap.htm Systems Management Concepts (See section: "Understanding JFS Online Backups and JFS2 Snapshots") http://publib16.boulder.ibm.com/pseries/en_US/aixbman/baseadmn/HT_baseadmn_snapshotfs.htm (**Comment: the JFS log has to be mirrored for "chfs -a splitcopy" to work)

backsnap Command
Purpose
Provides an interface to create a snapshot for a JFS2 file system and perform a backup of the snapshot.

Syntax
backsnap [ -R ] -m MountPoint -s size=Size [ BackupOptions ] FileSystem

Description
Provides an interface to create a snapshot for a JFS2 file system and perform a backup of the snapshot.

Flags
-m MountPoint -R -s size=Size Specifies the path of where the snapshot created should be mounted. Specifies that the snapshot created by this command will be removed when the backup completes. Specifies the size to create the new logical volume. If Size is followed by an M the value is treated as megabytes. If Size is followed by a G the value is treated as gigabytes. Otherwise the value is treated as 512-byte blocks.

Parameters
BackupOptions Any other options are passed to the backup command when the backup of the snapshot is performed. Minimally it is required to specify the type of backup desired. For backup by name the -i option must be specified along with the device for the backup. For backup by inode the level option, -[0-9], must be specified along with the device for the backup. Specifies the JFS2 file system to create a snapshot of and backup.

FileSystem

Exit Status
0 The command completed successfully. >0 An error occurred.

Examples
1. To create a snapshot for the /home/janet/sb file system and backup it up by name, enter:
backsnap -m /tmp/snapshot/janetsb -s size=16M -i -f/dev/rmt0 /home/janet/sb

This command creates a logical volume of size 16 megabytes and then creates a snapshot for the /home/janet/sb file system on the newly created logical volume. It then mounts the snapshot on /tmp/snapshot/janetsb and backups the files and directories in that file system by name to the /dev/rmt0

Make an Online Backup of a Mounted JFS or JFS2

Making an online backup of a mounted journaled file system (JFS) or enhanced journaled file system (JFS2) creates a static image of the logical volume that contains the file system. The following procedures describe how to make an online backup. Which procedure you choose depends on whether the file system is a JFS or JFS2.

Make an Online Backup of a JFS

To make an online backup of a mounted JFS, the logical volume that the file system resides on and the logical volume that its log resides on must be mirrored. Note: Because the file writes are asynchronous, the split off copy might not contain all data that was written immediately before the split. Any modifications that begin after the split begins might not be present in the backup copy. Therefore, it is recommended that file system activity be minimal while the split is taking place. To split off a mirrored copy of the /home/xyz file system to a new mount point named /jfsstaticcopy, type the following:
chfs -a splitcopy=/jfsstaticcopy /home/xyz

You can control which mirrored copy is used as the backup by using the copy attribute. The second mirrored copy is the default if a copy is not specified by the user. For example:
chfs -a splitcopy=/jfsstaticcopy -a copy=1 /home/xyz

At this point, a read-only copy of the file system is available in /jfsstaticcopy. Any changes made to the original file system after the copy is split off are not reflected in the backup copy. To reintegrate the JFS split image as a mirrored copy at the /testcopy mount point, use the following command:
rmfs /testcopy

The rmfs command removes the file system copy from its split-off state and allows it to be reintegrated as a mirrored copy.

Make and Back Up a Snapshot of a JFS2

Beginning with AIX 5.2, you can make a snapshot of a mounted JFS2 that establishes a consistent block-level image of the file system at a point in time. The snapshot image remains stable even as the file system that was used to create the snapshot, called the snappedFS, continues to change. The snapshot retains the same security permissions as the snappedFS had when the snapshot was made. In the following scenario, you create a snapshot and back up the snapshot to removable media without unmounting or quiescing the file system, all with one command: backsnap. You can also use the snapshot for other purposes, such as accessing the files or directories as they existed when the snapshot was taken. You can do the various snapshot procedures using Web-based System Manager, SMIT, or the backsnap and snapshot commands. To create a snapshot of the /home/abc/test file system and back it up (by name) to the tape device /dev/rmt0, use the following command:
backsnap -m /tmp/snapshot -s size=16M -i f/dev/rmt0 /home/abc/test

Notify Administrator when Physical Volume Is Missing

Although AIX logs an error when a physical volume becomes inaccessible, there are circumstances in which an error can go undetected. For example, when the physical volume is part of a mirrored volume group, users do not notice a problem because a good copy of the data remains accessible. In such cases, automatic notification can alert the administrator to the problem before the users notice any disruption to their work. The following procedure describes how to set up automatic notification when a physical volume is declared missing. By modifying the following procedure, you can track other errors that are significant to you. 1. With root authority, make a backup copy of the /etc/objrepos/errnotify ODM file. You can name the backup copy anything you choose. In the following example, the backup copy appends the errnotify file name with the current date:
2. cd /etc/objrepos cp errnotify errnotifycurrent_date

3. Use your favorite editor to create a file named /tmp/pvmiss.add that contains the following stanza:
4. errnotify: 5. en_pid = 0 6. en_name = "LVM_SA_PVMISS" 7. en_persistenceflg = 1 8. en_label = "LVM_SA_PVMISS" 9. en_crcid = 0 10. en_type = "UNKN" 11. en_alertflg = "" 12. en_resource = "LVDD" 13. en_rtype = "NONE" 14. en_rclass = "NONE" en_method = "/usr/lib/ras/pvmiss.notify $1 $2 $3 $4 $5 $6 $7 $8 $9"

After you complete all the steps in this article, the error notification daemon will automatically expand the $1 through $9 in this script with detailed information from the error log entry within the notification message. 15. Use your favorite editor to create a file named /usr/lib/ras/pvmiss.notify with the following contents:
16.#!/bin/ksh 17.exec 3>/dev/console 18.print -u3 "?" 19.print -u3 - "----------------------------------------------" 20.print -u3 "ALERT! ALERT! ALERT! ALERT! ALERT! ALERT!" 21.print -u3 "" 22.print -u3 "Desc: PHYSICAL VOLUME IS MISSING. SEE ERRPT." 23.print -u3 "" 24.print -u3 "Error label: $9" 25.print -u3 "Sequence number: $1" 26.print -u3 "Error ID: $2" 27.print -u3 "Error class: $3" 28.print -u3 "Error type: $4" 29.print -u3 "Resource name: $6" 30.print -u3 "Resource type: $7" 31.print -u3 "Resource class: $8" 32.print -u3 - "----------------------------------------------" 33.print -u3 "?" 34.mail - "PHSYICAL VOLUME DECLARED MISSING" root <<-EOF 35.---------------------------------------------36.ALERT! ALERT! ALERT! ALERT! ALERT! ALERT! 37.Desc: PHYSICAL VOLUME IS MISSING. SEE ERRPT.

Re-create a Corrupted Boot Image

The following procedure describes how to identify a corrupted boot image and re-create it. If your machine is currently running and you know the boot image has been corrupted or deleted, re-create the boot image by running the bosboot command with root authority. Attention: Never reboot the system when you suspect the boot image is corrupted. The following procedure assumes your system is not rebooting correctly because of a corrupted boot image. If possible, protect your system from a possible loss of data or functionality by scheduling your downtime when it least impacts your workload. 1. 2. 3. 4. 5. 6. 7. Insert the product media into the appropriate drive. Power on the machine following the instructions provided with your system. From the System Management Services menu, select Multiboot. From the next screen, select Install From. Select the device that holds the product media and then select Install. Select the AIX version icon. Follow the online instructions until you can select which mode you use for installation. At that point, select Start Maintenance Mode for System Recovery. 8. Select Access a Root Volume Group. 9. Follow the online instructions until you can select Access this Volume Group and start a shell. 10. Use the bosboot command to re-create the boot image. For example:
bosboot -a -d /dev/hdisk0

If the command fails and you receive the following message:

0301-165 bosboot: WARNING! bosboot failed - do not attempt to boot device.

Try to resolve the problem using one of the following options, and then run the bosboot command again until you have successfully created a boot image:
o

Delete the default boot logical volume (hd5) and then create a new hd5.

Or
o

Run diagnostics on the hard disk. Repair or replace, as necessary.

If the bosboot command continues to fail, contact your customer support representative. Attention: If the bosboot command fails while creating a boot image, do not reboot your machine. 11. When the bosboot command is successful, use the reboot command to reboot your system.

Reduce the Size of a File System in Your Root Volume Group

The simplest way to reduce all file systems to their minimum size is to set the SHRINK option to yes when restoring the base operating system from backup. The SHRINK option and the following scenario cannot be used in tandem. If you set the SHRINK option to yes after doing the following procedure, the installation overrides your changes to the /image.data file. This scenario leads you through a manual process to reduce the size of a selected rootvg file system. You will identify a file system that is not using all of its allocated disk space and then reallocate based on the amount of space the file system actually uses, thus freeing more space for the root volume group's use. As part of this procedure, you will back up your volume groups and reinstall the operating system, using the revised allocations. Attention: This procedure requires shutting down and reinstalling the base operating system. Whenever you reinstall any operating system, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality. Before reinstalling the operating system, ensure you have reliable backups of your data and any customized applications or volume groups. 1. Create a separate backup of all file systems that are not contained in the rootvg. The separate backup helps ensure the integrity of all your file systems. 2. With root authority, check which file systems in your root volume group are not using their allocated disk space by typing the following command:
df -k

The -k flag displays the file-system sizes in kilobytes. Your result will look similar to the following:
Filesystem /dev/hd4 /dev/hd2 /dev/hd9var /dev/hd3 /dev/hd1 /proc /dev/hd10opt 1024-blocks 196608 1769472 163840 65536 49152 32768 Free %Used 4976 98% 623988 65% 65116 61% 63024 4% 8536 83% 26340 20% Iused %Iused Mounted on 1944 2% / 36984 9% /usr 676 2% /var 115 1% /tmp 832 7% /home - /proc 293 4% /opt

Looking at these results, you notice a large number of free blocks and a fairly low percentage of use associated with the file system that is mounted on /usr. You decide you can release a significant number of blocks by reducing the number of partitions allocated to the /usr file system. 3. Check the contents of the /etc/filesystems file to ensure that all file systems in the rootvg are mounted. If not, they will not be included in the reinstalled system. 4. Create an /image.data file, which lists all the active file systems in the rootvg that are included in the installation procedure, by typing the following command:
mkszfile

5. Open the /image.data file in your favorite editor. 6. Search for the usr text string to locate the lv_data stanza that pertains to the /usr file system. Use numbers from this stanza as a base to determine how much you can reduce the /usr file system's number of logical partitions. The default size of each additional logical partition is defined in the PP_SIZE entry of the /image.data file. Your /image.data file would look similar to the following:
7. lv_data:

Replace a Failed Physical Volume in a Mirrored Volume Group

The following scenario replaces a failed or failing disk associated with a physical volume within a mirrored volume group. In the instructions, you use the Configuration Manager to configure the new disk (named hdisk10), and then use the replacepv command to replace a physical volume in a mirrored volume group that resides, at least in part, on a failed disk drive (named hdisk02) without losing the physical volume's contents. You do not need to reboot or schedule down time to complete the following procedure. 1. Select a new disk drive that has a capacity at least as large as the failed disk. 2. With root authority, run the Configuration Manager to configure the new disk. Type the following on the command line:
cfgmgr -l hdisk10

Use the -l flag to configure only the specified device and any "child" devices. Without this flag, the cfgmgr command runs Configuration Manager against the entire system. 3. Replace the physical volume so it can begin using the new disk, using the following command: Note: If the mirror for the logical volume is stale, the replacepv command does not work correctly.
replacepv hdisk02 hdisk10

4. When the associated mirrored volume group is the rootvg, you must also run the following commands to clear the failed disk from and add the new disk to the boot image:
5. chpv -c hdisk02 6. bootlist hdisk10 bosboot -a

The chpv -c command clears hdisk02 from the boot image. The bootlist command adds hdisk10 to the list of possible boot devices from which the system can be booted. The bosboot -a command creates a complete boot image on the default boot logical volume. At this point, the physical volume hdisk02 now maps to the newly configured hdisk10.

Reset an Unknown Root Password

The following procedure describes how to recover access to root privileges when the system's root password is unavailable or unknown. The following procedure requires some system downtime. If possible, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality. 1. Insert the product media for the same version and level as the current installation into the appropriate drive. 2. Power on the machine. 3. When the screen of icons appears, or when you hear a double beep, press the F1 key repeatedly until the System Management Services menu appears. 4. Select Multiboot. 5. Select Install From. 6. Select the device that holds the product media and then select Install. 7. Select the AIX version icon. 8. Define your current system as the system console by pressing the F1 key and then press Enter. 9. Select the number of your preferred language and press Enter. 10. Choose Start Maintenance Mode for System Recovery by typing 3 and press Enter. 11. Select Access a Root Volume Group. A message displays explaining that you will not be able to return to the Installation menus without rebooting if you change the root volume group at this point. 12. Type 0 and press Enter. 13. Type the number of the appropriate volume group from the list and press Enter. 14. Select Access this Volume Group and start a shell by typing 1 and press Enter. 15. At the # (number sign) prompt, type the passwd command at the command line prompt to reset the root password. For example:
16.# passwd 17.Changing password for "root" 18.root's New password: Enter the new password again:

19. To write everything from the buffer to the hard disk and reboot the system, type the following:
sync;sync;sync;reboot

When the login screen appears, the password you set in step 15 should now permit access to root privileges.

Restore Access to an Unlinked or Deleted System Library

When the existing libc.a library is not available, most operating system commands are not recognized. The most likely causes for this type of problem are the following:

The link in /usr/lib no longer exists. The file in /usr/ccs/lib has been deleted.

The following procedure describes how to restore access to the libc.a library. This procedure requires system downtime. If possible, schedule your downtime when it least impacts your workload to protect yourself from a possible loss of data or functionality.

Restore a Deleted Symbolic Link

Use the following procedure to restore a symbolic link from the /usr/lib/libc.a library to the /usr/ccs/lib/libc.a path: 1. With root authority, set the LIBPATH environment variable to point to the /usr/ccs/lib directory by typing the following commands:
2. # LIBPATH=/usr/ccs/lib:/usr/lib # export LIBPATH

At this point, you should be able to execute system commands. 3. To restore the links from the /usr/lib/libc.a library and the /lib directory to the /usr/lib directory, type the following commands:
4. ln -s /usr/ccs/lib/libc.a /usr/lib/libc.a ln -s /usr/lib /lib

At this point, commands should run as before. If you still do not have access to a shell, skip the rest of this procedure and continue with the next section, Restore a Deleted System Library File. 5. Type the following command to unset the LIBPATH environment variable.
unset LIBPATH

Restore a Deleted System Library File

The following procedure to restore a deleted system library file requires system downtime. The system is booted and then the library is restored from a recent mksysb tape. 1. Before your reboot, ensure the PROMPT field in the bosinst.data file is set to yes. 2. Insert a recent mksysb tape into the tape drive. The mksysb must contain the same OS and maintenance level as the installed system. If you restore a libc.a library from a mksysb that conflicts with the level on the installed system, you will not be able to issue commands. 3. Reboot the machine. 4. When the screen of icons appears, or when you hear a double beep, press the F1 key repeatedly until the System Management Services menu appears. 5. Select Multiboot. 6. Select Install From. 7. Select the tape device that holds the mksysb and then select Install. It can take several minutes before the next prompt appears.