AIX NOTES:
SANDEEP TANTI• 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.
Disks, LVM, & Filesystems
Concepts
• LVM (Logical Volume Manager) is the everpresent
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
• 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.
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.) -m specifies 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 varyon
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
à 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
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:
Flag Now After Boot
-I Ö
-B Ö Ö
-N Ö
• 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.
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.
à Command reference: showmount, chnfs, mknfs,
rmnfs, nfso, automount, chnfsexp, chnfsmnt,
exportfs, lsnfsexp, lsnfsmnt, mknfsexp,
mknfsmnt, rmnfsexp, rmnfsmnt, mount
Other
• 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
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.
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.
à Command reference: chps, lsps, rmps, swapoff,
swapon, mount, umount, cdromd, cdeject,
cdmount, cdcheck, cdumount, cdutil
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 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.
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
ent0 command 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 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.
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'
à Command reference: mktcpip, rmtcpip, ifconfig,
netcdctrl, no, tcpdump, chdev, lsattr, entstat,
netstat, route, host, hostname
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 forget
the device, so unless the physical device is
actually removed it will simply be found and recreated
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.
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
is physically 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 or awking 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 to scsi2. 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 grep command 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.
à Command reference: lsdev, lsparent, lscfg,
lsattr, chdev, rmdev, cfgmgr, lscons, swcons,
fcstat, entstat, ibstat, getconf getconf, lsslot,
drslot
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:
Mktcpip = Initial TCP/IP setup
lvm = Root of the LVM menus
mkuser =Screen to add a user
pgsp =Root of the paging space menus
nfs =Root of NFS menus
subserver =inetd config
mpio =Root screen for all MPIO operations
etherchannel =Root of EtherChannel / 802.3ad memus
chgenet =Configure paramaters on the ent device
vlan =Root of menus to manage VLAN
configurations
mkvg = Beginning screen to create a new VG
• 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)
F3 (Esc-3) Exit current screen
F4 (Esc-4) Generate a pop-up list that can be
chosen from
F6 (Esc-6) List the command that will be run
F5 (Esc-5) Reset the field to the original / default
value
F8 (Esc-8) Show the fast-path tag for this screen
F10 (Esc-0) Exit SMIT
/phrase Search for phrase in a list
n Used to find the next occourence of the
search phrase
Tab Used to alternatively select items from
a "ring" (a short list).
• Symbols that denote field data requirements:
* This is a required field
# This field requires a numeric value
/ This field requires a path
X This field requires a hexadecimal number
? The data entered will not be displayed
+ Data can be retrieved from a list
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 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.
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.
à Command reference: lssrc, startsrc, stopsrc,
refresh, srcmstr
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 nontrace
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:
atmstat - Show statistics and device details for
ATM adapters
curt - [T@] CPU Utilization Reporting Tool. A
trace based tool for monitoring CPU
activity.
entstat - Show statistics and device details for
Ethernet adapters
fcstat - Show statistics and device details for
FC HBAs
fddistat - Show statistics and device details for
FDDI adapters
fileplace - Show fragmentation and block / fs
usage for a file.
filemon - [T@] Generate a report of advanced /
detailed disk statistics that highlights
where I/O was generated and what
generated it.
gprof - Generate profiling statistics for a
binary.
iostat - [@] Supports I/O statistics on
multiple device types, but used
primarily as a first line disk I/O
statistic reporting tool.
ipcrm - [@] Remove IPC (InterProcess
Communication) semaphores,
message queues, and shared memory
segments
ipcs - [@] List IPC (InterProcess
Communication) semaphores,
message queues, and shared memory
segments
iptrace - Network packet tracing daemon.
Results can be viewed with ipreport
istat - A command line stat() tool. It gives
similar info to ls but in potentially
more scriptable output.
kdb - An interactive user-space command
for viewing kernel structures, memory
locations, tables, etc... from a running
system or a dump of the kernel.
lparstat - [@] Reports per-LPAR statistics -
primarily memory and CPU utilization.
Also reports virtualization-aware
statistics such as entitlement
consumption and hypervisor calls. The
WPAR flag on this command is -W not
-@.
lvmstat - Reports I/O statistics on VG
structures (as opposed to per-disk
statistics). Statistics gathering must
be enabled with the -e switch before
use.
mpstat - [@] Reports performance statistics
such as interrupts, context switches,
min/maj faults, system calls, and
processor affinity.
netpmon - [T@] Reports detailed network,
socket, and NFS related statistics over
an interval.
netstat - [@] Show networking status for TCP/
UDP through physical layers.
pmcycles - A tool to measure actual CPU speed
(presumably for CPUs that may go
into power save).
pprof - [T@] Reports detailed statistics on
kernel threads.
probevue - Lightweight dynamic tracing tool that
utilizes the Vue language. Additional
ProbeVue resources are available
locally on the ProbeVue page.
ps - [@] List processes
pstat - Show the contents of several system
tables from a core file or active kernel.
rmss - Tool to simulate a reduced memory
footprint for an application. Running
the LPAR with reduced memory may
be a more popular alternative to this
command.
splat - [T] Simple Performance Lock Analysis
Tool. Provides lock statistics. Must be
run on a system booted with lock trace
reporting enabled.
spray - Network load generation tool using a
remote sprayd daemon. Requires the
RPC daemon (rpc-sprayd) to be
registered.
svmon - Displays general to detailed reports of
VM usage on the system as a whole or
for individual processes.
tcpdump - Capture network packets. Packets can
be filtered by type, port, interface,
address, or other criteria. Packets can
be captured with detail or in summary.
See examples at the end of the
networking examples section.
topas - topas is a curses-based, interactive,
multi-area, general performance
reporting tool. topas is often the first
tool used in a performance tuning
exercise. New topas users may find
useful info on the local introduction to
topas page.
tprof - [T@] A trace based profiling tool.
truss - Reports syscall, signals, and most
aspects of system interaction by a
process.
uptime - Reports system uptime as well as 1, 5,
and 15 minute system load averages.
vmstat - [@] Report statistics from the virtual
memory subsystem.
• 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.
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:
• 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:
Odmget=
Query data from an ODM object class.
Specific queries are supported with the -
q option, but it is not possible to limit
results to specific "columns" without
using another command like grep. If the
query string is omitted, then all data will
be returned. (This is an effecive way to
back up the data from the object class.)
The data will be returned in the odmadd/
odmget stanza format
odmadd=
Insert data into an ODM object class. The
data must be in the odmadd/odmget
stanza format. Because null values are
not allowed, all "columns" must be filled
with appropriate data.
Odmchange=
Change data in an ODM object class. A
query syntax allows the user to specify a
limited set of objects (rows). The data
changed is specified in a odmadd/odmget
stanza format. The stanza file does not
need to be complete as only the
descriptors (columns) present in the
stanza file will be changed in each
matched object.
Odmcreate=
Creates an ODM object class based upon
an odmcreate/odmshow "struct" file. The
ODM file will be created in the default
directory. Existing object classes with the
same name will be overwritten without
warning.
Odmdelete=
Will delete objects (rows) from an ODM
object class. The -q query syntax is
supported to limit the objects deleted. If
the query is omitted, all items will be
deleted. Selective delete operations can
lead to bloated object class files.
Odmdrop=
Deletes an entire ODM object class. All
objects (rows) and the object class itself
will be deleted. All object class files are
deleted. Future queries to this object
class will fail.
Odmshow=
Create a odmcreate/odmshow struct
output based upon the description of the
ODM object class. The results will define
each descriptor (column) in the object
class (table) as well as have other data
related to the current contents of the
object class in comment format. This
output can be used to re-create an
empty object class using the odmcreate
command.
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
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
à Command reference: installp, inutoc, lslpp,
emgr, gencopy, suma, mksysb
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, nonadmin
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.
• 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 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.
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
à 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
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.
Power on
Hardware initialization
Retrieve bootlist from NVRAM
Locate BLV and load into memory 20EE000B
Kernel initializes and mounts RAM FS
Phase 1 (rc.boot 1)
RAM FS is resized
Logging begins
restbase copies ODM to RAM FS 548
cfgmgr configures base devices in
ODM
510
bootinfo determines boot device 511,554
Phase 2 (rc.boot 2)
ipl_varyon varies on rootvg 551,552,554,556
fsck of / 517,555
mount of / 517,557
fsck & mount of /usr 517,518
fsck & mount of /var 517,518
copycore, umount /var 517
swapon /dev/hd6 517
RAM FS version of ODM copied to /
etc/objrepos
517
RAM FS version of /dev copied to disk 517
mount /var 517,518
Actual boot log written to (from RAM
FS version)
517
rc.boot 2 is finished 553
Kernel changes root from RAM FS t
Disk 553
Phase 3 553
Kernel invokes init from rootvg 553
init invokes rc.boot 3 553
fsck & mount of /tmp 517,518
syncvg -v rootvg & 517
Load streams modules 517
Configure secondary dump device 517
cfgmgr -p2 (Normal) or cfgmgr -
p3 (Service) 517, 521-529
Continued
cfgcon configures console c31
(cfgcon exit codes. c33 is assumed
here) c32, c33, or c34
System hang detection is started c33
Graphical desktop is (optionally) started
savebase updates ODM copy on BLV 530
syncd & errdemon started
System LED is turned off
rm -f /etc/nologin
Start several optional services
log: "System initialization completed"
Phase 3 complete, init continues
processing inittab
• 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
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
à Command reference: alog, errpt, errlogger,
errdemon, errclear
No comments:
Post a Comment