Installation, backup, and recovery
The following AIX 7.1 topics are covered in this chapter:
9.1 AIX V7.1 minimum system requirements
This section discusses the minimum system requirements to install and run AIX V7.1.
9.1.1 Required hardware
Only 64-bit Common Hardware Reference Platform (CHRP) machines are supported with AIX V7.1. The following processors are supported:
PowerPC® 970
POWER4
POWER5
POWER6
POWER7
To determine the processor type on an AIX system you can run the prtconf command, as shown in Example 9-1.
Example 9-1 Using prtconf to determine the processor type of a Power system
# prtconf | grep 'Processor Type'
Processor Type: PowerPC_POWER7
 
Note: The RS64, POWER3™, and 604 processors, 32-bit kernel, 32-bit kernel extensions and 32-bit device drivers are not supported.
Minimum firmware levels
Update your systems to the latest firmware level before migrating to AIX V7.1. Refer to the AIX V7.1 Release Notes for information relating to minimum system firmware levels required for AIX V7.1 at:
For the latest Power system firmware updates, refer to the following website:
Memory requirements
The minimum memory requirement for AIX V7.1 is 512 MB.
The current minimum memory requirements for AIX V7.1 vary based on the configuration of a system. It may be possible to configure a smaller amount of memory for a system with a very small number of devices or small maximum memory configuration.
The minimum memory requirement for AIX V7.1 may increase as the maximum memory configuration or the number of devices scales upward.
Paging space requirements
For all new and complete overwrite installations, AIX V7.1 creates a 512 MB paging space device named /dev/hd6.
Disk requirements
A minimum of 5 GB of physical disk space is required for a default installation of AIX V7.1. This includes all devices, the Graphics bundle, and the System Management Client bundle. Table 9-1 provides information relating to disk space usage with a default installation of AIX V7.1.
Table 9-1 Disk space requirements for AIX V7.1
Location
Allocated (Used)
/
196 MB (181 MB)
/usr
1936 MB (1751 MB)
/var
380 MB (264 MB)
/tmp
128 MB (2 MB)
/admin
128 MB (1 MB)
/opt
384 MB (176 MB)
/var/adm/ras/livedump
256 MB (1 MB)
 
Note: If the /tmp file system has less than 64 MB, it is increased to 64 MB during a migration installation so that the AIX V7.1 boot image can be created successfully at the end of the migration.
Starting with AIX V6.1 Technology Level 5, the boot logical volume is required to be 24 MB in size.
The pre_migration script will check if the logical volume is the correct size. The script is located on your AIX V7.1 installation media or it can also be located in an AIX V7.1 NIM SPOT.
If necessary, the boot logical volume, hd5, size will be increased. The logical partitions must be contiguous and within the first 4 GB of the disk. If the system does not have enough free space, a message is displayed stating there is insufficient space to extend the hd5 boot logical volume.
To install AIX V7.1, you must boot the system from the product media. The product media can be physical installation media such as DVD or it can be a NIM resource. For further information and instructions on installing AIX V7.1, refer to the AIX Installation and Migration Guide, SC23-6722, in the AIX Information Center at:
AIX edition selection
It is now possible to select the edition of the AIX operating system during the base operating system (BOS) installation.
AIX V7.1 is available in three different editions:
Express This edition is the default selection. It is suitable for low-end Power systems for consolidating small workloads onto larger servers.
Standard This edition is suitable for most workloads. It allows for vertical scalability up to 256 cores and 1024 threads.
Enterprise This edition includes the same features as the Standard edition but with enhanced enterprise management capabilities. IBM Systems Directory Enterprise Edition and the Workload Partitions Manager™ for AIX are included. Systems Director Enterprise Edition also includes IBM Systems Director, Active Energy Manager, VMControl, IBM Tivoli® Monitoring and Tivoli Application Dependency Discovery Manager (TADDM).
Some of the differences between the AIX V7.1 editions are shown in Table 9-2.
Table 9-2 AIX edition and features
AIX V7.1 Feature
Express
Standard
Enterprise
Vertical Scalability
4 cores, 8 GB per core
256 cores, 1024 threads
256 cores, 1024 threads
Cluster Aware AIX
Only with PowerHA
Yes
Yes
AIX Profile Manager (requires IBM Systems Director)
Management target only
Yes
Yes
AIX 5.2 Versioned WPAR support (requires the AIX 5.2 WPAR for AIX 7 product)
Yes
Yes
Yes
Full exploitation of POWER7 features
Yes
Yes
Yes
Workload Partition support
Yes
Yes
Yes
WPAR Manager and Systems Director Enterprise Edition
No
No
Yes
As shown in Example 9-2, the administrator can change the AIX edition installed by selecting 5 Select Edition from the BOS installation menu.
Example 9-2 Selecting the AIX edition during a BOS installation
Installation and Settings
 
Either type 0 and press Enter to install with current settings, or type the
number of the setting you want to change and press Enter.
 
1 System Settings:
Method of Installation.............New and Complete Overwrite
Disk Where You Want to Install.....hdisk0
 
2 Primary Language Environment Settings (AFTER Install):
Cultural Convention................C (POSIX)
Language...........................C (POSIX)
Keyboard...........................C (POSIX)
 
