Overview
Design Philosophy
• AIX is primarily a tool-managed Unix. While some Unices have a file-managed interface, AIX tends to use stanza files and ODM databases as data stores for configuration options. This makes many configuration options rather difficult or simply impossible with just a text editor. The AIX alternative is to leverage an expansive set of specialized tools for all configuration options. • AIX is well integrated with System P hardware. As typical with big-Unix implementations, AIX has a tight integration with the hardware it runs on. The result of this integration is an OS that not only provides extensive diagnosis and reporting of hardware issues, but also is designed to exploit numerous hardware features. IBM extends this integration even more by allowing AIX insight into the virtualization layer with abilities like virtual processor folding. • IBM tends to lead with hardware and follow with the OS. Major releases of the OS tend to coincide with new hardware features and leverage those advances in the hardware. While other Unices may take a software-centric approach to a solution, IBM tends to rely upon all layers of the system to an end. One good example of this is the maturity and depth of virtualization technologies that permeate the System P product line. • Commands in AIX generally follow a verb-noun syntax. The verbs tend to be ls (list), mk (make), rm (remove), and ch (change). The nouns vary by the target area such as dev, fs, vg, and ps. Even many of the odd-named variants follow a similar syntax such as crfs, reducevg, and installp. | • Both System P hardware and AIX are heavily geared towards virtualization. AIX is practically a para-virtualized environment in how well it is integrated with the System P virtualization technologies. At the user level, all performance and management commands have been modified to account for differences that occur in a virtualized environment. Despite and because of these changes, a virtualized environment is virtually indistinguishable from a non-virtualized environment to the user. • AIX has a stable interface. While the management tools and style of those tools has not changed within AIX for over a decade, the technologies supported by AIX has grown considerably. This is a significant feature of AIX in that it introduces new technologies within a consistent, approachable, and well designed interface. • The LVM integration with AIX is thorough and mature. From the install, management, and maintenance every aspect of LVM design dovetails into other components of the OS, firmware, and hardware to create an unparalleled environment. It is for this reason that AIX systems are more likely to be SAN booted and less likely to have 3rd party LVM products layered on top than other Unices. • A central focus of IBM design has been on RAS features. Particularly with Power 6 systems, IBM has designed extensive error detection and recovery into the products. AIX is just one enabling component to this end. All systems from CPU, memory, I/O busses, to system processes are considered and accounted for in this design. |
Acronyms & Definitions
CoD - Capacity on Demand. The ability to add compute capacity in the form of CPU or memory to a running system by simply activating it. The resources must be pre-staged in the system prior to use and are (typically) turned on with an activation key. There are several different pricing models for CoD. DLPAR - Dynamic Logical Partition. This was used originally as a further clarification on the concept of an LPAR as one that can have resources dynamically added or removed. The most popular usage is as a verb; ie: to DLPAR (add) resources to a partition. HEA - Host Ethernet Adapter. The physical port of the IVE interface on some of the Power 6 systems. A HEA port can be added to a port group and shared amongst LPARs or placed in promiscuous mode and used by a single LPAR. (See IVE) HMC - Hardware Management Console. An "appliance" server that is used to manage Power 4, 5, and 6 hardware. The primary purpose is to enable / control the virtualization technologies as well as provide call-home functionality, remote console access, and gather operational data. IVE - Integrated Virtual Ethernet. The capability to provide virtualized Ethernet services to LPARs without the need of VIOS. This functionality was introduced on several Power 6 systems. IVM - Integrated Virtualization Manager. This is a management interface that installs on top of the VIOS software that provides much of the HMC functionality. It can be used instead of a HMC for some systems. It is the only option for virtualization management on the blades as they cannot have HMC connectivity. LHEA - Logical Host Ethernet Adapter. The virtual interface of a IVE in a client LPAR. These communicate via a HEA to the outside / physical world. (See IVE) LPAR - Logical Partition. This is a collection of system resources (CPU, Memory, I/O adapters) that can host an operating system. To the operating system this collection of resources appears to be a complete physical system. Some or all of the resources on a LPAR may be shared with other LPARs in the physical system. LV - Logical Volume. A collection of one or more LPs (Logical Partitions) in a VG (Volume Group) that provide storage for filesystems, journal logs, paging space, etc... See the LVM section for additional information. LVCB - Logical Volume Control Block. A LVM structure, traditionally within the LV, that contains metadata for the LV. See the LVM section for additional information. MES - Miscellaneous Equipment Specification. This is a change order to a system, typically in the form of an upgrade. A RPO MES is for Record Purposes Only. Both specify to IBM changes that are made to a system. | MSPP - Multiple Shared Processor Pools. This is a capability introduced in Power 6 systems that allows for more than one SPP. NIM - Network Installation Management / Network Install Manager (IBM documentation refers to both expansions of the acronym.) NIM is a means to perform remote initial BOS installs, and manage software on groups of AIX systems. ODM - Object Data Manager. A database and supporting methods used for storing system configuration data in AIX. See the ODM section for additional information. PP - Physical Partition. An LVM concept where a disk is divided into evenly sized sections. These PP sections are the backing of LPs (Logical Partitions) that are used to build volumes in a volume group. See the LVM section for additional information. PV - Physical Volume. A PV is an LVM term for an entire disk. One or more PVs are used to construct a VG (Volume Group). See the LVM section for additional information. PVID - Physical Volume IDentifier. A unique ID that is used to track disk devices on a system. This ID is used in conjunction with the ODM database to define /dev directory entries. See the LVM section for additional information. SMIT - System Management Interface Tool. An extensible X Window / curses interface to administrative commands. See the SMIT section for additional information. SPOT - Shared Product Object Tree. This is an installed copy of the /usr file system. It is used in a NIM environment as a NFS mounted resource to enable remote booting and installation. SPP - Shared Processor Pool. This is an organizational grouping of CPU resources that allows caps and guaranteed allocations to be set for an entire group of LPARs. Power 5 systems have a single SPP, Power 6 systems can have multiple. VG - Volume Group. A collection of one or more PVs (Physical Volumes) that have been divided into PPs (Physical Partitions) that are used to construct LVs (Logical Volumes). See the LVM section for additional information. VGDA - Volume Group Descriptor Area. This is a region of each PV (Physical Volume) in a VG (Volume Group) that is reserved for metadata that is used to describe and manage all resources in the VG. See the LVM section for additional information. |
Disks, LVM, & Filesystems
Concepts
• LVM (Logical Volume Manager) is the ever-present disk and volume management framework for AIX. The level of integration is visible not only in fileystem commands that understand the underlying LVM, but in other, higher level, commands like the install and backup utilities that can optionally grow filesytems when necessary. • Physical disks (hdisks) are placed under LVM control by adding them to a VG (volume group). Within LVM, these disks are referred to as PVs (Physical Volumes). • Each PV in a VG contains a unique ID called a PVID. The PVID of a disk is used to track all disks in a VG, but also provides a device name independence that makes importing, exporting, and disk management much simpler. Because the unique characteristics of the disk become the identifier, the device name remains consistent but does not need to as (properly) renaming / reordering disks under LVM control is of little consequence. • Once a hdisk is placed into a VG it is divided into PP (Physical Partitions). PPs are then used to create LVs (Logical Volumes). An additional layer of abstraction is placed between an LV and a PP called a LP (Logical Partition) that allows for more than one PP to be used (i.e. mirrored) to back each portion of a LV.  A simplistic logical view of two PVs in a VG providing mirrored PPs for a LV. • Several on-disk structures are responsible for holding all LVM information. The VGDA resides on each disk and holds structural information such as the member PVs. The VGSA also resides on each disk and contains status information on all member devices. The LVCB varies by VG type but traditionally has resided in the first part of an LV (when it exists as a separate structure). In addition to the basic LVM commands that manage these structures, there are a number of lower level LVM commands that accesses this metadata more directly. • The first disk in a VG will have two copies of the VGDA, and a two disk VG will have one disk with a single VGDA and the other with two copies. For three disk and larger VGs, each disk has a single copy of the VGDA. • The concept of quorum is achieved when > 50% of the copies of the VGSA/VGDAs are online. If quorum is lost then the VG can be taken offline. • Quorum is problematic for two disk VGs because the loss of the two VGDA disk means a loss of the entire VG. In a mirrored configuration (a typical case for two-disk VGs) it is inappropriate to offline the VG for a single disk failure. For this reason, quorum rules can be turned off in the case of a two disk mirrored VG. | • The ODM is central to managing off-disk LVM structures and physical device to hdisk mappings. When a VG is created or imported this information is added to the ODM as well as other system files such as /etc/filesystems. • AIX LVM supports several versions of VGs that have been introduced over the lifetime of the product. The VG types are normal, big, and scalable. Normal VGs were the original creation and are more limited than the big or scalable types. The easiest way to tell the type of an existing VG is to look at the Max PV value for the VG (see example in the next section).
• The default filesystem on AIX is JFS2. JFS2, and it predecessor JFS, are both journaling filesystems that utilize the fundamental Unix filesystem structures such as i-nodes, directory structures, and block allocations. (Technically, JFS2 allocates blocks in groups called "extents".) • JFS2 is not an implementation of UFS and expands considerably over basic filesystem features with such capabilities as snapshots, dynamic i-node allocation, online growth, extended attributes, and encryption. AIX provides a layer of abstraction over all supported filesystems that map filesystem specific structures to standard Unix filesystem tools so that filesystems like JFS2 appear as an implementation of UFS. • While most journaled Unix filesystem implementations use inline logs (within the filesystem structure), AIX tends to use a special type of LV that is created only to contain log data. The jfs(2)log LV can provide logging capability for more than one filesystem LV. The log type must match the filesystem type. JFS2 can log to an inline log, but these implementations tend to be the exception to the rule. • The default filesystems that are installed with AIX:
|
Management
List all PVs in a system (along) with VG membership lspv List all LVs on PV hdisk6 lspv -l hdisk6 List all imported VGs lsvg List all VGs that are imported and on-line lsvg -o ››› The difference between lsvg and lsvg -o are the imported VGs that are offline. List all LVs on VG vg01 lsvg -l vg01 List all PVs in VG vg02 lsvg -p vg02 List filesystems in a fstab-like format lsfs Get extended info about the /home filesystem lsfs -q /home Create the datavg VG on hdisk1 with 64 MB PPs mkvg -y datavg -s 64 hdisk1 Create a 1 Gig LV on (previous) datavg mklv -t jfs2 -y datalv datavg 16 Create a log device on datavg VG using 1 PP mklv -t jfs2log -y datalog1 datavg 1 Format the log device created in previous example logform /dev/datalog1 Place a filesystem on the previously created datalv crfs -v jfs2 -d datalv -m /data01 -A y ››› A jfs2 log must exist in this VG and be logform(ed). (This was done in the previous steps.) -mspecifies the mount point for the fs, and -A y is a option to automatically mount (with mount -a). Create a scalable VG called vg01 with two disks mkvg -S -y vg01 hdisk1 hdisk2 Create a FS using the VG as a parameter crfs -v jfs2 -g simplevg -m /data04 \ -A y -a size=100M ››› The VG name here is "simplevg". A default LV naming convention of fslvXX will be used. The LV, and in this case log-LV, will be automatically created. Take the datavg VG offline varyoffvg datavg Vary-on the datavg VG varyonvg datavg ››› By default the import operation will vary-on the VG. An explicit vary-on will be required for concurrent volume groups that can be imported onto two (or more) systems at once, but only varied-on on one system at a time. Remove the datavg VG from the system exportvg datavg Import the VG on hdisk5 as datavg importvg -y datavg hdisk5 ››› The VG in this example spans multiple disks, but it is only necessary to specify a single member disk to the command. The LVM system will locate the other member disks from the metadata provided on the single disk provided. Import a VG on a disk by PVID as datavg importvg -y datavg 00cc34b205d347fc Grow the /var filesystem by 1 Gig chfs -a size=+1G /var ››› In each of the chfs grow filesystem examples, AIX will automatically grow the underlying LV to the appropriate size. Grow the /var filesystem to 1 Gig chfs -a size=1G /var List the maximum LPs for LV fslv00 lslv fslv00 | grep MAX Increase the maximum LPs for fslv00 LV chlv -x 2048 fslv00 Create a mirrored copy of fslv08 mklvcopy -k -s y fslv08 2 ››› syncvg -l fslv08 must be run if the -k (sync now) switch is not used for mklvcopy. Add hdisk3 and hdisk4 to the vg01 VG extendvg vg01 hdisk3 hdisk4 Mirror rootvg (on hdisk0) to hdisk1 extendvg rootvg hdisk1 mirrorvg -S rootvg hdisk1 bosboot -ad hdisk0 bosboot -ad hdisk1 bootlist -m normal hdisk0 hdisk1 ››› The -S option to mirrorvg mirrors the VG in the background. Running bosboot on hdisk0 is not required - just thorough. | Find the file usage on the /var filesystem du -smx /var List users & PIDs with open files in /data04 mount fuser -xuc /data04 List all mounted filesystems in a factor of Gigabytes df -g → (-m and -k are also available) Find what PV the LV called datalv01 is on lslv -l datalv01 ››› The "COPIES" column relates the mirror distribution of the PPs for each LP. (PPs should only be listed in the first part of the COPIES section. See the next example.) The "IN BAND" column tells how much of the used PPs in this PV are used for this LV. The "DISTRIBUTION" column reports the number of PPs in each region of the PV. (The distribution is largely irrelevant for most modern SAN applications.) Create a LV with 3 copies in a VG with a single PV mklv -c 3 -s n -t jfs2 -y badlv badvg 4 ››› Note: This is an anti-example to demonstrate how the COPIES column works. This LV violates strictness rules. The COPIES column from lslv -l badlv looks like: 004:004:004 Move a LV from hdisk4 to hdisk5 migratepv -l datalv01 hdisk4 hdisk5 Move all LVs on hdisk1 to hdisk2 migratepv hdisk1 hdisk2 ››› The migratepv command is an atomic command in that it does not return until complete. Mirroring / breaking LVs is an alternative to explicitly migrating them. See additional migratepv,mirrorvg, and mklvcopy examples in this section. Put a PVID on hdisk1 chdev -l hdisk1 -a pv=yes ››› PVIDs are automatically placed on a disk when added to a VG Remove a PVID from a disk chdev -l hdisk1 -a pv=clear ››› This will remove the PVID but not residual VGDA and other data on the disk. dd can be used to scrub remaining data from the disk. The AIX install CD/DVD also provides a "scrub" feature to (repeatedly) write patterns over data on disks. Move (migrate) VG vg02 from hdisk1 to hdisk2 extendvg vg02 hdisk2 migratepv hdisk1 hdisk2 reducevg vg02 hdisk1 ››› Mirroring and then unmirroring is another method to achieve this. See the next example Move (mirror) VG vg02 from hdisk1 to hdisk2 extendvg vg02 hdisk2 mirrorvg -c 2 vg02 unmirrorvg vg02 hdisk1 reducevg vg02 hdisk1 ››› In this example it is necessary to wait for the mirrors to synchronize before breaking the mirror. The mirrorvg command in this example will not complete until the mirror is established. The alternative is to mirror in the background, but then it is up to the administrator to insure that the mirror process is complete. Create a striped jfs2 partition on vg01 mklv -C 2 -S 16K -t jfs2 -y vg01_lv01 \ vg01 400 hdisk1 hdisk2 ››› This creates a stripe width of 2 with a (total) stripe size of 32K. This command will result in an upper bound of 2 (same as the stripe size) for the LV. If this LV is to be extended to another two disks later, then the upper bound must be changed to 4 or specified during creation. The VG in this example was a scalable VG. Determine VG type of VG myvg lsvg myvg | grep "MAX PVs" ››› MAX PVs is 32 for normal, 128 for big, and 1024 for scalable VGs. Set the system to boot to the CDROM on next boot bootlist -m normal cd0 hdisk0 hdisk1 ››› The system will boot to one of the mirror pairs (hdisk0 or hdisk1) if the boot from the CD ROM does not work. This can be returned to normal by repeating the command without cd0. List the boot device for the next boot bootlist -m normal -o |
NFS
• Many of the NFS commands accept the -I, -B, or -N switches. These three switches are used to control the persistence of the command. -B is now and future boots, -I is future boot (but not now), and -N is now (but not next boot). The -B option tends to be the default. The following table relates how these options modify the NFS commands:
• The NFS daemons are started out of /etc/inittab using the /etc/rc.nfs script. The mknfs andrmnfs commands toggle the inittab entries and control if the NFS system starts. • The "share" commands are provided for compatibility with other Unices. The share commands are links to the exportfs command. Enable NFS daemons now, and on next start mknfs Disable NFS daemons now, and on next start rmnfs See if NFS will start on boot lsitab rcnfs ››› This command simply lists the rcnfs entry in /etc/inittab. If one exists (and is not commented out) then the rc.nfs script will be run from inittab (and start NFS). Start NFS daemons now, but not at next boot mknfs -N ←or→ startsrc -g nfs List the status of the NFS services lssrc -g nfs | List all exported file systems showmount -e ←or→ exportfs Temporarily export the /varuna_nfs directory exportfs -i -o rw,root=vishnu:varuna \ /varuna_nfs ››› The root users on vishnu and varuna are given root access to this share. This export was used to create a system WPAR called varuna on a LPAR called vishnu that can be found in the WPAR section below. Export all entries in /etc/exports exportfs -av (Temporarily) unexport the /proj share exportfs -u /proj Permanently export the /proj share mknfsexp -d /proj -t rw ››› The -N, -I, and -B options are valid with this command. Here, the -B is implied. If the NFS services are not set to re-start on boot then this export will technically not be "permanent" as the share, even though this entry is permanent, will not be enabled after next boot. List clients of this host with share points showmount -a Add an entry to the /etc/filesystems file mknfsmnt -f /projects -d /proj \ -h mumbai -A -E ››› Note that the -A and -E switches cannot be stacked (-AE). -A specifies to mount on boot and -E specifies the intr mount option. |
Other
• The procfs is the single (default) pseudo fs. Interestingly, /proc is not used by commands like ps ortopas but is used by commands like truss. Additional information on /proc can be found in the header file <sys/procfs.h> and the /proc InfoCenter page. • A list of supported filesystems can be found in the /etc/vfs file. • The cdromd daemon is used to automount CD / DVD media. It is not enabled by default. cdromduses the /etc/cdromd.conf file to configure default options for the cdX device such as the default mount directory. • Paging spaces are specified in the /etc/swapspaces file. The chps, mkps, rmps, and lsps commands are used to modify / view this file. Find your CD/DVD ROM lsdev -Cc cdrom List all paging spaces lsps -a Grow the hd6 paging space by 4 LPs chps -s 4 hd6 ››› The current LP count and LP/PP size can be found using lslv hd6. | Mount DVD media in the DVD drive mount -v udfs -o ro /dev/cd0 /mnt Mount CD media in the CD/DVD drive mount -rv cdrfs /dev/cd0 /mnt ››› Both the cdrfs and udfs are different types as defined in /etc/vfs, but both seem to work for AIX DVD media. |
Networking
Concepts
• Ethernet devices are entX devices while enX and etX devices represent different frame types that run on the underlying entX device. Typically the enX device is what is plumbed on most networks and etX is not used. • Attributes of the entX device are physical layer connection settings such as speed and duplex as well as driver settings such as transmit and receive queue sizes. Attributes of the enX device are configurable items such as IP address, subnet mask, and some TCP/IP tunables. • Like the enX device, the inet0 device is not a physical device. It is a representation / management interface for the Internet (networking) subsystem. The hostname, routing info and TCP/IP configuration method are attributes of this device. • Networking is typically started from /etc/rc.net using the settings stored in the ODM (and notfrom rc.tcpip). When started in this manner several helper commands are responsible for pulling the config from the ODM and configuring devices. Alternatively, /etc/rc.net can be configured to use ifconfig commands or /etc/rc.net can be bypassed completely and /etc/rc.bsdnet can be used instead. The setting that determines which method (rc.net or rc.bsdnet) is used is stored as an attribute to the inet0 device. (The point here is not necessarily to recommend the use the alternative methods but to point to where the options are set and where additional details on the process can be found.) • AIX supports trunking (EtherChannel / 802.3ad), tagged VLANs (802.1q), Virtual IP addresses (VIPA), dead gateway detection (multiple default gateways), IP multippath routing, and network adapter backup. The network adapter backup does not require EtherChannel but is part of the smitty EtherChannel setup section. | • The /etc/resolv.conf uses a traditional format, but can be managed via the namerslv and *namsvcommands. The /etc/netsvc.conf file is the AIX version of the nsswitch.conf file in that it determines the service lookup order for name services. • Hostname lookup order is determined using /etc/irs.conf, then /etc/netsvc.conf and finally$NSORDER. (The order of precedence is reverse - meaning, for example, a value set in $NSORDER will be used over the other two methods.) The irs.conf and $NSORDER methods are typically not used. • Network related tunables can be set globally, per-interface, or per-socket connection. Most global tunables are managed with the no command. Interface specific tunables are set on the entX or theenX devices using the chdev command. AIX now recognizes a ISNO (Interface Specific Network Option) flag that overrides many of the global settings and uses the settings for each interface over those set globally. This is an important concept as much application documentation still refers to the global settings while the default is now to use the local settings. ISNO can be determined from querying with the no command or looking at ifconfig results. Examples of retrieving the defaults, ranges, and current values as well as setting new values are shown in the next section. • Settings for the HEA (Host Ethernet Adapter) are not always set from the OS. Physical layer settings for this device are typically set from the ASMI menus or from the HMC. • Changes were made to the AIX 6.1 network tunables. The no command will list many tunables as "restricted". IBM recommends against changing a restricted tunable from the default. |
Management
• The assumption of this section is that rc.net / ODM is used for IP configuration. If the configuration is not stored in the ODM and is configured via script then many of these "temporary" commands could be used to persistently configure the IP settings. • The following examples also assume the use of en0 over et0. List all Adapters in the system lsdev -Cc adapter List all interfaces in the system lsdev -Cc if Initial setup of an interface mktcpip ››› Note that mktcpip has an exceptional amount of options. They are not listed here because this command is a prime example of when to use SMIT. See next item for more typical use. Smitty interface to initial TCP/IP setup smitty mktcpip ››› This command is usually run once for a system (typically in the post-install setup if run from CD/DVD), additional changes can be done directly via the chdev command or via the smitty configtcp menu screen. Permanently set the hostname chdev -l inet0 -a hostname=bombay Temporarily add a default route route add default 192.168.1.1 Temporarily add an address to an interface ifconfig en0 192.168.1.2 \ netmask 255.255.255.0 Temporarily add an alias to an interface ifconfig en0 192.168.1.3 \ netmask 255.255.255.0 alias To permanently add an IP address to en1 chdev -l en1 -a netaddr=192.168.1.1 \ -a netmask=0xffffff00 Permanently add an alias to an interface chdev -l en0 -a \ alias4=192.168.1.3,255.255.255.0 Remove a permanently added alias from an interface chdev -l en0 -a \ delalias4=192.168.1.3,255.255.255.0 Remove all TCP/IP configuration from a host rmtcpip View the settings on inet0 lsattr -El inet0 ››› This can be run for ent0 and en0 as well. These settings are typically stored in the ODM object repository CuAt and are retrievable via odmget -q name=inet0 CuAt. Determine if rc.bsdnet is used over rc.net lsattr -El inet0 -a bootup_option Find actual (negotiated) speed, duplex, and link entstat -d ent0 ››› The interface must be up (ifconfig en0 up) for stats to be valid. The netstat -v ent0command gives similar results. Set (desired) speed is found through the entX device lsattr -El ent0 -a media_speed Set the ent0 link to Gig full duplex chdev -l ent0 -a \ media_speed=1000_Full_Duplex -P ››› Auto_Negotiation is another option (see the next example). View all configurable options for speed and duplex lsattr -Rl ent0 -a media_speed Find the MTU of an interface netstat -I en0 | To view the (current) route table netstat -r To view the (persistent) route table from the ODM lsattr -EHl inet0 -a route Add an entry for "rhodes" to the hosts file hostent -a 192.168.1.101 \ -h "rhodes.favorite.com rhodes" ››› The hostent is a command for editing the /etc/hosts file. Most edits on this file are done by hand. The hostent command is mentioned here first for its potential use as a scripting tool, but also as an example of the pervasive tool-managed nature of AIX. List all services represented by inetd lssrc -ls inetd List all open, and in use TCP and UDP ports netstat -anf inet List all LISTENing TCP ports netstat -na | grep LISTEN Flush the netcd DNS cache netcdctrl -t dns -e hosts -f Get (long) statistics for the ent0 device entstat -d ent0 ←or→ netstat -v ent0 ››› Remove the -d option from entstat for shorter results. The output of entstat varies by device type. Virtual, physical, and IVE (LHEA) devices all produce different results. Use caution and test throughly when scripting this command. List all network tunables no -a List all tunable settings in long format no -L ››› The "long" format is more readable as well as displaying current, default, persistent, min and max values. Get a description of the use_isno tunable no -h use_isno ››› These descriptions were expanded in AIX 6.1. Additionally many will be listed as restricted where they were not in previous versions. Turn off Interface Specific Network Options no -p -o use_isno=0 • The following tcpdump examples are simplistic and limited, an extended usage description fortcpdump is beyond the scope of this document. The intent is to give a few easy examples that can be expanded to the users needs. Additional help with filter expressions and command line options is available on the tcpdump InfoCenter page. Also note that while efforts have been made to account for line wraps in the printed version, these commands remain un-wrapped for readability. Watch all telnet packets from aachen tcpdump -Nq 'host aachen and (port telnet)' ››› -N gives short host names. Watch connect requests tcpdump -q 'tcp[tcpflags] & tcp-syn != 0' ››› -q gives abbreviated packet info. Watch all connection requests to port 23 tcpdump -q 'tcp[tcpflags] & tcp-syn != 0 and port telnet' |
System Configuration & Management
Devices
• Physical device to /dev device representations are mapped via ODM database entries. Actual locations of devices can be retrieved using the lscfg or lsdev commands. The mapping provided by the ODM provides a persistent binding for device names across boots of the system. • The mapping of physical devices to the logical devices in /dev is an automated process performed by the operating system. It is typically not required to move or otherwise re-order these devices. In a highly dynamic environment where devices are added and removed, it may be advantageous to clear previous instances of a device from the ODM and /dev directory. • New devices are added to the system with the cfgmgr command. Logical instances of of devices can be removed from the system via the rmdev command. rmdev simply tells the system to forgetthe device, so unless the physical device is actually removed it will simply be found and re-created when the cfgmgr command is run again (e.g. at next boot). • Device support requires that the appropriate packages (drivers) are installed for each device. The default AIX install includes support for devices not on the system. If a device is newer or a minimal OS install was done then support may not be included for new devices. In this case the cfgmgrcommand will flag an error that an unsupported device has been found. • Device configuration options are stored in the pre-defined device databases of the ODM. Information about actual devices are stored in the configured device databases of the ODM. These configured options include instances and well as configuration options to the devices / drivers. • The lsdev command is used to list devices in the predefined and configured device (ODM) databases. The lscfg command is used to display VPD (Vital Product Data) information about each device. To find all devices the system knows or has configured at one time use the lsdevcommand. To search for a device by a specific type, class, parent device or other complex criteria use the lsdev command. To find the serial number or device specific identifier of a device use thelscfg command. List all devices on a system lsdev ››› lsdev queries the predefined or configured databases using the -P and -C flags respectively. In this case the -C flag is implied. Addition of the -H option includes column header info. List all disk devices on a system lsdev -Cc disk ››› See next example for a list of potential classes as arguments to the -c option. List all customized device classes lsdev -Cr class ››› Customized device classes mean that they exist (or have existed) on the system. For a list of predefined devices (ones that AIX could support) change the -C option for -P. List locations of all hdisks in the system lscfg -l 'hdisk*' ››› This can be accomplished via the lsdev command. The point here is to show the use of wildcards in a lscfg option. Remove hdisk5 rmdev -dl hdisk5 ››› The -d option removes the configured device entry from the ODM. Unless the device isphysically removed, cfgmgr will bring it back. | Get device address of hdisk1 getconf DISK_DEVNAME hdisk1 ←or→ bootinfo -o hdisk1 ››› This is the same information available from other commands, just not requiring greping orawking to retrieve this specific data. bootinfo is not officially supported as an administrative command. Get the size (in MB) of hdisk1 getconf DISK_SIZE /dev/hdisk1 ←or→ bootinfo -s hdisk1 ››› Note that a full path to the device is required for the getconf version. Find the possible parent devices of hdisk0 lsparent -Cl hdisk0 ››› This lists all devices that support that device type, not the specific parent of this device. See the following lsdev examples for methods of finding parent devices. List all child devices of scsi1 lsdev -Cp scsi1 List all disks belonging to scsi1 lsdev -Cc disk -p scsi1 Test if hdisk2 is a child device of scsi2 lsdev -Cp scsi2 -l hdisk2 ››› This command will list all devices that meet the criteria of being hdisk2 and belonging toscsi2. Either it will list a device or it will not. Find the location of an Ethernet adapter lscfg -l ent1 Find device specific info of an Ethernet adapter lscfg -vl ent1 ››› One key piece of device specific info would be the MAC address. This command works for HBAs and other addressed adapters. The *stat commands also tend to return addresses, often formatted in a more readable manner. See the next example for an HBA / with the grepcommand to isolate the address. Find the WWN of the fcs0 HBA adapter lscfg -vl fcs0 | grep Network Get statistics and extended information on HBA fcs0 fcstat fcs0 ››› Similar *stat commands exist for numerous types of devices such as entstat, ibstat, tokstat,fddistat, etc.. List all MPIO paths for hdisk0 lspath -l hdisk0 Temporarily change console output to /cons.out swcons /cons.out ››› Use swcons to change back. Find the slot of a PCI Ethernet adapter lsslot -c pci -l ent0 ››› The lsslot command is used to find cards that are hot-swappable. Not all systems will support this command. |
SMIT (System Management Interface Tool)
• SMIT is a system management tool that assists the administrator with AIX utilities by providing an ASCII (curses) / X-Window GUI interface to those tools. SMIT provides pick lists and menus for command line options to AIX tools. The interface is designed to aid with recognition of more obscure switches, provide additional security & accounting, and perform some validation on the input to those commands. • The SMIT interface is not a monolithic binary, but an extensible framework of screens that relies upon underlying OS commands to do the work. Each SMIT screen is stored as a collection of ODM objects in SMIT specific object classes. • Stepping through the complex menu system can be avoided by jumping directly to a screen when a fastpath is specified when SMIT is invoked. Fast paths are single word (no spaces) phrases that typically are the command that will be run in that screen. The fast path for the current screen can be determined by using the F8 key while in that screen. • Sample fastpaths:
• SMIT will save a script of runnable commands in ~/smit.script and ~/smit.transaction as well as a log of commands run in ~/smit.log. When invoked with the -x switch, SMIT will not run any of the commands but will write the commands it would run to ~/smit.script and~/smit.transaction. (Note: With the -x switch SMIT will still run the discovery commands to build lists and find default/existing values but not the action commands.) | • SMIT can be invoked from the command line using smit or smitty. smit will start either the curses based version or the X Window version depending upon the presence of the X Window system.smitty will always start the curses (tty) version. • Additional information on customizing the SMIT interface can be found on the "Extending SMIT For Common Localized Tasks" page. • Key sequences (for the curses version)
• Symbols that denote field data requirements:
|
SRC
• The SRC (System Resource Controller) is a process manager that is used to spawn, monitor, and control services. Many of the standard Unix daemons are managed via this interface on AIX. • SRC does not have a persistent "service profile" and therefore does not comprehend persistence beyond the current boot. For this reason, it is necessary to find where the service is started and add or remove the startsrc (service start) command there. The most popular locations for this arerc.tcp and inittab. • SRC controlled processes must be started and stopped via the SRC interface. If a SRC process dies or is killed the srcmstr daemon will re-spawn that process and log an error to the system error log. • The core process for SRC (srcmstr) is spawned from /etc/initttab. Services that run under SRC control do not leave their process group (ie: have a PPID of 1), but instead, stay children ofsrcmstr. List the status of the cdromd service lssrc -s cdromd List the status of inetd subservices lssrc -l -s inetd List the status of all members of the NFS group lssrc -g nfs | Start the cdromd service startsrc -s cdromd ››› There is not a persistent flag for the startsrc command. For this service to automatically start on the next boot, a change must be made to one of the system initialization files. In this case, an entry must be made in /etc/initttab. Stop the cdromd service stopsrc -s cdromd Send a refresh request to the syslogd service refresh -s syslogd ››› This would typically be communicated via a HUP signal. Not all SRC controlled processes respond to a refresh request and may require a HUP signal. |
Performance / Kernel / Tuning
• The primary statistics provider for most basic performance commands on AIX is the Perfstat API / kernel extension (See /usr/include/libperfstat.h.) This API supports most non-trace based performance related tools. • The trace-based tools (denoted by a "T" in the list below) utilize the trace facility. These tools generate significantly more detail than the perfstat based tools. Unfortunately the level of detail provided by these tools comes at the expense of performance. Caution should be used when running these tools on a production system. • AIX 6.1 introduced probevue, a lightweight dynamic trace facility that provides trace-like insight but with a minimal performance impact. The probevue command utilizes scripts written in the Vue language to define what events to capture data on and how to report that data. Additional information can be found on the ProbeVue page. • With the introduction of Micro-partitions many commands were modified both to account for performance statistic gathering in the virtualized environment as well as reporting virtual statistics. When WPARs were introduced many commands were extended to report per-WPAR or WPAR specific statistics. The WPAR specific options are typically enabled with the -@ switch. Commands in the following list that support this option are marked with the "@" symbol. • The *o commands (vmo, schedo, no, nfso, raso, ioo, and lvmo) are used to view and set system related tunables. Persistent tunables are saved in /etc/tunables/nextboot. Some persistent tunables are inserted in and set from the BLV (therefore they require that bosboot run to set the value for next boot. • The following is a list of general and lower-level system commands for performance and diagnostics:
|
• Note: The examples section is not meant to be comprehensive or even well representative of the available options and performance monitoring methods. The scope and design of this page does not allow for a full treatment of the performance tools. Each section requires a careful selection of the command examples and information that is of use. This section requires significantly more abbreviation to fit in a reasonable space. The goal has been to give a mix of some common examples along with some that are slightly atypical. • Most iterative commands here use two second intervals. This is done only to make them consistentwhen showing the iterative options. List processes in ptree-like output ps -T1 List all file opens for the ls process truss -topen ls List all file opens for a running PID truss -topen -p 274676 ››› 274676 is simply a PID that was active on the system when I created the example. List all open files for a running PID procfiles -n 274676 List all memory segments for a running PID svmon -P 274676 Get a filename for an inode from previous results ncheck -i 1041 /dev/hd4 ››› Once again, this example is of a local (to this system) inode value. In this case svmon returned the inode and filesystem of the file - the actual filename was desired. Enable advanced statistics gathering on VG datavg lvmstat -v datavg -e ››› Use -e to enable, -d to disable. Monitor network throughput for ent0 while [ 1 ] ; do entstat -r ent0 | grep Bytes ; sleep 2 ; done ››› First column is transmit and second is receive. This is a non-curses based example, see the next example for a topas based solution. Monitor network throughput for all interfaces topas -E Paging - in use svmon -i 2 ››› The -i 2 parameter tells to iterate every two seconds. Paging - activity vmstat 2 Show top-like CPU usage by process topas -P Show system wide CPU usage mpstat 2 Get NFS server statistics while [ 1 ] ; do nfsstat -s ; sleep 2 ; done Generate CPU load dd if=/dev/random of=/dev/null List I/O stats organized by adapter iostat -a 2 Get extended I/O stats on just two disks iostat -D hdisk0 hdisk1 2 List I/O stats by file system iostat -F 2 ››› Not supported on 5.3 Show network statistics for interfaces netstat 2 |
ODM
• The ODM (Object Data Manager) is a database store for system information on AIX. The ODM is primarily used for system items such as device instances and the configuration options for those devices but may also be used for applications such as SMIT. • The ODM is a collection of object classes (files) that are primarily in /etc/objrepos but also stored in /usr/lib/objrepos, /usr/share/lib/objrepos and the BLV. The copy and/or location of the ODM to use is specified either by an application or the ODMDIR / ODMPATH environmental variables. For example, the SMIT screens are stored in object classes in /usr/lib/objrepos but can be stored in an alternate ODM source. ››› See the "Extending SMIT For Common Localized Tasks" page for info on using an alternate ODM source for SMIT. • While applications can create object classes anywhere they wish, the system object classes primarily exist in the three directories listed in the previous point. This is done to separate data based upon the type of filesystem it is in. Data that is specific to a system is stored in/etc/objrepos. Platform specific data that can be shared across systems (such as a network boot) is stored in /usr/lib/objrepos. Platform independent data that can be share across systems is stored in /usr/share/lib/objrepos. One example of this is the lpp object class that exists in all three locations. The lslpp -l will query each of these object classes and display each in its own group. • The primary benefits of the ODM is that it stores complex data, enforces data types on that data, and provides a rich API / set of command line utilities to access it. The API supports locking that insures a view consistency that is not guaranteed with flat files. • When mapping ODM to database concepts, an ODM object class is the equivalent of a database table, and is implemented as one or more files. An ODM object would be a row in that table. An object descriptor would be the equivalent of a database column definition. • The ODM supports relations in the form of the "link" data type. It does not allow for joins of the data, nor does it enforce referential integrity during inserts. The ODM does not enforce a primary key, specifically the unique constraint of a key. For this reason, it is possible to have duplicate objects in a object class. • ODM command line tools:
| • Object classes are implemented as one or two files depending upon the data types used in the definition of the object class. The primary file has the same name as the object class. An optional file ending in .vc is used for variable length and multi-byte nchar data. The ODM data files are notrecognized by the file command so I have included a sample MAGIC for both file types. 0 long 0x000dcfac ODM data file MAGIC entries for ODM files0 long 0x000caa1c ODM variable data file • Many introductions to the ODM use typical database examples to show how data is stored and retrieved. While this is useful for understanding the structure of an object class it is counter-productive in that it masks what is really stored in the ODM. Another method of learning the ODM is to use the truss-query method. This means that you wrap a command in truss (truss -topen) to capture the file opens, then query the resulting object classes for the data they contain. • The ODM command line tools work on two different formats of input/output from the object classes. The structure of the object classes are defined in a syntax that is very similar to a C struct. Actual object data is structured in a stanza format. class my_object_class { Example of odmcreate/odmshow struct. (Nonsensical table with two short int(eger)s and a string.)short descriptor1; short descriptor2; vchar text[1024]; }; CuAt: Example of odmadd/odmget stanza syntax. (Actual output from a system.)name = "inet0" attribute = "hostname" value = "mumbai" type = "R" generic = "DU" rep = "s" nls_index = 24 Steps to shrink an ODM object class called "Bloat" odmshow Bloat > Bloat.definition odmget Bloat > Bloat.data odmcreate Bloat.definition odmadd Bloat.data ››› odmshow saves the table definition. odmget saves the table data. odmcreate re-creates the table. odmadd restores the data. This is not a popular task on AIX. The example here is more to relate the purposes of the commands and give some insight into how they can be used. Determine the ODM files opened by lsattr truss -topen lsattr -El inet0 Query CuAt for the inet0 config odmget -o CuAt -q name=inet0 • The SMIT customization page has more ODM command examples. |
Software Management
• A fileset is the smallest manageable component in the LPP (Licensed Program Product) hierarchy. A package is a collection of related filesets. An LPP is a group of packages that tend to fall within one product type, such as "bos" - the base operating system. • Filesets are divided by what part of the system they install to. This is either "root", "usr", or "share". These divisions are determined by install location as well as platform dependence / independence. Use the lslpp -O flag with r, u, or s options to list filesets from only one location. (Additional discussion of this is found in the ODM section and the three separate lpp ODM data stores - one for each fileset install location.) • Most administrators perform installs via the SMIT or NIM methods. SMIT is most popular for simple one-off installs and smaller environments. Use of installp directly from the command line is significantly more complex than SMIT or NIM. • The most popular SMIT fast paths are install_latest and update_all. The install fast path requires that a package repository be specified on the first screen then presents the user with a screen of install options to include the option to browse and select from the supplied repository. • Bundles are simply formatted lists of packages to be installed as a unit. Bundle files are stored locally in /usr/sys/inst.data/sys_bundles and /usr/sys/inst.data/user_bundles. Bundles can be installed using the smitty easy_install command. • Filesets can be installed in the applied or committed states. Applied filesets retain previous versions and can be rolled back to the previous version (rejected). The first version of a fileset installed on a system is always committed. • SUMA (Service Update Management Assistant) is a method to automate the retrieval of system updates from the Internet. List all installed filesets separated by filesystem type lslpp -l List all installed filesets with combined filesystem info lslpp -L ››› Adding the -c option will make this output scriptable in that it will be colon delimited. See the next example. List just the filesets on a system lslpp -Lc | cut -d : -f 2 List all files in the bos.mp64 fileset lslpp -f bos.mp64 List all files in the root part of bos.rte.shell lslpp -Or -f bos.rte.shell List what known fileset provides ksh which_fileset ksh List the installed fileset that provides /usr/bin/ksh lslpp -w /usr/bin/ksh ››› *ksh* would have worked, but more results. | List all software packages on /dev/cd0 installp -l -d /dev/cd0 ››› It is not necessary to explicitly mount /dev/cd0. The installp command will do it automatically. None of the examples using /dev/cd0 (including SMIT) in this section require the explicit mounting of the CD/DVD ROM. List the software in the default repository location installp -ld /usr/sys/inst.images List all RPM packages on the system rpm -qa List all files in the installed gcc RPM rpm -ql gcc-4.2.0-3 List all filesets that are applied, and can be committed or rejected installp -s List packages on media in /dev/cd0 gencopy -Ld /dev/cd0 Copy contents of CD to local directory gencopy -d /dev/cd0 -t /proj/instsrc \ -UX all Copy contents of CD to default local directory gencopy -d /dev/cd0 -UX all Download AIX 5.3 TL10 updates to local repository suma -x -a Action=Download \ -a RqType=TL -a RqName=5300-10 ››› The updates will be placed in the default local repository in /usr/sys/inst.images. Install the mkinstallp tool installp -acgXYd /usr/sys/inst.images \ bos.adt.insttools ››› The options are: -a Apply -c Commit -g Install prerequsites -X Extend filesystems if necessary -Y Agree to licenses -d <dir> Specify a source bos.adt.insttools pagkage to install Backup the rootvg mksysb -eivX /mnt/bombay.mksysb ››› The options are: -e Exclude files listed in /etc/exclude.rootvg -i Create an /image.data file -v List files as they are backed up -X Extend /tmp if necessary /mnt/bombay.mksysb The file to create As this command will back up all mounted filesystems in rootvg it is necessary to account for the potential size of this file. The root user has a file size limit (fsize) and can be temporarily disabled with ulimit -f unlimited |
Users / Groups
• AIX users and groups have an administrative attribute that determines who can make changes to that user or group. Only the root user (or equivalent RBAC role) can modify a user or group that has the admin attribute set. Regular, non-admin accounts, may be modified by members of the security group. Non-admin groups can have group administrators (that are not part of the security group) that can modify the group members. • The following is a table that represents how the admin attribute of a user/group effects who can modify that item:
• RBAC (Role Based ACcounting) is a natural maturation from using simple SUID/SGID binaries to a more granular method of granting privileges to users to accomplish tasks. Legacy RBAC was introduced in AIX 4.2.1, and was upgraded to Enhanced RBAC in AIX 6.1. This document refers to the Enhanced version of RBAC and only mentions Legacy RBAC in contrast where appropriate. • Legacy RBAC was a simplified method to divide root tasks into groups and give non-root users ability to perform those tasks. This was done with traditional SUID/SGID applications that thenchecked to see if the user was assigned the privilege before the task was attempted. As a result, it required specialized binaries that were potentially open to exploit because the processes they spawned still had effective root access. The benefit was the more granular division of responsibilities that RBAC promises. Unfortunately, Legacy RBAC was not sufficient to change many administrator's minds on the use of root for all tasks administrative. • Enhanced RBAC does not rely upon SUID/SGID applications but instead allows for granular permissions based upon the users role membership and only the permissions required to complete the task. The kernel only allows authorizations to non-root users for very specific actions instead of relying on the application code to grant that access. • A user is assigned a role that aligns with an administrative task such as the ability to restart (or shutdown) the system. The role is a grouping method that defines all authorizations that are required to accomplish that type of task. Commands, files, and devices are added to priv* files that define what authorizations are required to perform that specific task or access that file / device. When a command is run, the required authorizations are checked against the authorizations assigned to roles for the user running the command. If the user lacks sufficient access then permission is denied. • The following table lists the key configuration files in the Enhanced RBAC system, the commands used to access/modify those files and what the files are for.
• The user environmental variables are stored in /etc/environment and /etc/security/environ. The variables set in /etc/environment are given to all users and processes while the settings in/etc/security/environ are per-user. • User limits are set for login processes from the /etc/security/limits file. The chuser command can be used to modify this file. • The default options for the mkuser command are stored in /usr/lib/security/mkuser.default. • The /etc/security/passwd file is the shadow password file. • The last command returns login information for the system (from the /var/adm/wtmp file. The/etc/security/lastlog file contains per-user information on each users login attempts. |  Relationship between RBAC files. Create an admin group called wfavorit with GID 501 mkgroup -a id=501 wfavorit List the attributes of the just-created group wfavorit lsgroup wfavorit Create an admin user called wfavorit with UID 501 mkuser -a id=501 shell=/usr/bin/ksh \ home=/home/wfavorit pgrp=wfavorit \ wfavorit Set the password for user wfavorit (run as privileged user) pwdadm wfavorit ←or→ passwd wfavorit Add wfavorit as member of the security group chgrpmem -m + wfavorit security Make a group with wfavorit as the admin mkgroup adms=wfavorit favorite Make wfavorit an administrator of the proj group chgrpmem -a + wfavorit proj List all users on the system lsuser -a ALL ››› The -a switch lists specific attributes, but in this case it is empty and only the user names are displayed. See other lsuser examples in this section for other uses of the -a switch. List all admin users on the system lsuser -a admin ALL | grep =true List attributes for user wfavorit in a stanza format lsuser -f wfavorit List login history for user wfavorit last wfavorit List the fsize ulimit for user wfavorit lsuser -a fsize wfavorit Change the file size ulimit to unlimited for wfavorit chuser fsize=-1 wfavorit List all groups and their IDs lsgroup -a id ALL List all members of the favorite group chgrpmem favorite ◊ User / Group admin command reference: mkuser, chuser, rmuser, lsuser, pwdadm, mkgroup,chgroup, rmgroup, lsgroup, chgrpmem, usrck, grpck, pwdck |
Other
Boot Process
• The normal numbers represent what you see as the step begins. The red numbers are error codes when that command / step fails. This is not a complete list of error codes. A more complete set can be found in Diagnostic Information for Multiple Bus Systems.
|
• The previous boot process listing is for a normal disk boot. This will vary for network, tape, and CD boots. Read the contents of /sbin/rc.boot for specifics on each boot device method and type (normal or service). • The boot order is stored in NVRAM. The settings are set and retrieved using the bootlistcommand. • The BLV (Boot Logical Volume) is /dev/hd5. It is created / updated with the bosboot command. • bosboot updates the boot record at the start of the disk, copies the SOFTROS from/usr/lib/boot/aixmon.chrp, copies the bootexpand utility, copies the kernel from /unix, creates a copy of the RAM FS from the list of files in /usr/lib/boot/chrp.disk.proto, and creates a base ODM.  Layout of a bootable disk with hd5 shown. • The kernel loaded from hd5 (the BLV) is the kernel the system will run under for the entirety of the boot (until the system is shutdown or restarted). For this reason it is important to re-run bosbootevery time that the kernel is updated or some boot-time kernel options are set. • This is an abbreviated list of boot codes. cfgmgr (alone) produces numerous display messages and potential error codes, far more than is practical to display here. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Error Logging
• AIX has three error logging and reporting methods; alog, errlog, and syslog. The alog is an extensible collection of logs, but primarily is used for boot and console logging. errlog is used primarily for system and hardware messages. syslog is the traditional logging method. • HMC managed systems will also have a log of serviceable events relating to all systems on that HMC. • Both errpt and alog keep binary circular logs. For this reason, neither requires the rotation process that is used for syslog logs. • A curses based error log browser can be found locally on the errbr page. • The AIX syslog.conf uses *.debug for all, not *.* • The following alog examples use the boot log as an example. These examples are transferable to any of the other existing logs as well as those created in addition to the AIX supplied logs. List all logs alog knows about alog -L Dump the contents of the boot log to stdout alog -o -t boot Send the current date to the boot log date | alog -t boot Increase the size of the boot log to twice the default. alog -C -t boot -s 8192 ››› Note: This changes the definition in the ODM, the size will be applied the next time that the log is re-created. Clear the boot log rm /var/adm/ras/bootlog echo "boot log cleared on `date`" \ | alog -t boot Find the current alog file size setting for the boot log odmget -q attribute="boot_logsize" \ SWservAt | Write a message to the errlog errlogger "This is not Solaris!" Display the entire contents of the errlog errpt ››› Add -a or -A for varying levels of verbosity. Clear all entries from the errlog errclear 0 Clear all entries from the errlog up to 7 days ago errclear 7 List info on error ID FE2DEE00 errpt -aDj FE2DEE00 ››› The ID is from the IDENTIFIER column in errpt output. Put a "tail" on the error log errpt -c List all errors that happened today errpt -s `date +%m%d0000%y` List all errors on hdisk0 errpt -N hdisk0 To list details about the error log /usr/lib/errdemon -l To change the size of the error log to 2 MB /usr/lib/errdemon -s 2097152 syslog.conf line to send all messages to a log file *.debug /var/log/messages syslog.conf line to send all messages to error log *.debug errlog |
WPAR
• WPARs (Workload PARtitions) are an AIX 6.1 feature that can be used to capture a process tree and lock it into its own environment. An AIX system can host multiple WPARs that each appear to be nearly identical to a regular system. All processes in the WPAR are subject to the environment of that WPAR such as devices, filesystems, configurations, and networking unique to that WPAR. • There are two types of WPARs, system and application. The key differences are that a system WPAR begins at the init process while an application WPAR begins at the application process and the system WPAR has dedicated file systems while the application may not. System WPARs can be "sparse" or "whole root" but it is the application WPAR that is most different from the other container implementations. • The hosting AIX system is called the "global environment". The key differences in the global environment is that it runs the kernel, owns the devices, and can host WPARs. Significant effort has been taken for the user environment of a WPAR to be indistinguishable from the global environment. That said, the administrator needs to be aware of what environment she is in to perform various tasks. • Because of the limited and contextually relevant administrative environment of a WPAR, some commands behave differently than others when run in a WPAR or the global environment. Generally speaking, the more lower level the command, the more appropriate it is to run in the global environment. One example of administration tasks most appropriate for the global environment is device management commands. While a (system) WPAR has devices, the devices in a WPAR are much different than those in the global environment. • WPARs are started from /etc/inittab with the /etc/rc.wpars script, using the configuration information in /etc/wpars/. • By default, the root filesystems of sytem WPARs are created in /wpars/WPAR_name/. The filesystems are browsable by (properly permissioned) users of the global environment. Users in a WPAR cannot see filesystems of other WPARs. • By default the /usr, /opt, and /proc filesystems of a system WPAR are shared with the global environment via a read-only "namefs" vfs type. (/proc is mounted read-write in each of the non-global WPARs.) As a result, software and updates cannot be applied to these read-only WPAR views of the filesystems from the WPAR. Filesystems that are local to the WPAR (such as /home, /,/tmp, and /var) can be modified from within the WPAR. Examples in this section show the default read-only and alternate options for these filesystems. • Some options for system WPAR filesystems include: – Using a dedicated VG or external NFS mount for WPAR filesystems. (Unless otherwise specified, system WPAR filesystems are created from rootvg.) – Using a single LV for all local filesystems. (The default filesystem layout is similar to traditional AIX installs in that it will be broken into multiple LVs / filesystems.) – Creating a dedicated (local copy) of the /usr and /opt file systems. (In the default filesystem setup/home, /, /tmp, and /var are unique to the WPAR while /usr and /opt are views on the actual file systems in the global environment.) – Creating additional filesystems dedicated to the WPAR. (This can take the form of a NFS mount or a dedicated filesystem just for the WPAR.) • A number of commands support a new -@ flag for WPAR related output. The required parameters and output of the -@ flag varies by command, and what environment the command is run in (WPAR or global). • A system WPAR is started and stopped much like a separate OS with the startwpar and stopwparcommands. These act effectively as boot and shutdown operations. The shutdown will be the most familiar, while the boot operation is significantly different from booting a system. Instead of bootstrapping the system from a disk, the WPAR startup process involves bringing online all the required filesystems, changing to that root filesystem / environment, and then picking up the boot process at init. (This is a simplistic treatment of the process designed to illustrate the difference from a system boot of something like a LPAR in a virtualized environment.) • Application WPARs are not started like a system WPAR. It is more appropriate to describe them as being executed in a different context. Application WPARs can see the global environment filesystems and devices, they inherit everything not explicitly set by the wparexec command. The large majority of examples and discussion in this section refer to system WPARs. • The Solaris implementation of containers offers a command called zonename that tells what zone the user is in. It works like the hostname command when run from a zone but returns the word "global" when run from the global environment. AIX provides the uname -W to tell if you are in a WPAR or not. I have included the logic (script) to create a wparname command that tells if you are in a WPAR as well as the hostname of the WPAR (like the zonename command). #!/bin/sh Sample source of wparname command.if (( `uname -W > /dev/null 2>&1` )) then echo "global" else hostname fi | Create the rudra WPAR with default options mkwpar -n rudra ››› This command will pull the IP configuration for ruda from DNS. Naturally, rudra must be defined in DNS for the global environment to find. Start the rudra WPAR startwpar -v rudra Log into the console of rudra clogin rudra -l root Create indra WAPR with useful options mkwpar -A -n indra -r -s -v -A = Start automatically on system boot. -n name = Workload partition name. -r = Copy global network name resolution configuration into the workload partition. -s = Start after creation. -v = Verbose mode. Create a WPAR on a dedicated VG mkwpar -n varuna -A -g varuna_vg \ -r -s -v ››› If a VG or other filesystem options are not supplied then the filesystems for a system WPAR will be created from LVs on the rootvg. This command uses a dedicated VG called varuna_vg. The /usr and /opt filesystems will still be shared with the global WPAR and therefore will still come from rootvg but will not take any additional space. If the -l option was used in the above command then a new /usr and /opt would have been created for this WPAR using the specified VG. Create an additional fs on dedicated VG crfs -v jfs2 -g varuna_vg \ -m /wpars/varuna/data01 -u varuna \ -a size=100M ››› This command is run from the global environment. The mount point is within the varuna root filesystem (/wpars/varuna) so that it can be seen by the varuna WPAR. The -u varuna option specifies this fs as part of the varuna mount group so that it will be mounted when varuna starts. Remove the varuna WPAR rmwpar -s varuna ››› -s stops it first, -p preserves the filesystems. (In this case we delete the underlying filesystems.) Create a WPAR with mount options mkwpar -n varuna -r -s \ -M directory=/ vfs=nfs \ dev=/varuna_nfs host=shiva \ -M directory=/var vfs=directory \ -M directory=/home vfs=directory \ -M directory=/tmp vfs=directory \ -M directory=/usr vfs=directory \ -M directory=/opt vfs=directory ››› The mkwpar command in this example uses a remote NFS share to host the filesystems for this system WPAR. It also specifies that each of the regular mount points will instead be directories and not mounts. The resulting WPAR will have only two mount points, one for the /filesystem and one for the /proc filesystem. The NFS mount in this example must be root mountable by both the global environment and the system WPAR. An example of the actual (but temporary) NFS share is given in the NFS section above. List all WPARs on the system lswpar ››› Default output will include Name, State, Type, Hostname, and Directory. Valid types are S (System), A (Application) and C (Checkpointable). Determine if you are in global WPAR uname -W ››› This command will print 0 to stdout and return 0 if in a global environment, and give non-zero values if in a system WPAR. Another method is to look for the wio0 device in lsdev output -wio0 only exists in a system WPAR. List WPARs with (basic) network configuration lswpar -N Change rudra WPAR to start on system boot chwpar -A rudra List all processes in the indra WPAR from global ps -ef@ indra List ports / connections for the global environment netstat -naf inet -@ Global ››› Run in global environmnet. Stop WPAR rudra from global stopwpar -v rudra Start apache in an application WPAR wparexec -n varuna \ /usr/sbin/apachectl start & ››› In this example varuna is defined in DNS. Because the -h flag is not used, the hostname will default to the WPAR name, and will pull IP configuration from DNS for that host. Subnet mask, name resolution, and all other settings will be inherited from the appropriate interface in the Global environment. |
No comments:
Post a Comment