Overview

Additional documents of interest

Successful Business Continuity - Part 1 - Users and Groups
This article was published in the April 2005 issue of AIX Update magazine and discusses system administration needs and requirements oriented around users and groups. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters, such as user names, group names, UID and GID numbers.: This article was published in the April 2005 issue of AIX Update magazine and discusses system administration needs and requirements oriented around users and groups. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters, such as user names, group names, UID and GID numbers.
Successful Business Continuity - Part 2 - Machine and Host Names
This article was published in the May 2005 issue of AIX Update magazine and discusses naming structures for machines, systems, adapters, and aliases. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.: This article was published in the May 2005 issue of AIX Update magazine and discusses naming structures for machines, systems, adapters, and aliases. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.
Successful Business Continuity - Part 3 - Volume Names
This article was published in the December 2005 issue of AIX Update magazine and discusses naming structures for volume groups, logical volumes, log logical volumes, directory mount points, etc. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.: This article was published in the December 2005 issue of AIX Update magazine and discusses naming structures for volume groups, logical volumes, log logical volumes, directory mount points, etc. The overall emphasis of this series of articles is for implementation of enterprise wide unique identifiers for a variety of parameters.
Successful Business Continuity - Part 4 - MQ Series, Startup/Shutdown Scripts, Error Processing
This article was published in the April 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. The topic of this article is the assignment of MQ Series queue names and aliases, resource group startup and shutdown script names (Application startup/shutdown script names), error logging, and error notification.: This article was published in the April 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. The topic of this article is the assignment of MQ Series queue names and aliases, resource group startup and shutdown script names (Application startup/shutdown script names), error logging, and error notification.
Successful Business Continuity - Part 5 - Miscellaneous topics
This article was published in the August 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. A variety of topics is discussed in this article including automated documentation generation and management.: This article was published in the August 2006 issue of AIX Update magazine and discusses how to implement AIX in an environment dedicated to business continuity. A variety of topics is discussed in this article including automated documentation generation and management.
Automated Microcode Management System
One of the most difficult administration tasks in an AIX environment is attempting to keep the firmware and microcode up-to-date. Mt Xia has devised an automated method of gathering the Microcode information, determining which microcode needs to be updated, generating reports, and uploading the required microcode updates to each individual system.: One of the most difficult administration tasks in an AIX environment is attempting to keep the firmware and microcode up-to-date. Mt Xia has devised an automated method of gathering the Microcode information, determining which microcode needs to be updated, generating reports, and uploading the required microcode updates to each individual system.
Calculating the size of a Virtual Processor
This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation describes how to calculate CPU utilization, NOT how to size for configuration, this document clarifies this process. A description of the HMC input fields for the processor tab is included.: This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation describes how to calculate CPU utilization, NOT how to size for configuration, this document clarifies this process. A description of the HMC input fields for the processor tab is included.
Basics of Partition Load Manager Setup
This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup.
ppt

pdf: This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup.
ppt

pdf

Overview

Documentation
Virtual Processor Size
Overview

Policies

Frames
MicroCode
Storage
Hostname/Alias
HMC
VIO Server
PLM
LPAR
NIM
Resource Group
WLM AIX 433
WLM AIX 5
VG Name
LV Name
JFS Logs
FS Mt Point
User/UID
Group/GID
Security
HACMP
Installation
Monitoring
Patch Management
Tivoli TEC

Guidelines

Frames
MicroCode
Storage
Hostname/Alias
HMC
VIO Server
PLM
LPAR
NIM
Resource Group
WLM AIX 433
WLM AIX 5
VG Name
LV Name
JFS Logs
FS Mt Point
User/UID
Group/GID
Security
HACMP
Installation
Monitoring
Patch Management
Tivoli TEC

Standards

Frames
MicroCode
Storage
Hostname/Alias
HMC
VIO Server
PLM
LPAR
NIM
Resource Group
WLM AIX 433
WLM AIX 5
VG Name
LV Name
JFS Logs
FS Mt Point
User/UID
Group/GID
Security (DRAFT)
HACMP
Installation
Monitoring
Patch Management
Tivoli TEC

Procedures

Frames
Microcode
Storage
Hostname/Alias
HMC
VIO Server
PLM
LPAR
NIM
Resource Group
WLM AIX 433
WLM AIX 5
VG Name
LV Name
JFS Logs
FS Mt Point
User/UID
Group/GID
Security
HACMP
Installation
Monitoring
Patch Management
Tivoli TEC

viohdlm VIO HDLM Parms

Table of Contents

- Documentation

Consolidated view of policies, guidelines, standards and procedures

The documentation referenced here describes the policies, guidelines, standards and procedures for insuring business continuity for the business function supported using IBM's Power 5 architecture. This architecture supports the ability to provide capacity on-demand and virtual I/O. The ability to micro-partition using pieces of a processor and dynamically allocate and deallocate memory is supported in this environment as well.

The Power 5 architecture provides the ability to define LPAR's and Virtual LPAR's. The difference between an LPAR and a Virtual LPAR is the implementation of the virtualization features. The Power 5 architecture allows the sytem administrator to configure logical partitions with dedicated resources such as processors, memory, and I/O adapters. The system administrator may also configure logical partitions utilizing shared processors, memory, and virtualized I/O adapters. The virtual I/O adapters are configured and made available to the LPAR's via the VIO server. The VIO server provides the ability to reduce the number of adapters required to support multiple LPAR's by virtualizing the hardware and allowing multiple LPAR's to share the same hardware I/O adapters.

Additional documents of interest

Calculating the size of a Virtual Processor
This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation does not fully describe how the size of a virtual processor is determined, this document clarifies this process. A description of the HMC input fields for the processor tab is included.: This document describes the algorithms used to calculate the size of a virtual processor when using shared processors in an LPAR. The IBM documentation does not fully describe how the size of a virtual processor is determined, this document clarifies this process. A description of the HMC input fields for the processor tab is included.
Basics of Partition Load Manager Setup
This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup.
ppt

pdf: This presentation was provided by Ron Barker from IBM regarding the PLM Basic setup.
ppt

pdf

Table of Contents

- Virtual Processor Size

This document describes the algorithms used to calculate the size of a virtual processor in a shared processor environment using the Power5 architecture. The IBM documentation does not fully explain this concept and this document attempts to clarify this issue.

When defining an LPAR through the HMC for the Power5 architecture, the type of processors assigned to the LPAR must be defined. The possible choices for this are: Dedicated and Shared. If "Shared" is selected, the following input fields are presented:

When entering "shared" mode processors, the "Processing units" input fields define the total amount of processing units that will be allocated to all virtual processors. This translates to the following algorithm:

Algorithm:

V_s = P_u / V_n

Rules:

1.00 P_u = 1 full power5 physical processor P_u < P_t V_n <= 64

Variable Definitions:

V_s = Virtual processor size P_u = Physical processing units ( number of physical processors ) V_n = Number of virtual processors assigned to LPAR P_t = Total number of physical processors in frame

As an example of using this algorithm:

These values would allocate "0.5" physical processing units to the LPAR and "2" virtual processors. The size of each virtual processor would be "0.25" physical processing units.

Algorithm:

V_s = P_u / V_n V_s = 0.5 / 2 V_s = 0.25

Variable Definitions:

V_s = Virtual processor size P_u = Physical processing units ( number of physical processors ) V_n = Number of virtual processors assigned to LPAR

Another example using this algorithm:

These values would allocate "2.5" physical processing units to the LPAR and "5" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

Algorithm:

V_s = P_u / V_n V_s = 2.5 / 5 V_s = 0.50

Variable Definitions:

V_s = Virtual processor size P_u = Physical processing units ( number of physical processors ) V_n = Number of virtual processors assigned to LPAR

A final example illustrating how the EGATE Proof of Concept LPAR's were configured:

In this example, if the desired number of physical processing units was allocated to the LPAR, "3.0" physical processing units would be allocated to the LPAR and "6" virtual processors. The size of each virtual processor would be "0.50" physical processing units.

Algorithm:

V_s = P_u / V_n V_s = 3.0 / 6 V_s = 0.50

Variable Definitions:

V_s = Virtual processor size P_u = Physical processing units ( number of physical processors ) V_n = Number of virtual processors assigned to LPAR

Table of Contents

- Overview

Table of Contents

Policies

The policies described here are specific to the Power 5 LPAR environment.
Standards defined here will apply to LPAR's and Virtual LPAR's.
Each entity defined in this environment will be configured with an enterprise wide unique identifier so that it may be moved or reconfigured anywhere in the environment.
The Network Information Manager (NIM) is utilized for providing access to all operating system components.
The configuration and implementation of all components comprising each LPAR is documented with both hard and soft copies of the documentation.

Table of Contents

Policies - Frames

Frame Policies

All frames will be configured with redundant architecture for high availability. This includes power, network, and storage attachment.
Frame Maintenance windows (outages) will be scheduled quarterly at a minimum.
Each new Frame shall be entered into the Configuration Management Database (CMDB) upon installation.

Table of Contents

Policies - MicroCode

Microcode Policies

The microcode for all system components will be checked for newer revisions monthly and implemented quarterly. If revisions are available, they will be considered for implementation during the next available outage for a system. Recommendations for microcode implementation will be recorded in the system log.
IBM systems with release dates less than one year shall implement microcode as soon as possible after release.
IBM systems with release dates greater than one year shall implement microcode no newer than three months.

Table of Contents

Policies - Storage

Storage Policies

All disk storage shall be external to the system, including bootable volumes.
Only the operating system shall be stored in the "rootvg" volume group. All data and applications shall be stored separately from the "rootvg".
No striping, RAID, mirroring, etc shall be performed by the operating system. All storage management shall be performed by the external disk storage subsystem.
All disk storage will be accessible through redundant paths.
All Tier 1 applications shall be on core switches as opposed to edge switches.

Table of Contents

Policies - Hostname/Alias

Hostname Policies

Hostnames shall be enterprise wide unique identifiers.

Table of Contents

Policies - HMC

HMC Policies

Each frame introduced into the Mt Xia environment shall be managed by a Hardware Management Console (HMC).
Where a single HMC manages one or more systems for multiple customers, redundant HMC's will be implemented.

Table of Contents

Policies - VIO Server

Virtual I/O Server Policies

Redundant VIO servers shall be configured for each frame introduced into Mt Xia's environment. Each VIO server shall be configured with 50% of the frame's resources.

Table of Contents

Policies - PLM

Partition Load Manager Policies

CPU and memory resources for all application LPAR's will be managed by a Partition Load Manager (PLM).
At least one PLM shall be operational in each data center, with a policy file for each frame managed by the PLM.

Table of Contents

Policies - LPAR

Logical Partition Policies

Shared CPU and memory resources shall be configured for all new LPAR's.
Virtual SCSI and Ethernet adapters shall be configured for all non-production LPAR's. Virtualization of production LPAR's is dependent upon SLA tier and expected applicaiton load.
Initial minimum values shall be used for configuration of CPU and memory, adjustments will be controlled by the Partition Load Manager (PLM).
Each LPAR will be accessible through two networks, application and management.
Each LPAR will be accessible through the Mt Xia Administration network.

Table of Contents

Policies - NIM

Network Installation Manager Policies

At least one Network Installation Manager (NIM) Server shall be maintained in each data center.
All AIX and application installation processes shall be managed by the NIM server.
NIM servers shall be synchronized between data centers.
NIM servers shall always be maintained at the latest OS level to ensure functionality with all managed systems.
NIM servers shall have communication with all networks within a data center.

Table of Contents

Policies - Resource Group

Resource Group Name Policies

All system resources will be divided into logical resource groups, each resource group shall have an enterprise wide unique name. The resource group name shall be the basis of numerous naming structures and policies.
Resource groups will be defined for standalone and high availability systems. All systems will be designed as though they participate in a high availability environment, regardless of whether or not they actually do. This does not mean that all systems will have HACMP or other automated high availability software installed.
A centralized repository shall contain a list of all configured resource groups enterprise wide. New resource groups shall be entered into this repository.

Table of Contents

Policies - WLM AIX 433

Workload Manager for AIX 4.3.3.0 Policies

Workload Manager shall be implemented on all AIX systems, usually in passive mode. Active mode implementations of WLM will be dependent upon system, application, and administrative requirements.

Table of Contents

Policies - WLM AIX 5

Workload Manager for AIX Policies

Workload Manager shall be implemented on all AIX systems, usually in passive mode. Active mode implementations of WLM will be dependent upon system, application, and administrative requirements.

Table of Contents

Policies - VG Name

Volume Group Name Policies

All data and applications will be stored separately from the "rootvg" volume group. Additional volume groups will be configured as necessary.
Volume group names shall be enterprise wide unique values based on the resource group name.

Table of Contents

Policies - LV Name

Logical Volume Name Policies

Each logical volume shall have an enterprise wide unique name for the purpose of eliminating naming conflicts during manual, HACMP, or Disaster Recovery failovers.

Table of Contents

Policies - JFS Logs

JFS Log Logical Volume Name Policies

Each volume group that contains file systems will require at least one JFS log. The name of the JFS Log shall be an enterprise wide unique value.

Table of Contents

Policies - FS Mt Point

File System Mount Point Directory Name Policies

Every application filesystem shall have an enterprise wide unique mount point directory. The purpose is to eliminate conflicts during manual, HACMP, disaster recovery, or consolidation failovers.

Table of Contents

Policies - User/UID

User Name Policies

All individual users will have an enterprise wide unique user names.
Administration user names may be dictated by application requirements.
The UID number associated with each user name shall be an enterprise wide unique identifier.
LDAP shall be implemented as a centralized User/UID management system.

Table of Contents

Policies - Group/GID

Group Name Policies

Group names may be dictated by application requirements. The GID number associated with each group name shall be an enterprise wide unique identifier.
LDAP shall be implemented as a centralized Group/GID management system.

Table of Contents

Policies - Security

Security Policies

Each user shall be assigned an enterprise wide unique name.
Each user shall be assigned an enterprise wide unique UID number.
Each group shall be assigned an enterprise wide unique GID number.
Mt Xia Corporate security policy shall be observed and adhered to. This policy can be reviewed by contacting the Mt Xia security officer.
Internal security audits shall minimally be performed quarterly on all Unix Systems.
Administration passwords shall be changed according to Mt Xia's security standards.

Table of Contents

Policies - HACMP

HACMP Policies

HACMP shall be implemented for all production applications, between frames within a data center for availability, maintenance, and redundancy.

Table of Contents

Policies - Installation

Installation Policies

All installations of operating system or application components shall be performed using the Network Installation Manager (NIM).
All operating system or application components must be capable of remote installation without the use of original media.
Application installation requiring Administrator level access will be performed by system engineers.
All Operating Systems, Databases, and/or Applications shall be at a supported level by the vendor. A support contract must be active before implementation of any hardware, operating system, application or daatabase. The support contract must be maintained for the duration of the services provided by Mt Xia.
Current valid licenses shall be obtained and maintained for all software.
Each new LPAR shall be entered into the Configuration Management Database (CMDB) upon installation.

Table of Contents

Policies - Monitoring

Monitoring Policies

Each system shall be monitored by Tivoli TEC.
All systems will be monitored for Up/Down status.
All hardware shall be monitored for failures.
All filesystems will be monitored for full conditions.
Any custom monitors outside of Tivoli TEC should integrate their information into Tivoli TEC's alerting mechanism.
Automated documentation describing a systems configuration and status will be generated and stored on a centralized documentation server.

Table of Contents

Policies - Patch Management

Patch Management Policies

Microcode, AIX, and application updates will be analyzed quarterly and updates will be scheduled. Outages will be required and must be factored into the SLA's for all supported business functions. This includes production, test, and development.

Table of Contents

Policies - Tivoli TEC

Table of Contents

Guidelines

Guidelines define recommended practices in support of business continuity but not necessarily required practices.
The guidelines described here are specific to the Power 5 LPAR environment.
Guidelines defined here will apply to standalone, LPAR's, and Virtual LPAR's

Table of Contents

Guidelines - Frames

Frame Guidelines

Table of Contents

Guidelines - MicroCode

Microcode Guidelines

Even though it is policy that monthly checks be performed for microcode updates, that does not necessarily mean that microcode must be updated on a monthly basis. If after examining the microcode documentation, it is determined the revised microcode does not fix or enhance any significant features, then a recommendation may be made by the system engineer NOT to update the microcode.
Just because a microcode update is available, does not mean it must be implemented.
Inventory Scout should be used to perform the microcode analysis on a monthly basis whether performed via HMC or local to host.

Table of Contents

Guidelines - Storage

Storage Guidelines

External boot is for systems running AIX 5.2+

Table of Contents

Guidelines - Hostname/Alias

Hostname Guidelines

Users should NOT access application services via the hostname identifier. All access to application services should be provided through the use of aliases.

Table of Contents

Guidelines - HMC

HMC Guidelines

Table of Contents

Guidelines - VIO Server

Virtual I/O Server Guidelines

Resources dedicated to an LPAR may be excluded from the VIO Server.
WLM will be used to monitor/manage the VIO resources.

Table of Contents

Guidelines - PLM

Partition Load Manager Guidelines

The Partition Load Manager (PLM) Server should be a standalone machine dedicated for this purpose.
A secondary PLM should be implemented for each data center and contain the policy files from the primary PLM, ready to be activated.

Table of Contents

Guidelines - LPAR

Logical Partition Guidelines

CPU and Memory values may be augmented after installation based on software requirements.
I/O Adapters in production environments may be dedicated to an LPAR based on bandwidth requirements.

Table of Contents

Guidelines - NIM

Network Information Manager Guidelines

Alternate NIM master servers may be configured in each data center, but are not required.

Table of Contents

Guidelines - Resource Group

Resource Group Name Guidelines

Each system will host one or more resource groups.
There should be a unique DNS entry based on each resource group name. These names may or may not have unique associated IP addresses.

Table of Contents

Guidelines - WLM AIX 433

Workload Manager for AIX 4.3.3.0 Guidelines

Table of Contents

Guidelines - WLM AIX 5

Workload Manager for AIX 5L Guidelines

Table of Contents

Guidelines - VG Name

Volume Group Name Guidelines

Where possible, create volume groups with a unique major number.

Table of Contents

Guidelines - LV Name

Logical Volume Name Guidelines

The logical volume name should be based on the resource group name.

Table of Contents

Guidelines - JFS Logs

JFS Log Logical Volume Name Guidelines

More than one JFS log may be configured for a volume group if necessary, dependent upon filesystem load.

Table of Contents

Guidelines - FS Mt Point

File System Mount Point Directory Name Guidelines

In order to ensure successful installation of an application into unique mount points, the application team must work closely with the system engineer.

Table of Contents

Guidelines - User/UID

User Name Guidelines

Administrators usually have a user name structure different than normal users, so they are easily identifiable.

Table of Contents

Guidelines - Group/GID

Group Name Guidelines

Table of Contents

Guidelines - Security

Security Guidelines

Where possible all users should be managed by LDAP.
Each client or business unit should have independent organizational units within LDAP.

Table of Contents

Guidelines - HACMP

HACMP Guidelines

Table of Contents

Guidelines - Installation

Installation Guidelines

New installations should be updated to the latest level.
Multiple installation should be performed via mksysb from the NIM server.
The 64 bit AIX OS should be installed wherever possible.

Table of Contents

Guidelines - Monitoring

Monitoring Guidelines

Application monitoring will be provided by application teams to Tivoli TEC.
Filesystem monitors (other than root filesystems) will be based on applicaiton requirements.

Table of Contents

Guidelines - Patch Management

Patch Management Guidelines

Microcode, AIX, and application updates will be evaluated for installation, but updates are not necessary required.
As a minimum, the system should be rebooted on a quarterly basis.

Table of Contents

Guidelines - Tivoli TEC

Table of Contents

Standards

This document references the standards implemented by Mt Xia to ensure business continuity for all business functions implemented on the AIX Power 5 architecture. Many of these standards are not specific to the Power5 architecture but are intended as enterprise wide standards for all AIX systems.

These standards have been developed over many years of supporting standalone, high availability, and disaster recovery environments. The purpose of these standards is to ensure business continuity during normal system maintenance, planned and unplanned outages, hardware and software failures, network and communication failures, and/or a disaster recovery implementation.

A design aspect of these standards is they can be implemented in a standalone, high availability, or disaster recovery scenario. Recognize that there are not multiple standards, one for each scenario, there is one single standard that is portable across all scenario's. This reduces support and training costs, and increases efficiency, supportability, recoverability, and availability.

Some of the basic concepts of these standards:

Business functions are not tied to a specific machine.
Hardware resources can be shared or distributed among associated business functions.
Any system can act as a failover for any other system.
Any data center can act as a disaster recovery site for any other data center.

Table of Contents

Standards - Frames

Frame Standards

A Frame is the Entire system that houses LPARS. A P590 is a frame as well as a 6M2. Frame Names will consist of the Model and Serial number: - e.g. p590-51A432A

Table of Contents

Standards - MicroCode

Microcode Management

Systems without an HMC

Use IBM's Microcode Discovery Service at the following URL to determine what microcode should be updated, to retrieve the microcode, and the instructions for installing the microcode.

https://techsupport.services.ibm.com/server/aix.invscoutMDS

Normally the "java applet" is used to peform the microcode discovery which requires the password for the user "invscout" to be set. This also requires internet communication from the system over port 808. To use the java applet perform the following steps on the target system:

Set the password for the user "invscout"

passwd invscout

Clear the password administration flags on the user "invscout"
pwdadm -c invscout
Start the "invscout" daemon
invscoutd
The system is now ready for microcode discovery via the java applet
The microcode discovery service will require several pieces of information to be able to perform the survey:
- Fully qualified hostname of the system
- Password for the user "invscout"
- Port number (default: 808)
- System Model Number
  lsattr -El sys0 -a modelname -F value
- System Serial Number
  lsattr -El sys0 -a systemid -F value

Systems with an HMC

Use the facilities built into the HMC for performing microcode updates to all managed systems.

Table of Contents

Standards - Storage

Storage Standards

All operating system, application, and data storage in the Mt Xia environment shall be configured external to the system. The purpose of this is to increase the recoverability of the system, reduce hardware related outages, and to centralize the management of storage.

All systems will have multiple hardware paths to the storage, those paths may be physical or virtual.

Multiple volume groups shall be created in the AIX environment. The operating system volume group, called "rootvg", will contain only operating system related applications and files. The "rootvg" will contain a minimum amount of storage.

The standard "rootvg" will contain a single 9 GB disk that exists on the SAN and is mirrored by the SAN environment. Multiple paths to the "rootvg" disk are configured using IBM's Multi-Path I/O (MPIO) device driver. Optionally, the "rootvg" may have an "alt_disk" that exists on internal storage. The "alt_disk" is used to perform Operating System updates.

All non-operating system related programs and data will be stored in volume groups other than "rootvg". The Volume group names will be created in accordance with Mt Xia's VG naming standards and will contain storage as required by the supported business function.

All non-rootvg volume groups residing on Hitachi SAN based storage will utilize the latest HDLM driver and multiple hardware paths to the SAN. The HDLM driver is updated on a regular basis.

Further information regarding Mt Xia's storage standards can be obtained from the following document: Unix-Storage-Presentation.pdf

Table of Contents

Standards - Hostname/Alias

Hostname Standards

In order to achieve maximum flexibility during normal operations, maintenance, disaster recovery, and business continuity efforts, it is important to provide a naming standard for business functions that can be translated easily into hostnames and/or aliases. The purpose of using hostnames instead of IP addresses is that they are easier to remember and use. Hostnames are not necessary, but usually desirable.

Normal user access to an application or business function will always be through an alias. Normal users should never access a system using a hostname. The reason is for portability and availability. It is easy to redirect an alias to any host, it is significantly more difficult to change hostnames. By having the users access required services through aliases rather than hostnames, the users can be redirected quickly to available services in the event of a failure.

Hostnames

In Mt Xia's environment, a hostname refers to an IP address, the IP address is associated with one or more network adapters. It is important to recognize that an IP address is not necessarily tied to a network adapter, but may float across adapters and machines. The same is true with the hostnames. A hostname should be viewed as being independent from any machine or data center. The hostname shall be an enterprise wide unique value in order to eliminate conflicts during manual, automated, or disaster recovery failovers.

The hostname shall consist of exactly 10 characters with the following structure:

LocationCode + OS Type + Environment + ApplicationCode + SequenceID
   3 char    + 1 char  +    1 char   +      3 char     +   2 char   =  10 char

The detailed information for each component of the resource group name is described below:

HostName
Component Number of
Characters Values

Location Code 3 dal = Dallas Data Center bos = Boston Data Center

OS Type 1 a = AIX s = Sun

Environment 1 a = acceptance a = pre-production d = test/development p = production t = test x = disaster recovery x = pre-production

Application Code 3 atl = Atlas ega = EGATE nim = NIM ora = Oracle tps = Maximo vio = Virtual I/O

Sequence ID 2 0-9,A-Z,a-z

Examples of Hostnames (HN):

dalapega01
EGATE Production database on AIX at Dallas Data Center, first instance: EGATE Production database on AIX at Dallas Data Center, first instance
dalapega01
EGATE Production database on AIX at Dallas Data Center, second instance: EGATE Production database on AIX at Dallas Data Center, second instance
bosapnim01
Production Network Information Manager on AIX at Boston Data Center, first instance: Production Network Information Manager on AIX at Boston Data Center, first instance
dalapnim01
Production Network Information Manager on AIX at Dallas Data Center, first instance: Production Network Information Manager on AIX at Dallas Data Center, first instance
bosapvio01
Production Virtual I/O Server on AIX at Boston Data Center, first instance: Production Virtual I/O Server on AIX at Boston Data Center, first instance
bosapvio02
Production Virtual I/O Server on AIX at Boston Data Center, second instance: Production Virtual I/O Server on AIX at Boston Data Center, second instance
bosapvio03
Production Virtual I/O Server on AIX at Boston Data Center, third instance: Production Virtual I/O Server on AIX at Boston Data Center, third instance
bosapvio04
Production Virtual I/O Server on AIX at Boston Data Center, fourth instance: Production Virtual I/O Server on AIX at Boston Data Center, fourth instance
dalaavio01
Acceptance Virtual I/O Server on AIX at Dallas Data Center, first instance: Acceptance Virtual I/O Server on AIX at Dallas Data Center, first instance
dalaavio02
Acceptance Virtual I/O Server on AIX at Dallas Data Center, second instance: Acceptance Virtual I/O Server on AIX at Dallas Data Center, second instance
dalaavio03
Acceptance Virtual I/O Server on AIX at Dallas Data Center, third instance: Acceptance Virtual I/O Server on AIX at Dallas Data Center, third instance
dalaavio04
Acceptance Virtual I/O Server on AIX at Dallas Data Center, fourth instance: Acceptance Virtual I/O Server on AIX at Dallas Data Center, fourth instance

Aliases

The rules for defining alias names are significantly less rigid than for hostnames. The alias can be any name as long as it is unique within the domain. This allows the application to be accessed though a name that makes logical sense to the user. For example, the production EGATE Application Server at the Dallas Data Center may have a hostname of "bosapega03", however the alias may be "bosegate". The use of aliases preserves the structure needed for hostnames and the ease of use desired by users.

Table of Contents

Standards - HMC

HMC Standards

Contained here are the standards for defining new LPAR's in the Power5 architecture environment using the Hardware Management Console. These standards describe the information required to define the LPAR's and the format in which this information should be presented.

This environment utilizes the VIO server to virtualize the hardware I/O adapters to client LPAR's, thus allowing multiple LPAR's to share resources. Implementation of this type of environment requires extensive up-front design work and planning. Each hardware adapter must be identified to the VIO server and virtualized for use by each client LPAR.

To begin configuring this environment, build a spreadsheet to contain all frame and I/O adapter information, this spreadsheet should contain at least the following:

Frame Type:

Frame S/N:

System Name:

CPUs

RAM (GB)

CUoD CPUs

CUoD RAM (GB)

Drawer Serial Bus Slot Adapter LPAR

Much of this information can be automatically generated using the script "hmcparse.ksh". Example results from this script follow:

Server9119590SN51A432B

Drawer Serial Bus Slot Adapter LPAR

U5791.001.91800WT-P1 13 T6 SCSI bus controller dalapvio01

U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus dalpocdb01

U5791.001.91800WT-P1 13 C09 Empty slot

U5791.001.91800WT-P1 13 C10 Empty slot

U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WT-P1 15 T5 SCSI bus controller dalapvio01

U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P1 15 C07 Empty slot

U5791.001.91800WT-P2 19 T6 SCSI bus controller dalapvio01

U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P2 19 C09 Empty slot

U5791.001.91800WT-P2 19 C10 Other Communications Device

U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 21 T5 SCSI bus controller dalapvio01

U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P2 21 C07 Empty slot

U5791.001.91800WW-P1 10 T6 SCSI bus controller dalapvio02

U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus dalpocdb01

U5791.001.91800WW-P1 10 C09 Empty slot

U5791.001.91800WW-P1 10 C10 Storage controller dalapvio01

U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 12 T5 SCSI bus controller dalapvio02

U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P1 12 C07 Empty slot

U5791.001.91800WW-P2 16 T6 SCSI bus controller dalapvio02

U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P2 16 C09 Empty slot

U5791.001.91800WW-P2 16 C10 Other Communications Device

U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WW-P2 18 T5 SCSI bus controller dalapvio02

U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P2 18 C07 Empty slot

U5791.001.91800WT-P1 13 T6 SCSI bus controller dalapvio01

U5791.001.91800WT-P1 13 C08 Fibre Channel Serial Bus dalpocdb01

U5791.001.91800WT-P1 13 C09 Empty slot

U5791.001.91800WT-P1 13 C10 Empty slot

U5791.001.91800WT-P1 14 C01 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WT-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WT-P1 15 T5 SCSI bus controller dalapvio01

U5791.001.91800WT-P1 15 C05 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P1 15 C06 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P1 15 C07 Empty slot

U5791.001.91800WT-P2 19 T6 SCSI bus controller dalapvio01

U5791.001.91800WT-P2 19 C08 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P2 19 C09 Empty slot

U5791.001.91800WT-P2 19 C10 Other Communications Device

U5791.001.91800WT-P2 20 C01 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio01

U5791.001.91800WT-P2 21 T5 SCSI bus controller dalapvio01

U5791.001.91800WT-P2 21 C05 PCI 1Gbps Ethernet dalapvio01

U5791.001.91800WT-P2 21 C06 Fibre Channel Serial Bus dalapvio01

U5791.001.91800WT-P2 21 C07 Empty slot

U5791.001.91800WW-P1 10 T6 SCSI bus controller dalapvio02

U5791.001.91800WW-P1 10 C08 Fibre Channel Serial Bus dalpocdb01

U5791.001.91800WW-P1 10 C09 Empty slot

U5791.001.91800WW-P1 10 C10 Storage controller dalapvio01

U5791.001.91800WW-P1 11 C01 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P1 12 T5 SCSI bus controller dalapvio02

U5791.001.91800WW-P1 12 C05 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P1 12 C06 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P1 12 C07 Empty slot

U5791.001.91800WW-P2 16 T6 SCSI bus controller dalapvio02

U5791.001.91800WW-P2 16 C08 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P2 16 C09 Empty slot

U5791.001.91800WW-P2 16 C10 Other Communications Device

U5791.001.91800WW-P2 17 C01 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WW-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WW-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio02

U5791.001.91800WW-P2 18 T5 SCSI bus controller dalapvio02

U5791.001.91800WW-P2 18 C05 PCI 1Gbps Ethernet dalapvio02

U5791.001.91800WW-P2 18 C06 Fibre Channel Serial Bus dalapvio02

U5791.001.91800WW-P2 18 C07 Empty slot

Server9119590SN51A432C

Drawer Serial Bus Slot Adapter LPAR

U5791.001.91800WR-P1 13 T6 SCSI bus controller dalapvio04

U5791.001.91800WR-P1 13 C08 Fibre Channel Serial Bus dalpocdb02

U5791.001.91800WR-P1 13 C09 Empty slot

U5791.001.91800WR-P1 13 C10 Empty slot

U5791.001.91800WR-P1 14 C01 PCI 1Gbps Ethernet dalapvio04

U5791.001.91800WR-P1 14 C02 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WR-P1 14 C03 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WR-P1 14 C04 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WR-P1 15 T5 SCSI bus controller dalapvio04

U5791.001.91800WR-P1 15 C05 PCI 1Gbps Ethernet dalapvio04

U5791.001.91800WR-P1 15 C06 Fibre Channel Serial Bus dalapvio04

U5791.001.91800WR-P1 15 C07 Empty slot

U5791.001.91800WR-P2 19 T6 SCSI bus controller dalapvio04

U5791.001.91800WR-P2 19 C08 Fibre Channel Serial Bus dalapvio04

U5791.001.91800WR-P2 19 C09 Empty slot

U5791.001.91800WR-P2 19 C10 Other Communications Device

U5791.001.91800WR-P2 20 C01 PCI 1Gbps Ethernet dalapvio04

U5791.001.91800WR-P2 20 C02 PCI 10/100Mbps Ethernet w/ IPSec

U5791.001.91800WR-P2 20 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio04

U5791.001.91800WR-P2 20 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio04

U5791.001.91800WR-P2 21 T5 SCSI bus controller dalapvio04

U5791.001.91800WR-P2 21 C05 PCI 1Gbps Ethernet dalapvio04

U5791.001.91800WR-P2 21 C06 Fibre Channel Serial Bus dalapvio04

U5791.001.91800WR-P2 21 C07 Empty slot

U5791.001.91800WY-P1 10 T6 SCSI bus controller dalapvio03

U5791.001.91800WY-P1 10 C08 Fibre Channel Serial Bus dalpocdb02

U5791.001.91800WY-P1 10 C09 Empty slot

U5791.001.91800WY-P1 10 C10 Storage controller dalapvio03

U5791.001.91800WY-P1 11 C01 PCI 1Gbps Ethernet dalapvio03

U5791.001.91800WY-P1 11 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio04

U5791.001.91800WY-P1 11 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio03

U5791.001.91800WY-P1 11 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio04

U5791.001.91800WY-P1 12 T5 SCSI bus controller dalapvio03

U5791.001.91800WY-P1 12 C05 PCI 1Gbps Ethernet dalapvio03

U5791.001.91800WY-P1 12 C06 Fibre Channel Serial Bus dalapvio03

U5791.001.91800WY-P1 12 C07 Empty slot

U5791.001.91800WY-P2 16 T6 SCSI bus controller dalapvio03

U5791.001.91800WY-P2 16 C08 Fibre Channel Serial Bus dalapvio03

U5791.001.91800WY-P2 16 C09 Empty slot

U5791.001.91800WY-P2 16 C10 Other Communications Device

U5791.001.91800WY-P2 17 C01 PCI 1Gbps Ethernet dalapvio03

U5791.001.91800WY-P2 17 C02 PCI 10/100Mbps Ethernet w/ IPSec dalapvio03

U5791.001.91800WY-P2 17 C03 PCI 10/100Mbps Ethernet w/ IPSec dalapvio03

U5791.001.91800WY-P2 17 C04 PCI 10/100Mbps Ethernet w/ IPSec dalapvio03

U5791.001.91800WY-P2 18 T5 SCSI bus controller dalapvio03

U5791.001.91800WY-P2 18 C05 PCI 1Gbps Ethernet dalapvio03

U5791.001.91800WY-P2 18 C06 Fibre Channel Serial Bus dalapvio03

U5791.001.91800WY-P2 18 C07 Empty slot

Server9119590SN51A432B

Configuring Virtual Ethernet Adapters

Configuring virtual ethernet adapters for use in Mt Xia's high availability environment requires configuration of multiple server side ethernet adapters as well as multiple client side adapters. Each VIO server will have one server side ethernet adapter that can be shared to all client LPAR's requiring virtual ethernet adapters.

This document describes a standard for establishing virtual ethernet adapters in the VIO Server environment. This standard is specific to the numbering scheme used to identify the VLAN ID's of the virtual ethernet adapters. The VLAN ID number is also referred to in the HMC as the PVID number.

This document assumes there are two VIO servers in the environment and the names of the VIO servers are represented by "*vio0" and "*vio5".

The VLAN ID numbers will be three digit numbers, each digit representing a different aspect of the underlying ethernet adapter.

3 Digit VLAN ID Number
First Digit Second Digit Third Digit

5: Boot/Service
6: Standby
7: Backup
8: Management
9: Intra-Frame 0: Gigabit
5: 10/100
9: Bus 0,2,4,6,8: VIO Server with even numbered hostnames
1,3,5,7,9: VIO Server with odd numberd hostnames

The first digit of the VLAN ID numbers associated with virtual ethernet adapters will be used to represent a variety of adapter purposes. Those purposes include boot, standby, backup, management, and intra-frame communications.

500-599: boot/service
600-699: standby
700-799: backup
800-899: management
900-999: intra-frame

The third digit of the three digit VLAN ID number assigned to virtual ethernet adapters associated with the VIO Server named *vio0 will end with a number between 0 and 4.

Example: 500, 501, 502, 510, 520, 521, ...

The VLAN ID numbers assigned to virtual ethernet adapters associated with the VIO Server named *vio5 will end with an odd number beginning at 5.

Example: 505, 506, 507, 515, 525, 526, ...

The second digit of the three digit VLAN ID sequence will represent the adapter speed, gigabit cards will be represented by 0 thru 4, 10/100 adapters by 5 thru 8, and bus speed adapters by a 9. This digit may be reconfigured as necessary.

Examples:

Adapter Speed
VLAN ID Adapter Type Adapter Speed VIO Server

500 Boot 0 Gigabit *vio0

501 Boot 1 Gigabit *vio0

505 Boot 0 Gigabit *vio5

506 Boot 1 Gigabit *vio5

550 Boot 0 10/100 *vio0

551 Boot 1 10/100 *vio0

555 Boot 0 10/100 *vio5

556 Boot 1 10/100 *vio5

590 Boot 0 Bus *vio0

591 Boot 0 Bus *vio0

595 Boot 0 Bus *vio5

596 Boot 1 Bus *vio5

An LPAR may have multiple adapters of a variety of types, for example an LPAR that provides database services and is a member of an HACMP cluster may have boot, standby, management, backup, and intra-frame virtual adapters as follows:

Gigabit adapter used for boot/service address
Gigabit adapter used for standby address
10/100 backup adapter
10/100 management adapter
2 intra-frame adapters

VIO Server Configuration:
VLAN ID Adapter Type Adapter Speed VIO Server

500 Boot Gigabit *vio0

600 Standby Gigabit *vio0

750 Backup 10/100 *vio0

850 Management 10/100 *vio0

990 Intra-frame Bus *vio0

991 Intra-frame Bus *vio0

505 Boot Gigabit *vio5

605 Standby Gigabit *vio5

755 Backup 10/100 *vio5

855 Management 10/100 *vio5

995 Intra-frame Bus *vio5

996 Intra-frame Bus *vio5

LPAR VLAN ID configuration to utilize virtual adapters:
VLAN ID Adapter Type Adapter Speed VIO Server

500 Boot Gigabit *vio0

505 Boot Gigabit *vio5

600 Standby Gigabit *vio0

605 Standby Gigabit *vio5

750 Backup 10/100 *vio0

755 Backup 10/100 *vio5

850 Management 10/100 *vio0

855 Management 10/100 *vio5

990 Intra-frame Bus *vio0

991 Intra-frame Bus *vio0

995 Intra-frame Bus *vio5

996 Intra-frame Bus *vio5

This virtual ethernet information can be automatically gathered from an existing frame through the HMC using the script "virtualeth.ksh. Example output from this script follows:

Server9119590SN51A432B

Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name

server 10 1 595 12F3F000200A dalapvio01

server 20 1 593 12F3F0002014 dalapvio01

server 15 1 594 12F3F000300F dalapvio02

server 25 1 592 12F3F0003019 dalapvio02

client 10 0 595 12F3F000500A dalpocap01

client 15 0 594 12F3F000500F dalpocap01

client 20 0 593 12F3F0005014 dalpocap01

client 25 0 592 12F3F0005019 dalpocap01

client 10 0 595 12F3F000600A dalpocap02

client 15 0 594 12F3F000600F dalpocap02

client 20 0 593 12F3F0006014 dalpocap02

client 25 0 592 12F3F0006019 dalpocap02

client 10 0 595 12F3F000700A dalpocap03

client 15 0 594 12F3F000700F dalpocap03

client 20 0 593 12F3F0007014 dalpocap03

client 25 0 592 12F3F0007019 dalpocap03

client 10 0 595 12F3F000400A dalpocdb01

client 15 0 594 12F3F000400F dalpocdb01

client 20 0 593 12F3F0004014 dalpocdb01

client 25 0 592 12F3F0004019 dalpocdb01

Server9119590SN51A432C

Adapter Type Slot Trunk Device Port Virtual LAN ID MAC Address LPAR Name

client 520 0 520 EE9530001208 dalapplm73

client 525 0 525 EE953000120D dalapplm73

server 10 1 510 EE953000300A dalapvio03

server 20 1 520 EE9530003014 dalapvio03

server 15 1 515 EE953000400F dalapvio04

server 25 1 525 EE9530004019 dalapvio04

client 10 0 510 EE953000500A dalpocdb02

client 15 0 515 EE953000500F dalpocdb02

client 20 0 520 EE9530005014 dalpocdb02

client 25 0 525 EE9530005019 dalpocdb02

Configuring Virtual SCSI Adapters

Configuration of the virtual I/O adapters requires the knowledge of disk layouts as well as networking configuration. The virtual SCSI adapters require server and client side adapters to be configured on the HMC. The server side portion of the SCSI adapter, configured on the VIO, requires a frame wide unique "slot number" be defined. For high availability a server side portion of the SCSI adapter must be configured for each VIO server. This means that each virtual disk or logical volume connection is associated with two server side SCSI adapters, one on each VIO server. By convention the standard has become that each SCSI adapter is numbered as a multiple of 10, with the first SCSI adapter of the server side high availability pair being configured on the first VIO server and ending with the number 0, i.e., 210, 220, 230, 240, ... The second SCSI adapter of the server side high availability pair is configured on the second VIO server and ends with the number 5, i.e., 215, 225, 235, 245, ...