3 Security Model.......................Default
4 More Options (Software install options)
5 Select Edition.......................express
>>> 0 Install with the settings listed above.
 
+-----------------------------------------------------
88 Help ? | WARNING: Base Operating System Installation will
99 Previous Menu | destroy or impair recovery of ALL data on the
| destination disk hdisk0.
>>> Choice [0]:
Possible selections are express, standard, and enterprise. The default value is express. The edition value can also be set during non-prompted NIM installations by using the INSTALL_EDITION field in the control_flow stanza of the bosinst_data NIM resource. The AIX edition can be modified after BOS installation using the chedition command, as shown in Example 9-3.
Example 9-3 The chedition command flags and options
# chedition
Usage chedition: List current edition on the system
chedition -l
 
Usage chedition: Change to express edition
chedition -x [-d Device [-p]]
 
Usage chedition: Change to standard edition
chedition -s [-d Device [-p]]
 
Usage chedition: Change to enterprise edition
chedition -e [-d Device [-p]]
The edition selected defines the signature file that is copied to the /usr/lpp/bos directory. There are three signature files included in the bos.rte package. The files are located in /usr/lpp/bos/editions. These files are used by the IBM Tivoli License Manager (ITLM) to determine the current edition of an AIX system. When an edition is selected during installation (or modified post install), the corresponding signature file is copied to the /usr/lpp/bos directory.
For example, to change the edition from express to enterprise you would enter the command shown in Example 9-4 on page 369. You will notice that the corresponding signature file changes after the new selection.
Example 9-4 Modifying the AIX edition with the chedition command
# chedition -l
standard
# ls -ltr /usr/lpp/bos | grep AIX
-r--r--r-- 1 root system 50 May 25 15:25 AIXSTD0701.SYS2
# chedition -e
chedition: The edition of the system has been changed to enterprise.
# ls -ltr /usr/lpp/bos | grep AIX
-r--r--r-- 1 root system 50 May 25 15:25 AIXENT0701.SYS2
# chedition -l
enterprise
For further usage information relating to the chedition command, refer to the command reference section in the AIX Information Center at:
A SMIT interface to manage AIX editions is also available with the SMIT fastpath, smit editions.
For further information relating to managing AIX editions, refer to the AIX V7.1 Information Center at:
IBM Systems Director Command Agent
AIX V7.1 includes the IBM Systems Director Common Agent as part of the default install options. It is included in the System Management Client Software bundle.
When AIX is restarted, the Director agent and its prerequisite processes are automatically enabled and started. If these services are not required on a system, follow the instructions in the AIX V7.1 Release Notes to disable them.
Refer to the AIX V7.1 Release Notes in the AIX Information Center for additional information relating to minimum system requirements:
9.2 Loopback device support in NIM
In addition to the Activation Engine, support for loopback devices will also be implemented in NIM. This support will allow a NIM administrator to use an ISO image, in place of the AIX installation media, as a source to create lpp_source and spot resources.
This functionality will rely on the underlying AIX loopback device feature introduced in AIX 6.1 via the loopmount command. Loopback device support was implemented in AIX 6.1, allowing system administrators to mount ISO images locally onto a system in order to read/write them.
This functionality limits the requirement of using the physical AIX installation media to create lpp_source and spot resources.
9.2.1 Support for loopback devices during the creation of
lpp_source and spot resources
On the AIX Infocenter site at:
it is specified that you can define an lpp_source in several ways. One is that an ISO image containing installation images can be used to create an lpp_source by specifying its absolute path name for the source attribute. For example:
nim -o define -t lpp_source -a server=master -a location=/nim/lpp_source/lpp-71 -a source=/nim/dvd.71.v1.iso lpp-71
would define the lpp-71 lpp_source at /nim/lpp_source/lpp-71 on the master NIM server using the /nim/dvd.71.v1.iso ISO image.
If you wanted to define a spot labeled “spot-71” at /nim/spot/spot-71 on the master server using the /nim/dvd.71.v1.iso ISO image, then the following would be executed:
nim -o define -t spot -a server=master -a location=/nim/spot -a source=/nim/dvd.71.v1.iso spot-71
9.2.2 Loopmount command
The loopmount command is the command used to associate an image file to a loopback device and optionally make an image file available as a file system via the loopback device.
It is described in the infocenter at:
A loopback device is a device that can be used as a block device to access files. It is described in the infocenter at:
The loopback file can contain an ISO image, a disk image, a file system, or a logical volume image. For example, by attaching a CD-ROM ISO image to a loopback device and mounting it, you can access the image the same way that you can access the CD-ROM device.
Use the loopmount command to create a loopback device, to bind a specified file to the loopback device, and to mount the loopback device. Use the loopumount command to unmount a previously mounted image file on a loopback device, and to remove the device. There is no limit on the number of loopback devices in AIX. A loopback device is never created by default; you must explicitly create the device. The block size of a loopback device is always 512 bytes.
The loopmount command restrictions
The following restrictions apply to a loopback device in AIX:
The varyonvg command on a disk image is not supported.
A CD ISO, DVD UDF+ISO, and other CD/DVD images are only supported in read-only format.
An image file can be associated with only one loopback device.
Loopback devices are not supported in workload partitions.
Support of the loopmount command in NIM
In order to create an lpp_source or spot resource from an ISO image, NIM must be able to mount ISO images using the loopmount executable.
NIM tries to mount the ISO image using:
/usr/sbin/loopmount -i image_pathname -m mount_point_pathname -o "-V cdrfs -o ro
If the ISO image is already mounted, loopmount will return an error.
Since umount would unmount an ISO image, nothing has changed,
Add ISO image documentation to the Define a Resource smitty menu (nim_mkres fastpath).
9.3 Bootlist command path enhancement
Configuration path commands such as bootlist, lspath, chpath, rmpath, and mkpath have been enhanced with Multiple PATH I/O devices (MPIO) path manipulation. It means that you can now include the pathid of a device.
9.3.1 Bootlist device pathid specification
The bootlist command includes the specification of the device pathid.
The AIX V7.1 man page for the bootlist command is shown in Example 9-5.
Example 9-5 Bootlist man page pathid concerns
Purpose
Displays information about paths to a device that is capable of
multiPath I/O.
Syntax
bootlist [ { -m Mode } [ -r ] [ -o ] [ [ -i ] [ -V ] [ -F ]| [ [ -f File ] [ Device [ Attr=Value ... ] ... ] ] ] [ -v ]
Description
.......
When you specify a path ID, identify the path ID of the target disk by using the pathid attribute. You can specify one or more path IDs with the pathid attribute by entering a comma-separated list of the required paths to be added to the boot list. When the bootlist command displays information with the -o flag, the pathid attribute is included for each disk that has an associated path ID.
Examples
11 To specify path ID 0 on disk hdisk0 for a normal boot operation, type:
bootlist -m normal hdisk0 pathid=0
12 To specify path ID 0 and path ID 2 on disk hdisk0 for a normal
boot operation, type one of the following commands:
bootlist -m normal hdisk0 pathid=0,2
bootlist -m normal hdisk0 pathid=0 hdisk0 pathid=2
 
Note: Because the pathid argument can be repeated, both syntax pathid=0,2 and pathid=0 pathid=2 are equivalent.
The order of the pathid arguments is how bootlist will process the paths. For example, pathid=2,0,1 will be different from patid=0,1,2.
The bootlist command display option specifies the pathid information; Example 9-6.
Example 9-6 bootlist -m normal -o command output
# bootlist -m normal -o
hdisk0 blv=hd5 pathid=0
9.3.2 Common new flag for pathid configuration commands
A new flag, -i, will print paths with the specified pathid specified as argument; Example 9-7.
Example 9-7 lspath, rmpath and mkpath command
lspath Command
 
Purpose
Displays information about paths to an MultiPath I/O (MPIO) capable device.
Syntax
lspath [ -F Format | -t ] [ -H ] [ -l Name ] [ -p Parent ] [ -s Status] [ -w Connection ] [ -i PathID ]
...
-i PathID
Indicates the path ID associated with the path to be displayed.
----------------------------------------------------------------------
rmpath Command
 
Purpose
Removes from the system a path to an MPIO capable device.
Syntax
rmpath [ -l Name ] [ -p Parent ] [ -w Connection ] [ -i PathID ]
...
-i PathID
Indicates the path ID associated with the path to be removed and is used to uniquely identify a path.
-----------------------------------------------------------------------
mkpath Command
 
Purpose
Adds to the system another path to an MPIO capable device.
Syntax
mkpath [ -l Name ] [ -p Parent ] [ -w Connection ] [ -i PathID]
...
-i PathID
Indicates the path ID associated with the path to be added and is used to uniquely identify a path. This flag cannot be used with the -d flag.
 
Note: The lspath command also gets a new flag, -t, which makes it possible to print information using the pathid field.
-t displays the path ID in addition to the current default output. The -t flag cannot be used with the -F or the -A flags.
# lspath -t
Enabled hdisk0 vscsi0 0
Enabled hdisk1 fscsi0 0
Enabled hdisk2 fscsi0 0
Enabled hdisk3 fscsi0 0
Enabled hdisk4 fscsi0 0
In case there is only one pathid, lspath and lspath -i 0 get the same output.
# lspath
Enabled hdisk0 vscsi0
Enabled hdisk1 fscsi0
Enabled hdisk2 fscsi0
Enabled hdisk3 fscsi0
Enabled hdisk4 fscsi0
 
9.4 NIM thin server 2.0
With the AIX Network Installation Manager (NIM), you can manage the installation of the Base Operating System (BOS) and any optional software on one or more machines.
The NIM environment includes a server machine called master and clients that receive resources from the server.
The Network Install component has provided several options for network security and firewall enhancements, but in AIX 6.1 it did not offer a method for encrypting or securing network data on resource servers in the NIM environment. In AIX 7.1 the NIM service handler (nimsh) provides NIM users with a client-configurable option for service authentication. Support of NFS V4 offers that capability.
NFS V4 support also permits support of the IPv6 network. The NIM server has been updated to support the IPv6 network.
An overview of the features and their implementation follows.
9.4.1 Functional enhancements
NFSv4 provides service authentication that provides information security in the following contexts:
Identification - Creation and management of the identity of users, hosts, or services.
Authentication - Validation of the identity of users, hosts or service.
Authorization - Control of the information and data that a user or entity can access.
Some security attributes were then added to the NIM object database for the resource objects accessed through NFS V4.
You may specify the NFS export requirements for each NIM resource object when it is created or when changing options. The NFS protocol options available are summarized in the following table:
Table 9-3 NFS available options
option
values (default bolded)
version
v3 or v4
security
sys or krb5
The Kerberos configuration specified with previous the krb5 flag must be created by you. Samples are available in /usr/samples/nim/krb5, and Kerberos credentials are viewable using query commands so clients can verify their credentials.
 
Note: In order to propagate the Kerberos configuration to NIM clients, the credentials must be valid for NFS access when strong security is enabled.
In the IPv6 network we can find two types of addresses:
Link-local addresses prefixed by FE80::/16, which are used by hosts on the same physical network, that is, when there is only one hop of communication between nodes.
Global addresses that uniquely identify a host on any network.
NIM supports installation of clients on IPv6 networks. Thin Server IPv6 network clients are also supported.
To support IPv6, NIM commands and SMIT menus have been preserved but new objects have been added; see Table 9-4.
Table 9-4 New or modified NIM objects
Object name
Meaning
ent6
Represents an Ethernet IPv6 network.
IPv6 clients must be a member of this network.
if1 new semantic
The third field of if1 must contain the client’s link-local address instead of the MAC address, such as
If1=“v6net myclient.company.com fe80:23d7::663:4”
 
Note: For IPv6 clients, BOOTP is not used but the boot image is downloaded directly through TFTP, which requires specification of a boot image file name. The convention being used is that the boot image file name is simply the hostname used by the client.
TFTP support is also available via new SMS menus for IPv6 added to the firmware. See an example in 9.4.5, “IPv6 boot firmware syntax” on page 378.
9.4.2 Considerations
Because the security options rely on exporting options for machine, network and group objects in the NIM environment, the mount options must be consistent across NFS client access:
You cannot mix export options for an NFS mount specification.
Only one single version support for a file system.
You are limited to exporting NIM spot resources with an NFS security option of sys.
You cannot define pseudo root mappings for NFS V4 exports. The NFS default of / will be used for accessing the NIM resources.
The NFS options are only manageable from the NIM master. NIM clients can only do queries.
The NFS attributes of the NFS protocols called nfs_vers and nfs_sec are what you get when mounting resources or restricting access.
 
Note: The NFS server calls the rpc.mountd daemon to get the access rights of each client, so the daemon must be running on the server even if the server only exports file systems for NFS version 4 access.
When master and client are on the same network, link-local addresses must be used.
When master and client are on different networks, global addresses are used as normal.
Gateway must always be link-local.
NIM resources that are allocated to IPv6 clients must be exported using NFS4 with the option -a nfs_vers=4.
Only AIX 6.1 TL1 and greater can be installed over IPv6.
Only AIX 6.1 TL6 and greater thin servers can boot over IPv6.
Only AIX 6.1 and greater can be installed at the same time as other IPv6 clients.
Static IPv6 addresses are enforced so there is no DHCP support, no support for router discovery nor service discovery.
9.4.3 NIM commands option for NFS setting on NIM master
On the NIM master, if SMIT panels would drive you to specify the NFS options, the nim command is able to enable NFS client communication options:
To enable the global use of NFS reserved ports type:
# nim -o change -a nfs_reserved_port=yes master
To disable global usage of NFS reserved ports type:
# nim -o change -a nfs_reserved_port=no master
To enable port checking on the NIM master NFS server type:
# nfso -o portcheck=1
To disable port checking on the NIM master NFS server.
# nfso -o portcheck=0
9.4.4 Simple Kerberos server setting on NIM master NFS server
In order to use Kerberos security options for NFS you need to set a Kerberos server. A sample is provided in
/usr/samples/nim/krb5/config_rpcsec_server
To create a new system user-based on the principal name and password provided, just type:
/usr/samples/nim/krb5/config_rpcsec_server -p <password> -u <user principal name>
If you want to delete the Kerberos V configuration information related to the Kerberos server and principals on the NIM master NFS server, just type the following command on the NIM master:
# /usr/sbin/unconfig.krb5
 
Note: Because Kerberos is relying on time, a mechanism should be invoked to automatically synchronize time through the network. The NIM server must run the AIX timed daemon or an NTP daemon.
9.4.5 IPv6 boot firmware syntax
The boot command has changed to support IPv6 and the new format:
> boot /lhea@23c00300/ethernet@23e00200:ipv6,ciaddr=FE80::214:5EFF:FE51:D5,
giaddr=FE80::20D:60FF:FE4D:C1CE,siaddr=FE80::214:5EFF:FE51:D51,
filename=mylparwar.domain.com
9.4.6 /etc/export file syntax
The syntax of a line in the /etc/exports file is:
directory -option[,option]
directory is the full path name of the directory. Options can designate a simple flag such as ro or a list of host names. See the specific documentation of the /etc/exports file and the exportfs command for a complete list of options and their descriptions.
9.4.7 AIX problem determination tools
Numerous files and commands can be used to investigate problems.
syslogd NFS uses the syslog to write its error and debug information. Before carrying out any problem determination, the administrator should turn syslog logging on.
iptrace To examine network traffic, the developer should create an iptrace.
ipreport To decode an iptrace into a readable format, the developer should use ipreport and ensure that Kerberos packets are included in the log.
rpcinfo Used to check the status of remote procedural call servers.
fuser Used to determine mount problems. fuser lists the process numbers of local processes that use the local or remote files specified by the command’s file parameter.
lsof Tool available at the following site for listing files opened by a process:
nfs4cl Allows display of NFS v4 statistics. The command can also be used to modify current NFS v4 properties.
nfsstat Displays information about NFS and RPC calls.
errpt Can be used to determine why a daemon is not starting or core dumping during its execution.
9.5 Activation Engine for VDI customization
This feature first became available in AIX 6.1 TL 06. Documentation is available in the Information Center under the Activation Engine topic.
The main purpose of the Activation Engine (AE) is to provide a toolkit that allows one image of an AIX instance to be deployed onto many target machines, each with a different configuration.
The Activation Engine includes a script that runs at boot time and automatically configures the system with a set of defined system parameters. These parameters are specified by the system administrator in the virtual image template file on the optical media.
A generic system image, such as a Virtual Disk Image (VDI) or mksysb, can be used to boot multiple clients using different virtual image template files. Each of the target machines will then be deployed with a completely different configuration including network configuration, custom file systems, and user accounts.
9.5.1 Step-by-step usage
Activation Engine usage can be summarized in the following five steps:
1. Enable Activation Engine on the AIX system.
2. Capture a VDI using the current system as the source.
3. Create a virtual image template file for any systems you wish to deploy to.
4. Place virtual image templates on optical drives of the systems you are deploying to.
5. Boot the target systems using the VDI.
Enable Activation Engine on the AIX system
The Activation Engine needs to be enabled on the target system.
By running the ae –o enable template_file command we are telling AE to enable itself to run at the next boot-up through an inittab entry. It will execute the processing of the XML template called template_file.
 
Note: We did not have to specify any scripts to run. The scripts are all defined and referenced in the XML template file itself.
The AIX Activation Engine is available in the bos.ae installp package. The contents of the package are listed below. It provides the ae command as well as some sample scripts.
Example 9-8 Content of the ae package
# lslpp -f bos.ae
Fileset File
-----------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.ae 7.1.0.0 /usr/samples/ae/templates
/usr/samples/ae/scripts/ae_accounts
/opt/ibm/ae/dmtf_network_bringup
/opt/ibm/ae/ae
/usr/samples/ae
/opt/ibm
/opt/ibm/ae/ae_template.xsd
/usr/samples/ae/scripts
/usr/sbin/ae -> /opt/ibm/ae/ae
/usr/samples/ae/scripts/ae_filesystems
/opt/ibm/ae
/usr/samples/ae/templates/ae_template.xml
/usr/samples/ae/scripts/ae_network
/opt/ibm/ae/ae_template.dtd
The first step is to enable and configure AE on a target system. This is done by running the ae -o enable command as shown in Example 9-9, which creates an aengine entry in /etc/inittab that will be executed at boot time.
Example 9-9 .Enabling activation engine
# ae -o enable
Activation Engine was successfully enabled.
Using template 'ae_template.xml' from first available optical media.
# grep engine /etc/inittab
aengine:23456789:wait:/usr/sbin/ae -o run ae_template.xml
The argument ae_template.xml is the name of the XML template that will be read from the optical media at boot time. It is the default name. However, it can be specified as an argument to the ae -o enable command. See the command syntax in Example 9-10.
Example 9-10 The Activation Engine command syntax
# ae
USAGE: /usr/sbin/ae -o {enable | disable | status | check | run}
 
enable <template> - Enable the Activation Engine
disable - Disable the Activation Engine
status - Print current status of Activation Engine
check <template> - Validate a user created template against the Activation Engine schema
run <template> - Execute the activation engine against a particular template file
Capture a VDI using the current system as the source
The second step involves capturing an image of your current system. This is the image that you will use to deploy to other systems. The captured image must have the Activation Engine enabled so that AE can customize specific parameters at boot time. This capture step is usually performed using VMControl, which is one of the main consumers of AE.
This step can also be done using the mksysb or NIM.
 
Note: Image creation must be performed after Activation Engine has been enabled.
Create a virtual image template
Since each deployed system gets configured with its own network address, custom users, and file system, you usually need to create separate template files for each system you plan to deploy to. These files must be stored in the root of the optical media, which must be mountable by the Activation Engine at boot time.
The configuration is organized using two types of files:
The data contained in the XML template files.
The scripts that perform actions using the data extracted from XML template files.
The template file example /usr/samples/ae/templates/ae_template.xml listed in Example 9-12 references the scripts associated with the network, user, and file systems sections as seen in the grep command output shown in Example 9-11.
Example 9-11 Grep of script in user created template file.
<!--<section name="network" script="ae_network">
<section name="accounts" script="ae_accounts">
<section name="filesystems" script="ae_filesystems">
These default scripts are available in /usr/samples/ae/scripts.
Example 9-12 Sample script /usr/samples/ae/templates/ae_template.xml
# cat /usr/samples/ae/templates/ae_template.xml
<?xml version="1.0" encoding="UTF-8"?>
<template name="Sample Activation Engine template">
<settings>
<!-- log directory is created automatically if it doesn't exist -->
<logDirectory>/var/adm/ras/ae</logDirectory>
<!-- / is assumed to be / dir of optical media -->
<scriptsDirectory>/scripts</scriptsDirectory>
<!-- Here we specify all user created templates that we want AE to execute, in order. scripts are defined within -->
<extensions>
<!--<extendedTemplate>/user_template1.xml</extendedTemplate>-->
</extensions>
</settings>
<rules>
<!-- the following section was commented to out prevent accidental execution -->
<!-- script paths are assumed to be relative to / directory of optical media -->
<!--<section name="network" script="ae_network">
<ruleSet>
<hostname>hostanme.domain</hostname>
<interface>en0</interface>
<address>XX.XX.XX.XX</address>
<mask>255.255.254.0</mask>
<gateway>XX.XX.XX.0</gateway>
<domain>hostname.domain</domain>
<nameserver>XX.XX.XX.XX</nameserver>
<start_daemons>yes</start_daemons>
</ruleSet>
</section>
<section name="accounts" script="ae_accounts">
<ruleSet>
<username>username</username>
<groups>sys</groups>
<admin>true</admin>
<home>/home/apuzic</home>
</ruleSet>
</section>
<section name="filesystems" script="ae_filesystems">
<ruleSet>
<mountpoint>/usr/testmount</mountpoint>
<type>jfs2</type>
<volume_group>rootvg</volume_group>
<size>16M</size>
</ruleSet>
</section>-->
</rules>
</template>
 
Note: A template can reference as many scripts as it wants, as long as all those scripts are present on the optical media.
Creating AE scripts
Script creation must follow three distinct guidelines:
The scripts must accept parameters defined in the <ruleSet> tags of the template file. (See Example 9-12 on page 382.)
They must not pipe standard output or standard error to any external files because the Activation Engine pipes both of these to the specified log files. This makes debugging and status tracking easier.
The script must return 0 after a successful execution. Any other return code is interpreted as a failure.
 
Note: Each template can also link to other template files, which allows for further flexibility. For example, you can create one template to customize all network parameters on the system, another to create new file systems, and another to add new custom user accounts and groups. This allows for easier categorization of customized data. It also makes it easier to add new customized data to the image because you can create a new template and have one of the existing templates point to the newly created file.
Checking virtual image templates
Running ae –o check template_name against your own template checks your XML file against the schema and alerts you of any errors. It is a best practice that you do this before using your template files to make sure that you are not using the Activation Engine with an invalid template file in a production environment. A successful check is performed in Example 9-13.
Example 9-13 Successful Activation Engine template file structure check
# ae -o check ae_template.xml
Template 'ae_template.xml' is valid AE template
# cp /usr/samples/ae/scripts/* /
 
Note: The ae -o check command only checks syntax of the XML file, not the content. It does not check the existence of the script files referenced in the XML file.
Place virtual image templates on the optical media
Once a valid XML template file and optional corresponding shell scripts have been created, burn the files to the optical media.
The template file has to be located in the root directory of the media in the optical device.
 
Note: Activation Engine checks all bootable optical media for virtual image templates and uses the first one found. If you are booting a VDI on a system with two (or more) optical discs and all discs have virtual image templates, then AE will use the first template it finds on any of the mounted discs.
Boot the target systems using the VDI
Because the Activation Engine is executed at boot time through the inittab entry, the scripts will be executed and will only perform configurations limited to the boot phase. For example, you cannot expect to install new filesets using AE.
9.6 SUMA and Electronic Customer Care integration
In August 2004 AIX V5.3 introduced the Service Update Management Assistant (SUMA) tool, which allows system administrators to automate the download of maintenance updates such as Maintenance Levels (MLs), Technology Levels (TLs) and Service Packs (SPs). In the AIX V5.3 and AIX V6.1 releases SUMA uses the undocumented fixget interface to initiate a standard multipart data HTTP POST transaction to the URL where the fix server’s fixget script resides to retrieve AIX updates. The fix server’s URL is configured through the FIXSERVER_URL parameter of the SUMA global configuration settings during the base configuration and can be viewed with the suma -c command. Example 9-14 shows the suma -c command output on an AIX V6.1 TL 6100-05 system after a SUMA base configuration has been performed.
Example 9-14 SUMA default base configuration on AIX V6.1
# suma -c
FIXSERVER_PROTOCOL=http
DOWNLOAD_PROTOCOL=ftp
DL_TIMEOUT_SEC=180
DL_RETRY=1
MAX_CONCURRENT_DOWNLOADS=5
HTTP_PROXY=
HTTPS_PROXY=
FTP_PROXY=
SCREEN_VERBOSE=LVL_INFO
NOTIFY_VERBOSE=LVL_INFO
LOGFILE_VERBOSE=LVL_VERBOSE
MAXLOGSIZE_MB=1
REMOVE_CONFLICTING_UPDATES=yes
REMOVE_DUP_BASE_LEVELS=yes
REMOVE_SUPERSEDE=yes
TMPDIR=/var/suma/tmp
FIXSERVER_URL=www14.software.ibm.com/webapp/set2/fixget
A usage message for the fixget script is given at:
when entered in the address field of a web browser. Note that the fixget utility is not intended for direct customer use but is rather called internally by the SUMA tool.
Beginning with AIX V7.1, SUMA no longer uses fixget but instead utilizes the Electronic Customer Care (eCC) services to retrieve AIX updates.
IBM Electronic Customer Care services are strategically designed to offer a centralized access point to code updates for IBM systems. Independent of a given platform, similar terminology and application programming interfaces enable a standardized user interface with a consistent usage environment.
Currently eCC provides an update repository for instances such as Power Systems Firmware, Hardware Management Console (HMC), IBM BladeCenter, Linux, IBM i and now also for AIX 7. The eCC Common Client’s Java API is used as a common interface by all supported platforms to download the updates. In AIX V7.1 the eCC Common Client functionality is available through the bos.ecc_client.rte fileset. The same fileset is also required to support the IBM Electronic Service Agent™ (ESA) and the Inventory Scout utility on AIX. This means that on AIX 7, SUMA, ESA, and the Inventory Scout are all consumers of the same eCC Common Client and share the eCC code, the libraries, and the connectivity settings. However, each of the named utilities will run individually in a separate Java Virtual Machine.
9.6.1 SUMA installation on AIX 7
As in previous AIX releases, the SUMA code is delivered in the bos.suma fileset. But on AIX 7 this fileset is not installed by default because it is no longer included in the /usr/sys/inst.data/sys_bundles/BOS.autoi file. In AIX 7 the bos.suma fileset is contained in the graphics software bundle (Graphics.bnd) and the system management software bundle (SystemMgmtClient.bnd). Both predefined system bundles are located in the /usr/sys/inst.data/sys_bundles/ directory. The bos.suma fileset requires the installation of the bos.ecc_client.rte fileset, which in turn needs the support of Java 6 through the Java6.sdk fileset. Both SUMA and eCC rely on the support of the Perl programming language.
 
The lslpp command output in Example 9-15 shows the fileset dependencies of SUMA and eCC.
Example 9-15 The lslpp command output
7501lp01:/> lslpp -p bos.suma bos.ecc_client.rte
Fileset Requisites
-----------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.ecc_client.rte 7.1.0.0
*ifreq bos.rte 7.1.0.0
*prereq perl.rte 5.10.1.0
*prereq perl.libext 2.3.0.0
*prereq Java6.sdk 6.0.0.200
bos.suma 7.1.0.0 *prereq bos.rte 7.1.0.0
*prereq bos.ecc_client.rte 7.1.0.0
*prereq perl.rte 5.8.2.0
*prereq perl.libext 2.1.0.0
 
Path: /etc/objrepos
bos.ecc_client.rte 7.1.0.0
*ifreq bos.rte 7.1.0.0
*prereq perl.rte 5.10.1.0
*prereq perl.libext 2.3.0.0
*prereq Java6.sdk 6.0.0.200
bos.suma 7.1.0.0 *prereq bos.rte 7.1.0.0
*prereq bos.ecc_client.rte 7.1.0.0
*prereq perl.rte 5.8.2.0
*prereq perl.libext 2.1.0.0
9.6.2 AIX 7 SUMA functional and configuration differences
The SUMA implementation in AIX V7.1 is governed by the following two guidelines:
IBM AIX operating system release and service strategy
Electronic Customer Care cross-platform service strategy for IBM Systems
The current AIX service strategy was introduced in 2007 and requires fixpacks such as Technology Levels (TL) or Service Packs (SP) to be downloaded in a single entity. The download of individual fixes or filesets is no longer supported. SUMA in AIX 7 adheres to this service strategy and supports the following request type (RqType) values for the suma command only:
ML Request to download a specific maintenance or technology level.
TL Request to download a specific technology level. The TL must be specified by the full name, for example 6100-03-00-0920 instead of 6100-03.
SP Request to download a specific service pack. The SP must be specified by the full name, for example 6100-02-04-0920 instead of 6100-04-04.
PTF Request to download a Program Temporary Fix (PTF). Only certain PTFs may be downloaded as an individual fileset. For example, PTFs containing bos.rte.install, bos.alt_disk_install.rte, or PTFs that come out in between service packs. Otherwise, the TL or SP must be downloaded.
Latest Request to download the latest fixes. This RqType value returns the latest service pack of the TL specified in the FilterML field of the suma command. The FilterML field specifies a technology level to filter against; for example, 6100-03. If not specified, the value returned by oslevel -r on the local system will be used.
The following request type (RqType) values are obsolete and are no longer supported on AIX 7:
APAR Request to download an APAR.
Critical Request to download the latest critical fixes.
Security Request to download the latest security fixes.
Fileset Request to download a specific fileset.
Also, the field FilterSysFile that was once used to filter against the inventory of a running system is not supported on AIX 7.
The integration of SUMA and Electronic Customer Care has only been implemented on AIX 7 and not on any of the previous AIX releases. Nevertheless, SUMA on AIX 7 can be used to download AIX V5.3 TL 5300-06 and newer updates. AIX V5.3 TL 5300-06 was released in June 2007 and is the starting level of updates that are loaded into the eCC update repository.
The conversion of SUMA to use eCC instead of fixget has significant impact on the supported protocols utilized for fix server communication and to download updates. The following protocol-specific characteristics and changes are related to the relevant SUMA configuration parameters:
FIXSERVER_PROTOCOL
The FIXSERVER_PROTOCOL parameter specifies the protocol to be used for communication between the eCC Common Client and the eCC fix service provider as a part of the order request that SUMA will make to get the list of fixes. SUMA utilizes the Hypertext Transfer Protocol Secure (HTTPS) protocol since it is the only supported protocol for communication between the eCC Common Client and the IBM fix service provider. The only allowed value for this configuration setting is https. The http setting of previous AIX releases is no longer supported.
DOWNLOAD_PROTOCOL
The DOWNLOAD_PROTOCOL parameter specifies the protocol to be used for communication by the eCC Common Client for a download request from SUMA. SUMA takes advantage of the secure and multi-threaded Download Director Protocol (DDP) if the Hypertext Transfer Protocol (HTTP) has been configured. The HTTP protocol is specified by default and is recommended as eCC protocol for downloading updates. The related value for this configuration setting is http. The suma command can be used to modify the default configuration to use the HTTP Secure (HTTPS) protocol for downloads. But the related https setting restricts the secure downloads to single-threaded operations. The ftp setting of previous AIX releases is no longer supported.
Example 9-16 shows the suma -c command output on an AIX V7.1 TL 7100-00 system after a SUMA base configuration has been performed.
Example 9-16 SUMA default base configuration on AIX V7.1
7501lp01:/> suma -c
FIXSERVER_PROTOCOL=https
DOWNLOAD_PROTOCOL=http
DL_TIMEOUT_SEC=180
DL_RETRY=1
HTTP_PROXY=
HTTPS_PROXY=
SCREEN_VERBOSE=LVL_INFO
NOTIFY_VERBOSE=LVL_INFO
LOGFILE_VERBOSE=LVL_VERBOSE
MAXLOGSIZE_MB=1
REMOVE_CONFLICTING_UPDATES=yes
REMOVE_DUP_BASE_LEVELS=yes
REMOVE_SUPERSEDE=yes
TMPDIR=/var/suma/tmp
The SUMA-related eCC-specific base configuration properties are stored in the eccBase.properties file under the directory /var/suma/data. The initial version of the eccBase.properties file is installed as part of the bos.suma fileset. Example 9-17 shows the content of the eccBase.properties file after a SUMA default base configuration has been done on an AIX 7 system.
Example 9-17 eccBase.properties file after SUMA default base configuration
7501lp01:/> cat /var/suma/data/eccBase.properties
## ecc version: 1.0504
#Thu Apr 08 09:02:56 CDT 2010
DOWNLOAD_READ_TIMEOUT=180
INVENTORY_COLLECTION_CONFIG_DIR=/var/suma/data
DOWNLOAD_RETRY_WAIT_TIME=1
TRACE_LEVEL=SEVERE
DOWNLOAD_SET_NEW_DATE=TRUE
AUDITLOG_MAXSIZE_MB=2
CONNECTIVITY_CONFIG_DIR=/var/ecc/data
PLATFORM_EXTENSION_CLASS=com.ibm.esa.ea.tx.ecc.PlatformExtensions
TRACE_FILTER=com.ibm.ecc
WS_TRACE_LEVEL=OFF
AUDITLOG_COUNT=2
TRACELOG_MAXSIZE_MB=4
DOWNLOAD_MAX_RETRIES=3
LOG_DIR=/var/suma/log
RETRY_COUNT=1
DOWNLOAD_MONITOR_INTERVAL=10000
REQUEST_TIMEOUT=600
The CONNECTIVITY_CONFIG_DIR variable in the eccBase.properties file points to the directory where the connectivity configuration information is stored in the eccConnect.properties file. An initial version of this file is installed as part of the bos.ecc_client.rte fileset in the /var/ecc/data directory. The eccConnect.properties file connectivity configuration information is shared by SUMA, IBM Electronic Service Agent, and the Inventory Scout. This file holds the proxy server information if required for the service communication.
The proxy configuration task is supported by the SMIT panels that are dedicated to set up an AIX service configuration. System administrators can use the smit srv_conn fastpath to directly access the Create/Change Service Configuration menu. In this menu the Create/Change Primary Service Configuration selection will bring up the Create/Change Primary Service Configuration menu where the desired connection type can be configured.
The following three alternatives are available for the connection type: Not configured, Direct Internet, and HTTP_Proxy. For the connection type HTTP_Proxy selection you need to provide the IP address of the proxy server, the port number used, and an optional authentication user ID. Up to two additional service configurations (secondary, and tertiary) are supported to back up the primary connection in case of a failure. Note that the HTTP_PROXY selection in SMIT supports both HTTP_PROXY and HTTPS_PROXY if the customer proxy server is configured to support both http and https.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset