Contact Us | Products/Services | Korn Shell | MicroEMACS


Mt Xia: Business Continuity/Disaster Recovery Methodologies

 

Overview

Contact Mt Xia for assistance with your Business Continuity, Disaster Recovery, and High Availability planning and implementation projects at 615.556.0456 or dfrench@mtxia.com

Current:Overview
Previous:Monitoring
Home Page

Table of Contents

  1. Overview

    1. Documentation
    2. Virtual Processor Size
    3. Overview

  2. Policies

    1. Frames
    2. MicroCode
    3. Storage
    4. Hostname/Alias
    5. HMC
    6. VIO Server
    7. PLM
    8. LPAR
    9. NIM
    10. Resource Group
    11. WLM AIX 433
    12. WLM AIX 5
    13. VG Name
    14. LV Name
    15. JFS Logs
    16. FS Mt Point
    17. User/UID
    18. Group/GID
    19. Security
    20. HACMP
    21. Installation
    22. Monitoring
    23. Patch Management
    24. Tivoli TEC

  3. Guidelines

    1. Frames
    2. MicroCode
    3. Storage
    4. Hostname/Alias
    5. HMC
    6. VIO Server
    7. PLM
    8. LPAR
    9. NIM
    10. Resource Group
    11. WLM AIX 433
    12. WLM AIX 5
    13. VG Name
    14. LV Name
    15. JFS Logs
    16. FS Mt Point
    17. User/UID
    18. Group/GID
    19. Security
    20. HACMP
    21. Installation
    22. Monitoring
    23. Patch Management
    24. Tivoli TEC

  4. Standards

    1. Frames
    2. MicroCode
    3. Storage
    4. Hostname/Alias
    5. HMC
    6. VIO Server
    7. PLM
    8. LPAR
    9. NIM
    10. Resource Group
    11. WLM AIX 433
    12. WLM AIX 5
    13. VG Name
    14. LV Name
    15. JFS Logs
    16. FS Mt Point
    17. User/UID
    18. Group/GID
    19. Security (DRAFT)
    20. HACMP
    21. Installation
    22. Monitoring
    23. Patch Management
    24. Tivoli TEC

  5. Procedures

    1. Frames
    2. Microcode
    3. Storage
    4. Hostname/Alias
    5. HMC
    6. VIO Server
    7. PLM
    8. LPAR
    9. NIM
    10. Resource Group
    11. WLM AIX 433
    12. WLM AIX 5
    13. VG Name
    14. LV Name
    15. JFS Logs
    16. FS Mt Point
    17. User/UID
    18. Group/GID
    19. Security
    20. HACMP
    21. Installation
    22. Monitoring
    23. Patch Management
    24. Tivoli TEC

    1. viohdlm VIO HDLM Parms

Overview

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.

  • Basics of Partition Load Manager Setup
    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:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    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:

    Vs = Pu / Vn

    Rules:

    1.00 Pu = 1 full power5 physical processor
    Pu < Pt
    Vn <= 64

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR
    Pt = Total number of physical processors in frame

    As an example of using this algorithm:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    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:

    Vs = Pu / Vn
    Vs = 0.5 / 2
    Vs = 0.25

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

    Another example using this algorithm:

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    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:

    Vs = Pu / Vn
    Vs = 2.5 / 5
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = Number of virtual processors assigned to LPAR

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

    Processing mode
    Dedicated
    Shared

    Processing units

    Total Managed System processing units: 16
    Minimum processing units:
    Desired processing units:
    Maximum processing units:

    Virtual processors

    Minimum processing units: 0.10
    Minimum virtual processors:
    Desired virtual processors:
    Maximum virtual processors:

    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:

    Vs = Pu / Vn
    Vs = 3.0 / 6
    Vs = 0.50

    Variable Definitions:

    Vs = Virtual processor size
    Pu = Physical processing units ( number of physical processors )
    Vn = 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:

    1. Set the password for the user "invscout"

      2. passwd invscout

    2. Clear the password administration flags on the user "invscout" 

      pwdadm -c invscout

    3. Start the "invscout" daemon 

      invscoutd

    4. The system is now ready for microcode discovery via the java applet
    5. 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

  • dalapega01
    EGATE Production database on AIX at Dallas Data Center, second instance

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

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

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

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

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

    • 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

    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  

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

    Configuring Virtual SCSI Adapters

    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.

    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.

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

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

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

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

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

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

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

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

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

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

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

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

    • 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

  • egapdmx1
    EGATE Production database RG for Mt Xia, second instance

  • nimpuib0
    Network Information Manager production utility RG for IBM, first instance

  • nimpuib1
    Network Information Manager production utility RG for IBM, second instance

  • viopuib1
    Virtual I/O production utility RG for IBM, first instance

  • viopuib2
    Virtual I/O production utility RG for IBM, second instance

  • viopuib3
    Virtual I/O production utility RG for IBM, third instance

  • viopuib4
    Virtual I/O production utility RG for IBM, fourth instance

  • vioauib1
    Virtual I/O acceptance utility RG for IBM, first instance

  • vioauib2
    Virtual I/O acceptance utility RG for IBM, second instance

  • vioauib3
    Virtual I/O acceptance utility RG for IBM, third instance

  • vioauib4
    Virtual I/O acceptance utility RG for IBM, fourth instance

  • tpspdmx0
    Maximo production database RG for Mt Xia, first instance

  • tpspdmx1
    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"

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

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

    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 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]

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

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

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

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

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

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

    Table of Contents

    Standards - JFS Logs

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

     

    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

     

    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

    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

    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

     

    For information regarding this page, contact Dana French ( dfrench@mtxia.com )
    Copyright 2008 by Mt Xia Inc, All Rights Reserved