For each LPAR that uses virtual disk or logical volumes, a client side virtual SCSI adapter must be configured on the HMC. The client side of the virtual SCSI adapter requires additional information and it's settings to correspond with the server side of the SCSI adapter. Coordination of the slot numbers defined here will make debugging and tracking of problems much easier and is highly desired. The information required to configure a client side SCSI adapter includes slot number, the name of the server side SCSI adapter remote partition, and the slot number of the server side SCSI adapter on the remote partition. The client side slot number should correspond with the server side slot number to make debugging and tracking easier. As an example of defining both server and client side SCSI adapters in a high availability environment:

For each LPAR, a pair of virtual SCSI adapters shall be configured to be used for attachment of the operating system and paging disks. Another pair of virtual SCSI adapters shall be configured for the purpose of application disk attachment. The virtual SCSI adapters designated for use as operating system disk attachment shall be numbered between 10 and 199. The virtual SCSI adapters designated for use as application disk attachment shall be numbered between 200 and 499.

Using this standard, each VIO server will have one virtual SCSI adapter per LPAR for the operating system, and one virtual SCSI adapter per LPAR for the application storage. Each LPAR will reference two virtual SCSI adapters, one from each VIO server, for the operating system storage, and two virtual SCSI adapters, one from each VIO server, for the application storage. Examples of this is shown below.

Example Virtual SCSI Slot Numbers
LPAR VIO 0
OS Slot VIO 1
OS Slot VIO 0
Appl Slot VIO 1
Appl Slot

daladcal01 10 15 200 205

daladfim03 20 25 210 215

daladesp01 30 35 220 225

dalapega01 40 45 230 235

dalaaora02 50 55 240 245

Each virtual SCSI adapter may have one or more disks with it, depending upon the LPAR requirements. These disk associations are performed on the VIO server by referencing the slot numbers assigned to each LPAR.

This virtual SCSI adapter information can be automatically gathered from an existing frame through the HMC using the script "virtualscsi.ksh. Example output from this script follows:

Server9119590SN51A432B

Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name

server 100 any 0x8100000000000000//ap01rootlv dalapvio01

server 110 any 0x8100000000000000//ap02rootlv dalapvio01

server 120 any 0x8100000000000000//ap03rootlv dalapvio01

server 130 any 0x8100000000000000//db01rootlv dalapvio01

server 150 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L1000000000000/hdisk5 dalapvio01

server 160 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L2000000000000/hdisk6 dalapvio01

server 170 any 0x8100000000000000/U5791.001.91800WT-P1-C06-T1-W50060E8003334713-L3000000000000/hdisk7 dalapvio01

client 190 dalapvio01 190 none dalpocdb01

server 30 any 0x8100000000000000//pocap01lv dalapvio01

server 40 any 0x8100000000000000//pocap02lv dalapvio01

server 50 any 0x8100000000000000//pocap03lv dalapvio01

server 60 any 0x8100000000000000//pocdb01lv dalapvio01

server 105 any // dalapvio02

server 115 any // dalapvio02

server 125 any // dalapvio02

server 135 any // dalapvio02

server 155 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L1000000000000/hdisk5 dalapvio02

server 165 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L2000000000000/hdisk6 dalapvio02

server 175 any 0x8100000000000000/U5791.001.91800WW-P1-C06-T1-W50060E8003334703-L3000000000000/hdisk7 dalapvio02

client 195 dalapvio02 195 none dalpocdb01

server 35 any 0x8100000000000000//pocap01lv dalapvio02

server 45 any 0x8100000000000000//pocap02lv dalapvio02

server 55 any 0x8100000000000000//pocap03lv dalapvio02

server 65 any 0x8100000000000000//pocdb01lv dalapvio02

client 2 dalapvio01 60 none dalpocdb01

client 3 dalapvio02 65 none dalpocdb01

client 4 dalapvio01 130 none dalpocdb01

client 5 dalapvio01 170 none dalpocap03

client 6 dalapvio02 175 none dalpocap03

client 2 dalapvio01 60 none dalpocdb01

client 3 dalapvio02 65 none dalpocdb01

client 4 dalapvio01 130 none dalpocdb01

client 5 dalapvio01 170 none dalpocap03

client 6 dalapvio02 175 none dalpocap03

client 2 dalapvio01 60 none dalpocdb01

client 3 dalapvio02 65 none dalpocdb01

client 4 dalapvio01 130 none dalpocdb01

client 5 dalapvio01 170 none dalpocap03

client 6 dalapvio02 175 none dalpocap03

client 190 dalapvio01 190 none dalpocdb01

client 195 dalapvio02 195 none dalpocdb01

client 2 dalapvio01 60 none dalpocdb01

client 3 dalapvio02 65 none dalpocdb01

client 4 dalapvio01 130 none dalpocdb01

Server9119590SN51A432C

Adapter Type Slot Remote LPAR Remote Slot Backing Device LPAR Name

server 140 any 0x8100000000000000//s32Cplmrootlv dalapvio03

server 145 any 0x8100000000000000//i32Cplmrootlv dalapvio04

server 130 any 0x8100000000000000//sdb02rootlv dalapvio03

server 140 any 0x8100000000000000//s32Cplmrootlv dalapvio03

client 190 dalapvio03 190 none dalpocdb02

server 145 any 0x8100000000000000//i32Cplmrootlv dalapvio04

client 195 dalapvio04 195 none dalpocdb02

server 65 any 0x8100000000000000//db02rootlv dalapvio04

client 190 dalapvio03 190 none dalpocdb02

client 195 dalapvio04 195 none dalpocdb02

client 2 dalapvio04 65 none dalpocdb02

client 3 dalapvio03 130 none dalpocdb02

Table of Contents

Standards - VIO Server

Virtual I/O Server Standards

Defined here are the standards that describe how a Virtual I/O (VIO) server will be configured in the Mt Xia environment. The purpose of these standards is to ensure business continuity, disaster recovery, high availability, serviceability, managability, and supportability of the virtualized environment.

Procedure to enable centralized statistics gathering from a VIO server via WLM

The Virtual I/O (VIO) servers should not have extraneous software installed on them, therefore the performance toolbox software is not installed or enabled. However the Workload Manager (WLM) is installed and should be enabled in passive mode. The procedure to enable WLM on the VIO servers follows:

This procedure assumes there is a centralized storage location for the WLM statistics shared to the VIO server via NFS. In the following example the centralized storage is located on the NIM server whose hostname is "dalapnim01". The specific directory being shared via NFS from "dalapnim01" is "/prfdmce0".

This procedure also uses an example VIO server hostname of "daladvio01".

Establish the NFS mount from the centralized NFS storage location.

/usr/sbin/mknfsmnt -f /prfdmce0 -d /prfdmce0 -h dalapnim01-mc2 -M sys -t rw -w bg -ABSXYZ -jqg

Add a directory to the centralized NFS storage location to contain the statistics files from the VIO server.

mkdir -p /prfdmce0/ddadvio01/wlm

Add a record line to "/etc/inittab" to start the WLM statistics gathering daemon

mkitab 'ptxwlm:2:respawn:/usr/bin/xmwlm -d /prfdmce0/daladvio01/wlm -n xmwlm > /dev/null 2>&1'

Start the WLM in "passive" mode.

/usr/sbin/wlmcntrl -p > /dev/console 2>&1

Add a record to the "/etc/inittab" to start the WLM at system boot time.

mkitab -i rc 'wlm:2:once:/usr/sbin/wlmcntrl -p > /dev/console 2>&1'

Table of Contents

Standards - PLM

Partition Load Manager Standards

The Partition Load Manager (PLM) provides CPU and memory resource management and monitoring across logical partitions (LPARs). Partition Load Manager allows you to effectively use CPU and Memory resources by allowing you to set thresholds for designated resources. When a threshold is exceeded, Partition Load Manager can try to assign CPU and/or Memory resources to that LPAR by using resources assigned to other LPARs that are not being used.

Determining which node is more or less deserving of resources is primarily done by taking into account certain values defined in what is known as a policy file. This policy file details partitions, their entitlements, their thresholds, and organizes the partitions into groups. Every node, but not every LPAR, managed by Partition Load Manager must be defined in the policy file along with several associated attribute values. Some of the attributes that are associated with the node are the maximum, minimum, and guaranteed resource values, variable share values, and so on. These are the attributes taken into consideration by Partition Load Manager when a decision is made as to whether a resource is reallocated from one LPAR to another.

PLM is an automated mechanism for utilizing the Dynamic LPAR (DLPAR) capabilities of the HMC and requires communication with the HMC. This means that before PLM will function, DLPAR must be functional on the HMC. DLPAR requires communication with each LPAR via the Resource Monitoring and Control (RMC) subsystem.

NOTE: The RMC subsystem is not installed when the AIX operating system is installed from the NIM server as an "rte" install.

The following fileset must be installed on every PLM client LPAR to enable RMC communications with the HMC and PLM:

csm.client

The PLM communications are also dependent upon SSH and SSL and must be installed on every PLM client LPAR.

Refer to the PLM configuration procedures for more information

A single PLM server can manage multiple frames across multiple HMC's. In the Mt Xia environment there is a single primary PLM in each data center. Within a frame there are two classifications of CPU's, dedicated and shared. Policy files are used by the PLM to control each frame and a single policy file will exist for each frame. The policy file is named for the serial number of each frame. When new frames are added to Mt Xia's environment, a policy file will be created on the PLM and the name of the policy file will be the serial number of the frame. Policy files currently exist with names such as:

107CE4E - p520 - Warner Home Video
10F6BEE - p570 - Warner Home Video
51A432B - p590 - Mt Xia
51A432C - p590 - Mt Xia

Every LPAR created in the Mt Xia environment will be managed by a PLM and will be initially assigned a minimum amount of CPU and memory resources. This means there will be a policy file on the PLM for every frame in the data center where the PLM exists.

Within a PLM policy there are two groups to represent the two CPU classifications, dedicated and shared. Each LPAR will be assigned to one of these two groups, depending upon what type of CPU's are assigned to the LPAR.

As a configuration standard, every policy will be configured to immediately release free CPU and memory resources. Most other configuration parameters within the PLM will depend upon the LPAR and application requirements.

Table of Contents

Standards - LPAR

Logical Partition Standards

LPAR, short for logical partitioning, is a mechanism of taking a computer's total resources - processors, memory and storage -- and splitting them into smaller units that each can be run with its own instance of the operating system and applications. Each partition can communicate with the other partitions as if the other partition is in a separate machine.

In Mt Xia's environment, the ability to obtain outages for the purpose of maintenance and upgrades will be difficult. Furthermore, systems supporting multiple business functions will be even more difficult to obtain outage windows. Therefore it is desirable to create LPAR's to support each business function, thus reducing the impact of an outage upon the overall environment. So rather than creating large LPAR's supporting multiple business functions for a client, it is preferable to create multiple LPARs to support each business function.

When creating an LPAR, the following standards will be applied:

The LPAR name and profile name will be the same as the short machine name assigned to the LPAR.
Minimum Memory: 512 MB
Desired Memory: 512 MB
Maximum Memory: All available memory

For LPARs that will require 3 physical processors or less during normal operations:

Processor Mode: shared
Minimum processing units: 0.20
Desired processing units: 0.20
Maximum processing units: All available CPUs
Minimum Virtual Processors: 2
Desired Virtual Processors: 2
Maximum Virtual Processors: 30

For LPARs that will require more than 3 physical processors during normal operation:

Processor Mode: shared
Minimum processing units: 1.00
Desired processing units: 1.00
Maximum processing units: All available CPUs
Minimum Virtual Processors: 2
Desired Virtual Processors: 2
Maximum Virtual Processors: 64

Physical I/O will be assigned as required by the business functions supported by by each LPAR, Virtual I/O will be assigned as required by each LPAR and in accordance with Mt Xia's VIO standards. Connection monitoring will be enabled for each LPAR and no LPARs will be started automatically when the frame is powered on.

Table of Contents

Standards - NIM

Network Information Manager Standards

Features

NIM permits the installation and maintenance of AIX, its basic operating system, and additional software and fixes that may be applied over a period of time over token-ring, ethernet, FDDI, and ATM net works.

NIM also permits the customization of machines both during and after installation . As a result, NIM has eliminated the reliance on tapes and CD-ROMs for software installation; the onus, in NIM’sase, is on the network. NIM will allow one machine to act as a master in the environment. This machine will be responsible for storing information about the clients it supports, the resources it or other servers provide to these clients, and the networks on which they operate.

Benefits

Some of the benefits of NIM are:

Manageability - It allows central localization of software installation images, thus, making backup and administration easier.
Central Administration - Administrators can install remote AIX machines without having to physically attend them.
Scalability - You can install more than one machine at a time, implement a group strategy of machines and resources, and choose how many machines to install at a time.
Usability - VSM GUI for NIM has been improved so that, now, it can be used to configure NIM groups.
Availability - Where server down time means loss of profits, NIM provides you with a backup image of all your servers. A new server can be set up and running in just over an hour.
Non-prompted installation - NIM provides a function to install systems without having to go to the machine, thus, avoiding the sneaker net method.

Installations can be initiated by either the client or master at a convenient time. For example, if a client is unavailable at the time of the install, you can initiate an install when it is back on line, or, if there is less traffic on your network at a certain time, you can initiate the installations to occur then.

It is a relatively faster means of installation than tape or CD-ROM.

NIM provides greater functionality than CD-ROM or tape. Among other things, it allows you to customize an install, initiate a non-prompted install, or install additional software.

Mt Xia's NIM Environment

NIM Server Machines

Each data center currently has one NIM server which serves various resources to the client machines in that data center. Some cross data center communication occurs for the purpose of disaster recovery. The NIM Server machines are:

Boston Data Center: bosapnim01.tu.com
Dallas Data Center: dalapnim01.tu.com

No NIM Alternate-Master servers are currently configured, but will be implemented soon. This capability will provide automated redundancy of NIM resources between data centers.

NIM Client Machines

All AIX and linux machines in the Mt Xia enviroment utilize resources originating from the NIM Servers.

NIM Resources

The resources available from the NIM servers include operating systems, OS updates, OS backup and restores, clustering software, applications, device drivers, firmware, and disaster recovery services and information. These resources can be delivered from any NIM server to any NIM client in any Mt Xia data center. Some of the resources available on the NIM Servers include:

AIX
Linux
mksysb repository
AIX Maintenance Levels
AIX APAR's
AIX Fixes
HACMP
HACMP-ES
MQ Series Software
Tivoli Storage Manager Software
Linux Toolbox for AIX
freeware
Hitachi Sofware
Performance monitoring software
firmware updates
Disaster Recovery hub for AIX

NIM Server Operations

Using the resources previously listed, a wide variety of operations may be peformed on or by a NIM client. These operations include the ability to perform a bare-metal install of a new operating sytem or backup. Other operating system installation options are also available, dependent only upon what the system administrator is attempting to accomplish. For example, using the NIM server, a backup of a production machine can be performed, the backup restored to an alternate-disk on the same production machine, and the operating system on the alternate-disk can be updated to the latest maintenance level, all without interuption or downtime to the production machine. Some of the operations that are regularly performed utilizing the resources provided by the NIM servers include:

Network boot server

AIX operating system installation

AIX operating system maintenance level updates

AIX operating system APAR updates

AIX operating system efix updates

AIX mksysb repository

AIX mksysb installation

AIX alt-clone installation

AIX alt-clone maintenance level updates

AIX alt-disk installation

Linux operating system installation

Linux operating rpm updates

Oracle database installation

Application installation and updates

Script Server

Disaster Recovery information gathering

Disaster Recovery information distribution

Disaster Recovery automated documentation generator

NIM Server Structure

To maintain structure and order on the NIM Servers, a specific directory hierarchy has been adopted and utilized. This structure must be observed and practiced when making modifications to the resources provided by the NIM Servers.

The top level directory for storage of NIM resources begins at the directory:

/export

Each resource class provided by the NIM server should exist as a subdirectory under /export. The list of valid NIM resource classes are:

boot: represents the network boot resource
nim_script: directory containing customization scripts created by NIM
spot: Shared Product Object Tree - equivalent to /usr/filesystem
root: parent directory for client / (root) directories
paging: parent directory for client paging files
dump: parent directory for client dump files
home: parent directory for client /home directories
shared_home: home directory shared by clients
tmp: parent directory for client /tmp directories
exclude_files: files to be excluded when creating a mksysb or savevg image
lpp_source: source device for optional product images
installp_bundle: installp bundle file
fix_bundle: fix (keyword) input file for the cust or fix_query operation
bosinst_data: config file used during base system installation
image_data: config file used during base system installation
vg_data: config file used during volume group restoration
mksysb: a mksysb image
script: an executable file which is executed on a client
resolv_conf: configuration file for name-server information
savevg: a savevg image
adapter_def: directory containing secondary adapter definition files
fb_script: an executable script added to /etc/firstboot and run at first reboot after bos install to configure devices.

Not all NIM resource classes are currently utilized, however when a new resource is utilized, this guide should be followed for the directory naming structure.

The currently implemented NIM resource classes and class instances follow. Naming conventions for class instances are included here and should be adhered to when new class instances are created:

Currently implemented NIM Resource's

/export/bosinst_data

The "bosinst_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "bosinst_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "bosinst_data" resource class and file follow:

bosinst_data Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
ID Maintenance
Level NIM
Resource Name Storage
Location

Base OS Install Data bosinst_data Default bosinst_data /export/bosinst_data/bosinst_data

Base OS Install Data bosinst_data noprompt bosinst_data_noprompt /export/bosinst_data/bosinst_data_noprompt

Base OS Install Data bosinst_data bosmtxapp52 bosinst_data_bosmtxapp52 /export/bosinst_data/bosinst_data_bosmtxapp52

Base OS Install Data bosinst_data egate bosinst_data_egate /export/bosinst_data/bosinst_data_egate

Base OS Install Data bosinst_data 4330 bosinst_data_4330 /export/bosinst_data/bosinst_data_4330

Base OS Install Data bosinst_data 4330 10 bosinst_data_4330-10 /export/bosinst_data/bosinst_data_4330-10

Base OS Install Data bosinst_data 4330 11 bosinst_data_4330-11 /export/bosinst_data/bosinst_data_4330-11

Base OS Install Data bosinst_data 4330 09 bosinst_data_4330-09 /export/bosinst_data/bosinst_data_4330-09

Base OS Install Data bosinst_data 4330 10.5 bosinst_data_4330-10_5 /export/bosinst_data/bosinst_data_4330-10_5

Base OS Install Data bosinst_data 5100 bosinst_data_5100 /export/bosinst_data/bosinst_data_5100

Base OS Install Data bosinst_data 5100 02 bosinst_data_5100-02 /export/bosinst_data/bosinst_data_5100-02

Base OS Install Data bosinst_data 5200 bosinst_data_5200 /export/bosinst_data/bosinst_data_5200

Base OS Install Data bosinst_data 5200 01 bosinst_data_5200-01 /export/bosinst_data/bosinst_data_5200-01

Base OS Install Data bosinst_data 5200 02 bosinst_data_5200-02 /export/bosinst_data/bosinst_data_5200-02

Base OS Install Data bosinst_data 5200 04 bosinst_data_5200-04 /export/bosinst_data/bosinst_data_5200-04

Base OS Install Data bosinst_data 5200 05 bosinst_data_5200-05 /export/bosinst_data/bosinst_data_5200-05

Base OS Install Data bosinst_data 5300 bosinst_data_5300 /export/bosinst_data/bosinst_data_5300

Base OS Install Data bosinst_data 5300 01 bosinst_data_5300-01 /export/bosinst_data/bosinst_data_5300-01

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "bosinst_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.: The "bosinst_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "bosinst_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "bosinst_data" resource class and file follow:

bosinst_data Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
ID Maintenance
Level NIM
Resource Name Storage
Location

Base OS Install Data bosinst_data Default bosinst_data /export/bosinst_data/bosinst_data

Base OS Install Data bosinst_data noprompt bosinst_data_noprompt /export/bosinst_data/bosinst_data_noprompt

Base OS Install Data bosinst_data bosmtxapp52 bosinst_data_bosmtxapp52 /export/bosinst_data/bosinst_data_bosmtxapp52

Base OS Install Data bosinst_data egate bosinst_data_egate /export/bosinst_data/bosinst_data_egate

Base OS Install Data bosinst_data 4330 bosinst_data_4330 /export/bosinst_data/bosinst_data_4330

Base OS Install Data bosinst_data 4330 10 bosinst_data_4330-10 /export/bosinst_data/bosinst_data_4330-10

Base OS Install Data bosinst_data 4330 11 bosinst_data_4330-11 /export/bosinst_data/bosinst_data_4330-11

Base OS Install Data bosinst_data 4330 09 bosinst_data_4330-09 /export/bosinst_data/bosinst_data_4330-09

