• 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.

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.

• 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.

• 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:

 

◊ Command reference: lspv, lsvg, lslv, mkvg, mklv, reducevg, extendvg, mklvcopy, chvg, logform, lvmo, exportvg, importvg, varyonvg, varyoffvg, bosboot, bootlist, /etc/filesystems, crfs, chfs, lsfs, rmfs, mount, fuser, df, du

• 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 and rmnfs 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.

 

 

◊ Command reference: showmount, chnfs, mknfs, rmnfs, nfso, automount, chnfsexp, chnfsmnt, exportfs, lsnfsexp, lsnfsmnt, mknfsexp, mknfsmnt, rmnfsexp, rmnfsmnt, mount

• The procfs is the single (default) pseudo fs. Interestingly, /proc is not used by commands like ps or topas 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. cdromd uses 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.

 

◊ Command reference: chps, lsps, rmps, swapoff, swapon, mount, umount, cdromd, cdeject, cdmount, cdcheck, cdumount, cdutil

• 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 not from 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 *namsv commands. 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 the enX 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.

• 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.

 

• The following tcpdump examples are simplistic and limited, an extended usage description for tcpdump 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.

 

◊ Command reference: mktcpip, rmtcpip, ifconfig, netcdctrl, no, tcpdump, chdev, lsattr, entstat, netstat, route, host, hostname

• 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 forget the 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 cfgmgr command 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 lsdev command. 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 the lscfg command.

 

 

◊ Command reference: lsdev, lsparent, lscfg, lsattr, chdev, rmdev, cfgmgr, lscons, swcons, fcstat, entstat, ibstat, getconf getconf, lsslot, drslot

• 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:

 

• 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 are rc.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 of srcmstr.

 

 

◊ Command reference: lssrc, startsrc, stopsrc, refresh, srcmstr

• 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 consistent when showing the iterative options.

 

• 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.

• 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 not recognized by the file command so I have included a sample MAGIC for both file types.

• 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.

• The SMIT customization page has more ODM command examples.

 

◊ Command reference: odmget, odmadd, odmchange, odmcreate, odmdelete, odmdrop, odmshow

• 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.

 

 

◊ Command reference: installp, inutoc, lslpp, emgr, gencopy, suma, mksysb

• 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 then checked 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.

 

◊ User / Group admin command reference: mkuser, chuser, rmuser, lsuser, pwdadm, mkgroup, chgroup, rmgroup, lsgroup, chgrpmem, usrck, grpck, pwdck

◊ RBAC command reference: setkst, chrole, mkrole, lsrole, rmrole, mkauth, chauth, lsauth, rmauth, ckauth, setsecattr, lssecattr, rmsecattr

◊ User command reference: users, w, who, whoami, whodo, id, chsh, passwd, setgroups, ulimit, setsenv, last, finger

• 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 bootlist command.

• 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.

• 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 bosboot every 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.

 

◊ Command reference: bosboot, bootlist

• 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.

 

 

◊ Command reference: alog, errpt, errlogger, errdemon, errclear

• 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:

– 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 stopwpar commands. 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).

 

◊ Command reference: mkwpar, chwpar, lswpar, rmwpar, startwpar, stopwpar, wparexec, rebootwpar, syncwpar, syncroot