Base OS Install Data bosinst_data 4330 10.5 bosinst_data_4330-10_5 /export/bosinst_data/bosinst_data_4330-10_5

Base OS Install Data bosinst_data 5100 bosinst_data_5100 /export/bosinst_data/bosinst_data_5100

Base OS Install Data bosinst_data 5100 02 bosinst_data_5100-02 /export/bosinst_data/bosinst_data_5100-02

Base OS Install Data bosinst_data 5200 bosinst_data_5200 /export/bosinst_data/bosinst_data_5200

Base OS Install Data bosinst_data 5200 01 bosinst_data_5200-01 /export/bosinst_data/bosinst_data_5200-01

Base OS Install Data bosinst_data 5200 02 bosinst_data_5200-02 /export/bosinst_data/bosinst_data_5200-02

Base OS Install Data bosinst_data 5200 04 bosinst_data_5200-04 /export/bosinst_data/bosinst_data_5200-04

Base OS Install Data bosinst_data 5200 05 bosinst_data_5200-05 /export/bosinst_data/bosinst_data_5200-05

Base OS Install Data bosinst_data 5300 bosinst_data_5300 /export/bosinst_data/bosinst_data_5300

Base OS Install Data bosinst_data 5300 01 bosinst_data_5300-01 /export/bosinst_data/bosinst_data_5300-01

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "bosinst_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.
/export/image.data

The "image_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "image_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "image_data" resource class and file follow:

image_data Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
ID Maintenance
Level NIM
Resource Name Storage
Location

Base OS Install Data image_data Default image_data /export/image_data/image_data

Base OS Install Data image_data noprompt image_data_noprompt /export/image_data/image_data_noprompt

Base OS Install Data image_data bosmtxapp52 image_data_bosmtxapp52 /export/image_data/image_data_bosmtxapp52

Base OS Install Data image_data egate image_data_egate /export/image_data/image_data_egate

Base OS Install Data image_data 4330 image_data_4330 /export/image_data/image_data_4330

Base OS Install Data image_data 4330 10 image_data_4330-10 /export/image_data/image_data_4330-10

Base OS Install Data image_data 4330 11 image_data_4330-11 /export/image_data/image_data_4330-11

Base OS Install Data image_data 4330 09 image_data_4330-09 /export/image_data/image_data_4330-09

Base OS Install Data image_data 4330 10.5 image_data_4330-10_5 /export/image_data/image_data_4330-10_5

Base OS Install Data image_data 5100 image_data_5100 /export/image_data/image_data_5100

Base OS Install Data image_data 5100 02 image_data_5100-02 /export/image_data/image_data_5100-02

Base OS Install Data image_data 5200 image_data_5200 /export/image_data/image_data_5200

Base OS Install Data image_data 5200 01 image_data_5200-01 /export/image_data/image_data_5200-01

Base OS Install Data image_data 5200 02 image_data_5200-02 /export/image_data/image_data_5200-02

Base OS Install Data image_data 5200 04 image_data_5200-04 /export/image_data/image_data_5200-04

Base OS Install Data image_data 5200 05 image_data_5200-05 /export/image_data/image_data_5200-05

Base OS Install Data image_data 5300 image_data_5300 /export/image_data/image_data_5300

Base OS Install Data image_data 5300 01 image_data_5300-01 /export/image_data/image_data_5300-01

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "image_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.: The "image_data" resource class is for the configuration files used during the AIX base operating system installation. The default instance shall be named "image_data". Additional instances shall be suffixed with unique identifying information such as the AIX Operating System version number, machine name, user name, application name, etc. Example instances of the "image_data" resource class and file follow:

image_data Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
ID Maintenance
Level NIM
Resource Name Storage
Location

Base OS Install Data image_data Default image_data /export/image_data/image_data

Base OS Install Data image_data noprompt image_data_noprompt /export/image_data/image_data_noprompt

Base OS Install Data image_data bosmtxapp52 image_data_bosmtxapp52 /export/image_data/image_data_bosmtxapp52

Base OS Install Data image_data egate image_data_egate /export/image_data/image_data_egate

Base OS Install Data image_data 4330 image_data_4330 /export/image_data/image_data_4330

Base OS Install Data image_data 4330 10 image_data_4330-10 /export/image_data/image_data_4330-10

Base OS Install Data image_data 4330 11 image_data_4330-11 /export/image_data/image_data_4330-11

Base OS Install Data image_data 4330 09 image_data_4330-09 /export/image_data/image_data_4330-09

Base OS Install Data image_data 4330 10.5 image_data_4330-10_5 /export/image_data/image_data_4330-10_5

Base OS Install Data image_data 5100 image_data_5100 /export/image_data/image_data_5100

Base OS Install Data image_data 5100 02 image_data_5100-02 /export/image_data/image_data_5100-02

Base OS Install Data image_data 5200 image_data_5200 /export/image_data/image_data_5200

Base OS Install Data image_data 5200 01 image_data_5200-01 /export/image_data/image_data_5200-01

Base OS Install Data image_data 5200 02 image_data_5200-02 /export/image_data/image_data_5200-02

Base OS Install Data image_data 5200 04 image_data_5200-04 /export/image_data/image_data_5200-04

Base OS Install Data image_data 5200 05 image_data_5200-05 /export/image_data/image_data_5200-05

Base OS Install Data image_data 5300 image_data_5300 /export/image_data/image_data_5300

Base OS Install Data image_data 5300 01 image_data_5300-01 /export/image_data/image_data_5300-01

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "image_data" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.
/export/lpp_source

Software filesets and updates are identified in the NIM server as an "lpp_source". The top level directory location to be used for storage of these resources will be "/export/lpp_source". The storage location of these resources will be further divided into subdirectories such as "aix", "hacmp", "hitachi", etc.: Software filesets and updates are identified in the NIM server as an "lpp_source". The top level directory location to be used for storage of these resources will be "/export/lpp_source". The storage location of these resources will be further divided into subdirectories such as "aix", "hacmp", "hitachi", etc.
/export/lpp_source/aix

The "lpp_source" resources stored in the "aix" subdirectory shall be those that are directly related to the AIX operating system. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX operating system, AIX device drivers, AIX expansion packs, Partition Load Manager, Virtual I/O Server, and others. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

aix: AIX Operating System

aixdoc: AIX Documentation

dev: AIX Device Drivers

exppack: AIX Expansion Pack

plm: Partition Load Manager

vio: Virtual I/O Server

Each AIX "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (aix, aixdoc, dev, exppack, plm, vio) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

AIX lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX Operating System aix 4330 aix_4330 /export/lpp_source/aix/aix_4330

AIX Operating System aix 4330 10 aix_4330-10 /export/lpp_source/aix/aix_4330-10

AIX Operating System aix 4330 11 aix_4330-11 /export/lpp_source/aix/aix_4330-11

AIX Operating System aix 4330 09 aix_4330-09 /export/lpp_source/aix/aix_4330-09

AIX Operating System aix 4330 10.5 aix_4330-10_5 /export/lpp_source/aix/aix_4330-10_5

AIX Operating System aix 5100 aix_5100 /export/lpp_source/aix/aix_5100

AIX Operating System aix 5100 02 aix_5100-02 /export/lpp_source/aix/aix_5100-02

AIX Operating System aix 5200 aix_5200 /export/lpp_source/aix/aix_5200

AIX Operating System aix 5200 01 aix_5200-01 /export/lpp_source/aix/aix_5200-01

AIX Operating System aix 5200 02 aix_5200-02 /export/lpp_source/aix/aix_5200-02

AIX Operating System aix 5200 04 aix_5200-04 /export/lpp_source/aix/aix_5200-04

AIX Operating System aix 5200 05 aix_5200-05 /export/lpp_source/aix/aix_5200-05

AIX Operating System aix 5300 aix_5300 /export/lpp_source/aix/aix_5300

AIX Operating System aix 5300 01 aix_5300-01 /export/lpp_source/aix/aix_5300-01

AIX Documentation aixdoc 5300 aixdoc_5300 /export/lpp_source/aix/aixdoc_5300

AIX Device Drivers dev 4330 dev_4330 /export/lpp_source/aix/dev_4330

AIX Device Drivers dev 5100 dev_5100 /export/lpp_source/aix/dev_5100

AIX Device Drivers dev 5200 dev_5200 /export/lpp_source/aix/dev_5200

AIX Expansion Pack exppack 5300 exppack_5300 /export/lpp_source/aix/exppack_5300

Partition Load Manager plm 1100 plm_1100 /export/lpp_source/aix/plm_1100

Virtual I/O Server vio 1100 vio_1100 /export/lpp_source/aix/vio_1100: The "lpp_source" resources stored in the "aix" subdirectory shall be those that are directly related to the AIX operating system. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX operating system, AIX device drivers, AIX expansion packs, Partition Load Manager, Virtual I/O Server, and others. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

aix: AIX Operating System

aixdoc: AIX Documentation

dev: AIX Device Drivers

exppack: AIX Expansion Pack

plm: Partition Load Manager

vio: Virtual I/O Server

Each AIX "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (aix, aixdoc, dev, exppack, plm, vio) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

AIX lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX Operating System aix 4330 aix_4330 /export/lpp_source/aix/aix_4330

AIX Operating System aix 4330 10 aix_4330-10 /export/lpp_source/aix/aix_4330-10

AIX Operating System aix 4330 11 aix_4330-11 /export/lpp_source/aix/aix_4330-11

AIX Operating System aix 4330 09 aix_4330-09 /export/lpp_source/aix/aix_4330-09

AIX Operating System aix 4330 10.5 aix_4330-10_5 /export/lpp_source/aix/aix_4330-10_5

AIX Operating System aix 5100 aix_5100 /export/lpp_source/aix/aix_5100

AIX Operating System aix 5100 02 aix_5100-02 /export/lpp_source/aix/aix_5100-02

AIX Operating System aix 5200 aix_5200 /export/lpp_source/aix/aix_5200

AIX Operating System aix 5200 01 aix_5200-01 /export/lpp_source/aix/aix_5200-01

AIX Operating System aix 5200 02 aix_5200-02 /export/lpp_source/aix/aix_5200-02

AIX Operating System aix 5200 04 aix_5200-04 /export/lpp_source/aix/aix_5200-04

AIX Operating System aix 5200 05 aix_5200-05 /export/lpp_source/aix/aix_5200-05

AIX Operating System aix 5300 aix_5300 /export/lpp_source/aix/aix_5300

AIX Operating System aix 5300 01 aix_5300-01 /export/lpp_source/aix/aix_5300-01

AIX Documentation aixdoc 5300 aixdoc_5300 /export/lpp_source/aix/aixdoc_5300

AIX Device Drivers dev 4330 dev_4330 /export/lpp_source/aix/dev_4330

AIX Device Drivers dev 5100 dev_5100 /export/lpp_source/aix/dev_5100

AIX Device Drivers dev 5200 dev_5200 /export/lpp_source/aix/dev_5200

AIX Expansion Pack exppack 5300 exppack_5300 /export/lpp_source/aix/exppack_5300

Partition Load Manager plm 1100 plm_1100 /export/lpp_source/aix/plm_1100

Virtual I/O Server vio 1100 vio_1100 /export/lpp_source/aix/vio_1100
/export/lpp_source/hacmp

The "lpp_source" resources stored in the "hacmp" subdirectory shall be those that are directly related to the HACMP Clustering Software, this does NOT include HACMP ES. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP Clustering software.

Each HACMP "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (hacmp) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

HACMP lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

HACMP hacmp 4500 hacmp_4500 /export/lpp_source/hacmp/hacmp_4500: The "lpp_source" resources stored in the "hacmp" subdirectory shall be those that are directly related to the HACMP Clustering Software, this does NOT include HACMP ES. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP Clustering software.

Each HACMP "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (hacmp) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

HACMP lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

HACMP hacmp 4500 hacmp_4500 /export/lpp_source/hacmp/hacmp_4500
/export/lpp_source/hacmpes

The "lpp_source" resources stored in the "hacmpes" subdirectory shall be those that are directly related to the HACMP ES Clustering Software. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP ES Clustering software.

Each HACMP ES "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (hacmpes) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

HACMP ES lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

HACMP ES hacmpes 4400 hacmpes_4400 /export/lpp_source/hacmpes/hacmpes_4400

HACMP ES hacmpes 4410 hacmpes_4410 /export/lpp_source/hacmpes/hacmpes_4410

HACMP ES hacmpes 4410 01 hacmpes_4410-01 /export/lpp_source/hacmpes/hacmpes_4410-01

HACMP ES hacmpes 4419 hacmpes_4419 /export/lpp_source/hacmpes/hacmpes_4419

HACMP ES hacmpes 4500 hacmpes_4500 /export/lpp_source/hacmpes/hacmpes_4500

HACMP ES hacmpes 4507 hacmpes_4507 /export/lpp_source/hacmpes/hacmpes_4507

HACMP ES hacmpes 5100 hacmpes_5100 /export/lpp_source/hacmpes/hacmpes_5100

HACMP ES hacmpes 5200 hacmpes_5200 /export/lpp_source/hacmpes/hacmpes_5200

HACMP ES hacmpes 5200 01 hacmpes_5200-01 /export/lpp_source/hacmpes/hacmpes_5200-01: The "lpp_source" resources stored in the "hacmpes" subdirectory shall be those that are directly related to the HACMP ES Clustering Software. The "lpp_source" resources stored in this directory will consist of a number of different versions of the HACMP ES Clustering software.

Each HACMP ES "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (hacmpes) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

HACMP ES lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

HACMP ES hacmpes 4400 hacmpes_4400 /export/lpp_source/hacmpes/hacmpes_4400

HACMP ES hacmpes 4410 hacmpes_4410 /export/lpp_source/hacmpes/hacmpes_4410

HACMP ES hacmpes 4410 01 hacmpes_4410-01 /export/lpp_source/hacmpes/hacmpes_4410-01

HACMP ES hacmpes 4419 hacmpes_4419 /export/lpp_source/hacmpes/hacmpes_4419

HACMP ES hacmpes 4500 hacmpes_4500 /export/lpp_source/hacmpes/hacmpes_4500

HACMP ES hacmpes 4507 hacmpes_4507 /export/lpp_source/hacmpes/hacmpes_4507

HACMP ES hacmpes 5100 hacmpes_5100 /export/lpp_source/hacmpes/hacmpes_5100

HACMP ES hacmpes 5200 hacmpes_5200 /export/lpp_source/hacmpes/hacmpes_5200

HACMP ES hacmpes 5200 01 hacmpes_5200-01 /export/lpp_source/hacmpes/hacmpes_5200-01
/export/lpp_source/hitachi

The "lpp_source" resources stored in the "hitachi" subdirectory shall be those that are directly related to the Hitachi SAN Subsystems. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX ODM software, DLM Drivers, HDLM Drivers, Hitachi's MPIO Drivers, and Hitachi's performance monitoring software. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

aixodm: Hitachi's AIX ODM Software

dlm: DLM Drivers

hdlm: HDLM Drivers

hdsmpio: Hitachi's MPIO Drivers

lunstat: Performance Monitoring

Each Hitachi "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (aixodm, dlm, hdlm, hdsmpio, lunstat) followed by an underscore "_", followed by the four(4) digit version number of the resource. The version number of the Hitachi filesets should be taken from the filenames, NOT from the media on which the software was delivered. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Hitachi lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX ODM Software aixodm 5000 aixodm_5000 /export/lpp_source/hitachi/aixodm_5000

AIX ODM Software aixodm 5001 aixodm_5001 /export/lpp_source/hitachi/aixodm_5001

AIX ODM Software aixodm 5002 aixodm_5002 /export/lpp_source/hitachi/aixodm_5002

AIX ODM Software aixodm 5004 aixodm_5004 /export/lpp_source/hitachi/aixodm_5004

AIX ODM Software aixodm 5014 aixodm_5014 /export/lpp_source/hitachi/aixodm_5014

DLM Drivers dlm 2430 dlm_2430 /export/lpp_source/hitachi/dlm_2430

DLM Drivers dlm 2530 dlm_2530 /export/lpp_source/hitachi/dlm_2530

HDLM Drivers hdlm 5024 hdlm_5024 /export/lpp_source/hitachi/hdlm_5024

HDLM Drivers hdlm 5112 hdlm_5112 /export/lpp_source/hitachi/hdlm_5112

HDLM Drivers hdlm 5231 hdlm_5231 /export/lpp_source/hitachi/hdlm_5231

HDLM Drivers hdlm 5251 hdlm_5251 /export/lpp_source/hitachi/hdlm_5251

HDLM Drivers hdlm 5411 hdlm_5411 /export/lpp_source/hitachi/hdlm_5411

Hitachi MPIO Driver hdsmpio 5400 hdsmpio_5400 /export/lpp_source/hitachi/hdsmpio_5400

Performance Monitoring lunstat 122 lunstat_122 /export/lpp_source/hitachi/lunstat_122: The "lpp_source" resources stored in the "hitachi" subdirectory shall be those that are directly related to the Hitachi SAN Subsystems. The "lpp_source" resources stored in this directory may consist of a number of different types including the AIX ODM software, DLM Drivers, HDLM Drivers, Hitachi's MPIO Drivers, and Hitachi's performance monitoring software. The following identifiers will be used when defining the lpp_source of this type on the NIM Server and when creating directories to store the lpp_source on the NIM Server:

aixodm: Hitachi's AIX ODM Software

dlm: DLM Drivers

hdlm: HDLM Drivers

hdsmpio: Hitachi's MPIO Drivers

lunstat: Performance Monitoring

Each Hitachi "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (aixodm, dlm, hdlm, hdsmpio, lunstat) followed by an underscore "_", followed by the four(4) digit version number of the resource. The version number of the Hitachi filesets should be taken from the filenames, NOT from the media on which the software was delivered. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Hitachi lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX ODM Software aixodm 5000 aixodm_5000 /export/lpp_source/hitachi/aixodm_5000

AIX ODM Software aixodm 5001 aixodm_5001 /export/lpp_source/hitachi/aixodm_5001

AIX ODM Software aixodm 5002 aixodm_5002 /export/lpp_source/hitachi/aixodm_5002

AIX ODM Software aixodm 5004 aixodm_5004 /export/lpp_source/hitachi/aixodm_5004

AIX ODM Software aixodm 5014 aixodm_5014 /export/lpp_source/hitachi/aixodm_5014

DLM Drivers dlm 2430 dlm_2430 /export/lpp_source/hitachi/dlm_2430

DLM Drivers dlm 2530 dlm_2530 /export/lpp_source/hitachi/dlm_2530

HDLM Drivers hdlm 5024 hdlm_5024 /export/lpp_source/hitachi/hdlm_5024

HDLM Drivers hdlm 5112 hdlm_5112 /export/lpp_source/hitachi/hdlm_5112

HDLM Drivers hdlm 5231 hdlm_5231 /export/lpp_source/hitachi/hdlm_5231

HDLM Drivers hdlm 5251 hdlm_5251 /export/lpp_source/hitachi/hdlm_5251

HDLM Drivers hdlm 5411 hdlm_5411 /export/lpp_source/hitachi/hdlm_5411

Hitachi MPIO Driver hdsmpio 5400 hdsmpio_5400 /export/lpp_source/hitachi/hdsmpio_5400

Performance Monitoring lunstat 122 lunstat_122 /export/lpp_source/hitachi/lunstat_122
/export/lpp_source/mqseries

The "lpp_source" resources stored in the "mqseries" subdirectory shall be those that are directly related to the MQ Series software. Each MQ Series "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (mq) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

MQ Series lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

MQ Series mq 5300 mq_5300 /export/lpp_source/mqseries/mq_5300: The "lpp_source" resources stored in the "mqseries" subdirectory shall be those that are directly related to the MQ Series software. Each MQ Series "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (mq) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

MQ Series lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

MQ Series mq 5300 mq_5300 /export/lpp_source/mqseries/mq_5300
/export/lpp_source/performance

The "lpp_source" resources stored in the "performance" subdirectory shall be those that are related to performance monitoring and management. Each Performance related "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory will depend upon the resource and may deviate from those identified in this document. The resource identifiers shall have the following specific format:

The resource identifier (perfaide, perftoolbox, etc) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Performance related lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

Performance perfaide 3100 perfaide_3100 /export/lpp_source/performance/perfaide_3100

Performance perftoolbox 3100 perftoolbox_3100 /export/lpp_source/performance/perftoolbox_3100: The "lpp_source" resources stored in the "performance" subdirectory shall be those that are related to performance monitoring and management. Each Performance related "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory will depend upon the resource and may deviate from those identified in this document. The resource identifiers shall have the following specific format:

The resource identifier (perfaide, perftoolbox, etc) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Performance related lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

Performance perfaide 3100 perfaide_3100 /export/lpp_source/performance/perfaide_3100

Performance perftoolbox 3100 perftoolbox_3100 /export/lpp_source/performance/perftoolbox_3100
/export/lpp_source/tsm

The "lpp_source" resources stored in the "tsm" subdirectory shall be those that are directly related to the Tivoli Storage Manager(TSM). The "lpp_source" resources stored in this directory will consist of a number of different versions of the TSM software.

Each TSM "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (tsmclient,tsmserver) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Tivoli Storage Manager related lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

TSM tsmclient 42125 tsmclient_42125 /export/lpp_source/tsm/tsmclient_42125

TSM tsmclient 4221 tsmclient_4221 /export/lpp_source/tsm/tsmclient_4221

TSM tsmclient 5162 tsmclient_5162 /export/lpp_source/tsm/tsmclient_5162: The "lpp_source" resources stored in the "tsm" subdirectory shall be those that are directly related to the Tivoli Storage Manager(TSM). The "lpp_source" resources stored in this directory will consist of a number of different versions of the TSM software.

Each TSM "lpp_source" resource shall be stored in a subdirectory. The name of the resource and subdirectory shall have the following specific format:

The resource identifier (tsmclient,tsmserver) followed by an underscore "_", followed by the four(4) digit version number of the resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Tivoli Storage Manager related lpp_source Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

TSM tsmclient 42125 tsmclient_42125 /export/lpp_source/tsm/tsmclient_42125

TSM tsmclient 4221 tsmclient_4221 /export/lpp_source/tsm/tsmclient_4221

TSM tsmclient 5162 tsmclient_5162 /export/lpp_source/tsm/tsmclient_5162
/export/mksysb

The "mksysb" resource class is for AIX mksysb backups of the "rootvg" volume group. "mksysb" resources can be used by the NIM server to perform a new installation or restore a machine to a known state. The "mksysb" images are specific to an individual machine at a particular point in time.

Each "mksysb" resource shall be stored under the "/export/mksysb" subdirectory. The name of the resource shall have the following specific format:

The resource identifier (mksysb) followed by an underscore "_", followed by the machine name from which the "mksysb" image was generated. If multiple versions are desired, follow the machine name with an underscore "_", followed by the 4 digit year, 2 digit month number, 2 digit day of the month, 2 digit hour of the day, 2 digit minute of the hour, and 2 digit seconds. If this level of granularity is not required, the date/time identifer can be truncated as necessary, but should remain in the stated sequence and format.

mksysb Resource Names and Subdirectories
Resource
Type Resource
Identifier Originating
Machine Date/Time
Stamp NIM
Resource Name Storage
Location

Backup mksysb dalaaega01 mksysb_dalaaega01 /export/mksysb/mksysb_dalaaega01

Backup mksysb dalaaega02 mksysb_dalaaega02 /export/mksysb/mksysb_dalaaega02

Backup mksysb dalpocdb01 mksysb_dalpocdb01 /export/mksysb/mksysb_dalpocdb01

Backup mksysb bosmtxapp80 20050412 mksysb_bosmtxapp80_20050412 /export/mksysb/mksysb_bosmtxapp80_20050412

Backup mksysb bosmtxapp80 20050414 mksysb_bosmtxapp80_20050414 /export/mksysb/mksysb_bosmtxapp80_20050414: The "mksysb" resource class is for AIX mksysb backups of the "rootvg" volume group. "mksysb" resources can be used by the NIM server to perform a new installation or restore a machine to a known state. The "mksysb" images are specific to an individual machine at a particular point in time.

Each "mksysb" resource shall be stored under the "/export/mksysb" subdirectory. The name of the resource shall have the following specific format:

The resource identifier (mksysb) followed by an underscore "_", followed by the machine name from which the "mksysb" image was generated. If multiple versions are desired, follow the machine name with an underscore "_", followed by the 4 digit year, 2 digit month number, 2 digit day of the month, 2 digit hour of the day, 2 digit minute of the hour, and 2 digit seconds. If this level of granularity is not required, the date/time identifer can be truncated as necessary, but should remain in the stated sequence and format.

mksysb Resource Names and Subdirectories
Resource
Type Resource
Identifier Originating
Machine Date/Time
Stamp NIM
Resource Name Storage
Location

Backup mksysb dalaaega01 mksysb_dalaaega01 /export/mksysb/mksysb_dalaaega01

Backup mksysb dalaaega02 mksysb_dalaaega02 /export/mksysb/mksysb_dalaaega02

Backup mksysb dalpocdb01 mksysb_dalpocdb01 /export/mksysb/mksysb_dalpocdb01

Backup mksysb bosmtxapp80 20050412 mksysb_bosmtxapp80_20050412 /export/mksysb/mksysb_bosmtxapp80_20050412

Backup mksysb bosmtxapp80 20050414 mksysb_bosmtxapp80_20050414 /export/mksysb/mksysb_bosmtxapp80_20050414
/export/resolv_conf

The "resolv_conf" resource class is the configuration file for the Domain Name Server (DNS) information. A instance of this class shall be defined for each data center and may contain DNS information for multiple data centers. Example instances of the "resolv_conf" resource class and file follow:

resolv_conf Resource Names and Subdirectories
Resource
Type Resource
Identifier Datacenter
ID Maintenance
Level NIM
Resource Name Storage
Location

DNS Resolution resolv_conf Default resolv_conf /export/resolv_conf/resolv_conf

DNS Resolution resolv_conf dal resolv_conf_dal /export/resolv_conf/resolv_conf_dal

DNS Resolution resolv_conf bos resolv_conf_bos /export/resolv_conf/resolv_conf_bos

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "resolv_conf" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.: The "resolv_conf" resource class is the configuration file for the Domain Name Server (DNS) information. A instance of this class shall be defined for each data center and may contain DNS information for multiple data centers. Example instances of the "resolv_conf" resource class and file follow:

resolv_conf Resource Names and Subdirectories
Resource
Type Resource
Identifier Datacenter
ID Maintenance
Level NIM
Resource Name Storage
Location

DNS Resolution resolv_conf Default resolv_conf /export/resolv_conf/resolv_conf

DNS Resolution resolv_conf dal resolv_conf_dal /export/resolv_conf/resolv_conf_dal

DNS Resolution resolv_conf bos resolv_conf_bos /export/resolv_conf/resolv_conf_bos

When adding an instance of this class to the NIM server, the name of the instance shall contain the prefix "resolv_conf" followed by an underscore "_" and will be suffixed with a unique identifier. The file names used to store the resource shall correspond exactly with the name used to define the resource in the NIM server.
/export/spot

The "spot" resource class is for the bootable images to use for network booting a machine and OS installation. Each "spot" image is specific to a particular version and maintenance level of AIX or other operating system and shall be identified accordingly. The resource identifier for the AIX "spot" images is "aixspot". The reason "aixspot" is used for this identifier instead of just "spot" is because Linux spots are also be included in this resource class and are identified by the brand of Linux such as "susespot", "redhatspot", "debianspot", etc. These resource identifiers shall be be used to identify each instance as follows:

The resource identifier (aixspot) followed by an underscore "_", followed by the four(4) digit version number of the AIX OS resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Spot Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX Spot aixspot 4330 aixspot_4330 /export/spot/aixspot_4330

AIX Spot aixspot 5100 aixspot_5100 /export/spot/aixspot_5100

AIX Spot aixspot 5200 aixspot_5200 /export/spot/aixspot_5200

AIX Spot aixspot 5200 02 aixspot_5200-02 /export/spot/aixspot_5200-02

AIX Spot aixspot 5200 05 aixspot_5200-05 /export/spot/aixspot_5200-05

AIX Spot aixspot 5300 aixspot_5300 /export/spot/aixspot_5300

Suse Spot slesspot 9000 slesspot_9000 /export/spot/slesspot_9000: The "spot" resource class is for the bootable images to use for network booting a machine and OS installation. Each "spot" image is specific to a particular version and maintenance level of AIX or other operating system and shall be identified accordingly. The resource identifier for the AIX "spot" images is "aixspot". The reason "aixspot" is used for this identifier instead of just "spot" is because Linux spots are also be included in this resource class and are identified by the brand of Linux such as "susespot", "redhatspot", "debianspot", etc. These resource identifiers shall be be used to identify each instance as follows:

The resource identifier (aixspot) followed by an underscore "_", followed by the four(4) digit version number of the AIX OS resource. If the version number of the resource is less than four(4) digits, add zero's(0) to make it a four(4) digit number. If the "lpp_source" resource is a maintenance level, then add a dash "-" followed by the two(2) digit maintenance level number. Base level filesets will not have a maintenance level associated with them. The directory location names for the resource shall correspond exactly with the resource name used in the NIM server.

Spot Resource Names and Subdirectories
Resource
Type Resource
Identifier Version
Number Maintenance
Level NIM
Resource Name Storage
Location

AIX Spot aixspot 4330 aixspot_4330 /export/spot/aixspot_4330

AIX Spot aixspot 5100 aixspot_5100 /export/spot/aixspot_5100

AIX Spot aixspot 5200 aixspot_5200 /export/spot/aixspot_5200

AIX Spot aixspot 5200 02 aixspot_5200-02 /export/spot/aixspot_5200-02

AIX Spot aixspot 5200 05 aixspot_5200-05 /export/spot/aixspot_5200-05

AIX Spot aixspot 5300 aixspot_5300 /export/spot/aixspot_5300

Suse Spot slesspot 9000 slesspot_9000 /export/spot/slesspot_9000

Table of Contents

Standards - Resource Group

Resource Group Name Standards

The concept of Resource Group is used here in a larger scope than it is used in HACMP. In Mt Xia's environment, a resource group is any logical collection of resources, this may include disk, I/O, users, applications, etc. A resource group should be viewed as being independent from any machine or data center. The resource group name is used as the basis of all other naming structures for all entities whether or not they are controlled by HACMP. The resource group name shall be an enterprise wide unique value in order to eliminate conflicts during manual, automated, or disaster recovery failovers.

When designing any new system, the first step is to determine the resource group name(s). The names of volume groups, logical volumes, mount points, major numbers, WLM classes, etc, are all derived from the resource group name(s).

The resource group name shall consist of exactly 8 characters with the following structure:

ApplicationCode + Environment + Function + Company + Sequence ID
     3 char     +    1 char   +  1 char  +  2 char +   1 char

The detailed information for each component of the resource group name is described below:

RG Name
Component Number of
Characters Values

Application Code 3 atl = Atlas ega = EGATE nim = NIM ora = Oracle tps = Maximo vio = Virtual I/O

Environment 1 a = acceptance a = pre-production d = test/development p = production t = test x = disaster recovery x = pre-production

Function 1 a = application c = combination/multi-purpose d = database m = management u = utility

Company 2 mx = Mt Xia mi = Mt Xia - India ib = IBM tw = Time Warner cg = Capgemini

Sequence ID 1 0-9,A-Z,a-z

Examples of Resource Group (RG) names:

egapdmx0
EGATE Production database RG for Mt Xia, first instance: EGATE Production database RG for Mt Xia, first instance
egapdmx1
EGATE Production database RG for Mt Xia, second instance: EGATE Production database RG for Mt Xia, second instance
nimpuib0
Network Information Manager production utility RG for IBM, first instance: Network Information Manager production utility RG for IBM, first instance
nimpuib1
Network Information Manager production utility RG for IBM, second instance: Network Information Manager production utility RG for IBM, second instance
viopuib1
Virtual I/O production utility RG for IBM, first instance: Virtual I/O production utility RG for IBM, first instance
viopuib2
Virtual I/O production utility RG for IBM, second instance: Virtual I/O production utility RG for IBM, second instance
viopuib3
Virtual I/O production utility RG for IBM, third instance: Virtual I/O production utility RG for IBM, third instance
viopuib4
Virtual I/O production utility RG for IBM, fourth instance: Virtual I/O production utility RG for IBM, fourth instance
vioauib1
Virtual I/O acceptance utility RG for IBM, first instance: Virtual I/O acceptance utility RG for IBM, first instance
vioauib2
Virtual I/O acceptance utility RG for IBM, second instance: Virtual I/O acceptance utility RG for IBM, second instance
vioauib3
Virtual I/O acceptance utility RG for IBM, third instance: Virtual I/O acceptance utility RG for IBM, third instance
vioauib4
Virtual I/O acceptance utility RG for IBM, fourth instance: Virtual I/O acceptance utility RG for IBM, fourth instance
tpspdmx0
Maximo production database RG for Mt Xia, first instance: Maximo production database RG for Mt Xia, first instance
tpspdmx1
Maximo production database RG for IBM, second instance: Maximo production database RG for IBM, second instance

Table of Contents

Standards - WLM AIX 433

Workload Manager for AIX 4.3.3.0 Standards

This document describes the Workload Manager implementation standards on AIX 4.3.3.0 machines only.

For WLM implementation on AIX version 5 systems, see the AIX 5 WLM standards document.

The workload manager (WLM) shall be implemented on all AIX systems. On most systems WLM will be running in "passive" mode, which does not limit resources. In Mt Xia's environment, only a few selected systems will have WLM implemented in "active" mode to control and regulate resources. If there is any question as to whether WLM should be implemented in "active" or "passive" mode, default to "passive".

The WLM provides a mechanism to classify and segment resources by process, user, group, etc. The classification scheme must be constructed by the AIX system administrator. This WLM classification scheme in the Mt Xia environment is based on the concept of the Resource Group. Each Resource Group will be represented in WLM as a class. Multiple instances of an application within a single resource group shall be represented in WLM as subclasses.

In order to configure WLM, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a WLM class must be defined using the resource group name as the WLM class name.

To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Add a class" to define a new WLM class.

                              Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The CPU and Memory values will be defaulted to a minumum of 0% and a maximum value of 100%.

                                  Add a Class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
  Class name                                         [atladmx1]
  Description                                        [Atlas pre-prod Database for Mt Xia, instance 1]
  Tier                                               [0]
  Minimum CPU time (%)                               [0]
  Maximum CPU time (%)                               [100]
  Shares of CPU                                      [1]
  Minimum Memory (%)                                 [0]
  Maximum Memory (%)                                 [100]
  Shares of Memory                                   [1]

Class rules are used to determine which processes are assigned to which WLM classes and the order of the rules is significant. The first rule that matches is used to determine the WLM class assignment, so the class rules should be ordered from highly specific to less specific.

To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Class assignment rules" to define a new WLM class.

                              Workload Management

Move cursor to desired item and press Enter.

  List all Classes
  Add a Class
  Change / Show Characteristics of a Class
  Remove a Class
  Class Assignment Rules
  Start/Stop/Update WLM

Select "Class assignment rules" to define a new WLM class rule.

                             Class Assignment Rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule

In the following example, a rule is defined to assign all processes owned by oracl817 to the the WLM class "atladmx1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                               Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the Rule                                  [1]
* Class                                              [atladmx1]
  User                                               [oracl817]
  Group                                              [-]
  Application                                        [-]

Under AIX 4.3.3.0, to start WLM in passive mode, it must be done from the command line. If WLM is started from "smitty", it will be started in "active" mode. So to be safe and exact, always start/stop WLM from the command line using the appropriate flags.

To start WLM from the command line in "passive" mode:

wlmcntrl -p

To start WLM from the command line in "active" mode:

wlmcntrl -a

To stop WLM from the command:

wlmcntrl -o

Any changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

An example WLM configuration of the Atlas pre-production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains five WLM classes. It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

The AIX 4.3.3.0 WLM does not support the concept of subclasses, therefore multiple instances of an application will likely be configured as multiple WLM classes, requiring multiple resource groups. Since the AIX 4.3.3.0 WLM does not support subclasses, the WLM configuration will be different between AIX 4.3.3.0 and AIX 5.X systems.

daladatl01:/etc/wlm/standard/classes

System: Default: atladmx1: description = "Atlas pre-prod Database for Mt Xia, AMST instance" atladtu2: description = "Atlas pre-prod Database for Mt Xia, C2KR instance" atladtu3: description = "Atlas pre-prod Database for Mt Xia, ATLP instance": System: Default: atladmx1: description = "Atlas pre-prod Database for Mt Xia, AMST instance" atladtu2: description = "Atlas pre-prod Database for Mt Xia, C2KR instance" atladtu3: description = "Atlas pre-prod Database for Mt Xia, ATLP instance"

The class rules associated with this "standard" configuration assign processes to multiple classes depending upon the user id. Rules are defined to segment the processes owned by the three oracle instances into separate WLM classes. All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

daladatl01:/etc/wlm/standard/rules

* class resvd user group application atladmx1 - oracl817 - - atladtu2 - oracle8i - - atladtu3 - oracle - - System - root - - Default - - - -: * class resvd user group application atladmx1 - oracl817 - - atladtu2 - oracle8i - - atladtu3 - oracle - - System - root - - Default - - - -

Table of Contents

Standards - WLM AIX 5

Workload Manager for AIX 5L Standards

This document describes the Workload Manager implementation standards on AIX version 5 machines only.

For WLM implementation on AIX version 4.3.3.0 systems, see the AIX 4.3.3.0 WLM standards document.

To define a new WLM class using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Add a class" to define a new WLM class.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

Enter the resource group name as the WLM class name, and provide a description of this WLM class. The Tier level will normally be 0 (zero) unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".

The user and group values will be dependent upon the nature of the resource group. It may be desirable to specify a non-root user and group that is permitted to administer the WLM class and/or assign processes to the class. This will have to be determined on a resource group by resource group basis. If this information is unknown, default to "root" for the user values and "system" for the group values.


                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdmx1]
  Description                                            [EGATE Production Database for Mt Xia, Instance 0]
  Tier                                                   [0]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

To define WLM class rules using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Class assignment rules" to define a new WLM class.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

Select "Class assignment rules" to define a new WLM class rule.

                             Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM class "egapdmx1". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                               Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          [egapdmx1
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

To define a new WLM subclass using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Add a class" to define a new WLM subclass.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

When defining a subclass, again enter the resource group name, followed by a period (.) followed by the name of the subclass to create. The Tier level will normally be 1 (one) for a subclass, unless there is a specific reason to change this. The "Resource Set Inheritance" value will normally be set to "Yes".


                       General characteristics of a class

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                         [Entry Fields]
* Class name                                             [egapdmx1.oracleex511]
  Description                                            [EGATE Production Database for Mt Xia, Instance 511]
  Tier                                                   [1]
  Resource Set                                          
  Inheritance                                            [Yes]
  User authorized to assign its processes to this class  [oracle]
  Group authorized to assign its processes to this class [dba]
  User authorized to administrate this class             [root]
  (Superclass only) 
  Group authorized to administrate this class            [system]
  (Superclass only)
  Localshm                                               [No]

To define a class rule for a subclass requires an additional step. First select a set of WLM subclasses to work on, then define the rule. To define a rule for a WLM subclass using smitty, start smitty using the "wlm" fastpath.

smitty wlm

Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

Select the WLM class that contains the subclass for which the rule will be defined, press enter, then return to the main WLM menu.

                            Select a Superclass or -

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Superclass name                                    [egapdmx1]

Select "Class assignment rules" to define a new WLM subclass rule.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets
  
  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)
  
  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

Select "Class assignment rules" to define a new WLM subclass rule.

                             Class assignment rules

Move cursor to desired item and press Enter.

  List all Rules
  Create a new Rule
  Change / Show Characteristics of a Rule
  Delete a Rule 
  Attribute value groupings

In the following example, a rule is defined to assign all processes owned by oracle or the group dba to the the WLM subclass "egapdmx1.oracleex511". Again the order of the rules is important. The rules should be ranked in order of highly specific, starting at 1, to less specific.

                               Create a new Rule

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Order of the rule                                  [1]
* Class name                                          oracleex511
* User                                               [oracle]
* Group                                              [dba]
  Application                                        [-]
  Type                                               [-]
  Tag                                                [-]

After all classes, subclasses, and rules have been defined, start WLM.

smitty wlm

Select "Work on a set of Subclasses" to select the subclass for which to define a rule.

                                Workload Manager

Move cursor to desired item and press Enter.

  Manage time-based configuration sets

  Work on alternate configurations
  Work on a set of Subclasses
  Show current focus (Configuration, Class Set)

  List all classes
  Add a class
  Change / Show Characteristics of a class
  Remove a class
  Class assignment rules

  Start/Stop/Update WLM
  Assign/Unassign processes to a class/subclass

Select "Start Workload Manager"

                             Start/Stop/Update WLM

Move cursor to desired item and press Enter.

  Start Workload Manager
  Update Workload Manager
  Stop Workload Manager
  Show WLM status

For the options on this page, select the "current" configuration set, choose the "Passive" management mode, and choose "Both" for the start option.

                             Start Workload Manager

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
  
                                                        [Entry Fields]
* Configuration, or for a set: set name/currently     current
      applicable configuration
  Management mode                                     Passive
  Enforce Resource Set bindings                       Yes
  Disable class total limits on resource usage        Yes
  Disable process total limits on resource usage      Yes
  Start now, at next boot, or both ?                  Both

Any subsequent changes to the WLM configuration will require that WLM be stopped and restarted in order for the changes to take effect.

An example WLM configuration of the EGATE Production Database server for Mt Xia follows. The "standard" WLM configuration for this machine contains a single WLM class called "egapdmx1". It is important to recognize that the "standard" WLM configuration will be different for every machine. The term "standard" is used in reference to the local machine, this is not enterprise wide terminology used here.

bosapega01:/etc/wlm/standard/classes

System: Default: Shared: egapdmx1: description = "Oracle Concurrent" inheritance = "yes" authuser = "oracle" authgroup = "dba" adminuser = "root" admingroup = "system": System: Default: Shared: egapdmx1: description = "Oracle Concurrent" inheritance = "yes" authuser = "oracle" authgroup = "dba" adminuser = "root" admingroup = "system"

The class rules associated with this "standard" configuration assign any processes owned by "oracle" or by the group "dba" to the WLM class "egapdmx1". All processes owned by "root" are assigned to the class "System", and all other processes are assigned to the class "Default".

bosapega01:/etc/wlm/standard/rules

*class resvd user group application type tag egapdmx1 - oracle dba - - - System - root - - - - Default - - - - - -: *class resvd user group application type tag egapdmx1 - oracle dba - - - System - root - - - - Default - - - - - -

Multiple subclasses are defined for the class "egapdmx1". These subclasses are intended to segment the processes by oracle instance. The definition of subclasses will be customized for each individual resource group.

bosapega01:/etc/wlm/standard/egapdmx1/classes

Default: Shared: oracleex011: description = "Instance ex011" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex061: description = "Instance ex061" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex071: description = "Instance ex071" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleexa11: description = "Instance a11" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex031: description = "Instance ex031" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex041: description = "Instance ex041" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex051: description = "Instance ex051" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba": Default: Shared: oracleex011: description = "Instance ex011" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex061: description = "Instance ex061" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex071: description = "Instance ex071" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleexa11: description = "Instance a11" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex031: description = "Instance ex031" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex041: description = "Instance ex041" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba" oracleex051: description = "Instance ex051" tier = 1 inheritance = "yes" authuser = "oracle" authgroup = "dba"

The rules associated with each subclass of the class "egapdmx1" associate all processes owned by "oracle" or the group "dba" to the subclass. In this instance the processes are not automatically assigned to subclasses by WLM, instead they are assigned by the oracle startup script.

bosapega01:/etc/wlm/standard/egapdmx1/rules

*class resvd user group application type tag oracleex011 - oracle - - - - oracleex031 - oracle - - - - oracleex041 - oracle - - - - oracleex051 - oracle - - - - oracleex061 - oracle - - - - oracleex071 - oracle - - - - oracleexa11 - oracle - - - -: *class resvd user group application type tag oracleex011 - oracle - - - - oracleex031 - oracle - - - - oracleex041 - oracle - - - - oracleex051 - oracle - - - - oracleex061 - oracle - - - - oracleex071 - oracle - - - - oracleexa11 - oracle - - - -

Table of Contents

Standards - VG Name

Volume Group Name Standards

This document describes the standards for assigning AIX Volume Group (VG) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This VG naming standard provides the mechanism to assign enterprise wide unique names to all AIX VG's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

To assign enterprise wide unique VG names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a VG name may be defined based on the resource group name.

A single system may contain multiple resource groups, and typically there will be one VG defined per resource group. However, a resource group may contain several VG's, depending upon the requirements of the application.

To define a VG name, obtain the 8 character resource group name, then add a 2 digit volume group sequence number that will uniquely identify the VG, followed by the characters "vg". The VG name will always end with the characters "vg".

The VG name shall consist of exactly 12 characters with the following structure:

ApplicationCode + Environment + Function + Company + Sequence ID + VG Sequence ID + "vg"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    +      2 char    + 2 char

As an example, a resource group named "egaapmx0", may have multiple associated VG's:

RG Name
Component VG Sequence
Identifier LV Identifier VG Name

egaapmx0 00 vg egaapmx000vg

egaapmx0 01 vg egaapmx001vg

egaapmx0 02 vg egaapmx002vg

Each VG also requires a system or cluster wide unique Major Number. A unique major number can be generated using the following algorithm:

MajorNbr=$( print "${VGNAME}" | sum -o | awk '{ print $1 }' )

To reiterate, before creating a VG, first establish an enterprise wide unique resource group name, a VG name, and a major number. Then create the VG.

Table of Contents

Standards - LV Name

Logical Volume Name Standards

This document describes the standards for assigning AIX Logical Volume (LV) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This LV naming standard provides the mechanism to assign enterprise wide unique names to all AIX LV's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

To assign enterprise wide unique LV names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a Volume Group (VG) must be defined based on the RG name. After the VG has been created, LV's can be assigned. A VG will typically contain several LV's, and each LV will be named based on the resource group to which it is associated.

To define a LV name, obtain the 8 character resource group name, then add a 4 digit logical volume sequence identifier that will uniquely identify the LV, followed by the characters "lv". The 4 digit LV sequence identifier will consist of alpha-numeric characters and must always be exactly 4 characters in length. The LV name will always end with the characters "lv".

The LV name shall consist of exactly 14 characters with the following structure:

ApplicationCode + Environment + Function + Company + Sequence ID + LV Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    +      4 char    + 2 char

As an example, a resource group named "egaapmx0", may have a volume group named "egaapmx00vg". This volume group may have multiple LV's associated with it:

RG Name
Component LV Sequence
Identifier LV Identifier LV Name

egaapmx0 db20 lv egaapmx0db20lv

egaapmx0 db21 lv egaapmx0db21lv

egaapmx0 db22 lv egaapmx0db22lv

JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

JFS Log Logical Volume Name Standards

The following is a description of the standards for assigning AIX JFS Log Logical Volume (JFS Log LV) names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This JFS Log LV naming standard provides the mechanism to assign enterprise wide unique names to all AIX JFS Log LV's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

To assign enterprise wide unique JFS Log LV names, the system administrator must first define the resource groups names. Once the resource group names have been defined, then a Volume Group (VG) must be defined based on the RG name. After the VG has been created, JFS Log LV's can be assigned. A VG will typically contain one JFS Log LV's, however multiple JFS Log LV's can exist.

To define a JFS Log LV name, obtain the 8 character resource group name, then add the 4 digit logical volume sequence identifier that will uniquely identify the JFS Log LV, followed by the characters "lv". The 4 digit JFS Log LV sequence identifier will consist of the characters "jfs" followed by a single digit to uniquely identify the JFS Log LV. The JFS Log LV name will always end with the characters "lv".

The JFS Log LV name shall consist of exactly 14 characters with the following structure:

ApplicationCode + Environment + Function + Company + Sequence ID +  "jfs" + JFS Log Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    + 3 char +       1 char        + 2 char

As an example, a resource group named "egaapmx0", may have a volume group named "egaapmx00vg". This volume group may have multiple JFS Log LV's associated with it:

RG Name
Component JFS Log LV
Sequence ID JFS Log
LV ID JFS Log
LV Name

egaapmx0 jfs0 lv egaapmx0jfs0lv

egaapmx0 jfs1 lv egaapmx0jfs1lv

egaapmx0 jfs2 lv egaapmx0jfs2lv

JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

Table of Contents

Standards - JFS Logs

JFS Log Logical Volume Name Standards

The JFS Log LV name shall consist of exactly 14 characters with the following structure:

ApplicationCode + Environment + Function + Company + Sequence ID +  "jfs" + JFS Log Sequence ID + "lv"
     3 char     +    1 char   +  1 char  +  2 char +   1 char    + 3 char +       1 char        + 2 char

As an example, a resource group named "egaapmx0", may have a volume group named "egaapmx00vg". This volume group may have multiple JFS Log LV's associated with it:

RG Name
Component JFS Log LV
Sequence ID JFS Log
LV ID JFS Log
LV Name

egaapmx0 jfs0 lv egaapmx0jfs0lv

egaapmx0 jfs1 lv egaapmx0jfs1lv

egaapmx0 jfs2 lv egaapmx0jfs2lv

JFS filesystems will require a logical volume for the JFS log. This must also have an enterprise wide unique name.

Table of Contents

Standards - FS Mt Point

File System Mount Point Directory Name Standards

This document describes the standards for assigning AIX filesystem mount point (MtPt) directory names. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This filesystem mount point directory naming standard provides the mechanism to assign enterprise wide unique names to all AIX filesystem mount point directory's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

To assign enterprise wide unique LV names, the system administrator must first define the Resource Groups, Volume Groups, and Logical Volumes. Once these have been defined, the filesystem mount point directory names can be assigned. Typically a filesystem mount point is required for each logical volume, therefore the mount point can usually be based on the logical volume name, or at a minimum the resource group name.

To define a filesystem mount point directory name, obtain the 8 character resource group name, then depending upon the applications filesystem requirements, use the RG name as the mount point, or add sub-directories to make it enterprise wide unique.

The filesystem mount point directory name shall consist of at least 8 characters, but may be of a variable length:

/ + ApplicationCode + Environment + Function + Company + Sequence ID + ( LV Sequence ID or Directory Structure )
         3 char     +    1 char   +  1 char  +  2 char +   1 char    +      4 or more char

As an example, a resource group named "egaapmx0", may have multiple file systems associated with it:

RG Name
Component Optional
Logical Volume
Sequence ID Optional
Sub-Directories Filesystem Mount Point

egaapmx0 db2_08_01/bin /egaapmx0/db2_08_01/bin

egaapmx0 db2_08_01/data /egaapmx0/db2_08_01/data

egaapmx1 mq01 /egaapmx1mq01

egaapmx1 mq02 /egaapmx1mq02

egaapmx1 mq03 /egaapmx1mq03

Table of Contents

Standards - User/UID

User Name Standards

This document describes the standards for assigning user names and UID numbers in Mt Xia's AIX environment. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This user naming standard provides the mechanism to assign enterprise wide unique user names to all AIX users's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

Users are normally divided into two major categories on a Unix system, administrators and normal users. Applications such as databases, SAP, MQSeries, etc normally require an administration user name and possibly a group name. With each new user created on a Unix system a user ID number is assigned to that user, this user ID number is referred to as the UID number and is normally unique to that user on that one Unix system. When building highly available and/or recoverable systems, the user name and UID number must be enterprise wide unique values. Therefore a centralized user management system must be implemented to manage users and UID numbers to ensure that no two users have the same user name or UID number.

This centralized user management function is performed in Mt Xia's environment by LDAP. All user requests and assignments must be performed through the centralized user management system via the LDAP servers.

Table of Contents

Standards - Group/GID

Group Name Standards

This document describes the standards for assigning group names and GID numbers in Mt Xia's AIX environment. A single standard has been developed for use in standalone, High Availability, and Disaster Recovery environments. This group naming standard provides the mechanism to assign enterprise wide unique group names to all AIX groups's and will eliminate naming conflicts in the event of a manual or automated failover, or if multiple instances of an application are running on a single server.

Groups are normally divided into two major categories on a Unix system, administration and normal user groups. Applications such as databases, SAP, MQSeries, etc may require an administration group. With each new group created on a Unix system a group ID number is assigned to that group, this group ID number is referred to as the GID number and is normally unique to that group on that one Unix system. When building highly available and/or recoverable systems, the group name and GID number must be enterprise wide unique values. Therefore a centralized group management system must be implemented to manage groups and GID numbers to ensure that no two groups have the same group name or UID number.

This centralized group management function is performed in Mt Xia's environment by LDAP. All group requests and assignments must be performed through the centralized group management system via the LDAP servers.

Table of Contents

Standards - Security (DRAFT)

Security Standards (DRAFT) - AIX, Solaris, Linux

1 General Security Design

1.1 Environment

1.1.1	The root user's PATH variable does not include the Current Working Directory or its parent.	If the root user's PATH includes '.' or '..', the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.	The default path for the root user does not include any directories which are writable by other users.
1.1.2	Any user's PATH variable does not include the Current Working Directory unless it's the last entry in the PATH; any specific $HOME directories must be after the standard system directories and before the current directories in a user's PATH variable.	If a user's PATH includes '.' or '..', the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.	The default path for any user should not include any directories which are writable by themselves or other users until checking for system supported commands first.

1.2 Network Services

1.2.1	Insecure Sendmail configuration options such as WIZ, VRFY, EXPN and DEBUG are not used.	Several of the Sendmail commands present serious security risks. For instance, the WIZ command allows anyone who knows the "Wizard" password to log into the system, gaining command line access. VRFY and EXPN ("verify" and "expand" respectively) allow anyone to query the Sendmail server as to the names of valid accounts on the system. DEBUG allows an outsider to put Sendmail in "debug" mode and execute commands on the system.	A mail program such as smap should be used. Smap eliminates most of the security weaknesses associated with sendmail.
1.2.2	The Sendmail daemon is only used if an approved business justification exists.	The Sendmail program is the mail system's routing program. The UNIX program /usr/lib/sendmail implements both the client and the server side of the mail program. Sendmail has been the source of numerous security breaches on UNIX systems. Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.11.2 This is the latest version of Sendmail ' see www.sendmail.com	On AIX, sendmail is started by the Run Control (rc) scripts. Locate the entry for sendmail and comment it out. In order for the changes to take effect, one must either reboot or kill the currently running sendmail process.
1.2.3	The sendmail.cf file allows only a minimal list of "trusted users."	The /etc/sendmail.cf file contains configuration information necessary for sendmail to run, include options which can create security vulnerabilities in the mail system. The T configuration command identifies the "trusted users" who can override a sender's name in a mail message by using the -f option with one of their own. Trusted users are necessary for certain kinds of mail to flow properly, but other trust relationships can be added which introduce security vulnerabilities.	Remove any T sendmail.cf directives not listing uucp, root or daemon.
1.2.4	DNS is configured to disallow unauthorized zone transfers.	Zone transfers can be used by intruders to rapidly obtain a complete map of an organization's servers. Such information is commonly used by intruders to facilitate target scanning and selection during break-in attempts.	DNS is configured to prevent unauthorized zone transfers as well as log unauthorized zone transfer attempts.
1.2.5	If the WAN architecture allows access from insecure networks such as the Internet, the server's network services are either disabled or implemented in a manner which appropriately minimizes the risk of intrusion from the insecure networks.	Many network services are unnecessary and may pose a security risk if enabled on servers accessable via the Internet or high risk WAN segments.	Only network services which are necessary for business operations are active.
1.2.6	The latest available version of BIND is installed on the system	Earlier versions of UNIX BIND contained security problems which might allow an attacker to gain access to the system	The latest available version of BIND should be installed. Currently (01/17/2001/19/2000), the latest version is BIND 9.1. You can find this information at www.isc.org.
1.2.7	The Sendmail Aliases file is configured securely.	An incorrectly configured /etc/aliases file may allow unauthorized access to the system.	1) The aliases file must be owned by root and protected mode 644. Use the following command to check the file permissions: ls -l /etc/aliases They should read: "-rw-r--r--" If permissions are incorrect, change them using the following command: chmod 644 /etc/aliases 2) Review the entries in the aliases file, using vi /etc/aliases, and comment out any undesirable entries (using a text editor, place a comment "#" marker at the front of the line in question). In particular: a) Remove the decode alias, which might appear in the alias file as follows: decode: \|/usr/bin/guudecode b) Review for any other entries which execute a program. Remove if not necessary. If NIS is used, run /usr/sbin/newaliases after changing the aliases file in order to rebuild the maps.
1.2.8	The Sendmail mail queue file is configured securely, with the minimum permissions necessary for operation.	Access to the mail queue can allow users to read other users mail, gaining sensitive information or to overwrite mail messages.	Check the mail queue's permissions, by: ls -l /var/spool/mqueue/mqueue Since only the owner, root, should have access, the permissions should look like: -rwx------ If permissions are not correct, change them by: chmod 700 /usr/spool/mqueue/mqueue
1.2.9	The sendmail.cf file has secure file permissions.	If the Sendmail configuration file has improper file permissions (e.g., world writeable) there is an increased risk than an unauthorized user may gain privileged access to the system or cause a disruption of service.	The sendmail.cf file should be secured with appropriate file permissions. The /etc/sendmail.cf file must be writable only by root with permission mode 640 or 660.
1.2.10	Sendmail is implemented in a secure manner, including immediate installation of the latest security patches as they become available.	Sendmail (a mail routing daemon) has been the source of numerous security breaches on UNIX systems. Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.8.11.2 (Sendmail is currently on version 8.11.2 as of 12/29/2000 . You can find this information at www.sendmail.com.	Check www.ers.ibm.com for the latest patches; follow site instructions to install patch. Subscribe to the IBM ERS service to keep abreast of latest patches to install, as well as the CERT (www.cert.org) and Bugtraq (www.netspace.org) mailing lists for breaking news regarding Sendmail (and other) security vulnerabilities. In addition, the latest information on sendmail can be found at www.sendmail.org. Evaluate the need to run sendmail, and disable if the service is not used. If sendmail is necessary, conisder using a more secure version (e.g, Qmail) or a sendmail wrapper (smrsh, SMAP / SMAPD).
1.2.11	Unnecessary RPC services are disabled.	RPC services provide unauthenticated or weakly authenticated access to systems to remotely execute commands (Remote Procedure Calls) for distributed computing. RPC is used for services such as NFS, but can be a significant vulnerability source.	Where RPC is necessary, secure versions of RPC which implement strong authentication and encryption are used.
1.2.12	Protect against an account name/password guessing attack	Parameters in the /etc/security/login.cfg file can be set by port to delay or prohibit additional logins after a failed login.	Consider setting the parameters appropriately to protect against a guessing attack on sensitive ports (i.e. a modem port). Examine failed logins using /usr/bin/who `-s` `/etc/security/failedlogin`
1.2.13	The organizational structure of the IS and security groups provides for adequate UNIX security.	I think you wanted to say IS personnel resources are insufficient to allow for the time and effort needed to address security issues, security needs are generally assigned a very low priority.	Sufficient lets either use IS or MIS not both when talking about the same function.MIS resources should be devoted to security. Job descriptions of system, network and database administrators should include security related tasks.

1.3 Network Information Services (NIS/NIS+)

1.3.1	(If NIS is used) a current (i.e., patched) version of NIS is implemented for enterprise wide user authentication.	NIS offer a robust set of administration options that organizations can use centrally manage access to system resources. However, there are many options that need to be configured correctly to provide security over the NIS environment. Moreover, many security related vulnerabilities have been associated with NIS. Thus, if NIS is not properly configured and patched, there is an increased risk an unauthorized user could gain privileged access to system resources.	Contact your vendor for the most up-to-date patches for NIS/NIS+. To check for active NIS, use: isypset=`domainname \| /bin/grep '^[a-zA-Z]' If active, to check the NIS domainname, use: /usr/bin/domainname
1.3.2	If NIS is used, it only provides users with access to those systems they have a business need to access.	Users with domain-wide access may have privileges which go beyond their job responsibilities, including unauthorized access to sensitive files.	Limited access via NIS can be accomplished by creating one or more designated login shells on each machine. For instance, the server sales may contain the login shells /usr/local/salessh and /usr/local/salesapp, the former being a copy of /bin/sh and the latter being a shell which launches an application on this server. Most users will now have the NIS entry /usr/local/salesapp, while users requiring shell access to the server will have the NIS entry /usr/local/salessh. These users can now be administered on a domain-wide basis, but their login access is limited to the server sales. Note also that the .login/.cshrc/.profile files can play a role in controlling NIS access.
1.3.3	NIS configuration files have secure file permissions.	World-writable NIS configuration files could make it possible for an attacker to change NIS information, including adding privileged accounts.	NIS configuration files have restrictive permissions. In particular, the passwd.adjunct file is not accessible by users other than root. The umask value for the root user is set to 077 to ensure that files are created with secure default permissions.
1.3.4	NIS Master servers do not use NIS for password information.	Since NIS master servers are key to NIS security, and thus a point of compromise for the entire network, such systems should have extra security protections	NIS master servers use only local account information for authentication.
1.3.5	Root level UIDs are only defined on the local server and do not provide domain-wide access through the NIS password file.	If root IDs are implemented domain-wide using NIS, it is likely that system administrators will have privileged access to systems not required for their job functions, while the compromise of a single root account would result in the compromise of all systems in the domain.	NIS contains no root level UIDs (uid=0).

1.4 System Configuration

1.4.1	Access to the at command is limited.	The at command allow users to run commands at a later time, using the cron command queue. The unrestricted use of these commands is a security risk.	Review the at.allow and at.deny files for appropriate entries, using the cat command. If users other than root have a business need to use the at and batch commands, create the at.allow and at.deny files to control which users can use the at command. The login names of users that are allowed to use the at command must be listed in the at.allow file. The at.deny file specifies the list of denied users. These files must be owned by root and members of the sys group, with permissions mode 640. Where necessary, add entries to at.allow and at.deny using a text editor, and change permissions on these files using chmod.
1.4.2	Devices (except terminals) are not world readable, writeable or executable.	Improperly protected devices (which are represented to the UNIX OS as files) can leave systems vulnerable to attackers. For instance, if an attacker can write to the /dev/kmem device (kernel memory) with a debugger, he may be able to modify his UserID (to become root), modify data in system buffers, or write garbage over critical data structures, causing the system to crash. Similarly, unauthorized access to disk devices, tape devices, network devices and terminals being used by others can lead to problems.	Use the chmod command to set appropriate permissions on device files.
1.4.3	The network interface card should not be in promiscuous mode.	Most Ethernet cards can be placed in "promiscuous" mode, which enables a user to gather and review all Ethernet packets on the local subnetwork, including the data in those packets, such as passwords. Intruders will often attempt to install such gathering software (such as etherfind or tcpdump) upon breaking into the system, in order to gain further access.	To determine whether the network interface is in promiscuous mode, use the CPM tools, available from www.cert.org
1.4.4	Use of the mount command should not be executable by users and any untrusted file system (i.e. CD-ROMS) should only be mounted without the ability to execute suid programs.	Users can inadvertantly mount systems over one another and do not need to routinely mount file susyems. A file system mounted, such as a CD-ROM may contain suid to root programs, allowing an attacker to gain root access.	Remove the mount command from world access and require untrusted file systems to be mounted with the 'o nosuid option.

1.5 Support, Maintenance & Planning

1.5.1

Corporate IS security policies include specific sections pertaining to the UNIX environment, including configuration guidelines to significant security areas.

AIX System Administrator that does not know and understand the Corporate IS security policies may wrongly configure the AIX system and thereby expose the system to security risks.

Review the corporate information security policies and procedures to determine if sufficient support exists for a controlled environment. UNIX policies should include specific configuration guidelines, tailored to particular environments such as "file servers," "DMZ systems," etc.

1.5.2

Procedures must be implemented for the regular acquisition and installation of vendor (both IBM and third party applications) patches and upgrades necessary to correct security flaws, as well as installation of workarounds for unpatched problems.

The system may be needlessly vulnerable to security flaws discovered on an ongoing basis, in terms of both system penetration and denial of service. System crackers are aware of security flaws, and will exploit them if patches are not implemented.

Inquire about the system administrator's procedures for obtaining the latest and Inquire about the system administrator's procedures for obtaining the latest and installing the security patches and workarounds.

Review vendor resources (including www.ers.ibm.com) and security sites such as CERT (www.cert.org) and Bugtraq (www.netspace.org) for the existence of security-related system patches for the particular OS, and install said patches. If using an older version of the OS, upgrading to the latest version of the OS (plus any patches for that version is usually preferable to keeping the older version with patches. The IBM ERS web site contains (but not for any other software such as a third party Web server or for Sendmail - consult other vendors as appropriate.

Important: Some patches may change to your system configuration to insecure defaults.installing the security patches and workarounds.

Important: Some patches may change to your system configuration to insecure defaults.

1.5.3

If significant programming is done on the server, an appropriate system development life cycle and change control methodology is in place.

A disorderly development environment, including problems such as a blurring of the development and production environments, insufficient quality assurance testing, insufficient documentation, and excessive programmer privileges, can lead to a breakdown in the security of the system and the integrity of the production data.

Develop applications on a development system. (NOTE: Development system needs to be completely separate from Production system and network).

Test new application/program on the Development/Test system. Provide the test criteria and application/program documentation.

Submit program to Quality & Assurance group for testing.

Develop a migration plan to the Production system.

Prepare a back-out plan.

Notify the system administrator about the migration and the tentative date.

If all tests have been conducted and passed, submit a change request following the Change Management Process.

If all authorizations have been obtained and the date approved, migrate to production according to plan.

Verify that the migrated application is working.

Provide any required maintenance documentation to the system administrator.

1.6 Physical Access

1.6.1

The server's physical surroundings are designed for the safety and availability of the system, including cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.

If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.

Rooms containing critical servers should be climate-controlled.

If conditions are inappropriate, take steps to correct.

2 Identification

2.1 User Accounts

2.1.1	Each user has a unique user name and user ID.	UNIX tracks users by UID, rather than by username. Therefore, where users share UIDs, they may gain access to each others' files, while security administrators will not be able to track specific security events to specific users.	All server user names and UIDs are unique. The process for user addition and deletion is constructed so as to minimize the risk of duplicate user names and UIDs.
2.1.2	User account group identification (GID) codes should be greater than 100 and never be 1 or 0. User account UIDs should be greater than 100 and must never be 0.	UNIX UIDs under 100 are reserved for system accounts. By allowing users to have UIDs under 100, the risk is increased that the user will have access to information or resources that are reserved for more powerful system level accounts.	To change a user's UID or GID, use the smit tool. Next, use the chmod command to change ownership any files owned by the old UID to the new UID.
2.1.3	User names follow an organizational naming convention.	Following a pre-defined set of standards allows for the easier recognition of new accounts that may have been created in violation of policy, either by intruders or system administrators.	Best Practices call for a naming standard which makes it hard for outsiders to guess individual account names based on personal information. We have a namiming standard in the Account Management and MSB Introduction documents. You may want to reference these two documents here. This naming standard prevents outsiders' deriving user account names from publically available information such as employee names. User account names can be used in combination with password guessing and social engineering to gain unauthorized access to systems.
2.1.4	Generic or group user accounts are not used. A generic account is identified as a user account in which multiple users, on a regular basis, access and have knowledge of a single user account with a known identification/password combination.	Generic user accounts limit accountability on user actions performed while logged in as a generic user. Use of a generic account are extremely difficult to audit since it is impossible differentiate between the activities of individual users, making it a high priority target for intruders.	If a generic account is identified, perform the following: 1. Identify the purpose of the account, 2. Identify all users of the account, 3. Create unique accounts for all users of the generic account, 4. Assign appropriate rights to all new user accounts, and 5. Delete the generic account.
2.1.5	Third party tech support accounts are disabled, and only enabled temporarily as needed.	Vendor accounts are often left enabled, with default passwords shared among vendor employees and known to vendor ex-employees.	Vendor support accounts should only be enabled on a temporary basis. Support contracts with third-party vendors should be reviewed to determine liability in case a break-in takes place through the vendor's network. The third-party vendor should be contacted to determine whether secure systems practices are being followed, whether third-party security reviews have been performed, and whether such reviews are available for inspection.

2.2 System Configuration

2.2.1

Default system accounts that do not need to be used are disabled.

Default system accounts, such as daemon, bin, sys and adm, are automatically created when the AIX Operating System is installed. Many of these accounts are never logged into but are instead place holders for software ownership.

The following accounts provided by default with AIX 4.x should be disabled:

daemon, bin, sys, adm, uucp, guest, nobody, lpd.

2.2.1

All user accounts should be managed consistently to minimize inappropriate account configurations.

Managing user accounts and their associated parameters by editing the native unix files, or even the mkuser command can lead to misconfiguartions creating a security exposure.

Use the smit utility whenever its capabilitiy is sufficient. All normal administration of user accounts should utilize the smit utility.

3 Authentication

3.1 User Accounts

3.1.1

Accounts that run a single command, without authentication, are not allowed.

UNIX allows accounts that simply run a single command or application program (rather than a shell) at login. These accounts typically have no password and are used, for example, to allow people to log in as who to obtain a list of who is on the system, to log in as lpq to check the printer queue, and so on. Examples of such accounts include who, finger, lpq, mail, news, date, uptime, sync, and help. These types of accounts are often exploited by an intruder.

Delete any unauthenticated single command logins using the smit tool.

3.1.2

Dormant accounts are removed or disabled.

Dormant entries are a target for intruders, as the account user will not notice the activity.

Procedures should be in place for checking for dormant accounts on a regular basis. Same comment as 2.4.1.

3.2 Password Composition & Management

3.2.1	Passwords are not easily guessable, i.e. words found in a dictionary, or a variation on the user name; they do not pertain directly to a user's family or personal interests. While passwords should contain both alpha and numeric characters, passwords with special characters are even harder to guess or crack with a utility.	Passwords which are easy to guess give intruders an easy opportunity to break into the system.	Define password/user characteristics in /etc/security/user, /etc/security/mkuser.default, /etc/security/login.cfg Minimum requirements (defined in /etc/security/user): minlen=8 maxage=12 minage=1 maxrepeat=2 minalpha=5 minother=3 mindiff=3 maxrepeats=2 maxexpired=0 histsize=24 pwdwarntime=14 Set dictionlist= dictionary file of invalid passwords Set minimum default values for smit user field (defined in /etc/security/user) for the default stanza as follows: admin=false login=true su=false daemon=true rlogin=false sugroups=ALL ttys=ALL auth1=SYSTEM auth2=NONE tpath=noask umask=027 expire=0
3.2.2	A unique initial password must be assigned to all new accounts and all users must change their passwords immediately when using a new account for the first time and passwords are distributed in a secure manner.	If passwords are distributed in printed format or by e-mail, the likelihood is greatly increased that the information will fall into the hands of intruders, who can intercept e-mail or regularly check the office printer for password lists.	Initial system passwords should be created in a secure manner, for instance by using a random character generator. Users should be required to obtain their initial system password in person and instructed to destroy any written material which may contain their password. We have a clearly defined process for new user password creation and communication in our Account Management Policy and MSB Introduction. We need to either reference these two documents or write the appropriate guidelines.
3.2.3	Root passwords should be different for each machine.	Using the same root password on all machines can lead to compromise of all machines with the compromise of just one.	The root password is set differently on each machine. The frequency with which they are changed should be irregular and unpredictable.
3.2.4	The root account does not allow for the separation of duties.	Separation of duties is basic to security controls. The root account is all-powerful; access to this account for a subset of privileges violates this concept.	Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.
3.2.5	The shadow password file is used, with appropriate file permissions.	The standard UNIX password file is world readable, so that anyone logged into the system can read the file and attempt to crack the account passwords, including root. The shadow password file removes this threat by moving the password information to a separate file, readable only by root. If the shadow password file is accessible by other users, the value of the shadow file is lost.	Password shadowing should be in use for every account on the system. No encrypted passwords should exist in the etc/passwd file (null, * and ! only in the password field).
3.2.6	Insure proper password maintenance.	Improperly maintained passwords can result in explotitation of the system and reduce user accountability.	To scan for password inconsistencies, use: /usr/bin/pwdck ?n ALL To scan for group inconsistencies, use: /usr/bin/grpck ?n ALL Both of these will report errors but will not fix them automatically. To have the errors fixed, change the '-n' to '-y' in both cases. Review /etc/passwd, /etc/security/passwd, /etc/security/group regularly for changes

3.3 System Configuration

3.3.1

Only one root level account (UID = 0) is defined on the server.

Multiple root level accounts increase the risk that users have system access privileges not required for their job functions. In addition, intruders who target privileged accounts have multiple opportunities to gain root access. It also becomes more difficult to maintain an accurate audit trail when more than one root-level user exists on the system.

Only one account with UID=0 exists on the system.

Administrators are required to log into their own unprivileged accounts and su to root. No direct logins to the system as root are allowed.

Administrators are to never su to root from a user's session without resetting the path variable or entering the full path for each command.

4 System Access Controls

4.1 User Accounts

4.1.1	Employee accounts are removed in a timely manner after separation from employment.	Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.	Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner. Often, and particularly in large orgainzations, software to support the above processes must be acquired.
4.1.2	End users are not provided command line (shell) access to the UNIX operating system unless necessary for their job functions.	Access to the command line via a shell (the command line interpreter) increases the risk that the user can access unauthorized resources, as well as the risk to the system if an account is compromised.	The following methods, in order of effectiveness, represent best practices: 1) Replace the shell located in the last field of the password file (cat /etc/passwd). with a menu program, 2) Use the chroot command to prevent user from accessing unauthorized files, 3) Give users a restricted shell with no access to cd, rm, cat, and other sensitive commands (historical implementations of restricted shells have often been found to be ineffective). Note that restricting the shell is ineffective unless the rshd daemon is disabled on the server.
4.1.3	User configurable environment files should only be changeable by the user or root.	Only the user should have write access to these files and no other users need to be able to see them.	Group and world require no access privilieges to the following files: $HOME./.profile $HOME./cshrc. $HOME./.Xdefaults
4.1.4	The umask is set to control access to newly created files. Only the owner of a file has default permissions to read, write and execute the newly created file.	Files and directories are created with a default set of permissions; these default permissions are controlled by the umask (user mask) system variable. Often, the default permissions are far in excess of what is needed for job functions, such as default world read and write privileges, creating opportunities for access to sensitive files or compromise of other accounts including root.	The umask setting should be one of: 077 - Most restrictive, but may hinder some collaborative efforts. Only the user has any access to the files he/she creates. 027 - Somewhat less restrictive. Allows others in the user's group to read files created by the user. 022 - Less restrictive. Allows any user to read files created by the user. The umask value must be set in the system file /etc/default/login. User umasks are set in the /etc/profile file (for Bourne and Korn shell users) and in the .login or .cshrc files in the user's home directory. For files deemed sensitive or confidential, use ACLs to further refine file access permissions.
4.1.5	Employee accounts are removed in a timely manner after separation from employment.	Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.	Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner. Often, and particularly in large orgainzations, software to support the above processes must be acquired.

4.2 System Configuration

4.2.1	Any ' r ' services such as rlogin, rsh, rexec and .rhosts files are disabled.	By using .rhosts authentication on a server, a user can permit specified users on specified machines to log in to the server without entering a password. Thus, individual users can set security policy (without the system administrator's knowledge), potentially leading to loss of critical resources within that account, and potentially compromising the entire host.	Run the securetcpip command to disable the 'r' commands and deamons A cron job should be established to periodically check for, and remove, all 'r' commands such as rlogin, rsh, rexec, rcp and .rhosts files. This can be accomplished manually by issuing the following command: find / $-name .rhosts -o -name .netrc $ -print Remove any 'r' files that are not required (rm <filename>). If 'r' files are required, utilize a utility such as Tripwire to verify that the files are not modified. Where .rhosts files are permitted, they should be limited to those users with a need for UNIX r-services. This can be accomplished on a per-user basis by editing the 'rlogin=no' parameter in /etc/security/user. .rhosts files may be effectively monitored by including them in the AIX Trusted Computing Base.
4.2.2	All user shells are listed in the /etc/shells file.	The program chsh uses /etc/shells to determine which files are valid shells when the user wishes to change their shell. A user may be able to use any file as a shell if /etc/shells does not exist.	The /etc/shells file exists and contains the names of a small number of valid shells.
4.2.3	Data files are given only the minimum access permissions necessary for operation.	World writeable data files can be changed by anyone having any access to the system. Even without malicious intent, an inexperienced user may accidentally make critical changes to sensitive data files, or inadvertently allow an intruder to gain unauthorized access.	Obtain a list of world readable and writeable files and directories by: find / $-perm -0004 -o -perm -0002 $ -print >> ey.ww This command will search the file system for world readable and writeable files and send the contents to a local text file called "ey.ww". Note: exact command syntax may vary from system to system. Consult the system's man page. Also, this file may have already been created in a previous review step. Review the list for appropriateness. Change file permissions as necessary using chmod.
4.2.4	UNIX executables (e.g. /bin/sh and /usr/sbin/netstat), shell scripts (e.g. the /etc/rc scripts) and configuration files (e.g. /etc/inittab, /etc/inetd.conf, .profile and .login) are given only the minimum privileges necessary for operation.	World writeable binaries and shell scripts can be changed or replaced with command files to give the intruder further access, or to damage the system (a.k.a. a "Trojan horse"). In any event, inexperienced users may accidentally damage the system or make hard to trace bugs due to critical files.	Executables and shell scripts generally should not be world writeable, e.g., those in /bin, /usr/sbin, /dev, (although some devices may need to be world writeable), /etc, /etc/conf, /etc/default, /etc/init.d, /etc/log, /lib, /root, /shlib. Some key system files which should not be world writeable include /etc/passwd, /etc/group, /etc/profile, /etc/vfstab (default boot parameters), /etc/default/fs and /etc/dfs/fstypes (file system types), /etc/initab, /sbin/init and /etc/bootrc (boot script). Tools such as Tripwire ensure that system executables have not been tampered with. Alternatively, the AIX Trusted Computing Base (TCB) should be expanded to include the system executables.

4.3 Password Composition & Management

4.3.1

Account names and passwords are not embedded in scripts, files or applications.

If account names and passwords are embedded in login scripts, files or applications, anyone with read access to the scripts, files or applications (e.g. using the strings command) could extract the username and password, and gain unauthorized access to the system.

Account names and passwords should not be embedded in executables or text files, including .netrc files.

4.4 Physical Access

4.4.1	A server key lock facility is used (if available), and the key is removed and stored in a secure location.	Key lock facilities can prevent illicit or unauthorized use of the system.	Policies should be developed, implemented and effectively communicated concerning the procedures for the proper use of the key lock facility. A key lock facility is used (if available) to prevent unauthorized use or removal of a system. The key is removed and stored in a secure location.
4.4.2	The server console is physically secured within a locked facility.	With physical access to the server console, all system security can be bypassed. It may be possible for unauthorized persons to obtain confidential data located on the server, or even reboot and take control over the server giving them instant root access without a password.	Develop and implement procedures to control physical access to the system. - Servers should be located in locked rooms with physical access restricted to authorized personnel. - Key or card access to these rooms should be limited to those who have a job requirement to enter the room frequently. - Visitors and vendors should be escorted at all times. - Closed-circuit surveillance of the server room entrance should be considered.
4.4.3	The system key lock is in the secure position.	Without this preventive measure, anyone with physical access to the server could cause it to reboot off of any tape, diskette, CD-ROM or hard drive, potentially allowing access to all information stored on the server.	Ensure that the system key lock is in the secure position and that the key is removed and securely stored.
4.4.4	The server's physical surroundings are designed for the safety and availability of the system, including cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.	If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.	Rooms containing critical servers should be climate-controlled. If conditions are inappropriate, take steps to correct.

5 Resource Access Controls

5.1 System Configuration

5.1.1

Access to the Crontab command is limited. Best practices call for only the root user to have access.

The crontab command submits, edits, list, or remove cron jobs. A cron job is a command run by the cron daemon at regularly scheduled intervals. The crontab program is owned by root and run with the SUID bit set. By default, everyone on the system can use the crontab command.

Review (using cat) the files cron.allow and cron.deny, which control access to crontab. The files must be owned by root and members of the sys group, with permissions mode 640. Under AIX, the crontab access files are /etc/cron.d/cron.allow and cron.deny. The cron.allow file is checked by the system first. This file must include all of the login names (one name per line) of users allowed to use the crontab command. The root user's login name (root) must be listed in the cron.allow file. The cron.deny file must be used to list the login names of users who are not allowed to use crontab. If neither the cron.deny nor the cron.allow file exists, only the superuser can submit a job with the crontab command.

To allow root only, remove the two files:

/var/adm/cron/cron.deny

/var/adm/cron/cron.allow

Where necessary, add appropriate entries to the cron.allow and cron.deny files.

To explicity allow a user to use crontab:

touch cron.allow

put the userid in it

To explicitly deny a user:

touch cron.deny

put the userid in it

5.1.2

Idle/inactive terminals are automatically locked or logged out after a period of inactivity.

If accounts are not logged out (e.g. if the user doesn't log out at lunchtime or the end of the work day) someone with physical access to a terminal can gain access to sensitive information or install backdoors allowing later access to the account.

Idle or inactive terminals should be automatically logged out after 5-20 minutes of inactivity, depending on business needs and work patterns. (TMOUT variable for the Korn shell, TIMEOUT for the Borne shell)

6 Privileges

6.1 User Accounts

6.1.1	Membership in privileged groups is limited to users with a business necessity for such access.	Accounts listed in privileged groups, such as GID=0, have access to group writeable files created and owned by the root user. Allowing unauthorized users to have a GID=0 increases the risk that sensitive system configuration files will be changed or deleted.	Only necessary and authorized users belong to privileged groups. Membership in privileged groups should be limited to users with a business need for the access. Of particular concern on AIX are the admin, adms and audit groups, whose menbership should be tightly controlled. For the predefined AIX groups, users should be added to the staff group only, or locally created groups.
6.1.2	Regularly examine group definitions.	A common exploit is for an attacker to modify group permissions and privileges so that their activities are possibly less noticeable to the system administrator.	To examine user group definitions, use: /usr/sbin/lsgroup `-fa` `id` `users` `ALL`
6.1.3	Regularly examine user information.	A common exploit is for an attacker to modify group memberships for cracked accounts so that their activieites are possibly less noticeable to the system administrator.	To examing user information, use (single command): /user/sbin/lsuser `-fa` `id` `groups` `home` `auditclasses` `login` `su` `rlogin` `telnet` `ttys` `ALL`
6.1.4	SUID and SGID programs are used only when no other reasonable, more secure means exists for the function. Where such programs are necessary, they are implemented in a secure manner, including limiting access to such programs using group permissions.	If the SUID bit is set in the file permissions, the program executes with the permissions of the owner of the program in addition to the user executing it. For example, ps, the process status program, is SUID to root because it needs to read from system memory, something normal users are not allowed to do. The SGID bit behaves in exactly the same way as the SUID bit, except that the program operates with the permission of the group associated with the file. A vulnerability in a SUID root program (e.g.) can lead to a root-level compromise of the system. Accordingly, world writable SUID programs are especially dangerous.	Where SUID or SGID programs are necessary, restrict access to SUID and SGID programs by creating a group especially for that program. This group should have execute permissions, while 'world' should not have access to the program. The permission bits on such a program would look like: r-sr-x--- 1 root print 9872 Dec 28 17:44 print_cleaner SUID programs should NOT be shell scripts, but should be compiled from C or a similar language.
6.1.5	Disable direct logins for root.	Allowing for someone to log in directly as root is dangerous because it removes a layer of authentication and it may be more prone to a sniffing attack to capture the password.	Set 'User can LOGIN REMOTELY' = false' in SMIT CHANGE/SHOW User Characteristics Screen.
6.1.6	If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.	Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.	Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access. Use a third-party facility to further partition root functionality, if required. For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality. For sensitive data files, use ACLs to implement refined access controls. If sudo is not in use, inquire about the appropriateness of using sudo. Keep root users to a minimum. To see which userids each user can use with su, use: lsuser 'f ALL

6.2 System Configuration

6.2.1

If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.

Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.

Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

Use a third-party facility to further partition root functionality, if required. For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality.

For sensitive data files, use ACLs to implement refined access controls.

If sudo is not in use, inquire about the appropriateness of using sudo.

Keep root users to a minimum.

To see which userids each user can use with su, use:

lsuser 'f ALL

7 Accountability

7.1 Intrusion Detection

7.1.1

A regular program of logging and monitoring is in place.

Logging and monitoring is often ignored or under utilized by system administrators, as it is often given a low priority by both IS and other departments. However, it is the only way to ensure the effectiveness of security measures, provide the opportunity to react to security breaches, and collect evidence of potential intrusions.

A program of logging and monitoring is in place which includes real-time monitoring and notification of potential intrusions.

7.1.2

Log files are not world writeable.

Log files provide the system audit trail and must be properly protected from unauthorized modification.

Log files, including syslog and messages, should not be writable by users other than root. Change permissions using the command

chmod go-w syslog

7.1.3

The loginlog is not world writeable.

If the loginlog is world writeable, a intruder may delete records of their attempts to gain access, decreasing the likelihood that that their activities will be discovered.

The loginlog should not be writable by any user other than root.

Change permissions using the command

chmod go-w loginlog

7.2 System Configuration

7.2.1

The "sticky bit" is set on all world-writeable public directories.

If the sticky bit is not set on a world-writable directory, files in that directory may be renamed or removed by users other than the owner of the directory or file. Some applications create temporary files in public directories; if the sticky bit is not set, an intruder might be able to overwrite the temporary files and compromise the application.

The sticky bit should be set on all public directories which are normally world-writable, such as /tmp, /usr/tmp (/var/tmp) and /usr/spool/uucppublic. Set the sticky bit using chmod +t <name>.

No sensitive or confidential information should be written to files in these directories, since any user can read them.

7.3 Logging & Monitoring

7.3.1

Error logging should always be active.

Many times, security exposures happen because of errors made. Recording and reviewing these errors can reduce the exposure they potentially represent.

Ensure error logging is active ( the errdemon is running) and review the error log regularly.

7.3.2

Examine failed logins frequently.

Failed logins can be an indication of possible attack against the system.

Use the command:

/usr/bin/who '-s' '/etc/securtiy/failedlogin'

to generate a list of usernames that are unsuccessfully used to access the system.

8 Remote Access Management

8.1 User Accounts

8.1.1

Root login is restricted to the console.

If root login is not restricted to the console, then the list of intruders who may attempt to directly gain root access increases from only those with physical access to the system to (potentially) anyone in the world. Users may still login to an unprivileged account and su to root.

Remote logins as root are not permitted.

8.1.2

.netrc files are implemented securely.

.netrc files can be a source of security risk because of the authentication information they contain. The $HOME/.netrc file is used by the ftp and rexec commands to allow automatic login to remote hosts without specifying passwords, and contains a list of host names, login names, and unencrypted passwords and other information to use at the remote hosts. This gives anyone with read access to the .netrc file (root on the local host) the ID's and passwords of remote systems.

Forbid the use of .netrc files unless they are absolutely necessary (e.g.: the risk of disseminating remote passwords is acceptable).

To prevent the use of .netrc files, adhere to the following standards:

1. They should not contain passwords,

2. They should be 0 bytes, and

3. They should be owned by root.

8.1.3

Users such as root, as well as various system accounts, are not allowed to use FTP.

Use of FTP access through the root account allows an additional remote path to supervisor level access by an intruder. Allowing FTP from system accounts (such as bin, smtp and sys) which normally would not require FTP also create additional paths into the system without providing an offsetting business benefit.

Using a text editor, edit the file /etc/ftpusers. To disable ftp access for a particular account, add the name of the account to the file.

8.2 NFS

8.2.1	Use NFS only when necessary. Check regularly for unauthorized NFS activation and use.	The NFS service allows for users to mount a systems filesystems remotely. This service is a common way to exploit a system and gain access to private information.	To check current NFS status use: lssrc 'g nfs To check if NFS is installed, use: lslpp 'l \| /bin/grep nfs To check if NFS is active, use: lssrc 'g nfs \| /bin/grep active To display which directories are exported, use: cat /etc/xtab To display which hosts are exporting directories, use: /usr/bin/showmount If the host is a client, to show what's mounted from remote systems, use: mount \| grep 'v '^ '
8.2.2	File systems are not mounted writeable, absent a compelling business justification. Executables are mounted read only, if at all.	The default configuration of NFS is to grant full access (read, write and execute) to all hosts to a mounted file system. Thus there is a high chance of allowing access to unauthorized individuals. Unauthenticated access to server executables can lead to numerous security vulnerabilities due to flaws in the mounted programs. Program coding mistakes which can become security exploits exist (whether publicly known or not) in as many as 50% of programs.	The access control options, and recommended settings for the /etc/export and etc/dfs/dfstab files are: -ro=host, host - Exports the directory read-only. If this option is not specified, the directory is exported with read-write permission, -access=host,host - Restricts access to only the named hosts or netgroup name. If no -access option is specified, all hosts will have access. The default value allows any machine to mount the directory, -rw=host,host - Exports the directory read-write. This mode of exporting inherently lowers directory security and must be implemented with caution, -root=host,host - Allows superuser access from the named hosts. If NFS root access is not enabled for a remote NFS client, the root UID of the server is mapped to a default UID of -2 or 60001 (the nobody account) This restricts access against the superuser UID on a remote machine. Exports specifying root access are inherently less security and must be implemented with caution. The default is for no hosts to be granted root access. -secure - Requires NFS clients to use a more secure protocol when accessing the directory. Export only to fully-qualified host names to prevent spoofing. Revise where inappropriate. Use ACLs to implement refined access controls; however, if it is a heterogeneous environment, do not use ACL functions
8.2.3	NFS exported file systems are protected with access lists.	Entering a directory or filesystem in the /etc/exports file without specifying an access list allows any host to mount the directory.	NFS should be configured to allow for the minimum access necessary. The number of servers allowed to mount an exported file system whould be reduced to the minimum necessary. If the /etc/exports file does not specify a list of hosts for each exported file system, then NFS is insecurely configured. Additionally, do not use the 'root=' option unless absolutely necessary.
8.2.4	NFS mounted files and directories are configured with appropriately secure file permissions.	If individual file permissions in NFS mounted shares are not configured for security, the likelihood that unauthorized users will have access to sensitive information increases.	Files and directories on the server should be protected by setting their owner to root and their protection mode to 755 (in the case of programs and directories) or 644 (in the case of data files).

8.3 System Configuration

8.3.1	Network services, including login, telnet, FTP, and HTTP do not display system identifying banners prior to authentication. Instead, a warning message displays a warning against unauthorized use.	Servers often display sensitive information by default, such as the hostname, the OS version, and the server software version, e.g. ftp.clienthost.com, AIX4.3.3, wuftp version2.14(b9). An intruder could then attempt to exploit known vulnerabilities in these software types (available from public Internet databases). Legitimate users generally do not need to know such information. A warning message may also be necessary for subsequent prosecution of offenders.	Instead of banners that identify system type and other sensitive information, network services display generic warning banners.
8.3.2	Only necessary network services are enabled. Where necessary, services are only implemented in a secure manner, including IP filtering, TCP Wrapper, and installation with the latest software patches.	Unintended network access can be granted by computers that have more services enabled that is necessary. UNIX systems often are configured "out of the box" with numerous network services that are often unneeded, such as the Berkeley R commands (rshell, rexec and rlogin) and obsolete network testing services such as echo, discard and chargen. After installation, system administrators will often install unnecessary services, because they, or their managers, underestimate the security concerns involved. If a service is not enabled, it cannot be used to break in to the system.	Remove all unnecessary services by commenting them out of the inetd.conf file (restarting the inetd process is required at this point (kill 'HUP <pid>) or out of the appropriate boot script, as necessary (by placing a comment mark (#) at the beginning of the lines describing the service). To verify inet services running use: netserv 's 'S -X
8.3.3	Rlogin and rshell are used only if an approved business justification exists.	Rlogin and rsh provide remote virtual terminal and remote execution services similar to Telnet and rexec. However: a. rlogind and rshd do not require that the user type his login name; the login name is automatically transmitted at the start of the connection. b. If the connection comes from a trusted host (via hosts.equiv) or trusted user (via .rhosts), rlogind and rshd will accept the connection without requiring a password.	The use of rshd and rlogind is not allowed unless a viable business justification exists. Employ secure methods for remote shells and remote logins that include advanced authentication and encryption (e.g., Secure Shell- SSH).
8.3.4	Tftpd is disabled except on servers which act as a boot host. On these servers, tftp is configured securely.	The Trivial File Transfer Protocol (TFTP) is used to allow users to retrieve files without requiring an account on the remote system. TFTP is an unauthenticated file transfer service. It is commonly used for booting diskless workstations and downloading server code or fonts for X-terminals over the network. Many implementations of TFTP have security problems. In particular, unrestricted TFTP access allows remote intruders to retrieve a copy of any world-readable file without authentication, such as /etc/passwd.	If TFTP is required, restrict access to server files so that sensitive files can not be retrieved remotely via tftp. You may want to talk to Chris Watson regarding this. He may have some stuff that could help us improve this section.
8.3.5	The finger daemon is only used if an approved business justification exists, and then only in a secure manner.	The Finger daemon service allows a remote user to obtain information about local users, such as their user name, full name, home directory, last login time, and in some cases when she last received and/or read her mail. The fingerd program allows users (and intruders) on remote hosts to obtain this information.	If the finger service is necessary, a newer version should be run which requires that a user name be provided along with any request. This keeps arbitrary outsiders from obtaining a complete list of users logged in to the server.
8.3.6	The FTP daemon is only used if an approved business justification exists.	The File Transfer Protocol (FTP) allows users to connect to remote systems and transfer files. FTP may be used in either authenticated (where a plaintext username and password are required) or anonymous (no username or password required) mode, depending on system configuration. In either case, FTP allows remote access to the server's files, without secure authentication. FTP is an issue both because it allows remote users access to the file system and because legitimate users have been known to unwittingly store sensitive corporate information on publically available FTP sites.	If FTP is required, it should be enabled with the following standard: 1. Only the latest release (including patches) should be used, as various FTP servers have security bugs that allow intruders to break into the system, 2. Anonymous FTP is not allowed, and 3. The /etc/ftpusers file is utilized to restrict login from defined accounts.
8.3.7	The remote printer daemon is securely configured.	The /etc/hosts.lpd file is used to specify the remote hosts that are allowed to communicate with the lpd printer daemon and access local printer queues. An improper configuration can lead to unauthorized root access.	Edit the hosts.lpd file as necessary, using a text editor. Change file permissions using: chmod 640 /etc/hosts.lpd
8.3.8	The Rexec daemon is only used if an approved business justification exists.	The rexec (RPC remote program execution) allows users to execute commands on remote computers without prior authentication.	The use of rexecd is not allowed unless a viable business justification exists. Employ a secure methods for remote command execution that employs advanced authentication and encryption (e.g., Secure Shell- SSH).
8.3.9	The Telnet daemon is only used if an approved business justification exists.	Telnet provides remote virtual terminal service similar to that provided by a dial-up modem. Usernames and passwords are susceptible to sniffing, as they are transmitted in plaintext. On the other hand, even without a known username and password, telnet is susceptible to remote attack. Because it is significantly faster to connect with telnet than it is to call up with a modem, an attacker can try to guess more passwords in a given amount of time. Also, it is often easier (and less expensive) to call a computer anonymously on the Internet than over the phone lines.	If telnet functionality is needed, the standard telnet server is replaced with a program which encrypts passwords, such as ssh. Limit access to those accounts with a business justification through the accounts' LOGIN REMOTELY fields.
8.3.10	UUCP is only used if necessary for an approved business purposes.	All versions of UNIX provide a rudimentary form of networking called UUCP, which allows files and electronic mail to be transferred, as well as remote command execution. Installation of the UUCP subsystem is not recommended: a) there is no pairing of a single individual with a UID on UUCP, b) many UUCP systems are configured with anonymous logins. Unless UUCP is carefully configured, sensitive information can be stolen and files can be sent to your system that can compromise security.	UUCP can be disabled by changing the 'home directory' and 'shell' fields of the uucp passwd file entry to '/dev/null'. Disable UUCP-related commands such as uucp, uulog, uuname, uupick, uusend, uustat, uuto, uux, as well as commands in /usr/lib/uucp (Note that the uuencode and uudecode commands should not be disabled, as they are used by other applications such as mail clients. However, make sure that uuencode is not SUID, or else the user could accidentally create SUID executables).
8.3.11	X Windows is only used if necessary for an approved business purposes. If required, it is implemented in a secure manner, using secure shell to encrypt X traffic. Lets either use Xwindows or X Windows.	We need to have 'Impact(s)' discussed.	If X windows is not needed, it should be disabled by editing the AIX rc startup files and commenting out the line which starts X windows. If X windows is needed, it may be configured to use an encrypting "tunnel" such as Secure Shell.
8.3.12	Direct modem access to servers is only used if necessary for an approved business purpose; if necessary it is implemented in a secure manner.	It is not uncommon for systems to be configured with insecure direct modem access, either 'out of the box' or thereafter by non-security conscious administrators. Dial-up modems allow anyone who knows the correct telephone number to access the system and try to break in. For example, it is not uncommon for the modem to have no password, or a simple password such as 'guest'. Also, if improperly configured, modems may allow an attacker to call a system and obtain access to an already logged-in line that another user has unknowingly left behind.	Several options are available for increasing modem security. If practical, dial-back modems should be used. Hardware tokens is a secure way of providing remote access, and should be used if at all possible
8.3.13	hosts.equiv files are not used to establish trust relationships.	The file /etc/hosts.equiv is used to establish global, password-less trust relationships between remote systems and the server, similar to .rhosts files (the system actually checks hosts.equiv first, then .rhosts if no matches are found).	/etc/hosts.equiv files are not used to establish trust relationships between hosts. No application should need unauthenticated access to another server. If such applications exist and are mission-critical, they should be configured to make narrow use of the .rhosts feature of AIX while alternative applications are investigated or developed internally.

Table of Contents

Standards - HACMP

HACMP Standards

Mt Xia's HACMP standards are contained within the following document:

Unix-HACMP-Presentation.pdf

Table of Contents

Standards - Installation

Installation Standards

Table of Contents

Standards - Monitoring

Monitoring Standards

Table of Contents

Standards - Patch Management

Patch Management Standards

Table of Contents

Standards - Tivoli TEC

Table of Contents

Procedures

The procedures used to support the Policies, Guidelines, and Standards implemented in the Power 5 environment, are described here.

Table of Contents

Procedures - Frames

Frame Procedures

Table of Contents

Procedures - Microcode

Microcode Management

Systems without an HMC

Use IBM's Microcode Discovery Service at the following URL to determine what microcode should be updated, to retrieve the microcode, and the instructions for installing the microcode.

https://techsupport.services.ibm.com/server/aix.invscoutMDS

Set the password for the user "invscout"

passwd invscout

Clear the password administration flags on the user "invscout"
pwdadm -c invscout
Start the "invscout" daemon
invscoutd
The system is now ready for microcode discovery via the java applet
The microcode discovery service will require several pieces of information to be able to perform the survey:
- Fully qualified hostname of the system
- Password for the user "invscout"
- Port number (default: 808)
- System Model Number
  lsattr -El sys0 -a modelname -F value
- System Serial Number
  lsattr -El sys0 -a systemid -F value

Systems with an HMC

Use the facilities built into the HMC for performing microcode updates to all managed systems.

Table of Contents

Procedures - Storage

Storage Procedures

Table of Contents

Procedures - Hostname/Alias

Hostname Procedures

Table of Contents

Procedures - HMC

HMC Procedures

Table of Contents

Procedures - VIO Server

Virtual I/O Server Procedures

The procedures referenced by this document are related to the design, implementation, configuration and management of the AIX Virtual I/O Server (VIO Server).

Table of Contents

Procedures - PLM

Partition Load Manager Policies

The documents referenced here describe procedures related to the Partition Load Manager (PLM). The Partition Load Manager (PLM) provides CPU and memory resource management and monitoring across logical partitions (LPARs). Partition Load Manager allows you to effectively use CPU and Memory resources by allowing you to set thresholds for designated resources. When a threshold is exceeded, Partition Load Manager can try to assign CPU and/or Memory resources to that LPAR by using resources assigned to other LPARs that are not being used.

Table of Contents

Procedures - LPAR

Logical Partition Procedures

The procedures referenced by this document provide instructions for configuring an LPAR in several different environments. Those environments include:

Dedicated Resources
Shared Resources
Virtualized Resources

Table of Contents

Procedures - NIM

Network Information Manager Procedures

Table of Contents

Procedures - Resource Group

Resource Group Name Procedures

Table of Contents

Procedures - WLM AIX 433

Workload Manager for AIX 4.3.3.0 Procedures

WLM/Jtopas Trending Setup: Performance Data Gathering: This procedure describes how to setup the AIX Workload Manager (WLM) and Jtopas to store trending information to a central location via NFS.

Table of Contents

Procedures - WLM AIX 5

Workload Manager for AIX 5L Procedures

WLM/Jtopas Trending Setup: Performance Data Gathering: This procedure describes how to setup the AIX Workload Manager (WLM) and Jtopas to store trending information to a central location via NFS.

Table of Contents

Procedures - VG Name

Volume Group Name Procedures

Table of Contents

Procedures - LV Name

Logical Volume Name Procedures

Table of Contents

Procedures - JFS Logs

JFS Log Logical Volume Name Procedures

Table of Contents

Procedures - FS Mt Point

File System Mount Point Directory Name Procedures

Table of Contents

Procedures - User/UID

User Name Procedures

Table of Contents

Procedures - Group/GID

Group Name Procedures

Table of Contents

Procedures - Security

Security Procedures

Table of Contents

Procedures - HACMP

HACMP Procedures

Table of Contents

Procedures - Installation

Installation Procedures

Table of Contents

Procedures - Monitoring

Monitoring Procedures

WLM/Jtopas Trending Setup: Performance Data Gathering: This procedure describes how to setup the AIX Workload Manager (WLM) and Jtopas to store trending information to a central location via NFS.
WLM/Jtopas Trending Setup on VIO Server: Performance Data Gathering: This procedure describes how to setup the AIX Workload Manager (WLM) and Jtopas to store trending information from a VIO server to a central location via NFS.
AIX Workload Manager (WLM) Procedures: Procedures for configuring the Workload Manager (WLM) on an AIX Power 5 system and utilizing the information generated.
AIX 4.3.3 Workload Manager (WLM) Procedures: Procedures for configuring the Workload Manager (WLM) on an AIX Power 4 system and utilizing the information generated.

Table of Contents

Procedures - Patch Management

Patch Management Procedures

Table of Contents

Procedures - Tivoli TEC

Table of Contents

- viohdlm VIO HDLM Parms

Virtual I/O Server Procedures

The procedures referenced by this document are related to the design, implementation, configuration and management of the AIX Virtual I/O Server (VIO Server).

Table of Contents

Overview

FREE Domain Registration
included with Web Site Hosting
Tools, Social Networking, Blog
www.siteox.com

Business Web Site Hosting
$3.99 / month includes Tools,
Shopping Cart, Site Builder
www.siteox.com

*AIX^tm^mtXIA*	Site Guide \| Contact Us Mt Xia: *Technical Consulting Group*
	Business Continuity / Disaster Recovery / High Availability Data Center Automation / Audit Response / Audit Compliance


	Home About Mt Xia Mt Xia Officers Privacy Policies FAQs Contact Us Events Press Releases Business Continuity Business Continuity Planning BC Auditing BC Policies BC Guidelines BC Standards BC Procedures BC Automated Deployment Disaster Recovery Disaster Recovery Planning DR Plan Template DR Project Implementation DR Auditing DR Automated Deployment High Availability High Availability Planning HA Policies HA Guidelines HA Standards HA Procedures HA Automated Deployment Tech Support/Training AIX 4.3 Tech Support AIX 5.1 Tech Support AIX 5.2 Tech Support AIX 5.3 Tech Support HACMP 4.4.1 Tech Support HACMP 5.2 Tech Support HACMP 5.3 Tech Support Disaster Recovery Unix / Linux Shell Programming E-Business Downloads Scripts Editors Documentation Standards Project Template E-Business Methodology E-Business Model Random Fortune Cookie