Au086inst PDF

V3.1.0.
cover
Front cover
AIX 5L Network
Installation Management
(NIM)
(Course Code AU08)
Instructor Guide
ERC 6.0
IBM Certified Course Material

Instructor Guide
Trademarks
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX AIX 5L BladeCenter
Domino eServer Lotus Notes
Lotus Notes POWER3
PowerPC pSeries RS/6000
SP xSeries
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product and service names may be trademarks or service marks of others.
September 2005 Edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
© Copyright International Business Machines Corporation 1996, 2005. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V3.1.0.1
Instructor Guide
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Instructor Course Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Unit 1. Introduction to NIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Network Installation Manager (NIM) Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
CD Installation Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Network Installation Concepts (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
NIM Installation Concepts (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Important NIM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Listing NIM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Listing NIM Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Base Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Install Initiation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Master versus Client Initiation and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
NIM Configuration Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Introducing smitty NIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Introducing WSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Introducing the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
Release Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38
Lab Environment Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-43
Unit 2. NIM Master Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Disk Requirements for the NIM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Possible NIM Master Disk Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Other Requirements for the NIM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Laying the Groundwork for Your NIM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
NIM Master Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Setting Up Your NIM Master Using SMIT (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Setting Up Your NIM Master Using SMIT (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Generated NIM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Unconfiguring the NIM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Initial Security Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27
© Copyright IBM Corp. 1996, 2005 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit 3. Base (RTE) Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Base (RTE) Install Decisions - Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4
Base (RTE) Install Decisions - Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
Additional Base (RTE) Install Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
Basic (RTE) Install Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
Define a Client to NIM (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12
Define a Client to NIM (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
Set Up Master to Install Client (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18
NIM Master Setup Output (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25
NIM Master Setup Output (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27
Client Summary Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29
Stand-alone: Accessing SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31
HMC/LPAR: Accessing Your Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33
HMC/LPAR Opening Up Your Client's Console . . . . . . . . . . . . . . . . . . . . . . . . . . .3-35
HMC/LPAR: Accessing SMS (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-37
HMC/LPAR: Accessing SMS (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-39
SMS Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-41
Setting Your IPs (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-43
Setting Your IPs (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-45
Setting Your Bootlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-47
HMC/LPAR: Setting Your Bootlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-49
Starting Your Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-51
Initial Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-53
Monitoring Continued Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-55
Main BOS Installation Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-57
Installation and Settings Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-59
Monitoring the Rest of the Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-61
Showlog Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-63
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-66
Unit 4. Defining Additional Base Install Resources . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
Defining Resources to NIM (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Defining Resources to NIM (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Listing a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
installp_bundle Resource Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Defining a New Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
bosinst_data Resource Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Editing Your bosinst.data File (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Editing Your bosinst.data File (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20
Defining the bosinst_data Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22
image_data Resource Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24
Editing the image_data Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26
Defining an image_data Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-29
Script Resource Concepts and Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-32
iv Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
TOC Resource Group Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36

Defining a Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
Unit 5. Handling NIM Network Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
NIM Network Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
NIM Network Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Sample NIM Network Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Defining a Client on a Previously Defined Subnet . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Defining a Client on a New Network (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Defining a Client on a New Network (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Defining Networks Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Client Install IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
fb_script IP Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
/etc/resolv.conf Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Distributing Resource Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Setting Up a Distributed SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Unit 6. Implementing an Advanced Base Install. . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Customizing Your Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
PUSH Automation Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Using a PUSH During a Client Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Semi-Automating Your Installs with BOOTP Broadcast . . . . . . . . . . . . . . . . . . . . 6-12
Defining a Machine Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Installing Your Machine Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Monitoring your Machine Group Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Common Installation l Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Resetting your Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Unit 7. Using NIM for Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Disaster Recovery Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Joining the NIM Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Getting Ready for Your Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Simple NIM Client rootvg Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Recovering Your Client's rootvg - Master Side . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Recovering Your Client's rootvg - Client Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Getting Fancy on Your rootvg Backups and Restores . . . . . . . . . . . . . . . . . . . . . 7-16
Excluding Data from Your rootvg Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Utilizing Existing rootvg Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Automating Your BOS Install Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Using Your mksysb for Cloning - Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
Using Your mksysb for Cloning - Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
User VG Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30
© Copyright IBM Corp. 1996, 2005 Contents v

Instructor Guide
User VG Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-32

Backing Up and Recovering Your NIM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-34
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-38
Unit 8. LPP_SOURCE and SPOT Management . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
Code Level Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
Listing Filesets in an LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8
LPP_SOURCE Management Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11
SPOT Management Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14
Listing Fixes in an LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Creating a New LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18
Updating an LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24
Adding Fixes to an LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27
Cleaning Up Your LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-30
Removing an LPP_SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-32
Listing Filesets in a SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-34
Listing Fixes in a SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-36
Creating a New SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-38
Updating SPOT Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-41
Performing an Update All on Your SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-43
Removing a SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-45
Checking a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-47
Resource Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-49
Handling New Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-51
Handling New ML Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-53
Handling New Fix Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-55
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-58
Unit 9. Ongoing Client Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
Listing Filesets at Your Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Listing Fixes at Your Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
Adding Software to Your Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
Updating Software by Fix (APAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Updating Installed Software to Latest Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
Other Common Client Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16
Handling Version/Release Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19
Alternate Disk Install - ML Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22
Alternate Disk Install - Version/Release Updates . . . . . . . . . . . . . . . . . . . . . . . . . .9-25
Handling Installs from the Client Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-31
Appendix A. NIM in a Cluster Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Change Bundle Location Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Appendix C. Command Line Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
vi Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
TOC Appendix D. Configuring Multiple NICs with nimadapters . . . . . . . . . . . . . . . . . . D-1
Appendix E. Stand-alone Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1
Appendix F. Implementing an Alternate NIM Master. . . . . . . . . . . . . . . . . . . . . . . . F-1
Appendix G. Implementing nimsh with SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-1
Appendix H. Getting Started Back Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H-1
Appendix I. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1
© Copyright IBM Corp. 1996, 2005 Contents vii

Instructor Guide
viii Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
TMK Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX® AIX 5L™ BladeCenter™
Domino® eServer™ Lotus Notes®
Lotus® Notes® POWER3™
PowerPC® pSeries® RS/6000®
SP™ xSeries®
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product and service names may be trademarks or service marks of others.
© Copyright IBM Corp. 1996, 2005 Trademarks ix

Instructor Guide
x Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
pref Instructor Course Overview

This course teaches the student how to set up a basic NIM
environment and perform basic ongoing updates. It does not cover
problem determination as this supposedly is handled in an advanced
class that is now being developed.
Course Strategy
Overall Thoughts
This course teaches the student a lot of practical tasks that they need
to know to implement their NIM system. Not only are tasks discussed,
but potential strategy is discussed as well. Feel free to explore NIM
yourself and add in your own comments on strategy.
Handling the Tight Timing
There's a lot of material to cover in two days. This course could
almost have been extended to a three-day course, but it was decided
not to do this because there supposedly is a problem determination
course coming out as well. Hence, some advanced topics have
purposely been kept in the appendices. You probably won't have time
to cover them and, fortunately, not all students are interested in them.
Hence, if a student asks about these topics, merely refer the student to
the appendix and be available to discuss during breaks if they want to
do so. Try to level set the students upfront. This is a NIM
implementation course --- not a know everything about NIM course.
They do not have all their questions answered by the end of class, but
should have a good start toward that end.
Some students may really be interested in the material in the last
two lectures and can potentially be frustrated at not getting to it until
the end of the second day. However, remind them that many of the
new concepts they learn over the first day and a half are concepts they
can apply to those last two lectures. In fact, that's why those lectures
are shorter. It's because the students already understand many of the
concepts.
Also, think ahead for potential timing bottlenecks and make sure
you pave the way upfront before those potential bottlenecks occur. For
example, it might be a good idea to do a quick base install on one of
the machines right before you take your lunch break on the first day to
double check that no unusual network problems exist. Then, when the
students come back from lunch, their base install lab should run a lot
© Copyright IBM Corp. 1996, 2005 Instructor Course Overview xi

Instructor Guide
faster. Also consider talking with the local technician ahead of time to
double check any hardware/network issues.
Updates to this Course
This course has been totally rewritten to accommodate three
notable things: 1) make it more task-oriented and practical 2) take out
problem determination information as this is discussed in the
advanced class 3) move less important topics into the appendices or
take them out totally while moving more important topics into the
lecture material. This means that even many of your appendices have
changed.
Notice that the SP2 information was placed into the appendix.
This is because fewer folks are interested in this material than 2-3
years ago. Plus, most folks can easily scan through the appendix
material and pick this information up themselves. Finally, folks appear
to be more interested in lpp_source and SPOT management and
ongoing client updates than SP2 anymore.
Notice also that the diskless appendix was taken out. This is
because we here in the United States never get asked about this
material anymore. We've presumed folks are no longer interested in it.
If you have someone who interested, refer them to the NIM redbook.
Please Read the Instructor Notes
This course has a lot of instructor notes throughout to help the
instructor understand what's important, what's not, and potential
problem areas. Please read these before teaching. You probably won't
have time to discuss all of these notes with the students, but at least
be aware of the material in case the students ask. Obviously you as
the instructor bring your own expertise to the class and need to make
the final decision about what is taught and not taught.
xii Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
pref Course Description

AIX 5L Network Installation Management (NIM)
Duration: 2 days
Purpose
This two-day course is for support personnel who want to understand
how to do basic NIM implementation. Students learn basic NIM
concepts and how to perform basic NIM tasks such as setting up the
master, performing a base RTE and mksysb install, defining common
resources, basic lpp_source and SPOT management, and how to
handle ongoing client updates.
Lecture materials are re-enforced by students performing hands-on
exercises using AIX machines.
Audience
Network administrators, system administrators, or other personnel
responsible for the installation and maintenance of AIX code.
Prerequisites
Before attending this class, the student should:
• Have a working knowledge of AIX installation and maintenance in a
non-NIM environment
• Have a working knowledge and understanding of network
configuration and administration
• Have a working knowledge of the AIX environment and commands
• Be able to work with SMIT in configuring a system
• Be able to edit files with vi
• Understand AIX files, file systems, and directories
Objectives
After completing this course, you should be able to:
• Understand basic NIM concepts and terminology
• Setup a NIM master
• Perform a base AIX (RTE) install
© Copyright IBM Corp. 1996, 2005 Course Description xiii

Instructor Guide
• Define and utilize common NIM resources such as bosinst_data,

installp_bundle, resolv_conf and scripts.
• Understand basic NIM network issues
• Perform a NIM client mksysb backup and restore
• Perform a manual and an automated PUSH install
• Query information within lpp_sources, SPOTs and clients
• Maintain lpp_sources and SPOTs for clients at multiple levels
• Perform ongoing installation updates for lpp_sources, SPOTs and
clients
Contents
NIM Concepts and Terminology
Setting Up a NIM Master
Performing a Base AIX (RTE) Install
Defining Additional Base Install Resources
Understanding NIM Network Issues
Performing an Advanced RTE Install
Using NIM for Disaster Recovery
LPP_SOURCE and SPOT Management
Ongoing Client Updates
Curriculum relationship
• AU13: AIX 5L Basics (or equivalent experience) is a prerequisite
for this course.
• AU14: AIX System Administration I: Implementation (or equivalent
experience) is a prerequisite for this course.
• AU16: AIX System Administration II: Problem Determination is a
prerequisite for this course.
• AU07: AIX 5L TCP/IP I: Configuring (or equivalent experience) is
optional but helpful as a prerequisite for this course.
xiv Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
pref Agenda
Day 1
(01:15) Unit 1 - Introduction to NIM
(00:20) Exercise 1
(00:25) Unit 2 - NIM Master Configuration
(00:25) Exercise 2
(00:45) Unit 3 - Base (RTE) Install
(00:40) Exercise 3
(01:00) Unit 4 - Defining Additional Base Install Resources
(00:30) Exercise 4
(00:30) Unit 5 - Handling NIM Network Issues
Day 2
(00:50) Unit 6 - Implementing an Advanced Base Install
(00:30) Exercise 5
(01:00) Unit 7 - Using NIM for Disaster Recovery
(00:30) Exercise 6
(01:10) Unit 8 - LPP_SOURCE and SPOT Management
(00:40) Exercise 7
(00:30) Unit 9 - Ongoing Client Updates
(00:20) Exercise 8
© Copyright IBM Corp. 1996, 2005 Agenda xv

Instructor Guide
xvi Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
Uempty Unit 1. Introduction to NIM
What This Unit Is About

This unit introduces the NIM environment and basic NIM terminology.
It shows you how to list basic things in your NIM database. Finally, it
introduces you to your lab environment you use in class.
What You Should Be Able to Do

After completing this unit, you should be able to:
• Describe basic NIM environment
• Identify basic NIM terminology
• List basic NIM objects
• Identify basic access to your lab environment
How You Will Check Your Progress

Accountability:
• Checkpoint questions
• Lab exercise
References
Refer to IBM's AIX infocenter and www.redbooks.com Web site for the
following:
AIX Installation Guide
AIX Installation in a Partitioned Environment
AIX Commands Reference
NIM from A to Z in AIX 4.3
© Copyright IBM Corp. 1996, 2005 Unit 1. Introduction to NIM 1-1

Instructor Guide
Unit Objectives
•Describe basic NIM environment
•Identify basic NIM terminology
•List basic NIM objects
•Identify basic access to your lab environment
© Copyright IBM Corporation 2005
Figure 1-1. Unit Objectives AU086.0
Notes:
1-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
Uempty Instructor Notes:

Purpose —
Details —
Additional Information —
Transition Statement —

Instructor Guide
Network Installation Manager (NIM) Introduction
Base Install Disaster Recovery
Install Updates Diskless/Dataless
AIX Only
Master
Client/Server
Client Client
(Resource)
Figure 1-2. Network Installation Manager (NIM) Introduction AU086.0
Notes:
Basic Capabilities - NIM handles AIX-only basic installation and updates. It also handles
disaster recovery and, though rarely used anymore, diskless/dataless support.
NIM Alternatives - If you desire to manage software installations on a scale wider than just
AIX, consider investing in Tivoli's Configuration Manager or CSM. By the way, CSM utilizes
a lot of the NIM facilities to accomplish its tasks.
Linux Affiliation - You can now install an AIX machine from a Linux Server using the
nimol* commands. Refer to IBM's infocenter "Install AIX from a Linux Server" article, or one
of the nimol commands for more details.
Master/Clients - The master is where you set up and maintain your NIM environment. You
can also initiate installs from here. The NIM client can receive installs from the NIM master.
A NIM client automatically becomes a server when NIM resources are placed on it.

V3.1.0.1
Instructor Guide

Purpose — To show what NIM can do and to describe initial NIM terminology.
Details — Refer to the student notes for details.
Transition Statement — Before we can understand how network installs work, let's briefly
review the concepts behind a base CD install.

Instructor Guide
CD Installation Concepts
Upfront Intervention: Power On/Activate
Service Bootlist CD
Source Resources Installation Activity
Machine Firmware POST tests
CD Boot image Load boot image

(per bootlist)
Boot image running
(/sbin/rc.boot)
CD /usr/lib/methods -- Configure base devices
/usr/lib/drivers
CD /usr/lpp/bosinst BOS Installation Program
(bi_main)
CD /usr/sys/inst.images -- Image/Filesets to Install
(bos.rte/BOS.auoi bundle)
Figure 1-3. CD Installation Concepts AU086.0
Notes:
As you can see, the CD provides most of the resources needed for a base install. Only a
power on (or activate in case of an LPAR environment) and the setting of the bootlist is
needed. All of these resources could be found on the CD if you were to mount the CD and
look under the /usr directory. The only exception is the boot image. This boot image
appears to be in the /ppc/chrp directory. It is driven by a key shell script: /sbin/rc.boot. This
is the same /sbin/rc.boot file on your system right now.

V3.1.0.1
Instructor Guide

Purpose — To introduce a normal installation process. intervention required and resources
needed to perform an install.
Details — Most of the following information is for your reference only in case students ask
questions. You won't have time to discuss all this information in detail.
Why is a reboot required? - Reboots are required when going to install a new base, or to
upgrade to a new version or release level. This is because you need to make sure you're
using the latest install command with the latest filesets.
CD Booting Procedures - A stand-alone environment uses the default service bootlist
(F5/5) to make sure you boot from CD. The HMC/LPAR environment typically activates the
partition and goes into SMS mode. They then change the service bootlist to CD and exit
out.
This author is pretty sure that the /ppc/chrp/bootfile.exe file is the boot image, but it is
unclear whether this is the exact image used, or a copy of it.
BOS Install Program - It appears that the BOS install program is executed from the boot
image and replaces it. There are actually a few different programs that make up this BOS
install program, but bi_main is the main driver. It's a shell script in case you ever want to go
view it.
Image/Filesets - During a normal base install, the image that's installed is the bos.rte
fileset. Then, this command is used by the BOS install program to install everything in the
BOS.autoi bundle, and if requested, other bundles as well (that is, Graphics, CDE,
Server....) If interested, you could go out to the /usr/sys/inst.data/sys_bundles directory and
see what the BOS.autoi bundle would install.
Transition Statement — Now let's compare this install to a network install.

Instructor Guide
NIM Installation Concepts (1 of 2)

Upfront Intervention - Power On/Activate
Normal bootlist entX
IP of Server - direct/indirect
Machine Firmware POST tests
SPOT bootps Find Boot Image per

Server (/etc/bootptab) normal bootlist
(BOOTP)
SPOT /tftpboot/<client_name> Load Boot Image and info
Server /tftpboot/<client_name>.info file (TFTP)
Figure 1-4. Network Installation Concepts (1 of 2) AU086.0
Notes:
Key Network Differences - The network install environment is very similar to the CD
install environment. However, in a network environment no CD is available. Hence, the
resources that we use to retrieve from the CD will now have to come from two other
resources located somewhere on your NIM network: a spot and an lpp_source.
Booting Procedures - NIM uses the normal bootlist for all base installs. Setting up the
server IP either directly (for manual) or indirectly (for bootp broadcast) enables your client
to find the right server on your network when it attempts to boot over your ethernet (or other
NIC) adapter.
BOOTP/TFTP - The protocol used to find our boot image is BOOTP. TFTP is the protocol
used to transfer this boot image and the client's info file.
<client_name>.info - The <client_name>.info file is a key configuration file for your client.
It has all the information inside to help the client know what to do during the installation
process. For example, it shows where to go to mount the right spot and lpp_source in order
to complete the install.

V3.1.0.1
Instructor Guide

Purpose — To show how a network boot begins.
Details — Concentrate on the differences between the CD boot and this network boot.
Make sure they see why a SPOT is needed.
The bootp daemon refers to its /etc/bootptab configuration file to find out if it should boot a
client. More on this later. The /tftpboot/<client_name> file is the client's boot image.TFTP is
used to transfer this and the .info file to the client. TFTP is not kept wide open to security
threats as it only allows access to the /tftpboot directory via the auto set /etc/tftpaccess.ctl
file.
Transition Statement — Now that the boot image is loaded, let's see what happens next.

Instructor Guide
NIM Installation Concepts (2 of 2)

Boot Image Running

(/sbin/rc.boot)
SPOT Server SPOT --Mount Needed Resources
LPP_SOURCE LPP_SOURCE
Server
SPOT Server <spot>/usr/lib/methods --Configure Base Devices
<spot>/usr/lib/drivers
SPOT Server <spot>/usr/lpp/bosinst BOS Installation Program
(bi_main)
LPP_SOURCE <lpp_source> --Image/Filesets to Install
Server (bos.rte/BOS.autoi bundle)
Figure 1-5. NIM Installation Concepts (2 of 2) AU086.0
Notes:
The steps shown here are somewhat simplified, but they show what needs to be done in
order to accomplish the install. The boot image calls upon the methods inside the SPOT to
configure the needed devices. It then executes the installation program. The installation
program is then responsible for creating the rootvg volume group, creating appropriate
filesystems and then eventually using the lpp_source to install enough filesets to produce a
base AIX system.
This install should be equivalent to a normal AIX CD installation. The only key difference is
that enough TCP/IP information is configured to allow the NIM client to remain a NIM client
and to maintain a route back to the NIM master at the end of the install process. Plus, as
we see later, you can customize this operation significantly.

V3.1.0.1
Instructor Guide

Purpose — To continue to show how a network install works, and why SPOTS and
LPP_SOURCES are needed.
Details — Notice how similar the rest of this procedure is. The major difference is that the
needed install code comes from the SPOT and lpp_source. Hence, these resources have
to be mounted at the client.
Again, only base AIX images are installed from the lpp_source. Refer to the BOS.autoi and
other bundles in /usr/sys/inst.data/sys_bundles directory to get a feeling for what's
installed.
Transition Statement — So we can see how important the SPOT and LPP_SOURCE
resources are to our install. Let's take a look now at these two important NIM resources.

Instructor Guide
LPP_SOURCE
Directory of Installation Images to Install
Example contents:
<lpp_source_location>
installp RPMS
ppc ppc
.toc cdrecord
bos mkisofs
bos.64bit …
bos.rte
bos.rte.lvm
bos.rte.net
…
Figure 1-6. LPP_SOURCE AU086.0
Notes:
An lpp_source directory is just like an AIX install CD's /usr/sys/inst.images directory. It's
AIX installp and RPMS filesets that you can install.
The .toc file (only found in installp directories) must be kept up to date to reflect the latest
filesets found inside. Using NIM's facilities to keep this intact should work just fine.

V3.1.0.1
Instructor Guide

Purpose — To show what the contents of an LPP_SOURCE look like.
Details —
Transition Statement — Now let's take a look at another important resource - SPOTs.

Instructor Guide
SPOT
Directory of installed code used by client during installation process
<spotdir>
usr
lib lpp code to other code

construct for install
bosinst boot images (TCP/IP client
methods drivers NFS client
bi_main NIM client)
/tftpboot
spot53ML1.chrp.mp.ent
spot52ML3.chrp.mp.ent
spot52ML1.rspc.up.tok
Figure 1-7. SPOT AU086.0
Notes:
SPOT stands for Shared Product Object Tree. It is a directory of code that is used during
client booting procedures. Obviously the most important boot procedure is the base install.
Device drivers, the BOS install program and other necessary code that's needed on the
client to perform a base install are found here. When the client does the installation, it
mounts this resource in order to have the code necessary to do the installation.
The SPOT also has enough code in it (that is, bos.rte, bos.net.tcp.client, bos.net.nfs.client,
bos.nim.client) in order to make boot images that the client uses until it can manage to
mount the SPOT. Notice that many potential boot images can exist in the /tftpboot directory.
Many, smaller boot images help to save time when tftp'ing the boot image down to the
client, because the client merely loads down just the boot code it needs.

V3.1.0.1
Instructor Guide

Purpose — To discuss the contents of the SPOT resource.
Details — Since you've already discussed some of these programs in the initial concepts
diagram, you can now show the students how these programs reside inside a SPOT. Also
show that the boot images used are constructed from the code inside the SPOT. Notice
that although the boot images reside in a different directory than the SPOT, that they are
still considered to be part of the SPOT.
You may want to briefly point out that there may be several boot images that reside in
/tftpboot. Rather than constructing one big boot image, NIM uses many smaller boot
images that reflect given client environments. In this way, it takes less time to transfer the
boot image to the client.
Students may start to ask a lot of questions about levels of code here. Try to hold some of
this discussion off until the lpp_source and spot management lecture.
Transition Statement — We've seen two important NIM objects. Now, let's see what other
important objects may be found in your NIM database.

Instructor Guide
Important NIM Objects
Class: Resources Machines Network
Type: lpp_source master ent

spot stand-alone tok
mksysb diskless fddi
bosinst_data dataless atm
script generic
installp_bundle
Figure 1-8. Important NIM Objects AU086.0
Notes:
The NIM database is split into three classes: resources, machines and networks.
We've already discussed the lpp_source and the spot. A mksysb resource is a system
image backup. A bosinst_data resource allows the BOS installation questions to be
automatically answered. A script resource allows one to do post customization. An
installp_bundle resource allows one to install additional filesets after the base install goes
down.
The only two machines that are used anymore are the master (for the master) and
stand-alone (for any AIX client).
All network types are found at the client site except for generic support booting operations.

V3.1.0.1
Instructor Guide

Purpose — To briefly introduce important NIM objects.
Details — Make sure they understand the three classes and what types are. They see
these items as options on the lsnim command on the next screen.
Transition Statement — Now that we understand what's in a NIM Database, let's use a
command to list items in our database.

Instructor Guide
Listing NIM Objects

lsnim [-c][-t]
Object Class Type

master machines master
boot resources boot
nim_script resources nim_script
network1 networks ent
lpp_source530 resources lpp_source
spot530 resources spot
AllDevicesKernels resources installp_bundle
Alt_Disk_Install resources installp_bundle
App-Dev resources installp_bundle
lpar1 machines stand-alone
Figure 1-9. Listing NIM Objects AU086.0
Notes:
Listing NIM objects is easy. Merely use the lsnim command. Using the -c or -t options limits
your output by class or type, respectively.
What you see here is a typical NIM listing after setting up your NIM master and defining
your first few NIM clients.

V3.1.0.1
Instructor Guide

Purpose — To show how to use the lsnim command to list the NIM database.
Details —
Transition Statement — Now let's see how to list an individual object's attributes.

Instructor Guide
Listing NIM Object Attributes

Resources Machines
# lsnim -l spot530 # lsnim -l lpar1
spot530: lpar1:
class = resources class = machines
type = spot type = stand-alone
plat_defined = chrp connect = nimsh
arch = power platform = chrp
Rstate = ready for use netboot_kernel = mp
prev_state = verification is being performed if1 = network1 lpar1 0 ent0
location = /export/nim/spot/spot530/usr cable_type1 = tp
version =5 Cstate = ready for a NIM operation
release =3 prev_state = ready for a NIM operation
mod =0 Mstate = not running
oslevel_r = 5300-00
alloc_count =0
server = master
Rstate_result = success
mk_netboot = yes
mk_netboot = yes
Figure 1-10. Listing NIM Object Attributes AU086.0
Notes:
The lsnim -l object_name command gives you a low-level listing for any object in NIM's
database. You can list resources, machines and networks. We show you resources and
machines here. We discuss networks in another unit.
State Field - Key fields on both listings is the state field. Rstate is your resource state.
Cstate is your client state. These states determine whether your object is currently in use or
not. If it doesn't say Ready it's not ready to be used.
Other Key Fields - The location of any resource is determined by the server and location
fields. The server determines what NIM machine the resource is on. Then, the location field
helps to determine where on that server the resource resides. Another interesting field is
the oslevel_r field. This tells you what level this resource is. Finally, the alloc_count field
helps you to see if this resource is allocated to one or more clients during this timeframe.

V3.1.0.1
Instructor Guide

Purpose — To introduce important common fields in low-level listings.
Details —
Mstate - The Mstate field may or may not be accurate. That depends on whether NIM
handled the latest shutdown/reboot.
if1 - The if1 field shows what network this client belongs to, it's hostname, MAC address,
and install adapter. We discuss this information more in the network lecture.
connect - The connect field shows what protocol is used to communicate with the client
during push operations. shell means rsh is used. nimsh means nimsh is used.
Transition Statement — Installation is an important thing that NIM does. Let's see what
different install types NIM supports.

Instructor Guide
Base Installation Types
RTE MKSYSB
USE Install from Scratch Install from System Backup
Boot Image SPOT SPOT
Configure Devices SPOT SPOT
Install Program SPOT SPOT
Image to Install LPP_SOURCE MKSYSB

(bos.rte)
Other Images BUNDLES/FILESETS BUNDLES/FILESETS

(Default - BOS.autoi) (Default - none)
Customization SCRIPTS SCRIPTS
Figure 1-11. Base Installation Types AU086.0
Notes:
The two major installation types are RTE and MKSYSB. They both use very similar
resources. The key difference is in the area of the image that is installed and the normal
filesets that are installed. An RTE installs the bos.rte fileset as the image and then use the
standard AIX BOS.autoi bundle to install base AIX filesets. A MKSYSB install instead
installs the mksysb image. By default, it does not install any of the filesets in BOS.autoi
bundle.
Notice that no matter what method you use, you can customize it considerably. Hence, if
you wanted to, you could use an RTE install and with enough customization, you could
achieve the equivalent of a MKSYSB installation.

V3.1.0.1
Instructor Guide

Purpose — To show the two major install types, how they're similar, and especially how
they differ.
Details — You can see a copy of the BOS.autoi bundle in the
/usr/sys/inst.data/sys_bundles directory.
The SPOT install is supposedly going away and so is not discussed here. However, if
someone asks, the SPOT install uses the SPOT as the image to install. Again, other
resources are the same. This supposedly was originally set up for a very large customer.
This customer wanted a very fast base install and RTE wasn't fast enough. So what they
did is to install all the base code into their SPOT and then use the SPOT as the image to
install from. Since it is already installed code, the install time is about half that of a normal
RTE install if you are indeed installing the same amount of code as an RTE install.
However, remember that a SPOT requires that you have all device support inside. Hence,
you may be installing more code than you need to.
Transition Statement — Let's now see some different techniques that we can use to
initiate our install process.

Instructor Guide
Install Initiation Techniques
SPOT on
Same Subnet
Brand New Installs
Manual Bootp Push
Watch out Broadcast
Reboot N N Y
Machine
Change Bootlist N N Y
Set up IPs N Y Y
Master Client SPOT Server

Figure 1-12. Install Initiation Techniques AU086.0
Notes:
Initiating an install process really consists of the three methods shown above as well as
using a bosinst_data resource to answer the BOS install questions. For now, though, let's
just concentrate on the three install initiation methods.
Manual - The manual method doesn't automate anything, but can ALWAYS be used.
BOOTP Broadcast - The bootp broadcast method keeps you from having to set up the
Server, Client, and optional gateway IP while in SMS mode at the client. However, you still
have to reboot the client and set up the bootlist. It also requires that you have a SPOT
server on the local subnet and that you have stored the client's MAC address in the client's
definition at the master. When invoked, the client does a BOOTP broadcast over the local
subnet looking for a BOOTP server. The SPOT server replies and sends the boot image
down to the client.
PUSH - The push method automates everything, but requires that the client is a machine
that's already up and running and ideally already defined as a NIM client. Hence, it works
great for upgrades and re-installs, but is not useful for a brand new install.

V3.1.0.1
Instructor Guide

Purpose — To introduce the three standard install initiation techniques.
Details — The bootp broadcast can be used easily if a client is already up. Merely use the
bootlist command to change the boot device and IP addresses. Then, issue the shutdown
-r command at the client to start the process.
The BOOTP Broadcast method works pretty well on a new client. This is because the
bootlist is already set up to boot from your NIC. And, the IP addresses are set up to the
required "0.0.0.0" settings. Hence, when the client powers up, it searches on the local
subnet for a SPOT server to boot from. Assuming the SPOT server was set up correctly,
the install should automatically start.
Transition Statement — Let's now see what the Master versus the Client can do in this
NIM environment.

Instructor Guide
Master versus Client Initiation and Control
Master Client
Define Resources N/A
Base Install Base Install
Install Updates Install Updates
Force Push Disable Push
lsnim -l lpar1
control = master
Figure 1-13. Master versus Client Initiation and Control AU086.0
Notes:
Installations can be done from the master or client. Definitions (which include mksysb
backups) can only be done at the master.
If a procedure is initiated from the master, then you see a control attribute appear on your
client's lsnim listing, and it points to the master. If a procedure is initiated from the client,
then this attribute points to the client. Once one side has control, the other side can't do
anything. The only way to fix this is to go to the side that's in control and stop the operation
and reset the client if necessary.
The client can keep a master from performing push installations by choosing the option on
their "smitty nim_perms" menu to disable a push. This remain in effect until enabled by the
client or whenever the master does a force push.

V3.1.0.1
Instructor Guide

Purpose — To show what can be done at the client and master site and also to introduce
the concept of NIM control.
Details — Most operations can be done from either side. Obviously a client can only do
operations on itself.
Sometimes a client may know that a master is about ready to push a new upgrade on
them. And, they may not be ready yet. Disabling a push is a nice way to temporarily keep
the master from performing an operation. You could also potentially turn this on for security
reasons - to keep out unwanted intruders until you're ready for installation activity.
However, the master, as we see later on, has the ability to do a force push on the client.
A key point of interest is that you can't perform a mksysb or other VG backup from your
client. This procedure must be done at the master. This is because a mksysb backup in
NIM terminology means to define a mksysb resource and you can only do defines at the
master.
In case anyone is interested, the nimclient -P|-p command can also be used by the client to
disable/enable push permissions, respectively.
Transition Statement — Let's now take a brief look at some important security concerns
in the NIM environment.

Instructor Guide
Security Considerations
•Any user can join your network
•Any machine can download any images they want
•Use nimsh[/SSL] versus rsh
•Firewalls
–NFS shouldn't be used over a firewall
Figure 1-14. Security Considerations AU086.0
Notes:
Environment Options - By default, your NIM environment is not that secure. In the next
lecture we see how to tighten up whether or not clients can join your network and which
resources they can or can't download.
nimsh/SSL - By default, rsh is the method used to communicate with your client when
performing push operations. This means using .rhosts files which is considered insecure by
many folks. Only 5.3 allows the alternative of using the nimsh method. nimsh in and of itself
is semi-secure. It forces the person at the supposed NIM master to be root and to supply
the NIM master and client cpu_id to get in. If you desire stronger security, you can
optionally implement SSL. We won't have time in this class to discuss implementing SSL.
However, implementing SSL is not that difficult. Please refer to Appendix G Implementing
nimsh with SSL, for some basic information on how to do this.
Firewalls - Performing NIM operations over firewalls is not recommended because NFS is
not considered secure over a firewall.

V3.1.0.1
Instructor Guide

Purpose — To introduce major security issues in NIM. More is discussed on these issues
later on.
Details —
Environment Options - The top two bullets talk about how hacker clients can retrieve
security-conscious images. For example, a hacker could issue the smitty niminit command
and join your NIM network. Then, he could choose to install any mksysb image. He then
would use a maint_boot approach using his own master and SPOT (at the right release
level) to get into the image with root's authority. He now can view anything on that image he
wants.
nimsh/SSL - nimsh and rsh are protocols that are used only during NIM master push
operations. Hence, they help to control hacker masters from installing/removing software
from your client or totally re-imaging your client. nimsh is fairly secure, but SSL would
obviously tighten it up a bit. rsh is VERY insecure. Not only can a hacker master get in and
do unauthorized install work, they can use the .rhosts file to get in as root and do
ANYTHING. Hence, most folks still at 5.2 and below remove .rhosts file before/after any
NIM operation. You can run rsh and nimsh in a mixed environment according to your
clients' needs. You set this up when defining your client.
Firewalls - Working across firewalls is not encouraged in a NIM environment due to NFS
security concerns. NFS is not secure across firewall boundaries. A possible alternative is to
provide a master inside each firewall DMZ zone. Another potential alternative is to record
all the numerous, numerous ports in your firewall interface that NIM (and associated
protocols) uses. There is a document that NIM Development has put out on this. They are
right now in the process of updating it for 5.3. I presume your customer can pick this up by
calling their support center. Be aware, though, that this is not easy to implement. Many,
many ports need to be configured in their firewall interface.
Transition Statement — Now that we have a feel for common NIM terminology, let's see
what utilities we can use to configure our NIM environment.

Instructor Guide
NIM Configuration Utilities

•smitty nim
•smitty eznim
•wsm
•scripts
–nim_setup_master
–nim_setup_client
–nim_update_all
•Command line
Figure 1-15. NIM Configuration Utilities AU086.0
Notes:
There are many ways to access NIM. We concentrate on smitty nim for this class. It is
probably the most common technique in use today. smitty eznim was a technique
introduced fairly recently to address the most common reasons to use NIM. wsm is the
graphical alternative. The scripts shown are another technique introduced recently to very
quickly set up a master and clients using a lot of defaults. They've been used a lot by
contractors when setting up customer's LPARs. The nim_update_all script allows one to
easily upgrade a spot, lpp_source, master and client. However, it has some limitations
associated with it. These scripts should be easy to decipher once you've completed this
class. Finally, the command line is another very commonly used NIM technique. It's
especially useful if you need to perform several operations at once and desire to use a shell
script.

V3.1.0.1
Instructor Guide

Purpose — To introduce the different utilities that you can use to configure NIM.
Details — We concentrate on smitty nim for this course as it's commonly used and fast.
The other common technique used by more advanced customers is the command line.
A couple of command options to get you started on working with the nim commands are:
• lsnim -O <object_name> ---> to see operation codes you can use for that object.
• lsnim -q <op_code> <object_name> ---> to see the attributes possible for that
operation.
or
• lsnim -q <op_code> -t <type>
For example, let's assume we want to do a base install on our lpar1 machine. First, let's
refresh our memory on what operation code is needed, then let's identify appropriate
options to use.
lsnim -O lpar1 ---> bos_inst, cust, maint..... (all operation codes it can use)
lsnim -q bos_inst lpar1 ---> lpp_source, spot, mksysb, resolv_conf.... (all attributes it can
use)
This information is probably confusing to the students until they get through the first few
lectures. Hence, I would not discuss this now, but would merely keep this information for
your own reference.
By the way, there's an appendix in the back of the lectures that helps you and/or the
students to get started with the command line. Also, the student notes quite often show the
command line alternative to the smit screen shown on the visual. Plus, the exercises quite
often give the students the option of using either smit or the command line.
Students may also mention the nim_udpate_all script. This script at first glance appears to
do a very quick upgrade of their spot, lpp_source, master and client. However, it is
somewhat pre-canned and inflexible. We've chosen to not even show it to the students
during this class timeframe. We teach them alternative approaches to perform upgrades in
their environment.
Transition Statement — Let's look at smitty nim in a little bit more detail.

Instructor Guide
Introducing smitty NIM
Network Installation Management
Configure the NIM Environment

Perform NIM Software Installation and Maintenance Tasks
Perform NIM Administration Tasks
Create IPL ROM Emulation Media
Figure 1-16. Introducing smitty NIM AU086.0
Notes:
Use Configure the NIM Environment to configure your NIM master.
Use Perform NIM Software Installation and Maintenance Tasks for all types of installations.
Use Perform NIM Administrations Tasks to define any new object, such as a new client or
resource. You can also use it to perform unusual operations.
Create IPL-ROM Emulation Media isn't used anymore. It was used a long time ago with
REALLY old levels of firmware that wouldn't support a network boot.

V3.1.0.1
Instructor Guide

Purpose — To show smitty nim's main menu.
Details — Briefly introduce the information on this screen.
Note: smitty nim can be reached manually by going to smit, then Software Installation and
Maintenance. Then, choose Network Installation Management.
Transition Statement — Let's take a quick look at another utility: wsm.

Instructor Guide
Introducing WSM
Network Installation Manager
Overview and Tasks

(Configure Master) Resources Networks Machines
Figure 1-17. Introducing WSM AU086.0
Notes:
WSM is organized by object rather than by task. The Overview panel is where you
configure your master. After that, you probably go to one of the other three options to work
with that object type. The most common object type, machines, is shown here on this
screen. The Resources and Network screens would look similar.
NIM works similar to other WSM screens. To add a new machine, go to the machines tab at
the top and select to define a new machine. To perform all other tasks, click the machine of
interest and then either right-click or choose the selected menu at the top. Notice the
pop-up window that appears. From here, you can do all kinds of things with your machine,
including installation tasks or machine administration tasks, such as looking at or changing
your machine's properties or even deleting the machine definition.
Another nice thing about this screen is that you have the ability to monitor the status of your
machine during an install. The Cstate field is viewable from the State field next to each
client machine.

V3.1.0.1
Instructor Guide

Purpose — To show basic WSM organization and how to get common tasks done.
Details — Point out where to go to configure the NIM master. Then, point out that WSM is
object-oriented versus smit's task orientation. Hence, you need to go to the right panel to
perform your task. The panel shown here is the machines panel. Then, mention the
important information in the student notes.
Transition Statement — Now, let's briefly introduce using NIM from the command line.

Instructor Guide
Introducing the Command Line

•Major Commands:
–nimconfig - Configure NIM master
–nim - Most operations from master
–nimclient - Most operations from the client
•Major nim Operations:

–define, bos_inst, cust
Example:
nim -o bos_inst -a spot=spot530 \
-a lpp_source=lpp_source530 \
lpar1
Figure 1-18. Introducing the Command Line AU086.0
Notes:
There are three major commands in nim. The command you especially want to know is
nim. It defines your objects. It also performs your installation tasks. The key is in finding out
what operation to use. The three most common operations are shown. The define
operation allows you to define an object. The bos_inst operation performs a base install.
The cust operation performs additional installation tasks.
The example shown is a very simple Base install on the client lpar1, using a spot and
lpp_source.
We show the command line version of smit screens in your student notes throughout the
course.

V3.1.0.1
Instructor Guide

Purpose — To briefly introduce how to use the command line.
Details — The students can't absorb the command line details yet. Hence, merely discuss
the basics on the screen and tell the students that most smit screens in this course show
an associated command line alternative in their student notes.
For your reference only (in case the students ask later on):
Here's some information to get you started.
WORKING WITH AN EXISTING OBJECT:
lsnim -O <object_name> ---> to see operation codes you can use for that object.
lsnim -q <op_code> <object_name> ---> to see the attributes possible for that operation.
For example, let's assume we want to do a base install on our lpar1 machine. First, let's
refresh our memory on what operation code is needed, then let's identify appropriate
options to use.
lsnim -O lpar1 ---> bos_inst, cust, maint..... (all operation codes it can use)
lsnim -q bos_inst lpar1 ---> lpp_source, spot, mksysb, resolv_conf.... (all attributes it can
use)
DEFINING A NEW OBJECT
Use the define operation code.
Find out the appropriate type to use. A few common types are standalone to define a client,
spot to define a spot, and lpp_source to define an lpp_source. Refer to the nim man page
for extra help here.
lsnim -q define -t <type> ---> to see attributes to use on the define operation code
because when working with the define operation code there is
no object yet in your NIM database. The type would be
stand-alone to define a machine, spot to define a spot and so
forth. See the nim man page for appropriate types to use.
Example Definition:
nim -o define -t spot -a server=master \
-a location=/export/nim/spot \
-a source=lpp_source530 spot530
Again, this information is probably confusing to the students until they get through the first
few lectures. Hence, I would not discuss this now, but would merely keep this information
for your own reference.
Transition Statement — Now that we've viewed the three most common NIM utilities, let's
discuss one more major topic: Release Considerations.

Instructor Guide
Release Considerations
Keep NIM Master at the latest level you plan to support
5.1 - RPMS code can now be installed
5.2 - Can back up multiple mksysbs at a time

lpp_source Management Tools
Resource Groups
Easy Configuration Utilities (smitty eznim/scripts)
5.3 - nimsh
Alternate NIM master
Figure 1-19. Release Considerations AU086.0
Notes:
5.1 - AIX V5 introduced the ability to install RPMS filesets.
5.2 - NIM V5.2 allows you to define multiple resources at a time. This significantly effects
how many simultaneous mksysbs you can do. Another nice feature are some new
lpp_source tools to add/remove and cleanup filesets from your lpp_source. Resource
Groups allow you to group resources together for a particular operation. Finally, smitty
eznim and those configuration utilities mentioned earlier in this lecture were introduced in
5.2.
5.3 - NIM 5.3 introduced an alternative to using rsh for push operations - nimsh. It also
introduces a facility to do a partial cpu takeover of the NIM environment.

V3.1.0.1
Instructor Guide

Purpose — To briefly introduce what each level supports.
Details — You don't have to cover this in detail. Just let your students know they can use
this as a reference in case all their machines are not at the latest level.
This screen covers major changes only. Refer to the Installation Guide for additional
information.
There's an appendix in the back that talks about setting up an alternate NIM master. We
won't be discussing this in detail in this class as it does not appear to do a total recovery of
a NIM master. Refer to the unit on Disaster Recovery and the appropriate appendix for
more details.
Transition Statement — Before heading into lab, let's briefly review the two lab scenarios
and identify which one is ours.

Instructor Guide
Lab Environment Basics
Stand-alone HMC/LPAR
Environment Environment
NIM Master Stand-alone AIX Partition
Machine
NIM Client Stand-alone AIX Partition
Machine
Terminal Log in to CDE Log in to PC
Use Terminal Start up PuTTY
Emulator Log in to AIX
Session machine
Figure 1-20. Lab Environment Basics AU086.0
Notes:
Before we get into lab, let's review what our environment is. This environment affects how
we start up a terminal session. Later on, we see that this environment also affects how we
reach our console, get into SMS, and reboot our client. Fortunately, both environments are
described in this course.

V3.1.0.1
Instructor Guide

Purpose — To briefly introduce their lab environment so they're not confused when starting
their lab.
Details — Notice how the NIM master and client are either a standalone machine or a
partition. Notice also that the procedure they use to reach a terminal session is different
depending on whether they're using a stand-alone machine or an HMC/LPAR environment.
Transition Statement — Let's now do a brief checkpoint activity to review our material.

Instructor Guide
Checkpoint Questions
Exercise -- Unit 1 Checkpoint
1. T/F NIM can handle base installs, disaster recovery and ongoing
installation updates for your clients.
Correct Answer: True.
2. T/F A network install is very similar to a CD install. The major
difference is that the BOS install program and installation images
come from NIM's SPOT and lpp_source resources.
Correct Answer: True. Much of the methods are similar. The
biggest difference in NIM is that it doesn't have a CD to use, so it
compensates by using NIM resources instead.
3. What command would you use to list all the NIM objects?
___________________________________________
Correct Answer: lsnim
4. T/F The major difference between an RTE and MKSYSB install is
that an RTE install installs code from scratch whereas a mksysb
install installs code from a mksysb image.
5. Which base install initiation method provides the most automation:
manual, bootp broadcast or a push?
____________________________________________________
Correct Answer: Push. However, this only works with AIX
machines that are up and running.
6. T/F Your initial NIM environment provides security to keep client
hackers from joining your network and installing any image they
want.
Correct Answer: False. You must go to NIM's environment
options at your NIM master to adjust these security settings.
7. T/F NIM can be configured and utilized via many techniques
including smit, wsm and the command line.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
Having completed this unit, you should be able to:
•Describe the basic NIM environment
•Identify basic NIM terminology
•List basic NIM objects
•Identify basic access to your lab environment
Figure 1-21. Unit Summary AU086.0
Notes:

Instructor Guide
Instructor Notes:
Purpose —
Details —

V3.1.0.1
Instructor Guide
Uempty Unit 2. NIM Master Configuration

This unit covers all major issues that deal with setting up your NIM
master.

• Identify NIM master requirements
• Configure/unconfigure NIM master
• Set up important initial security options

Accountability:
• Lab exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-1
Instructor Guide
Unit Objectives
•Identify NIM master requirements
•Configure/unconfigure NIM master
•Set up important initial security options
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Disk Requirements for the NIM Master

Only Official Guideline: >=1 GB Disk Space
Some Considerations: 1. 3 GB per base lpp_source
2. More if optional lpp_sources
3. .5 GB per spot
4. .5 GB+ per mksysb
5. Other resource space is negligible
6. Add in buffer for growth, mistakes and so forth
Example: 9 GB = lpp_source520Base, lpp_source520ML3, lpp_source530ML1
1 GB = spot520ML3, spot530ML1
10 GB = 10 client mksysbs
5 GB = Buffer
______
25 GB
Figure 2-2. Disk Requirements for the NIM Master AU086.0
Notes:
There are no official guidelines because NIM environments vary so much. What's listed
here are some considerations in planning disk space at your NIM master. The two biggest
resources to consider are your lpp_sources and mksysb/uservg backups, if used.
The 3 GB per base lpp_source is based on using only three AIX CDs and then adding in a
buffer for extra support and some fixes. Since most of your core support is found on the
first two AIX CDs (2X700 MB), you still have 1.5 GB to download extra code, extra
language filesets, and/or some fixes. Be careful, this is ONLY an estimate. Please adjust
this figure for your environment.
A mksysb backup on a base RTE install only takes up about .5 GB. However, if one adds in
more bundles and/or more user data, this size can grow dramatically. Fortunately, the
mksysb command attempts to compress the output a bit. The example shown assumes a
base install with a reasonably small amount of extra code and data.
VG backups are not a part of the formula shown on the screen. If you're using NIM to back
up your user volume groups, please add in space requirements for these as well.

V3.1.0.1
Instructor Guide
Uempty Once you identify the client levels you need to support and have set up an lpp_source and
spot strategy (to be discussed more in a later lecture), then you can figure out how many
lpp_sources, spots and mksysbs you need to support. Merely add up the space for each.
Instructor Guide
Instructor Notes:
Purpose — To introduce some considerations on planning for disk space on their NIM
master.
Details — There are no official guidelines because environments vary widely. However,
students continue to ask for some guidelines. That's why this screen was introduced.
Please tell the students these are ESTIMATES only and not official guidelines!! Reinforce
to them that they need to adjust these figures for their specific environment.
Transition Statement — Now that we know the space required, let's look at a possible
disk layout.

V3.1.0.1
Instructor Guide
Uempty
Possible NIM Master Disk Layout
rootvg nimvg
/export/nim
spot lpp_source mksysb installp_bundle
spot520ML3 spot530ML1 lpp_source520ML3 lpp_source530ML1 clientA clientB
Figure 2-3. Possible NIM Master Disk Layout AU086.0
Notes:
When setting up your NIM master, it's important to decide where you want your resources
to reside. By default, they are put into the rootvg volume group. This is probably not as
ideal if you plan to do quick imports/exports of just your NIM data. In addition, it creates a
filesystem for both your spot and lpp_source resources. Instead, you may want to create
one big filesystem for all NIM resources.
Note that all resources are horizontally located. There's no accident to this. NFS can't
mount one resource under another resource.
Finally, watch your naming schemes. Let your names reflect what level of code resides
inside.
Instructor Guide
Instructor Notes:
Purpose — To show a potential disk layout of the NIM data.
Details — The diagram shown is what we implement in class. It's important that the
students feel reasonably comfortable with it at this time.
You could use other strategies. Some small shops prefer to keep everything in rootvg in
order to do a simple mksysb backup every night of their nim master. Another strategy is to
put the mksysbs in a totally different volume group and/or different filesystem since they're
so big and possibly handled by a different group of administrators.
Also, be careful of the installp_bundle directory. If you set up your master using smit, you'll
get all your installp_bundle contents in rootvg. That's because NIM puts them in the
/export/installp_bundle directory and not in the /export/nim/installp_bundle directory. To
undo this scenario afterwards, you probably have to remove and remake all of these
bundles in your new /export/nim location. Ideally, create the new ones using the old ones
as source. Then, remove the old ones. It's at times like this that the command line and a
shell script come in handy. Fortunately, we've included a simple script in your lecture
appendix area to change your bundle location. Refer the students to this if they're
interested.
Transition Statement — Let's check out other guidelines in setting up your NIM master
before we actually set it up.

V3.1.0.1
Instructor Guide
Uempty
Other Requirements for the NIM Master
No Official Guidelines
Realistic Minimums: 512 MB Memory

10 Mb Ethernet card
Portion of a 520 processor
Install Window: 6 simultaneous base installs

Planning (7 hours for 40 base installs)
Speeding Up: Hub/Switch speed

Your Performance Ethernet Speed
Keeping Resources in Memory
lpp_source
spot
Distributing Resources
spot
lpp_source
Security: Clients and Master inside same firewall

Keep it Tight!!
Figure 2-4. Other Requirements for the NIM Master AU086.0
Notes:
Again, the guidelines listed here are NOT official. They are merely guidelines to get you
started.
You really don't need much resource to do just a few installs at a time. The biggest reason
folks need more resource is because of a tight install window.
There are several things you can use to speed up your performance. First of all, slow hubs
or switches can actually slow your performance down dramatically. It's not unusual for a
really low-end hub to be able to handle just two simultaneous installs. Increasing your NIC
adapter speeds can also help. If you plan to use the same resource a lot, you might
consider configuring enough memory to hold the resource in RAM. For example, another
2-3 GB of RAM could help to maintain an lpp_source in memory. Finally, distributing your
resources out on the network so that they're on the same subnet as the client helps to
speed up an install, especially if your other networks are already heavily loaded.
Keep security tight on your NIM master. Remember, if you're root on the NIM master, you
can add glitchy fixes, remove software, reboot your client, and even blow it away to install
something that's meaningless.
Instructor Guide
Instructor Notes:
Purpose — To give the students some guidelines to help them in planning for their NIM
master.
Details — The realistic minimums come from this author's experience. Your experience
may vary.
I always used to be able to install eight machines (I conservatively mentioned six on the
screen) simultaneously in an SP environment. This SP environment had just a simple 10
mb/sec ethernet NIC, and I'm sure a small amount of memory installed on each node.
I've also run a NIM server on just a portion of a single 520 processor. In fact, in developing
this NIM course I'm running it on 40% of a single 520 processor using virtualization. I
believe I've also installed five simultaneous machines with no problem using this strategy.
Some students ask if you can combine a NIM master onto a machine that's used for other
activity. Typically my answer is yes. That's because NIM is only needed if someone needs
to install software and it's probably used at night for the backups. So, as long as the
customer keeps that in mind, they can probably combine the NIM master onto a machine
that's used for other purposes. This is especially useful for smaller shops.
Typically 512 MB of memory is fine. Only plan on increasing this if they have tight install
windows and need to install several machines at once. Having extra memory would allow
NIM to keep commonly used resources (like an lpp_source) in memory.
Remember, if the customer is using virtual ethernet and both NICs are on the same VLAN,
then you can get speeds of 2-3 GB/sec. This is commonly done in the HMC/LPAR arena for
LPARs on the same machine.
Remember that NFS does not operate securely over a firewall.
Transition Statement — OK, let's get started with setting up our NIM master.

V3.1.0.1
Instructor Guide
Uempty
Laying the Groundwork for Your NIM Master
• smitty install_latest
Network Installation Manager - Master Tools
(bos.sysmgt.nim.master)
•Make your nimvg VG
•Create and mount /export/nim filesystem
Figure 2-5. Laying the Groundwork for Your NIM Master AU086.0
Notes:
Install the code to make yourself a NIM master.
Then, if you decide you want to put your data in the nimvg volume group, you need to make
your volume group. Compute up the sizes of all your resources to figure out how big to
make it.
If you decide to create one big /export/nim filesystem, now's the time to create it and mount
it.
Instructor Guide
Instructor Notes:
Purpose — To show what upfront work needs to be done before you configure your NIM
master.
Details — There's also a bos.sysmgt.nim.spot fileset. This is installed in the SPOT
automatically when the SPOT is made, but is not required to exist natively at the NIM
master. The bos.sysmgt.nim.client fileset is already installed on every V5 AIX machine.
Once you've installed the nim.master fileset, your machine can not be a client. Hence, if
you decide in the future that you want to be a client, you'll need to remove the nim.master
fileset.
Setting up the disk strategy shown is optional. However, if you want this approach, you
need to set it up now because when your configure your NIM master, NIM immediately
starts building resources out in this area.
Transition Statement — Let's look at a quick overview of what the NIM master
configuration process requires and what setup it accomplishes for us.

V3.1.0.1
Instructor Guide
Uempty
NIM Master Configuration Overview
Important Questions:
1. What NIC do you plan to install over?
2. Where do you plan to setup your first lpp_source, spot?
3. Where's the install media to feed this whole operation?
NIM Master Setup Outcome:

1. Setup Master
NIM ODM Database
-- master
-- master's subnet
-- script
-- boot area
/etc/niminfo
nimesis Daemon
2. Setup Initial Resources
AIX Install CD --> lpp_source --> spot
Add lpp_source and spot to NIM ODM Database
Figure 2-6. NIM Master Configuration Overview AU086.0
Notes:
The questions shown here are asked when you set up your NIM master.
The output shown is what is set up when you configure the NIM master using smit. Most
items are fairly obvious. The script object points to an area to store internal NIM
customization scripts. The boot area is the /tftpboot directory that is used to store boot
images.
/etc/niminfo is the key configuration file that exists on the master and all clients. The
nimesis daemon is used to communicate with NIM client commands.
The initial resources needed for just about any install are an lpp_source and a SPOT.
Hence, setting up the master sets up these resources as well. The AIX install CD (or
alternative directory) feeds the lpp_source. The lpp_source is used to install some code in
the SPOT. In addition, NIM defines these resources in its database so it can refer to them.
Instructor Guide
Instructor Notes:
Purpose — To review what kinds of questions are asked during NIM master setup, and to
see what kind of output it generates.
Details — Don't get into too much detail on the NIM master stuff. Tell the students this is a
good reference page for them to come back to see if their NIM master has all the
appropriate components.
FYI - WSM has an option to JUST set up your NIM master and not to create any initial
resources. You can also use the nimconfig command to setup just the NIM master without
setting up any additional resources.
Transition Statement — We're ready now to configure your NIM master in SMIT.

V3.1.0.1
Instructor Guide
Uempty
Setting Up Your NIM Master Using SMIT (1 of 2)
smitty nim (or nim_config_env)
Configure the NIM Environment
Configure a Basic NIM Environment (Easy Startup)
Configure a Basic NIM Environment (Easy Startup)
Initialize the NIM Master:

* Primary Network Interface for the NIM Master [en0] +
Basic Installation Resources:

* Input device for installation images [cd0] +
* LPP_SOURCE Name [lpp_source530]
* LPP_SOURCE Directory [/export/nim/lpp_source]+
Create new filesystem for LPP_SOURCE? [no] +
Filesystem SIZE (MB) [650] #
VOLUME GROUP for new filesystem [rootvg] +
Figure 2-7. Setting Up Your NIM Master Using SMIT (1 of 2) AU086.0
Notes:
You can use more than one adapter at the master for installation activity.
If you already have a filesystem created for your nim data, then choose to say no to create
one here. The fields entered above set up the organization tree shown earlier. In this case,
the lpp_source is created from the AIX install CD in the cdrom drive. It is placed in the
/export/nim/lpp_source/lpp_source530 directory. Since /export/nim is a filesystem already
created in the nimvg Volume Group, your lpp_source is placed in the nimvg volume group.
Instructor Guide
Instructor Notes:
Purpose — To discuss the initial fields on a NIM master configuration screen.
Details — The sizes shown on the screen are not used in our case since we're not creating
a filesystem. If we would change the Create new FS field to yes, then we would get a new
filesystem /export/nim/lpp_source in the rootvg volume group that was 650 MB. If you
choose to go with this second route, make sure your size is big enough. 650 MB only
handles a small base lpp_source.
Transition Statement — Let's look at the rest of the fields on this screen.

V3.1.0.1
Instructor Guide
Uempty
Setting Up Your NIM Master Using SMIT (2 of 2)
* SPOT Name [spot530]

* SPOT Directory [/export/nim/spot] +
Create new filesystem for SPOT? [no] +
Filesystem SIZE (MB) [350] #
VOLUME GROUP for new filesystem [rootvg] +
.....
Define NIM System Bundles? [yes] +
Add Machines from a Definition File? [no] +

Specify Filename []
* Remove all newly added NIM definitions [yes] +

and filesystems if any part of this
operation fails?
Figure 2-8. Setting Up Your NIM Master Using SMIT (2 of 2) AU086.0
Notes:
The SPOT is created in the /export/nim/spot/spot530 directory. No additional filesystem is
generated.
Defining NIM system bundles is a nice way to automatically generate all installp_bundle
resources so that your NIM environment reflects all your standard AIX bundles. The only
downfall of this is that they get generated in the /export directory versus the /export/nim
directory. This means they are put into the rootvg volume group.
The last option is a backout option. If your operation blows half way through, this feature
backs everything out. This is nice. You don't have to worry about a half configured
environment.
Command Line - The basic equivalent of the above operation is:
# nimconfig -a pif_name=en0 \
-a netname=network1 \
-a cable_type1="N/A"
Instructor Guide
# nim -o define -t lpp_source \

-a server=master \
-a location=/export/nim/lpp_source/lpp_source530 \
-a source=/dev/cd0 \
lpp_source530
# nim -o define -t spot \

-a server=master \
-a source=lpp_source530 \
spot530
# mkdir /export/installp_bundle
# cp /usr/sys/inst.data/sys_bundles/* /export/installp_bundle
# nim -o define -t installp_bundle \
-a server=master \
-a location=/export/installp_bundle/<bundle_file_name> \
bundle_name
Repeat the above nim -o define -t installp_bundle command for all bundles.
Refer to your installation guide and nim manpages for more detail.

V3.1.0.1
Instructor Guide

Purpose — To show the last fields on the NIM master configuration screen.
Details — The SPOT setup guidelines are very similar to the lpp_source guidelines.
The definition file is rarely used. It can be used to automatically define several clients at
once. This is only useful if you plan to instal all of these clients. Refer to the nimdef
command for more details.
The section that's missing is on configuring resources for diskless and dataless machines
which no one uses anymore.
Additional Information — By the way, notice that the command line version differs slightly
from the smit version when dealing with the lpp_source's directory structure. We always
want our lpp_source to end up in the /export/nim/lpp_source/<lpp-name> directory.
However, how we specify this location can vary. We use the
/export/nim/lpp_source/<lpp_name> directory when creating an lpp_source either with
smitty nim_mkres or when creating an lpp_source at the command line. However, when
setting up our first lpp_source using this smitty nim_config_env screen, we use the
/export/nim/lpp_source directory name. Note also that whenever we set up the spot (either
when setting up the master or separately later on) we always use the /export/nim/spot
directory location. I'm not sure why these inconsistencies exist. It can be confusing for the
students.
Transition Statement — Let's quickly review what we just generated.
Instructor Guide
Generated NIM Objects
lsnim

boot resources boot
network1 networks ent
spot530 resources spot
AllDevicesKernels resources installp_bundle
Alt_Disk_Install resources installp_bundle
App-Dev resources installp_bundle
....
Figure 2-9. Generated NIM Objects AU086.0
Notes:
These are the objects that are generated from configuring your nim master. Not all
installp_bundles are shown.

V3.1.0.1
Instructor Guide

Purpose — Quickly show the resources that got generated.
Details — Be sure to point out the spot and lpp_source.
Transition Statement — Let's investigate how to undo this procedure just in case you'd
ever need it.
Instructor Guide
Unconfiguring the NIM Master
1. Put all clients in the Ready state

# lsnim -l -c machines | more (check Cstate values NOT = Ready)
# nim -Fo reset <appropriate_client>
# nim -Fo deallocate -a subclass=all <appropriate_client>
2. Unconfigure the ODM database and server daemons

# nim -o unconfig master
3. Remove the main configuration file

# rm /etc/niminfo
4. Remove the resources

# umount /export/nim
# reducevg –d –f nimivg hdiskX hdiskY …
# rm /tftpboot/spot*
# vi /etc/tftpaccess.ctl
Delete allow:/tftpboot
5. Uninstall the NIM master fileset

# installp -u bos.sysmgt.nim.master
Figure 2-10. Unconfiguring the NIM Master AU086.0
Notes:
This procedure can be used to undo the master we just generated. Be careful. If
implementing SSL, you have additional configuration files to undo. See your online
documentation for details.
CAUTION: If you forget to change all of your clients' Cstate values back to the Ready state
before you unconfigure your NIM master, the unconfiguration steps listed above do not
totally undo your NIM master configuration. You also have to clean up any remaining client
files in the /tftpboot directory, unexport any affected filesystems, and remove any affected
entries in the /etc/bootptab file.

V3.1.0.1
Instructor Guide

Purpose — To show how to unconfigure the NIM master.
Details — The reason this screen is covered is because some folks think that "nim -o
unconfig master" command or equivalent smit option unconfigures everything. It doesn't.
We discuss the reset/deallocation command set later on. For now, just tell the students to
reset their clients in order to get them back to the ready state.
The nim -o unconfig master command gets rid of the NIM ODM database and removes the
nim server daemons from the SRC database (nimesis and nimd - used for debugging). It
leaves the nimsh client daemon in the SRC database and the /etc/niminfo file. If you desire
to be a client in the future to someone else, you also want to remove the /etc/niminfo file.
The reducevg command clears out all normal NIM data. However, you still need to
manually remove boot images from the /tftpboot directory and stop tftp from allowing file
transfers from the /tftpboot directory.
Be careful!! If you do not successfully remove boot images from the /tftpboot directory it
can cause unpredictable results when this machine is reconfigured as a master. You
probably end up with unusual errors pointing to this old SPOT name when you try to utilize
one of your new SPOTs. Also remember that boot images and so forth, are stored
wherever the SPOT server exists (which may or may not be at the master site).
You don't want to leave the nim.master fileset on any machine that you plan to use as a
client in the future or you won't be allowed to join another network as a client.
If you want to reconfigure this machine as a master, you need to start again from scratch.
Transition Statement — Let's discuss a couple of important security options you probably
want to set up right away.
Instructor Guide
Initial Security Concerns

smitty nim (or nim_env_opts)
Configure NIM Environment Options
Configure NIM Environment Options
Manage Client Registration (enable/disable)
Control Client Resource Allocation
....
Control Client Resource Allocation
Set Allocation Permissions for All Clients

(allow/disallow)
Set Allocation Permissions for a Specific Client

(machine - allow/disallow)
Set Allocation Permissions for a Specific Resource

(resource - allow/disallow)
Figure 2-11. Initial Security Concerns AU086.0
Notes:
There are many environment options you can set in NIM, including ones that may affect
large environments. However, we want to concentrate here on the security options that
could majorly affect the overall security of your environment.
By default, any client can register itself to your NIM master. And, by default, a client can
install or utilize any resource. As we saw earlier, this means they can install a mksysb
image and go into low-level maintenance mode to get in as root.
Most folks choose to disable client registration until they need to register a new client.
Setting allocation permissions for all clients (or a single client) means that only the NIM
master can initiate NIM operations.
You can also allocate permissions on resources. In other words, maybe clients are allowed
to utilize most resources, but not certain mksysb backup resources.

V3.1.0.1
Instructor Guide

Purpose — To briefly discuss how to better secure your NIM master after initial
configuration.
Details — The information in parentheses are the options you see if you choose that menu
option. It's shown here so that we can introduce all these concepts on one screen versus
several screens. For example, the Manage Client Registration menu item allows you to
either enable or disable this feature.
If a hacker client manages to install an unauthorized mksysb, then typically they'd have to
rely on the master to put them in maintenance mode. However, they could get their own
media/NIM master to put them into maintenance mode if they had media (or a SPOT) at the
right level.
SSL is not discussed in this course. It's implementation is really beyond the scope of this
course. SSL actually secures much less than these options do. These options keep a
hacker client from getting to your data stored at the NIM master. SSL keeps a hacker
master from maliciously re-installing your client. However, even if you don't have SSL
installed, base nimsh still helps to keep this hacker out by requiring that the NIM master
must have root authority and must know the master's and client's cpu_id NIM stored
attribute.
Sometimes I find it handy to illustrate the difference between these environment options
and nimsh/SSL with the following diagram:
Master Client
Environment Options
<----------------------------------------------
nim_cmd/SSL nimsh/SSL
----------------------------------------------->
In other words, the environment options keep hackers from getting into the master. The
nimsh and SSL if used help to keep a hacker master from getting into the client.
Transition Statement — Let's review our lecture by doing a checkpoint activity.
Instructor Guide
Checkpoint
1. Disk space is the biggest requirement for your NIM master. Name
one big resource that NIM uses and estimate about how much
space it may take up.
_____________________________________________________
____________________________________________________
Correct Answer: An lpp_source probably takes up about 3 GB per
level you plan to support. The actual size depends on many
factors. Your mksysb backups also take up a lot of space. Each
backup takes at least .5 GB (for just a native base install). SPOTs
also take up about .5 GB apiece. User VG backups take up a LOT
of space if used.
2. T/F When setting up your NIM master in smit, the default settings
put your lpp_source and spot in the nimvg volume group.
Correct Answer: False. They are placed in the rootvg volume
group.
3. T/F smit's NIM Master configuration starts up a nimesis daemon,
creates an /etc/niminfo file, and defines some important initial
objects including the master, it's subnet, an lpp_source and a spot.
4. The SPOT is created from the lpp_source. What is used to create
the lpp_source?
____________________________________________________
Correct Answer: Your AIX install CDs.
5. T/F I can use one of NIM's environment options to keep hackers
from joining my NIM network.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
•Identify NIM master requirements
•Configure/unconfigure NIM master
•Set up important initial security options
Notes:
Instructor Guide
Instructor Notes:
Purpose —
Details —

V3.1.0.1
Instructor Guide
Uempty Unit 3. Base (RTE) Install

This unit shows the students how to do a base (RTE) install on a NIM
client using the manual initiation method.

• Identify different RTE install parameters
• Define a client
• Set up master and client for install
• Initiate and monitor a basic RTE install

Accountability:
• Lab exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-1
Instructor Guide
Unit Objectives
•Identify different RTE install parameters
•Define a client
•Set up master and client for install
•Initiate and monitor a base RTE install
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Base (RTE) Install Decisions - Contents
Required AIX CD #1 subset

Contents: -- BOS.autoi bundle
AIX Install CD #1 -- Equivalent to normal AIX CD install
Optional Additional Filesets/Bundles

Contents: -- Master: During Client Install Setup
AIX Install CD #2 … -- Client: BOS Install Question Screen
Figure 3-2. Base (RTE) Install Decisions - Contents AU086.0
Notes:
Refer to the bundle definitions in the /usr/sys/inst.data/sys_bundles directory to see what is
installed. The BOS.autoi file is always installed. Other bundles chosen at the BOS install
screen determine what other bundles in this directory are also installed. Notice that this is
equivalent to performing a normal AIX CD install.
You can augment this procedure by including extra bundles and/or filesets when setting up
the master to do this install (on the smitty nim_bosinst screen). Or, you could choose to
select additional bundles while answering the traditional questions when the BOS
installation screen comes up at the client console.

V3.1.0.1
Instructor Guide

Purpose — Briefly mention what code makes up an RTE Base install.
Details — A normal AIX CD install or NIM RTE install will install the same thing. They
install the contents of the /usr/sys/inst.data/sys_bundles/BOS.autoi fileset. This is
equivalent to most of what's on AIX install CD #1.
If optional bundles are chosen at either the smitty nim_bosinst screen or when the client
answers the BOS install questions, then you could end up installing the equivalent of the
rest of the AIX install CDs, the AIX Documentation CD, the AIX Toolbox CD, the AIX
Expansion CD, the Mozilla CD and maybe even other code like the Universal Database.
The key is to correlate either the bundles chosen on the smitty nim_bosinst screen or the
bundle choices on the BOS install screen with the actual bundle definitions. You can
typically find a sample of these definitions in the /usr/sys/inst.data/sys_bundles directory.
You probably won't have time to get into all of this right now, but it's good to know if the
students ask.
Transition Statement — Let's see what other decisions need to be made to do our RTE
install.
Instructor Guide
Base (RTE) Install Decisions - Other

Initiator: Master or Client (if up)
Initiation: Manual, bootp broadcast, Push

Technique
Needed spot, lpp_source

Resources:
Needed master, client

Machines:
What still needs to be defined?
Figure 3-3. Base (RTE) Install Decisions - Other AU086.0
Notes:
You can initiate this operation from the master or the client. We show you later on how to
initiate installs from the client. For now, we initiate this procedure from the master.
As talked about in the introduction lecture, there are three methods to initiate your install
process. Since the manual method can be used at anytime, we start out with this method.
We'll have an opportunity to use the others later on.
The SPOT is needed to provide the boot image, the device configuration programs, and the
BOS installation program. The lpp_source is used as the source of all installation images
used during the install process. Fortunately both of these resources were already set up
when we set up the master.
In order for this to work, you need the master and client defined. Our master was defined
when we set up our master. We still need to define our client.

V3.1.0.1
Instructor Guide

Purpose — To show what other decisions need to be made to do an RTE base install.
Details — Some customers may refer to the manual or bootp broadcast method as a pull
because the client is the one initiating this install versus the master.
What still needs to be defined? We still need to define our client.
Transition Statement — Let's see what else needs to be set up in order to accomplish this
install.
Instructor Guide
Additional Base (RTE) Install Needs

Server Client
Server/Client Gateway IPs
inetd Normal bootlist - entX
bootps BOOTP
/etc/bootptab
client:bf=/tftpboot/<client>
/tftpboot/<client> boot image

<client.info> /etc/niminfo
NFS exports: NFS mount SPOT,

SPOT LPP_SOURCE
LPP_SOURCE
Start BOS Install Program

Answer BOS Install Questions
What needs to be done on the master side?
What needs to be done on the client side?

Figure 3-4. Additional Base (RTE) Install Needs AU086.0
Notes:
This screen shows what happens during a normal RTE/manual install process. It's a
simplification of the actual procedure, but is useful to identify what resources need to be set
up at the master and client side in order to make an RTE base install work.
In a manual install, we go into SMS mode at the client and identify the IPs needed to
communicate to your server. Then, we set our normal bootlist to our NIC adapter (which is
typically an ethernet adapter). When we exit out, BOOTP contacts the server.
Notice all that has to be set up at the master to respond: an entry in /etc/bootptab, a boot
image in /tftpboot along with a config file, and finally an NFS exported SPOT and
lpp_source resource. Believe it or not, all of these items get done by using one simple smit
screen smitty nim_bosinst.
When the boot image and client.info file are tftp'd down to the client, they work together to
eventually bring up the BOS install program screen. From here, we can answer any final
questions such as the disks we want to install onto and any extra bundles we want to
install.

V3.1.0.1
Instructor Guide

Purpose — To help identify what else needs to be done in order to perform a base install
on our client.
Details — At the client side during a manual install, we'll need to supply the IP of the
server, client, and optionally, the gateway.
The server IP is the IP of the server that has the SPOT resource. This is typically the
master but doesn't have to be, as we see later on. When BOOTP runs, it sends its request
directly to this server IP. The client IP is needed so that the server knows which entry in its
/etc/bootptab file to use. The gateway IP is needed if the server is found over a gateway.
The client's bootfile is actually a symbolic link to the real bootfile.
The client.info file is the key configuration file the client uses during the install. Once tftp'd
over to the client, it is renamed /etc/niminfo.
The mounts may not occur as simply as shown. However, both resources are eventually
mounted before they can be used.
We address many of these things in more detail later on. Don't get too hung up here on the
details.
What needs to be done at the master? Prepare the master for the install (refer to the smitty
nim_bosinst screen).
What needs to be done at the client? Go into SMS -- set the IPs and bootlist and exit out.
Answer the BOS install questions.
Transition Statement — Let's now review the steps we need to go through to do an install
on our client.
Instructor Guide
Basic (RTE) Install Procedure
One Time
Add Client to Hostname Resolution

Define Client to NIM Master
Ongoing
Set Up Master to Install Client

Manual/Bootp Broadcast: Initiate Install at Client
Figure 3-5. Basic (RTE) Install Procedure AU086.0
Notes:
This is a summary of what needs to be done to install a client using an RTE install process.
The first two steps are only done if you have a machine that has not yet been defined in
your NIM database and/or hostname resolution database.
You can't successfully add a client to NIM unless it is first available in the master's host
resolution database (DNS or /etc/hosts). The only mandatory entry is the hostname of the
client's install adapter.
We show the remaining steps in the screens that follow.

V3.1.0.1
Instructor Guide

Purpose — To show what tasks need to be accomplished to do a base install.
Details — We do not show the student later how to put their hostname in either DNS or
/etc/hosts. Hence, emphasize that step here. Don't use alias names. NIM only seems to be
able to pick up the first name in the /etc/hosts file.
Setting up the master to install the client means going to smit's nim_bosinst screen.
If you're doing a push, you don't have to initiate the install at the client. Instead, the entire
operation is handled from the master.
Transition Statement — Let's see how to define our NIM client.
Instructor Guide
Define a Client to NIM (1 of 2)

smitty nim (or nim_mkmac)
Manage Machines
Define a Machine
Define a Machine
* Host Name of Machine [lpar1]

(Primary Network Install Interface)
Figure 3-6. Define a Client to NIM (1 of 2) AU086.0
Notes:
This is the hostname of the install adapter of this machine. By default, this also becomes
the main hostname of this client when the client is installed. If using DNS, enter in the long
hostname here (lpar1.my.company.com).
You are not able to proceed if your client's hostname is not in the master's hostname
resolution database.

V3.1.0.1
Instructor Guide

Purpose — To begin to show how to define an AIX machine to NIM.
Details — Your names also must match between your hostname resolution database and
your entry here. If they don't match, you usually end up with a 6XX LED hang during install.
This is typically because your first access to your NIM master's /etc/hosts file occurs during
a SPOT mount. And, since your client uses NIM's hostname for that server which doesn't
match the real DNS or /etc/hosts' name for that server, your client can't find that server.
Hence, it can't mount the SPOT.
Additional Information — If using DNS, you can use either a short or long hostname.
However, the actual hostname set on the client after the install is the long hostname.
Hence, I typically recommend to the students to set the long hostname here for
consistency. If they ever move the machine to another domain, then they can rename the
NIM client's hostname at that time.
If using /etc/hosts, then make sure you use the exact hostname as listed in the first entry of
the /etc/hosts file. NIM does not easily refer to aliases. And, it does not translate between
short and long hostnames.
Transition Statement — Now that we understand the importance of host names, let's see
what else needs to be defined.
Instructor Guide
Define a Client to NIM (2 of 2)
Define a Machine
* NIM Machine Name [lpar1]

* Machine Type [standalone] +
* Hardware Platform Type [chrp] +
Kernel to use for Network Boot [mp] +
Communication Protocol used by client [nimsh] +
Primary Network Install Interface
* Cable Type N/A +
Network Speed Setting [] +
Network Duplex Setting [] +
* NIM Network network1
* Host Name lpar1
Network Adapter Hardware Address [0]
Network Adapter Logical Device Name [ent0]
IPL ROM Emulation Device [] +/
CPU Id []
Machine Group [] +
Comments []
Figure 3-7. Define a Client to NIM (2 of 2) AU086.0
Notes:
NIM Machine Name/Host Name - There are two names given to your client: a NIM name
and a hostname. The NIM name is what's used when performing operations on this client.
The hostname becomes the system-wide hostname of this client and is also the assigned
to the client's adapter that NIM uses to do the client install. In our case we used a short
name on the prior panel. Hence, the NIM name and hostname are identical. If we had used
a long name on the prior panel, then we would see the long name for the hostname and the
short name for the NIM Name. For example, if we put lpar1.my.company.com on the prior
panel, then the hostname would be lpar1.my.company.com and the NIM name would be
lpar1.
Machine Type - Only one machine type is used anymore - standalone.
Hardware Platform Type - You can choose between chrp, rspc or the really old classical
rs6k. Since the chrp architecture came out in the mid 90s, most folks are using that today. If
you want to double check what architecture your client is using, run the command: "getconf
-a | grep MACHINE_ARCHITECTURE". On older AIX release levels try the bootinfo -p
command.

V3.1.0.1
Instructor Guide
Uempty Kernel Type - If your client machine is running the 64-bit kernel then your only choice here
is mp because that's all the 64-bit kernel runs. However, if your client is still running the
32-bit kernel, you have a choice as to whether to use either the up or mp kernel. If you want
to see what your client is currently running try issuing the ls -l /usr/lib/boot/unix command.
Notice whether it's linked to the 64, up or mp kernel in that same directory. You can also run
the getconf -a to notice whether the machine is even capable of running an mp kernel. An
MP_CAPABLE setting of 1 means yes. On older releases, try running the bootinfo -z
command to find out if the machine can handle mp. A setting of 1 again means yes.
Communication Protocol - You can either use the less secure shell protocol (which is
really rsh) or the newer nimsh protocol only available in 5.3.
Note: each client can have a different setting.
Cable Type - Most folks today are setting this to N/A as it is no longer applicable to your
adapter. You should be able to double check this by running the lsattr -El entX command
and noticing whether the cable_type field shows up. If not, then setting this to N/A should
work just fine. If you know you're running twisted pair cable, then setting it to tp should work
also.
Network Speed/Duplex - These settings are only used when you perform a push boot
operation on your client. It sets up the install adapter's settings to these speeds and duplex
settings. If not set, then the current speed/duplex settings for your install adapter currently
set up in your client's SMS is used.
NIM Network - This is the NIM network this client is assigned to. More on this later.
Hardware Address - This is obviously the MAC address of the client. It is only needed for
BOOTP broadcast operations. This MAC address, if ever needed, can be retrieved by
looking at your client's Remote IPL SMS menus.
Logical Device Name - This is the NIC physical adapter name that you plan to install over.
For example, it might be ent0 or ent1. This adapter receives the hostname you've set
above on this screen in the Host Name field when the client is installed.
IPL ROM Emulation - This is only set for really, really old machines that don't support
network boot. Please see online documentation for details.
CPU_Id - This is the machine ID retrieved from running the uname command on the client.
It will be used to uniquely identify this client in the future. You do not have to set this. NIM
will set this up itself.
Machine Group - You can assign a client to a machine group. More on this field later.
Command Line - The equivalent NIM command for the above operation is:
nim -o define -t standalone -a if1="network1 lpar1 0 ent0" \
-a cable_type1="N/A" -a connect=nimsh \
-a platform=chrp -a netboot_kernel=mp lpar1
Use the lsnim -q define -t standalone command for more information. Or see your nim man
page.
Instructor Guide
Instructor Notes:
Purpose — To show what fields to fill in to define your client.
Details —
Speed/Duplex - I normally choose not to set this in class as it can be confusing for the
students. Remember, this only takes affect during a push operation. Hence, they won't use
this setting on their first RTE install lab. Instead, it is used on their mksysb install lab since
that's the first time they perform a push. By then, they've totally forgotten that they've set it
and can't figure out why the install is going so slow. "After all", they say, "the last lab went
great!!" Just be aware that if you ever see a really slow install it could very well be due to a
wrong speed/duplex setting.
As I say many times in this course, make sure your server settings, client settings and
hub/switch port settings all match. Remember, auto-auto seems to work well for virtual
Ethernet adapters. However, many 100 Mb physical Ethernet adapters seem to work best
at 100-half.
The master's speed/duplex settings are checked with the lsattr -E -l entX command or for
some adapters with the entstat -d enX | grep Media Speed command. If needed, they can
be adjusted with the "smitty chgenet" screen after detaching the interface with smitty
chinet.
The client's speed/duplex settings can be viewed and adjusted for manual/bootp broadcast
installs by what's set in the client's Remote IPL SMS menus. They can be adjusted for push
operations by the fields on this Define the Client screen. If instead, the speed/duplex fields
on this Define the Client screen are left blank, then the SMS settings at the client take
affect.
Communication Protocol - Setting up nimsh does not automatically set up SSL. Refer to
the appendix in the back to set up SSL to run with nimsh.
Logical Device Name - This quite often defaults incorrectly to ent. This can cause
problems during the install process. That's why I always have the students set this to the
name of the adapter they plan to use for the install. ent0 is typically used. However, the
client on rare occasions could be using ent1. If needed, you can have the students double
check this by performing an lscfg | grep ent0 command at the client. Notice the physical
location code. Does it refer to the integrated adapter or the external adapter? Then, make
sure you have a physical Ethernet cable coming out of whatever Ethernet adapter ent0 is
referring to.
IPL ROM Emulation - No one probably needs this as most machine's firmware can handle
network boots. However, if the customer's machine is more than 10-12 years old or so, it's
conceivable they may need this. If so, then go to smitty nim and choose the IPL ROM
option to make an IPL ROM emulation diskette. Then, put this diskette into the client's
diskette drive before powering up to do the install.

V3.1.0.1
Instructor Guide
Uempty Transition Statement — Let's move on to step #2 -- setting up the master to install the
client.
Instructor Guide
Set Up Master to Install Client (1 of 3)

smitty nim (or nim_bosinst)
Install and Update Software
Install the Base Operating System on Stand-alone Clients
Select a TARGET for the operation
lpar1 machines standalone
Select the installation TYPE
rte - Install from installation images

mksysb - Install from a mksysb
spot - Install a copy of a SPOT resource
Figure 3-8. Set Up Master to Install Client (1 of 3) AU086.0
Notes:
In one step, by using the smitty nim_bosinst screen or by using the bos_inst command, we
can set up our master in order to be able to install our client.
First, select the NIM client you want to install. Then, choose the type. In our case, we use
the rte install method. We use the mksysb method later on for disaster recovery. The spot
method is a method not used as much in NIM and may be going away some time in the
future.

V3.1.0.1
Instructor Guide

Purpose — To show the initial screens in a smitty nim_bosinst operation.
Details — If you had multiple clients defined at this point, they would also show up on your
client list. Right now, we only have lpar1 defined, so that's all we see. Machine Groups
would also show up here if they had been defined.
The spot method as mentioned before in the instructor notes supposedly is going away so
we've chosen not to highlight it. It is not used much. If used, you must install enough
software from your lpp_source into your spot to handle a base install. Then, use the SPOT
as the image to install (versus the lpp_source or mksysb). It works just like an RTE install
but allows you to edit config files inside the spot, and install in about half the time of an RTE
install process (given the same number of filesets) because it's a straight copy of
pre-installed software.
Transition Statement — Let's continue this procedure on the next screen.
Instructor Guide
Select the LPP_SOURCE to use for the installation
Select the SPOT to use for the installation
spot530 resources lpp_source
Notes:
If you had multiple lpp_sources or spots defined at this point, they would also show up on
your list.
The lpp_source is used to supply the installation images to install. The SPOT is used to
supply the code used by the client to do the install.
Note: be sure to choose resources at the same release level.

V3.1.0.1
Instructor Guide

Purpose — To show how to choose the right lpp_source and spot for a base install.
Details —
Transition Statement — Alright, let's now take a look at the final dialogue screen.
Instructor Guide
Install the Base Operating System on Standalone Clients
* Installation Target lpar1

* Installation TYPE rte
* SPOT spot530
LPP_SOURCE [lpp_source530] +
MKSYSB
BOSINST_DATA to use during installation [] +

....
ACCEPT new license agreements? [yes] +
....
Initiate reboot and installation now? [no] +
Notes:
Notice the answers we already decided previously. If we wanted to automate this
operation, we would include a bosinst_data resource and choose to initiate the install
process now. However, we're going to do a manual install with no bosinst_data resource.
Hence, leave the bosinst_data field blank. Also choose NOT to initiate this installation now.
A yes here would be a push. Instead, we just want the master side to be set up. We
manually go to the client to start our install.
Be sure to accept the new license agreements.
These typically are the gpl licenses for the RPMS code that might be installed.
Command Line - The command alternative to the above would be:
nim -o bos_inst \
-a spot=spot530 \
-a lpp_source=lppsource530 \
-a no_client_boot=yes \
-a accept_licenses=yes \

V3.1.0.1
Instructor Guide
Uempty lpar1
Issue the lsnim -q bos_inst <client_name> command for quick help. See the nim manpage
for more thorough help.
Instructor Guide
Instructor Notes:
Purpose — To show what remaining fields need to be set to finish this operation.
Details — Notice that there are two Accept license agreements fields on the screen. The
top one appears to be the one that needs to be set in order for it to work.
Notice that we didn't bother to show many of the options on this screen. We'll get into these
more in the advanced install unit.
Transition Statement — Let's take a look at what we just generated.

V3.1.0.1
Instructor Guide
Uempty
NIM Master Setup Output (1 of 2)
lsnim -l lpar1
lpar1:
class = machines
type = stand-alone
connect = nimsh
platform = chrp
netboot_kernel = mp
if1 = network1 lpar1 0 ent0
cable_type1 = N/A
Cstate = BOS installation has been enabled
prev_state = ready for a NIM operation
Mstate = not running
boot = boot
lpp_source = lpp_source530
nim_script = nim_script
spot = spot530
control = master
Figure 3-11. NIM Master Setup Output (1 of 2) AU086.0
Notes:
Notice that the Cstate has changed and that the master now has control. Note also the
resources that have been assigned to this client.
Instructor Guide
Instructor Notes:
Purpose — To show how the client's lsnim listing has changed.
Details — Notice that it is now ready for a base install and has all appropriate resources
assigned to it.
Transition Statement — Let's see what else our operation affected.

V3.1.0.1
Instructor Guide
Uempty
NIM Master Setup Output (2 of 2)
/etc/bootptab
lpar1:bf=/tftpboot/lpar1:ip=10.31.209.55.......
/tftpboot
lpar1 -> /tftpboot/spot530.chrp.mp.ent
lpar1.info
spot530.chrp.mp.ent
Exported NFS Filesystems

export list for nimsrv:
/export/nim/spot/spot530/usr lpar1
/export/nim/lpp_source/lpp_source530 lpar1
/export/nim/scripts/lpar1.script lpar1
Figure 3-12. NIM Master Setup Output (2 of 2) AU086.0
Notes:
The bootptab entry is used by your bootps daemon to answer your client's boot request.
Hopefully your client's entry points to the right bootfile.
The /tftpboot directory should contain an entry for your client's boot image and its
configuration file. Both of these resources are tftp'd to the client during the initial portion of
the install.
Any needed resources should be exported for your client.
An internal NIM script is built in the /export/nim/scripts directory to handle post internal nim
customization and any post customization scripts you've personally set up for your client.
Instructor Guide
Instructor Notes:
Purpose — To show what other resources have been set up for you at the master site.
Details — The lpar1.info file becomes the /etc/niminfo file at the client. It contains variables
that help the client figure out where all its resources reside that it needs during the install.
This file should not be edited. Instead, if a mistake is found inside this file, it indicates that
earlier NIM setup steps were done incorrectly.
The exported filesystems shown are from the showmount -e command at the master.
The internal nim script sets up the client as a nimclient and sets up enough IP/hostname
info for the client to get back to the NIM master. It also calls any scripts you've personally
constructed to do further post customization.
Don't get too involved here. Merely point out what is normal output of a smitty nim_bosinst
operation.
Transition Statement — Now that the server side is ready to go, let's turn our attention to
the client side.

V3.1.0.1
Instructor Guide
Uempty
Client Summary Setup
•Access console and SMS
–Setup IPs
–Change normal bootlist to entX
–Exit out
Figure 3-13. Client Summary Setup AU086.0
Notes:
When doing a manual install, we need to enter SMS and perform a couple operations. As
we see, the stand-alone environment and the HMC/LPAR environment use different
procedures to accomplish this.
Instructor Guide
Instructor Notes:
Purpose — To briefly summarize what is covered on the next several screens.
Details —
Transition Statement — Let's first look at how to access our console and SMS in a
stand-alone arena.

V3.1.0.1
Instructor Guide
Uempty
Stand-alone: Accessing SMS
Power On
IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM Starting Software IBM IBM

IBM IBM Please Wait IBM IBM

memory keyboard network scsi speaker
1 = SMS 5 = Default Service

6 = Default Diag 8 = OK Prompt
Figure 3-14. Stand-alone: Accessing SMS AU086.0
Notes:
As you can see, getting into SMS mode when using a stand-alone machine is simple.
Merely power on the machine while sitting at the console. When the menu shown appears,
press the 1 key. Then wait a couple of minutes for SMS to appear.
Note: on some older machines, the bottom couple of lines do not appear. Instead, be sure
to press the key as the memory keyboard..... line begins to appear on the screen.
At this point, if all you care about is a stand-alone environment. Skip past all the
subsequent screens that show how to get into SMS using an HMC/LPAR environment. Go
straight to the SMS Main Menu screen.
Instructor Guide
Instructor Notes:
Purpose — To show how to get into SMS mode using a standalone machine.
Details — On some really old machines you may see icons versus the memory.... text line
shown.
If tight on time and running in a stand-alone environment, you could choose to bypass the
next several screens and go instead to the SMS menu screen.
Transition Statement — Let's see how to access SMS in an HMC/LPAR environment.

V3.1.0.1
Instructor Guide
Uempty
HMC/LPAR: Accessing Your Partition
Login to your HMC
Figure 3-15. HMC/LPAR: Accessing Your Partition AU086.0
Notes:
To get to the screen, do the following:
First, double-click your wsm icon at your PC. Then, enter in the hostname or IP address of
your HMC. When verification is done by your HMC, then enter in the appropriate HMC's
username and password. This should eventually bring up your main HMC screen. From
here, open up your HMC machine at the left (if necessary). Then, open up the Server and
Partition folder underneath your HMC machine. Then, double-click the Server Management
icon. Now at the right, open up your managed machine and then the partitions section.
Your client lpar should now appear.
Notice the state of your lpar1 client. It's not running yet.
Instructor Guide
Instructor Notes:
Purpose — To show students how to bring up their partition using their PC's wsm icon and
the HMC wsm session.
Details — In this case, 10.31.209.58 is our HMC machine. console58 is our 2-processor
520. viosrv, nimsrv, and all the lpars are the partitions inside this 520 machine. The NIM
Master is nimsrv. The three clients are lpar1, lpar2 and lpar3. viosrv is the Virtual I/O Server
that really owns the other partition's ethernet adapters and disk space.
Note that lpar1 is highlighted. As we go forward, it is assumed that the student right clicks
this partition in order to bring up the partition menu you'll see on subsequent screens.
Transition Statement — Now let's see how to access our partition's console.

V3.1.0.1
Instructor Guide
Uempty
HMC/LPAR Opening Up Your Client’s Console
Figure 3-16. HMC/LPAR Opening Up Your Client's Console AU086.0
Notes:
Once we right-click our partition we see the first menu. Choose the Open Terminal Window
menu item to open up a console window. Right now, there's no login prompt because
there's no running client. Notice that the top border points to what partition this console is
connected to.
When logging in, you are emulating a vt320 ASCII console.
If you want to close down this terminal, click the upper right X and then choose the Close
Terminal Connection menu item off of your partition's menu.
Instructor Guide
Instructor Notes:
Purpose — To show how to open up a partition's console.
Details — There are two ways to open up a console. This is one technique. Another
technique is available when you choose to activate your partition.
Watch out when closing out your console. If you forget to Close the Terminal Connection
then it's still considered active. No one else can get in unless you first close it from your
partition's menu. Also be aware that other folks can choose to close your console without
your notice.
Transition Statement — Now that we've identified our partition and opened up a console,
let's see how to access SMS.

V3.1.0.1
Instructor Guide
Uempty
HMC/LPAR: Accessing SMS (1 of 2)
View Partition State
Shutdown if necessary
(Immediate)
Figure 3-17. HMC/LPAR: Accessing SMS (1 of 2) AU086.0
Notes:
Assuming that your partition is down (note the state value), then you're ready to get into
SMS. If your machine is not down, then shut it down now.
Choose to Activate your partition from your partition menu. From this menu, notice that you
could also optionally open up your console session here. However, ours is already open
from the action we took earlier. From here, go to the advanced screen.
Instructor Guide
Instructor Notes:
Purpose — To show how to begin to get into SMS mode in an HMC/LPAR environment.
Details — You could also enter SMS by doing a normal activation from your partition.
However it works differently for a previously running versus a brand new machine. On a
previously running machine, it attempt to boot from disk, but initially present you with that
interrupt menu we saw earlier. Merely press 1 at the right time. Most folks don't like this
option cause on the faster machines, the interrupt menu goes by too quickly.
On a brand new machine where no valid disk boot image exists, it attempts to boot from
your NIC. If everything is set up right at the client and master, it just starts your ethernet
boot. If it's not set up right, it eventually times out and puts you into SMS mode.
Additional Information — Some older HMCs don't have an advanced button. Instead they
have you make another profile to handle SMS booting. Hence, at this screen the student
would choose an SMS profile versus the normal profile.
Another alternative is to do a normal boot startup versus an advanced SMS boot startup.
Then, when the interrupt menu appears, press the 1 key.
Note: on some faster systems, I've heard complaints that this interrupt menu goes by too
fast.
Transition Statement — Let's see what final menu options we need to take to get into
SMS mode.

V3.1.0.1
Instructor Guide
Uempty
HMC/LPAR: Accessing SMS (2 of 2)
Figure 3-18. HMC/LPAR: Accessing SMS (2 of 2) AU086.0
Notes:
Choose SMS off of the boot mode field and press OK twice.
This should bring up your SMS main menu.
Instructor Guide
Instructor Notes:
Purpose — To show what final option needs to be taken to bring up our SMS menu.
Details — Select SMS here. Then press OK on this advanced screen and then OK back on
the activate screen. Then, wait for a minute or so. SMS should eventually appear at your
console.
Transition Statement — Let's take a look at our SMS main menu.

V3.1.0.1
Instructor Guide
Uempty
SMS Main Menu
Main Menu
1. Select Language
2. Setup Remote IPL (Initial Program Load)
3. Change SCSI Settings
4. Select Console
5. Select Boot Options
Navigation Keys:
X = Exit System Management Services
Type the number of the menu item

and press Enter or Select Navigation Key: 2
Figure 3-19. SMS Main Menu AU086.0
Notes:
This particular menu is available on a 520 machine. Yet it should reflect almost exactly
what you see on the 5XX and 6XX line of processors. The only differences you may see on
a stand-alone machine or on another processor are a couple of options that don't pertain to
us here. For example, there's probably an extra option to change your SMS password and
to view an error log.
Main SMS navigation is done by entering in the number of your menu item. The Escape
key pulls you back to the previous menu. The M key pulls you back to the main menu.
When done, merely exit out with the X key. This causes the system to attempt a boot from
the first device on the normal bootlist.
We use two things from this menu - Setup Remote IPL and Select Boot Options. First, let's
set up our IPs by choosing Setup Remote IPL.
Instructor Guide
Instructor Notes:
Purpose — To show how to navigate SMS and what two options we'll be using.
Details — They should already be familiar with SMS. Just get them familiar with this layout.
This menu has been simplified somewhat in order to fit it better on the screen.
Transition Statement — Let's take a look at the Remote IPL menu in order to set up our
IPs.

V3.1.0.1
Instructor Guide
Uempty
Setting Your IPs (1 of 2)
NIC Adapters
Device Location Code Hardware Address
1. Interpartition Logical LAN U9111.520.100288E-V3-C2-T1 26d780003002
Network Parameters
Interpartition Logical LAN: U9111.520.100288E-V3-C2-T1
1. IP Parameters
2. Adapter Configuration
3. Ping Test
Figure 3-20. Setting Your IPs (1 of 2) AU086.0
Notes:
In this particular case, our partition only has one NIC. It's a virtual ethernet adapter.
To set your IPs, you choose IP Parameters.
Adapter Configuration allows you to check your speed and duplex settings. It also allows
you to enable or disable spanning tree.
The Ping Test allows you to ping your NIM server before initiating this whole operation.
We only cover the first option here in lecture. However, you do all three in lab.
Instructor Guide
Instructor Notes:
Purpose — To show the main options we may want to use in setting and testing our IP
addresses.
Details — It is strongly recommended to double check your Speed settings and to perform
a ping test after setting your IPs. However, in order to save time and to net out the
important points, we won't do that portion here in lecture. However, we will do it in lab.
Your speed settings are typically set to auto-auto. In fact, in a virtual ethernet environment,
this is your only setting.
It is probably a good idea to keep spanning tree on as some students have a tendency to
set up their IP addresses wrong and you could have a conflict.
Transition Statement — Let's take option #1 - IP Parameters.

V3.1.0.1
Instructor Guide
Uempty
Setting Your IPs (2 of 2)
IP Parameters
Interpartition Logical LAN: U9111.520.100288E-V3-C2-T1
1. Client IP Address [000.000.000.000]

2. Server IP Address [000.000.000.000]
3. Gateway IP Address [000.000.000.000]
4. Subnet Mask [255.255.255.000]
Type the number of the menu item: 1
X to Abort or Enter Client IP Address: 10.31.209.55
Figure 3-21. Setting Your IPs (2 of 2) AU086.0
Notes:
Enter in your client and server IPs and subnet mask using the method shown. Fortunately,
SMS does some syntax checking for you on your IP numbers.
If your server is over a gateway then enter in the gateway address here. Also be sure to
enable BOOTP forwarding at that gateway machine. If you're not using a gateway, merely
let this number default to zeros.
At this point, press the ESC key to return to the prior menu. From there, you could choose
to check your speed settings and then perform a ping test to your server.
Instructor Guide
Instructor Notes:
Purpose — To show how to enter in your IP addresses.
Details — Notice that the typical ESC M and X options are available here as well if you
need to back out to a prior menu or exit SMS. They are not shown in order to simplify the
menus for the students.
On some older machines, when you didn't want to use your gateway, you couldn't set that
IP address up or BOOTP would attempt to go over it. That's why we've gotten in the habit
of leaving it at zeros. However, in more modern machines, this is not as much of a problem.
So, setting your gateway, even if you don't plan to use it, would probably be ok.
Remember, this server address is the server wherever your SPOT is located. Right now,
it's at our master, but in a distributed environment, it could be on a NIM client somewhere
out in your network.
Transition Statement — Let's presume at this point that we've ping tested our client and it
appears to be communicating with our master just fine. Let's escape back out to the main
SMS menu and choose the menu item select boot options.

V3.1.0.1
Instructor Guide
Uempty
Setting Your Bootlist
Select Boot Options
1. Select Install/Boot Device

2. Configure Boot Device Order
3. Multiboot Startup <off>
Select Device Type
1. Diskette
2. Tape
3. CD/DVD
4. IDE
5. Hard Disk
6. Network
7. List all Devices
Figure 3-22. Setting Your Bootlist AU086.0
Notes:
To do a quick temporary override of the bootlist, choose Select Install/Boot Device. If you
plan on making a permanent change to the bootlist, choose Configure Boot Device Order.
Both options provide similar menu choices. We're choosing to Select Install/Boot Device.
This option is handy when trying to change your bootlist quickly to do an install. However,
taking the Configure Boot Device Order would work just as well because when NIM finishes
the install it will set the permanent bootlist back to disk.
In our case, we choose 6 from the second menu in order to choose our virtual ethernet
adapter as the device to boot from.
Instructor Guide
Instructor Notes:
Purpose — To show the difference between a temporary and permanent boot change and
to begin to show how to select the right boot device.
Details —
Transition Statement — Now let's see how to choose the actual NIC adapter we want.

V3.1.0.1
Instructor Guide
Uempty
HMC/LPAR: Setting Your Bootlist
Select Device
Device Current Device

Number Position Name
1. 1 Virtual Ethernet
(loc=U9111.520.100288E-V3-C2-T1)
Select Task
Virtual Ethernet
(loc=U9111.520.100288E-V3-C2-T1)
1. Information
2. Normal Mode Boot
3. Service Mode Boot
Figure 3-23. HMC/LPAR: Setting Your Bootlist AU086.0
Notes:
Let's now narrow down our choice to just one adapter to boot from. In this particular case,
we only have one adapter to choose from. We're using a virtual ethernet adapter on a 520
partition. Your machine could have a real ethernet adapter, and if using the 6XX or earlier
models, your physical location code probably looks different. Notice that this NIC is already
set up on the bootlist. That's probably because we haven't performed an install yet on this
machine. If we exited out at this point, it would probably try to boot from this device.
However, let's complete our procedure. Choose this device to be on your bootlist.
On the second menu, we choose the normal mode boot. This is useful for all installs. We
switch to the service mode boot later on when we do fancy things like maint_boot or diag
operations.
Instructor Guide
Instructor Notes:
Purpose — To show how to select the right NIC and select to use the normal bootlist.
Details —
Transition Statement — Once we choose to put this device on our temporary normal
bootlist, SMS assumes we want to exit out right now and start booting from this device.
Let's see how that looks.

V3.1.0.1
Instructor Guide
Uempty
Starting Your Boot
Are you sure you want to exit SMS?
1. Yes
2. No
Figure 3-24. Starting Your Boot AU086.0
Notes:
Whether exiting out manually yourself by pressing the X key or automatically after setting
the temporary bootlist, the exiting process is what starts your boot off of the normal bootlist
you just chose.
Notice that anytime you exit SMS you are asked to double check whether that's really what
you want to do.
Instructor Guide
Instructor Notes:
Purpose — To highlight the last menu you always see when exiting out of SMS and to
show that this is how we start the booting process.
Details — Whatever is on your normal bootlist at this point is what SMS will attempt to boot
from.
Transition Statement — Let's see what your initial output should look like.

V3.1.0.1
Instructor Guide
Uempty
Initial Output
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM Starting Software IBM IBM IBM

IBM IBM IBM Please Wait IBM IBM IBM
Press 0 to access this as your console
BOOTP: chosen-network-type = ethernet, auto, none, auto

BOOTP: server IP = 10.31.209.54
BOOTP: requested filename =
BOOTP: client IP = 10.31.209.55
BOOTP: client HW addr = 26 d7 80 0 30 2
BOOTP: gateway IP = 0.0.0.0
BOOTP: Device /vdevice/l-lan@30000000002
BOOTP: loc-code U9111.520.100288E-V3-C2-T1
Figure 3-25. Initial Output AU086.0
Notes:
The console message appears on brand new machines where a console has not been
chosen yet. We could also have set this up in SMS but chose not to.
The BOOTP menus come up quickly. Hence, you may not be able to check everything. The
top line shows that your speed is set to auto and your duplex setting is set to auto. You
probably also have time to quickly double check your server and client IP address. After
that the output goes by pretty quickly.
Instructor Guide
Instructor Notes:
Purpose — To show what normal initial output probably look s like.
Details — The top menu appears twice. The first time gives you an option to interrupt your
boot by showing the traditional interrupt menu you saw earlier. The second time this screen
appears, the interrupt lines do not appear.
Transition Statement — Let's see how to monitor the remainder of our installation.

V3.1.0.1
Instructor Guide
Uempty
Monitoring Continued Output
Master Client
bootps is running S=1 R=1
bootfile=/tftpboot/lpar1
tftp is running PACKET Count = XXXXX
Watch LEDs
lsnim -l client:
Cstate = "BOS Installation is being performed" BOS Install Screen Appears
info = prompting_for_data_at_console Answer BOS Install Questions
Figure 3-26. Monitoring Continued Output AU086.0
Notes:
Ideally you want to see that your client sends one BOOTP request to your server (S=1).
Then, you want to see that your server replies immediately (R=1). Check your boot image.
It should point to your client's name. Then watch the PACKET COUNT increase as the boot
image is being transferred down to your client.
At this point, watching your LEDs is the best method for tracking your progress. This can be
viewed from your HMC screen or directly at the stand-alone machine's LED panel. If it
stops for more than about one minute or two on an LED then you probably have a problem.
At the master, use the lsnim command to monitor your Cstate and eventually your info field.
When your info field says: "prompting_for_data_at_console" then you need to answer the
questions for the BOS install program at your console.
Typical initial BOS install questions are something like:
1. Type a 1 and press Enter to define this as the System Console.
2. Type 1 and press Enter to have English during the install.
Instructor Guide
Instructor Notes:
Purpose — To show what to monitor during a typical install.
Details —
Transition Statement — Let's review the important options on the Main BOS Installation
Menu.

V3.1.0.1
Instructor Guide
Uempty
Main BOS Installation Menu
Welcome to Base Operating System

Installation and Maintenance
>>> 1 Start Install Now with Default Settings
2 Change/Show Installation Settings and Install
3 Start Maintenance Mode for System Recovery
>>> Choice [1]: 2
Figure 3-27. Main BOS Installation Menu AU086.0
Notes:
It's typically a good idea to double check your settings before you start the install process.
Instructor Guide
Instructor Notes:
Purpose — To show what to choose to double check our settings before we start the
install.
Details —
Transition Statement — Now let's double check our settings.

V3.1.0.1
Instructor Guide
Uempty
Installation and Settings Screen
1 System Settings:
Method of Installation.........................New and Complete Overwrite
Disk Where You Want to Install.................hdisk0
2 Primary Language Environment Settings (AFTER install):

Cultural Convention............................C (POSIX)
Language.......................................C (POSIX)
Keyboard.......................................c (POSIX)
3 More Options (Desktop, Security, Kernel, Software,...)
>>> 0 Install with the Choices shown
>>> Choice [0]:
Figure 3-28. Installation and Settings Screen AU086.0
Notes:
Double check your method of installation and disk drives. For an RTE Base install you want
to use a New and Complete Overwrite. The disks shown are the disks that are replaced
with the new rootvg volume group.
You also want to check your language environment settings. C (POSIX) points to the
default language the programmer set up which should be English.
For our purposes here, we won't bother to install any additional software, though choosing
option 3 would allow us to do this.
When done, continue with your install process, check your settings on the verification
screen, and continue. The install starts, just like a normal CD install. When done, you have
a new system booted up with the normal bootlist set to your hdisk0 device. Plus, your
client's Cstate goes back to the Ready state.
Instructor Guide
Instructor Notes:
Purpose — To show what settings you may want to doublecheck before you start the
install.
Details — All resources are also automatically deallocated when the install finishes.
Common student problems are:
1. Hostname resolution mismatch between NIM and DNS.
2. Media Speed mismatches between server/client and hub ports.
3. Wrong client definition (which typically causes the boot image to hang).
4. The student forgot to do the bos_inst at the master or to complete the whole setup at
the client.
5. Network gear is overloaded or malfunctioning.
Transition Statement — Let's view the final client screen and how to monitor it.

V3.1.0.1
Instructor Guide
Uempty
Monitoring the Rest of the Install
At the Client:
Installing Base Operating System
Please wait…
Approximate Elapsed time

% tasks complete (in minutes)
0% 0
At the Master: lsnim –l <client> Cstate = BOS installation is being

performed
info = BOS Install 0% Complete
Figure 3-29. Monitoring the Rest of the Install AU086.0
Notes:
Once you reach this screen then your work is over. You can either view the progress from
the client directly or by issuing the lsnim command at the master. Refer to Appendix D in
your Exercise Guide to find out what Cstate and info fields are appropriate for a normal
RTE install.
You can write a simple while loop to monitor the output. In addition, consider just viewing
the Cstate and info attributes.
An example piece of code to use might be:
#!/usr/bin/ksh
while true
do
lsnim -a Cstate -a info
sleep 5
done
Instructor Guide
Instructor Notes:
Purpose — To show what screen appears after you answer the BOS install questions and
to show how to continue to monitor your installation progress.
Details —
Transition Statement — Now let's see how to view the progress of your install once it has
completed.

V3.1.0.1
Instructor Guide
Uempty
Showlog Screen
smitty nim (or nim_mac_op)
Manage Machines
Perform Operations on a Machine
Target: lpar1
Operation: showlog
Display Installation Log
* Target Name lpar1

Log Type [bosinst] +
Only Show Last Entry in Log? yes +
OR
# nim –o showlog -a log_type=bosinst lpar1
Figure 3-30. Showlog Screen AU086.0
Notes:
Once your install is done, you can view it directly by going to the client's /var/adm/ras
directory and viewing the selected logs. Or, better yet, try using the showlog facility at your
master. Merely choose the right target and the right operation and you're ready to go.
Probably the best two logs to view for a base install are the bosinst and devinst logs. The
niminst log is the default. It records the output of normal installation update activity.
The nimerr log shows errors. However, you need to look for it on the machine where you
initiated your install. For example, in our case, we initiated the install from the master
(smitty nim_bosinst). Hence the errors from our install will appear at the master's nimerr log
file.
If you do a lot of installations on a client, you may want to view just the last operation's
output. This is the default setting.
Instructor Guide
Instructor Notes:
Purpose — To show how to look at a client's log files after the install completes.
Details — Pressing F4 for the Log Type field enables the students to see all the log files
supported and their descriptions.
Transition Statement — Let's review this unit with a checkpoint activity.

V3.1.0.1
Instructor Guide
Uempty Checkpoint
1. T/F A native RTE install is similar to an AIX install from CD.
2. T/F A client must be defined at the NIM master before it can be
installed.
Correct Answer: True. You also must make sure the client's install
hostname is in your hostname resolution database that the master
accesses.
3. T/F Only one smit screen (nim_bosinst) is required to set up the
master to handle a client install.
4. T/F A manual setup at the client requires going into SMS mode and
merely changing your bootlist to point to your NIC adapter.
Correct Answer: False. You must also doublecheck the IP
addresses of your client, server and gateway.
5. T/F Once you see the PACKET_COUNT increase at the client side,
there's nothing more to monitor.
Correct Answer: False. If you didn't create a bosinst_data (or it
has problems) you have to answer the BOS install questions.
Actually, common problems can occur up until you've passed the
BOS Install Screen.
6. What key command can be used at the NIM master to monitor your
client's progress? Also, what key fields in the output of this
command are helpful to look at?
_____________________________________________________
Correct Answer: lsnim -l <client_name>
Look at the Cstate field and info fields. There may also be an
info_err field that displays if there are problems.
Instructor Guide
Unit Summary
•Identify different RTE install parameters
•Define a client
•Set up master and client for install
•Initiate and monitor a base RTE install
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 4. Defining Additional Base Install Resources

This unit shows the students how to define additional resources that
might be useful in a base install.

• Define bundles
• Define bosinst_data to automate BOS install questions
• Define image_data to change FS/LVM defaults
• Define scripts to perform post customization
• Define resource groups

Accountability:
• Lab exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-1
Instructor Guide
Unit Objectives
•Define bundles
•Define bosinst_data to automate BOS install questions
•Define image_data to change FS/LVM defaults
•Define scripts to perform post customization
•Define resource groups
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Defining Resources to NIM (1 of 2)

1. Make the resource
2. Put it in /export/nim/<resource_type> directory
3. Define the resource to NIM
smitty nim (or nim_mkres)

Manage Resources
Define a Resource
Resource Type
spot = Shared Product Object Tree - equivalent to /usr file

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 savev
lpp_source = source device for optional product images
installp_bundle = an installp bundle file
[MORE...10]
Figure 4-2. Defining Resources to NIM (1 of 2) AU086.0
Notes:
We introduce several resources in this unit. Each resource is defined using the same
technique. In fact, when defining most resources, you fill in the exact same fields on the
smit definition screen.
The first thing to do is to physically make the resource. It's typically some type of a file that
you construct. Then, move it to a directory under NIM's control. A good naming scheme
might be /export/nim/<resource_type>. Make sure all your resource directories are placed
horizontally from each other. Finally, go into smitty nim and define the resource to NIM. Tell
it what type of resource you want to define, and then, as shown on the next screen, fill in
the fields on the dialogue panel. When you press Enter, this puts an entry in NIM's ODM
database that points to this physical resource.

V3.1.0.1
Instructor Guide

Purpose — To show the generic procedure for defining a resource to NIM.
Details — Many of the resources shown here aren't usable for the stand-alone machine.
These are resources that are used for diskless and dataless clients. Merely ignore them.
We've chosen to define an installp_bundle as an example on how to define a resource, yet
most resources are set up using this same technique.
Transition Statement — Let's now take a look at the final dialogue screen.
Instructor Guide
Defining Resources to NIM (2 of 2)
Define a Resource
* Resource Name [udb_bund]

* Resource Type installp_bundle
* Server of Resource [master] +
* Location of Resource [/export/nim/installp_bundle/udb.bnd] /
Comments []
Source for Replication [] +
Figure 4-3. Defining Resources to NIM (2 of 2) AU086.0
Notes:
Resource Name - The resource name is the NIM name that you use in the future to refer to
this resource. For example, if I wanted to do a base install using this resource, then I would
type in the bundle name: udb_bund on the smitty nim_bosinst screen.
Server of Resource - The Server of Resource determines the machine where this
resource is placed. You could potentially have this resource placed on any NIM client in
your NIM network. In our case, we just put the resource at the master. If we wanted to put it
on a NIM client, we'd choose the NIM client's name from the F4 list.
Location of Resource - Now we need to tell NIM where this resource is physically located.
Type in the physical location of this file at the master site.
Source for Replication - The source for replication field gives us the ability to create a
resource from an existing resource. This is typically used when you want to distribute your
resources throughout your network. We talk more about this in the next lecture.

V3.1.0.1
Instructor Guide

Purpose — To show what fields need to be entered to finish defining a resource.
Details — In this scenario, it is presumed that the udb.bnd file is already made at the
master. When clients go to use this bundle, it shows up as udb_bund.
Note that installp_bundles ideally should be placed in the /export/nim directory to match our
naming scheme. However, the original installp_bundles generated when we made the NIM
master were placed in /export/installp_bundles. More on this later.
Transition Statement — Let's see how to list a resource once it's been defined.
Instructor Guide
Listing a Resource
# lsnim -l udb_bund
udb_bund:
class = resources
type = installp_bundle
Rstate = ready for use
prev_state = unavailable for use
location = /export/nim/installp_bundles/udb.bnd
alloc_count = 0
server = master
Figure 4-4. Listing a Resource AU086.0
Notes:
Notice that the server field points to the master. The location field points to where we said
this resource should reside. It's not currently being used (alloc_count=0). And, according to
the Rstate, it's ready to be used.

V3.1.0.1
Instructor Guide

Purpose — To show how to list your resource and identify important common attributes.
Details — Some resources such as the SPOT and lpp_source have more attributes yet.
However, here, we're concentrating on the common attributes that all resources have.
Transition Statement — OK, now that we have the generic procedure down, let's start
with our first resource -- installp_bundle.
Instructor Guide
installp_bundle Resource Concepts
installp_bundle ONE
I:bos.net.nfs.server SIMPLE CLIENT
R:openssl INSTALL
LPP_SOURCE
bos.net.nfs.server
openssl
Sample Standard Bundles: Server

openssh_server
App-Dev
infocenter_EN_US
graphics
CDE
Listing Current: lsnim -t installp_bundle
Original Source: /usr/sys/inst.data/sys_bundles

For AIX Bundles
Figure 4-5. installp_bundle Resource Concepts AU086.0
Notes:
Bundles are typically used during the base install to easily add additional filesets to your
base install. You can either use the system predefined bundles which should reflect your
AIX standard bundles, and/or you can create your own.
Notice that you need two things to complete the install, a bundle definition file and the code
that physically resides in the lpp_source you plan to use during the install.
Bundles can be used to install or remove software from a client. However, removing
software requires using the native nim -o maint command with an installp_bundle option.
If you don't see the bundle you want when listing your currently defined bundles, then look
in the /usr/sys/inst.data/sys_bundles directory. You find several bundle definition files there
that you can use or modify to create your own bundles.

V3.1.0.1
Instructor Guide

Purpose — To show how installp_bundles are used during an install.
Details — You can also use bundles to install code onto SPOTs, but don't highlight that
right now as we have a whole unit on SPOTs later on.
You can also create FIX bundles (where you include IY60283 type numbers inside instead).
Again, we talk about performing updates later on.
Watch out!! If you choose to define your bundles when configuring your NIM master, you'll
end up getting all standard bundles defined in the /export/installp_bundle directory and
NOT the /export/nim/installp_bundle directory. Refer the students to the appendix on
changing a bundle location. The shell script in this appendix changes the installp_bundles
set up at the master in the /export/installp_bundles directory to the
/export/nim/installp_bundles directory.
Transition Statement — Now that we understand how bundles work, let's see how to
define them to NIM.
Instructor Guide
Defining a New Bundle

1. mkdir /export/nim/installp_bundles
2. vi /export/nim/installp_bundles/my.bnd
I:bos.net.nfs.server
R:openssl
3. Define installp_bundle resource to NIM
4. Make sure the code is in an lpp_source

nim -o showres <your_lpp_source>
Figure 4-6. Defining a New Bundle AU086.0
Notes:
If you decided to define some system bundles when you set up your system, you already
have several bundles in the /export/installp_bundles directory. Yet, to make sure our bundle
definitions end up in the /export/nim filesystem, we've decided to define all of our bundles in
the /export/nim/installp_bundles directory.
The I prefix means it's an installp fileset. The R means it's an RPMS fileset.
The showres option is a nice way to look at what's inside just about any resource. In this
case it is used to list the filesets available in your lpp_source. Remember, if your
lpp_source doesn't have the filesets listed in your bundle, then your bundle won't work.
Command Line - The equivalent NIM command for the above would be:
nim -o define -t installp_bundle \
-a server=master \
-a location=/export/nim/installp_bundles/my.bnd nim_bundle_name
Use the lsnim -q define -t installp_bundle command for more details or see the nim man
page.

V3.1.0.1
Instructor Guide

Purpose — To show the actual steps involved in defining an installp_bundle resource.
Details — Be careful. Make sure your system bundle puts the filesets in the right order. For
example, the mozilla bundle does not work well the way it's originally designed as bundles
are processed from the top line to the bottom.
You can optionally leave off the I: prefix. It is the default.
It always attempts to install the latest level unless you specify the level next to the fileset
name. For example: I:bos.net.nfs.server 5.3.0.8
Transition Statement — Let's now take a look at another resource -- bosinst_data.
Instructor Guide
bosinst_data Resource Concepts
Installation and Settings
1 System Settings:
Method of Installation................New and Complete Overwrite
Disk Where You Want to Install........hdisk0
2 Primary Language Environment Settings (AFTER install):

Cultural Convention...................C (POSIX)
Language..............................C (POSIX)
Keyboard..............................C (POSIX)
3 More Options (Desktop, Security, Kernel, Software,...)
>>> 0 Install with the Choices shown
>>> Choice [0]:
Figure 4-7. bosinst_data Resource Concepts AU086.0
Notes:
The above screen is the BOS Install screen that is used during a normal RTE install. The
questions asked here are the types of questions you can automate with a bosinst_data
resource.

V3.1.0.1
Instructor Guide

Purpose — To show what kinds of information you are automating by constructing a
bosinst_data resource.
Details — The whole idea of using a bosinst_data resource is to automate all the questions
that are asked on this screen during a normal install. To do this, we need to edit a
bosinst.data file on your system and define it to nim.
Transition Statement — Now that we understand what we need to automate, let's view
the file we're going to have to edit to make this happen.
Instructor Guide
Editing Your bosinst.data File (1 of 2)

# vi <spot>/bosinst.data
control_flow:
CONSOLE = Default
INSTALL_METHOD = overwrite
PROMPT = no
EXISTING_SYSTEM_OVERWRITE = yes
RUN_STARTUP = no
....
BUNDLES = __________
....
ACCEPT_LICENSES = yes
....
ENABLE_64BIT_KERNEL = Default
CREATE_JFS2_FS = Default
ALL_DEVICES_KERNELS = yes
....
GRAPHICS_BUNDLE = yes
<Mozilla, CDE, KDE, Kerberos, Server bundle options>
Figure 4-8. Editing Your bosinst.data File (1 of 2) AU086.0
Notes:
bosinst.data template - There are many bosinst.data files that already exist on your
machine that you could use as a template. If you want one that reflects what happens
during a native RTE install, then refer to either the one in your SPOT's top directory (that is,
/export/nim/spot/spot530Base/bosinst.data) or the bosinst.template file in your
/usr/lpp/bosinst directory. If you want one that reflects what values were used when you
installed your own machine then use the one in the /var/adm/ras directory. There are
comments inside the file that tell you how to set up most of the information. You can refer to
the /usr/lpp/bosinst/bosinst.template.README file or IBM's infocenter Web site for more
information.
Probably one of the most important stanzas inside this bosinst.data file is the control_flow
stanza.
CONSOLE - The console field determines which device is set up to be used as your
console. Using the Default value should work fine. It sets up the console to be /dev/lft0 if it
finds a graphics device, /dev/vty0 for an HMC/LPAR console and /dev/tty0 for a native

V3.1.0.1
Instructor Guide
Uempty ASCII terminal console. You could, alternatively set this field to a specific device type (that
is, /dev/lft0).
INSTALL_METHOD - The install method field needs to be set to overwrite for any base
install. The default install method varies. For brand new machines it is set to overwrite. For
pre-existing machines, the default value is migrate.
PROMPT - Be sure to change the prompt value to no or your BOS install screen will
appear. The default value is yes. However, this procedure is more intense than specifying
them when you do your smitty nim_bosinst at your master.
EXISTING_SYSTEM_OVERWRITE - The existing system overwrite field allows you to
install onto a disk even if an old operating system appears on it. This almost always needs
to be set to yes. The default value is no.
BUNDLES - The bundles field allows you to define your own custom bundles. However,
using this field to locate your bundles can become quite complicated. Instead, it is more
desirable to use the bundle field on the smitty nim_bosinst screen.
ACCEPT_LICENSES - You definitely want to set this to yes or you are asked to accept
these AIX installp and RPM licenses at the console when your install has completed.
Accepting these licenses must be done before you are allowed to log in. The default value
for this field is no.
RUN_STARTUP - The run startup field is what causes the configassist or install_assist
programs to appear at the console once the install has completed. If you are trying to
automate an install it is presumed that you handle the important portions of these facilities
yourself. Hence, setting this to no is typically the desired choice. The default value for this
field is yes.
ENABLE_64BIT_KERNEL - This field determines whether the 64-bit kernel is enabled.
This kernel is installed onto the machine no matter what choice is taken. However, if set to
no, it is not enabled. The default value for this field is yes on SServer p5 or BladeCenter
JS20 machines. The default is no for other machines.
CREATE_JFS2_FS - This field determines whether JFS2 becomes the default file system
type. Hence, it determines whether your core file systems are JFS2 or JFS when generated
during the base install. The default value for this field is yes on SServer p5 or BladeCenter
JS20 machines. The default is no for other machines.
ALL_DEVICES_KERNELS - Specifies whether or not to install all device and kernel
filesets. It is typically recommended to do this if you plan on using this machine for future
cloning. The default value for this field is yes.
GRAPHICS_BUNDLE - Specifies whether to install the standard AIX graphics bundle. This
would install X11 and websm support. The default value for this field is yes. Unlike the
custom bundle field, the graphics bundle field is easy to implement. You could alternatively
choose to implement the graphics bundle on the smitty nim_bosinst screen.
Instructor Guide
OTHER BUNDLES - Although only referred to briefly on the screen, there are several other
fields that refer to several other bundles that you could potentially install. You can either
specify these bundles here or on the smitty nim_bosinst screen.

V3.1.0.1
Instructor Guide

Purpose — To show what fields to alter in the control_flow stanza of the bosinst.data file.
Details — bosinst.data template - As shown in the student notes, you can use at least
three different bosinst.data files to use as beginning template files. The one in the
/usr/lpp/bosinst directory or in your spot directory are identical. They represent the values
used during a native RTE install. The one in the /var/adm/ras directory represents the
values used during the latest install of the current machine. This one is sometimes used for
a bosinst.data template for a mksysb install as it has some additional fields pre-filled in to
represent the current machine's settings.
Highlighted Fields - The highlighted fields are those that will need to be changed from the
defaults if using one of the templates in the <spot> or /usr/lpp/bosinst directories.
Bundles - You can either specify bundles here or on the smitty nim_bosinst screen. For
most bundles, either location is fine. For custom bundles, specifying them in your
bosinst.data file can cause some extra work. This is because you'd have to place the
bundle file inside your spot and then refer to it correctly here inside the bosinst.data file. For
example, if you created the file /export/nim/spot/spot530Base/usr/mybund/my.bnd at your
master, you'd have to refer to it in your bosinst.data file as /../SPOT/mybund/my.bnd. This
is because when these bundles run at your client, the /export/nim/spot/spot530Base/usr
directory at the master is viewable at the /../SPOT directory at the client.
Additional Information — The SPOT directory at the master is initially mounted at the
/SPOT directory at the client. Then, when the root file system of the client becomes the real
root file system via the chroot command, the old RAM file system is viewable via the /../
directory. Thus, the SPOT is still viewable from the /../SPOT directory.
Transition Statement — Let's continue on looking at the final two stanzas inside this file.
Instructor Guide
Editing Your bosinst.data File (2 of 2)
target_disk_data:
PVID =
PHYSICAL_LOCATION =
SAN_DISKID =
CONNECTION =
LOCATION =
SIZE_MB =
HDISKNAME = hdisk0
locale:
BOSINST_LANG = en_US
CULTURAL_CONVENTION = en_US
MESSAGES = en_US
KEYBOARD = en_US
Figure 4-9. Editing Your bosinst.data File (2 of 2) AU086.0
Notes:
Each target_disk_data stanza represents a different disk that is part of your rootvg volume
group. In this case, we're only going to install AIX on one disk -- hdisk0. Some of the fields
shown under the target_disk_data stanza may not exist inside the
/usr/lpp/bosinst/bosinst.template or <spot>/bosinst.data template files. They are shown
here because they may exist inside the /var/adm/ras/bosinst.data template file.
The locale specifies the language to use DURING the installation (if you do see BOS install
screens), and then for your cultural convention, error messages and keyboard type to use
once the system is installed.

V3.1.0.1
Instructor Guide

Purpose — To show how to augment the target_disk_data and locale stanzas of the
bosinst.data file.
Details — There are many ways to specify the target_disk_data stanza. Typically folks use
just one field and blank out the others. There is a complicated formula to figure out which
entry to use. So if you're concerned you might have your logic wrong, you're better off to
just blank out the entries you don't want to use. The most common fields are hdiskname
(good for local simple scsi hookups), PHYSICAL_LOCATION (for more sophisticated
hookups) and SAN_DISKID (another technique for SAN devices that uses the WWN//LUN
format).
Refer to the infocenter Web site on bosinst.data for more details.
The locale for the United States can either be C or en_US. Both appear to use English
United States as their locale.
Transition Statement — Now that we understand how to augment the bosinst.data file,
let's look at the whole procedure to see how to define this resource to NIM.
Instructor Guide
Defining the bosinst_data Resource

1. mkdir /export/nim/bosinst_data
2. Consider naming structure

bosinst_base_noprompt
bosinst_base_prompt
bosinst_base_server_noprompt
3. cp <spotdir>/bosinst.data \
/export/nim/bosinst_data/bosinst_base_noprompt
4. vi /export/nim/bosinst_data/bosinst_base_noprompt
5. Define resource to NIM

Figure 4-10. Defining the bosinst_data Resource AU086.0
Notes:
Shown here is the overall technique on how to set up the resource.
Notice the naming schemes. Consider what you are using this resource for and come up
with an appropriate naming scheme.
You can use one of several templates as a starter file. In the case on the screen, we've
chosen the bosinst.data file found inside your spot. For example, for a spot530Base spot,
your bosinst.data file would be found in the /export/nim/spot/spot530Base directory.
nim -o define -t bosinst_data \
-a server=master \
-a location=/export/nim/bosinst_data/bosinst_base_prompt nim_bosinst_name
Use the "lsnim -q define -t bosinst_data" command for more details or see the nim man
page.

V3.1.0.1
Instructor Guide

Purpose — To show the overall technique to use to define a bosinst_data resource to NIM.
Details —
Transition Statement — Let's turn our attention now to another resource - image_data.
Instructor Guide
image_data Resource Concepts
BOS Install Program:

Ask BOS Install Questions
Create rootvg image_data
Make LVs resource can
Make FSs override
Install Filesets or Restore Data
image_data use:
Mirroring rootvg
Change PP size
Shrink FSs
Change LV/FS policies
Other
Used a lot more for mksysb restores
Figure 4-11. image_data Resource Concepts AU086.0
Notes:

V3.1.0.1
Instructor Guide

Purpose — To show how an image_data resource can override a base install.
Details — The image_data resource is used more with mksysb installs than with RTE
installs. However, some folks desire to mirror rootvg, adjust the default PP Size for rootvg
or to adjust LV and FS policies of the core operating system file systems during a base
install.
On mksysb installs, shrinking the file systems is probably the most common use. This is
particularly helpful when trying to shring the /usr or /root file systems.
The default image_data file used during an RTE install appears to be the one located at the
top of the <spot> directory. The default one used during a mksysb install is one created
with the mkszfile command during a normal mksysb backup. This creates an image.data
file in the /(root) file system of the system being backed up.
Transition Statement — Let's briefly view some fields inside this resource that you might
want to change.
Instructor Guide
Editing the image_data Resource

<spotdir>/image.data:
logical_volume_policy:
SHRINK=no
vg_data:
QUORUM=1
VG_SOURCE_DISK_LIST=hdisk0 hdisk1
PPSIZE=16
lv_data:
LOGICAL_VOLUME=hd4
LPs=6
PP=6
PP_SIZE=16
COPIES=2
fs_data:
FS_NAME=/
FS_SIZE=196608
FS_MIN_SIZE=156960
FS_LV=/dev/hd4
Figure 4-12. Editing the image_data Resource AU086.0
Notes:
Templates - You can use two different templates for an image_data resource. There's a
native one located in your <spot> directory. This tends to have more default values. There's
also one you can generate on any client with the mkszfile command. This creates the
/image.data file. This file reflects the actual settings on the current machine.
Mirroring Rootvg - The fields highlighted on the screen show which fields need to be set
in order to mirror rootvg during a base install. The quorum value of 1 means to turn off
quorum checking. The copies value of 2 means to create an original copy and mirror copy.
You could choose to specify additional mirroring policies under the lv_data stanzas of all
the logical volumes. By default, the original LVs end up on hdisk0. The mirrors end up on
hdisk1. This procedure also creates a mirrored hd5 and updates the bootlist accordingly.
This is because the BOS Install program notices the location of the hd5 logical volume and
reacts accordingly at the end of the install process. Make sure you also set up the two disks
shown here also in your bosinst.data file.
Adjusting PP Size - Only the PP_SIZE field in the vg_data stanza needs to be adjusted.
The PP_SIZE fields in the lv_data stanza don't have to be adjusted. The BOS Install

V3.1.0.1
Instructor Guide
Uempty program continues to make the LVs according to the lv_data's PP_SIZE and LPs fields. It
makes the translation between the lv_data PP_SIZE field and the vg_data PP_SIZE field
and adjusts the lv_data's LPs value accordingly.
Shrinking File Systems - This is handy when working with mksysb installs. Merely adjust
the SHRINK field in the logical_volume_policy stanza to yes. This adjusts all file systems
down to the FS_MIN_SIZE field shown in each fs_data stanza. If you desire to shrink just a
single file system, then you only need to adjust the LPs field on the lv_data stanza for that
file system. Also consider shrinking the PP field as well so that mirroring of the logical
volume will not be attempted. The BOS Install Program multiplies the number of LPs by the
PP_SIZE in the lv_data stanza to determine the LV (and thus the FS) size. It ignores size
information in the fs_data stanza. CAUTION: the BOS install program demands that LVs
and FSs are at least 16 MB in size.
Instructor Guide
Instructor Notes:
Purpose — To briefly show some major fields you might want to adjust inside this file.
Details — Don't spend a lot of time on this. This is probably the least used resource of the
resources covered in this unit. You might consider covering the mirroring rootvg fields and
leaving the rest for the students' reference later on.
Additional Information — If interested, you can view the BOS Install program's
implementation of the image_data file fields. Look at the /usr/lpp/bosinst/bi_main shell
script. In particular, note the Make_Sys_FS and Make_Sys_LV functions.
Transition Statement — Now let's look at the overall procedure to define this image_data
resource.

V3.1.0.1
Instructor Guide
Uempty
Defining an image_data Resource
1. mkdir /export/nim/image_data
2. cp <spotdir>/image.data /export/nim/image_data/image_mirror
3. vi /export/nim/image_data/image_mirror
4. Define the image_data resource to NIM
Figure 4-13. Defining an image_data Resource AU086.0
Notes:
Defining this resource is similar to defining other resources. This time, however, you define
an image_data resource.
Rather than creating the file from scratch you can use one of two templates. Use the
<spotdir>/image.data file for RTE installs because this template is what would be used
during normal base AIX installs. Use the /image.data file at the client for mksysb installs.
You can generate a full /image.data file at the client by issuing the mkszfile command.
In the case shown on the screen it is assumed that you're generating an image_data
resource to mirror your rootvg volume group.
Command Line - The equivalent NIM command for the above operation is:
nim -o define -t image_data \
-a server=master \
-a location=/export/nim/image_data/image_mirror \
nim_image_data_name
Instructor Guide
Use the lsnim -q define -t image_data command for more details or see the nim man
page.

V3.1.0.1
Instructor Guide

Purpose — To briefly show how to create an image_data resource.
Details — Again, don't spend a lot of time here.
Transition Statement — Let's now look at some resources that can help us with post
customization.
Instructor Guide
Script Resource Concepts and Definition

NIM Internal
Client install adapter
Hostname
Route back to Master
script fb_script
Before reboot
After reboot
Access to data
TCP/IP Config
at the master
1. mkdir /export/nim/script
mkdir /export/nim/fb_scripts
2. vi /export/nim/script/mkusers
mkuser valerie
mkuser bill
3. Define resource to NIM
4. Used after the base install goes down
Figure 4-14. Script Resource Concepts and Definition AU086.0
Notes:
NIM internal scripts are automatically run by NIM. Note how NIM already handles
configuring your client's install adapter's IP and hostname. It also sets the hostname of the
entire machine to this install adapter's hostname. Finally, it generates a route back to the
master.
Script resources are just that - shell scripts or binary programs that you want to use to do
some customization on your client after the base operating system has been installed.
To access data at the master, you can place it under any resource that's mounted during
the install. For example, in the case of a spot530Base spot, the
/export/nim/spot/spot530Base/usr directory at the master is mounted at the /../SPOT/usr
directory at the client. The lpp_source is mounted and viewable from the client's
/../SPOT/usr/sys/inst.images directory.
nim -o define -t script \
-a server=master \

V3.1.0.1
Instructor Guide
Uempty -a location=/export/nim/script/mkusers nim_script_name

Use the lsnim -q define -t script or lsnim -q define -t fb_script commands for more details.
The nim man page also helps.
Instructor Guide
Instructor Notes:
Purpose — To point out what post customization NIM handles, versus what we need to
handle. Also, to show which resource you might want to use for different types of activities.
Details — First of all, don't spend too much time on this page. This can get really
complicated. Merely introduce the concept to the customer. They have to experiment on
their own when the time comes. We really don't have time in this class to discuss this in
detail.
The key difference between the script and fb_script is that the script resource runs before
the client reboots while the fb_script runs right after reboot. This author has typically had
more luck with the regular nim script than the fb_script. I have heard some customers tell
me, though, that complex device configuration might go better after reboot. I've also been
able to use it to run IP/hostname configuration on anything NIM doesn't automatically do.
Notice that there is already an /export/nim/scripts directory set up by NIM master
initialization. This directory is for NIM internal use only. Instead, set up a separate
/export/nim/script directory for your scripts. Or consider setting up your scripts in
/export/nim/myscripts. The myscripts directory might be more easily detected as a custom
scripts directory versus the script directory.
script - One of the uses of scripts is to access data or programs that may not yet be on the
installed client. As shown in the notes, you can access resources at the master (or other
server) that are mounted during the install. Supposedly theses resources were mounted on
the RAM filesystem by the BOS install program. However, by the time your script runs,
supposedly the BOS install program has already done a chroot to change the root
filesystem to disk. Hence, your RAM filesystem is now available by referring to "/../". And,
since your spot (that is, /export/nim/spot/spot530Base/usr) was originally mounted on the
/SPOT/usr directory in the RAM file system, it should now be accessible from the
/../SPOT/usr directory. Since your lpp_source was previously mounted on the
/SPOT/usr/sys/inst.images directory in the RAM filesystem, it should now be available from
the /../SPOT/usr/sys/inst.images directory.
With the above knowledge, you can now store commands, scripts, datafiles, and so forth.
in resources like your SPOT or lpp_source and use them while running your nim scripts.
For example, if you created a directory in your spot called
/export/nim/spot/spot530/usr/mycust and stored a datafile inside called mydata, you could
copy it to your /home/valerie directory at your client by using the following command inside
your nim script:
cp /../SPOT/usr/mycust/mydata /home/valerie
Another use of scripts is to create entries in inittab to set up to do other post customization
after your normal daemons are up and running. This can get pretty complicated, so I didn't
even mention it to the students, but you might try to augment the following example if you
have a student in need of this support.
Let's say you wanted to create an NIS+ user. Well, you'd have to wait until your NIS+
daemons were up and running. And, you'd somehow have to come up with the logic to

V3.1.0.1
Instructor Guide
Uempty remove your inittab entry when done. You'd obviously have to create the following code
and then define it as a script resource to NIM.
mkitab "nisctl:2:once:/nismkuser.script > /dev/console 2>&1"
# the above line will cause /nismkuser.script to get kicked
# off after nis+ is running as it will go at the end of the inittab file.
echo "if <code to see if nis+ user does not exist>" > /nismkuser.script
echo "then" >> /nismkuser.script
echo " nismkuser valerie" >> /nismkuser.script
echo "else" >> /nismkuser.script
echo " at now + 15 min <<-EOF" >> /nismkuser.script
echo " rmitab nisctl" >> /nismkuser.script
echo " rm /nismkuser.script" >> /nismkuser.script
echo "<tab>EOF"
You might be able to come up with simpler code, but this is the type of logic that should
work.
fb_scripts - As mentioned earlier, fb_scripts aren't probably as useful. I have, however,
used them to perform TCP/IP configuration that NIM doesn't do automatically. For
example, I've run "chdev -l inet0 -a hostname=....." to make the system-wide hostname a
different one than the install interface. Be careful here!! See "smity mkhostname" and the
command that's generated before you run this command. There's a little more to it than
what I described. I've also used: "chdev -l en1 -a netaddr=9.19.98.1 -a
netmask=255.255.255.0 -a state=up" to bring a non-install interface up. Note: it's possible
that scripts could also do this, but this has not been tested.
When does the fb_script run? Well, the fb_script runs when the fbcheck entry runs from the
/etc/inittab file. This entry checks for an /etc/firstboot file on your system. /etc/firstboot only
exists right after a base install. When you create your fb_script, your entries will be
appended to the end of this current /etc/firstboot file that IBM already uses.
Transition Statement — Let's take a look at our last resource category -- resource groups.
Instructor Guide
Resource Groups Concepts
Manual:
spot530
Install has problems
lpp_source520
bosinst_for_mksysb_install
Resource Group:
spot530
lpp_source530 Install works great
bosinst_for_base_RTE_install
NOTE: Primarily Command Line Implementation
Figure 4-15. Resource Group Concepts AU086.0
Notes:
Resource groups are a great way to make sure that resources that are meant to be used
together ARE used together. Notice that when we (and especially our more novice users)
try to manually pick the resources we need, we might make mistakes. When we use a
resource group, we've already designated what resources are meant to go together and
we've given it a name. All that we to know is the name of the resource group.
We see in the advanced base install unit how to install your client using resource groups.
Unless you plan on using machine groups, you are forced to implement the resource group
via the command line. However, the command line attributes are very simple since the
resources have been pre-setup with the resource group.

V3.1.0.1
Instructor Guide

Purpose — To show the advantage of setting up a resource group.
Details — The biggest obstacle with resource groups is that they probably have to be
implemented with the command line. The only exception is if they plan on using it with
machine groups.
Hold off detail student questions until you cover the advanced base install unit later on.
Transition Statement — Let's briefly look at how we can define a resource group.
Instructor Guide
Defining a Resource Group

smitty nim (or nim_mkgrp_resource)
Manage Groups
Define a Group
Define a Resource Group
Define a Resource Group
* Group Name [530base_rte]

MEMBERS TO REMOVE [] +
SPOT [spot530] +
LPP_SOURCE [lpp_source530] +
INSTALLP_BUNDLE [] +
SCRIPT [] +
BOSINST_DATA [bosinst_data_base_rte] +
IMAGE_DATA [] +
.....
Figure 4-16. Defining a Resource Group AU086.0
Notes:
This resource group is named 530base_rte. It includes all appropriate resources for a base
530 RTE install.
There are many additional resources on the list not shown on our screen. We talk about
more of these other resources later.
nim -o define -t res_group \
-a spot=spot530 \
-a lpp_source=lppsource530 \
-a bosinst_data=bosinst_data_base_rte 530base_rte
Use the lsnim -q define -t res_group command for more details. Or, visit the nim man page.

V3.1.0.1
Instructor Guide

Purpose — To show how to define a resource group.
Details — We show in the Advanced Base Install lecture how to utilize this and all the
resources discussed in this unit. For now, just concentrate on the definition only.
Evidently the members to remove field is a technique to temporarily take resources away
from a resource group on a temporary basis in preparation for a unique install.
Transition Statement — Let's now review our material with a checkpoint activity.
Instructor Guide
1. T/F Making any resource typically means making the actual
resource and then using smit's Define a Resource screen to tell
NIM about it.
2. T/F Making a bundle file and Defining the Resource to NIM is all
you need to do to make sure a bundle is ready to go.
Correct Answer: False. You also need to make sure the filesets
listed inside the bundle file are available in an accessible
lpp_source.
3. T/F If your bosinst.data's PROMPT field is set to yes, you have to
answer your BOS install questions at your client.
Correct Answer: True. You also have to answer those questions if
you made an error inside your bosinst.data file.
4. What do you need to set your INSTALL_METHOD variable to
inside your bosinst.data file in order to do a base RTE install?
_____________________________________________________
Correct Answer: overwrite.
5. T/F Two target_disk_stanzas inside your bosinst.data file mean
that you'll be installing your system onto two disks.
Correct Answer: True. This of course assumes that you've set up
these stanzas correctly.
6. After your base install has been installed, you can perform some
post customization by using what two types of resources?
_____________________________________________________
Correct Answer: script, fb_script
7. T/F Resource groups help to ensure that appropriate resources are
paired together in order to perform a particular install process.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
•Define bundles
•Define bosinst_data to automate BOS install questions
•Define image_data to change FS/LVM defaults
•Define scripts to perform post customization
•Define resource groups
Notes:
Instructor Guide
Instructor Notes:
Purpose —
Details —

V3.1.0.1
Instructor Guide
Uempty Unit 5. Handling NIM Network Issues

This unit discusses issues that are important to NIM's network
environment. It discusses NIM network concepts, how to define NIM
networks, and how to make sure simple TCP/IP network settings get
set up in the client.

• Identify NIM network concepts
• Identify how NIM network objects get setup
• Handle simple IP/host config during install
• Distribute resources on the network

Accountability:
• Checkpoint
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-1
Instructor Guide
Unit Objectives
•Identify NIM network concepts
•Identify how NIM network objects get setup
•Handle simple IP/host configuration during install
•Distribute resources on the network
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
NIM Network Uses

•Configure client interfaces
–Done during base install
•Verify clients can reach resources

–Done during resource allocation
•Select the right boot image

–spot530.chrp.mp.ent
versus
–spot530.chrp.mp.tok
Figure 5-2. NIM Network Uses AU086.0
Notes:
Why does NIM even keep networking information? It's done for a few reasons. First, it uses
your client's install adapter information to configure its IP during the base install. You could
also set it up so that the client's other network interfaces were configured as well.
It also uses network routing information to verify that your client can indeed get to the
resources it needs to get to during NIM operations. This is done during the allocation
timeframe, which is right after any NIM install command is issued but before it runs.
Finally, networking information is used to help determine the right boot image to use for the
appropriate client. Notice the ent or tok at the end of the boot image name. Make sure that
it matches the type of interface the client is using for its install interface.

V3.1.0.1
Instructor Guide

Purpose — To highlight major reasons why NIM even maintains network information.
Details — NIM keeps networking information for several reasons as shown in the student
notes. Remember, your AIX normal routing statements are not available to the client during
a base install. Instead, NIM supplies this information to the master via the /etc/bootptab
entry and to the client via the /tftpboot/<client>.info file.
During normal ongoing non-bootable operations, AIX routes are typically used. However,
this author has personally experienced that when the AIX routes did not satisfy a NIM
need, that NIM went ahead and created new routes to handle a particular NIM operation.
This happened, of course, during the allocation phase which is right before the NIM
operation occurs. The AIX route did not disappear when the command finished.
The reason there are so many different boot images rather than one big one is because a
smaller, more customized boot image would transfer faster to the client.
Transition Statement — Let's first of all look conceptually at how NIM network definitions
are kept.
Instructor Guide
NIM Network Definitions
Master Intermediate
network1 G G network2 Client
subnets
if1=network1 route to client route to master if1=network2
When Define Master - network1 is set up (with AIX default route if defined)
When Define Client - network2 is set up (and routes are added to reach
each other)
-OR-
Set up network definitions manually
Figure 5-3. NIM Network Definitions AU086.0
Notes:
NIM only needs to know about the networks that its own machines are on. It presumes that
someone else is taking care of all the routes in the middle.
In this case, the master is on one subnet and a client is on another. To get to each other,
you need to define the networks for both, and routing statements on both to get to the
opposite side. All of the networking information, such as the IP address, netmask, and
routes, are kept ONLY on the network object and not in the client's definition. All the client
or master definition needs to have is at least one if the attribute is pointing them to the
network they belong to.
When we configured our master earlier, it automatically set up the first network object and
assigned the master to it. If we had an AIX default gateway defined at the time, it would
have also set up a default gateway on the master's subnet. If not, no route statement on
network1 would yet appear. When we define our first client on network2, we not only define
the client, but NIM also automatically defines the network2 network and routes (if
necessary) on network1 and network2 to get to each other. Hence, it appears you typically

V3.1.0.1
Instructor Guide
Uempty would never have to manually set up networks and routes yourself. Instead, NIM handles
these definitions on your behalf.
Alternatively, you could choose to manually define your networks and routes. And, you can
always use smitty nim screens to change attributes or to remove network definitions.
Instructor Guide
Instructor Notes:
Purpose — To show how NIM networks are defined.
Details — The key is to emphasize that network definitions are auto-configured and that all
the important information is stored on the network object and not at the client object
location. All the client has to do is to associate itself with a subnet via it's if1 attribute. If it
has more than one install adapter, then you would see an if2 attribute. You would NOT see
an if2 attribute if you had another non-install adapter on the client. The ifX attributes are
only for interfaces that you can install over.
If you generate a new network object and forget the needed routes, you would see a bad
Nstate and an extra attribute as follows:
Nstate = information is missing from this object's definition.
missing = route to the master
CSM environments typically have you define your networks manually to NIM and then they
run a special csm2nimnodes command to automatically define the clients to NIM according
to their own internal CSM database.
Transition Statement — Let's look at a couple of NIM network object listings that would
match the above given scenario.

V3.1.0.1
Instructor Guide
Uempty
Sample NIM Network Definitions
lsnim -l network1 lsnim -l network2
network1: network2:
class = networks class = networks
type = ent type = ent
Nstate = Ready for Use Nstate = Ready for Use
prev_state = information is missing
prev_state = information is missing
from this object’s
from this object's
definition
definition
net_addr = 192.168.1.0
net_addr = 10.31.208.0 snm = 255.255.255.0
snm = 255.255.248.0 routing1 = default 192.168.1.1
routing1 = default 10.31.208.1
lsnim -l master lsnim -l lpar10
master: lpar10:
if1 = network1 nimsrv 26D780002002 if1 = network2 lpar10 0 ent0
Figure 5-4. Sample NIM Network Definitions AU086.0
Notes:
The output you see here might represent the conceptual view on the last screen. Notice
that all the important information is in the network object. In this case, both sides are using
default routes to get to the opposite side. You could have additional routing attributes if you
had extra static routes you could potentially use to do the install.
Notice that the only information stored in the client's object is its hostname, MAC address,
its install adapter and the network it's tied to.
Instructor Guide
Instructor Notes:
Purpose — If you manually generate a new network object and forget the needed routes,
you would see a bad Nstate and an extra attribute as follows:
Nstate = information is missing from this object's definition.
missing = route to the master
If you had another static route defined, you would see something like:
routing2 = 10.31.208.0 192.168.1.252
In this case, the first number is the destination network. The second number is the gateway
to use to get there.
Remember, the information stored in here is for installation networks and routes only.
To configure non-install interfaces and additional routes on your client, you'll need to use
the fb_script resource as we'll see later on.
Details —
Transition Statement — Let's take a look at how defining a client can affect network
object definitions. First, let's define a client on a pre-existing NIM network.

V3.1.0.1
Instructor Guide
Uempty
Defining a Client on a Previously Defined Subnet
Define a Machine
Hostname of Machine: [lpar2]

(Primary network Install Interface)
Define a Machine
NIM Machine Name [lpar2]

* Cable Type N/A +
* NIM Network network1
* Host Name lpar2
Network Adapter Hardware Address [0]
Network Adapter Logical Device Name [ent0]
Figure 5-5. Defining a Client on a Previously Defined Subnet AU086.0
Notes:
When defining a client on a network that NIM already knows about, NIM recognizes that. It
then automatically assigns this new client to the pre-existing network1 object.
As you can see in the NIM Tasks below, NIM uses your lpar2 hostname and retrieves its IP
address. It then compares this IP address to its current NIM network definitions. Since it
found a match (network1), it then assigns your new client to this network1 network.
NIM Tasks:
1. lpar2 --> /etc/hosts or DNS --> 10.31.209.56
2. Looks at prior NIM network definitions
3. Sees that lpar2 is on the network1 network
Instructor Guide
Instructor Notes:
Purpose — Show how NIM automatically recognizes what network your hostname is on
and assigns it to this pre-existing NIM network definition.
Details — The key is to mention how NIM intervenes automatically on your behalf.
Transition Statement — Now, let's see what happens when NIM defines a client on a
network that your NIM database does not yet recognize.

V3.1.0.1
Instructor Guide
Uempty
Defining a Client on a New Network (1 of 2)
Define a Machine
Hostname of Machine: [lpar10]

(Primary network Install Interface)
Define a Machine
Type of Network Attached to primary Install Interface

tok = token ring
ent = ethernet
fddi = FDDI
generic = generic (no network boot)
atm = atm
Figure 5-6. Defining a Client on a New Network (1 of 2) AU086.0
Notes:
Notice how NIM saw that lpar10 was not on its pre-existing network1 subnet. It immediately
starts asking for networking information in order to build a new network object.
Instructor Guide
Instructor Notes:
Purpose — To show what begins to happen if you start to define a client on a network that
NIM doesn't know about yet.
Details — In this case, we need to start entering in information to define this new network
object as well. On this screen, let's choose ethernet as the network type. Remember, this is
used during a base install to pick up the right boot image for the client.
Transition Statement — Let's see what additional fields we have to enter now that we're
generating not only a client definition, but its new network definition as well.

V3.1.0.1
Instructor Guide
Uempty
Defining a Client on a New Network (2 of 2)
Define a Machine
* NIM Machine Name [lpar10] +

* Cable Type N/A +
* NIM Network [ent-Network1]+
* Network Type ent +
* Ethernet Type Standard +
* SubnetMask [] +
* Default Gateway Used by Machine [] +
* Default Gateway Used by Master [10.31.208.1] +
* Host Name lpar10 +
Network Adapter Hardware Address [0] +
Network Adapter Logical Device Name [ent0] +
Figure 5-7. Defining a Client on a New Network (2 of 2) AU086.0
Notes:
You're asked a lot more questions this time. That's because NIM not only defines the client,
but also defines a new network, and generates some new routes.
Be sure to enter in a valid NIM network name, check the ethernet type, the new network's
subnetmask, and gateways needed from the master and client to now get to each other.
Notice that it presumes you want to use the pre-existing default route for network1
(10.31.208.1). If we didn't have a default gateway already assigned to the master, it would
allow us to enter one in now.
Instructor Guide
Instructor Notes:
Purpose — To show the additional fields asked when defining your new client that deal
with generating a network definition.
Details — The key is that you now not only define your client, but also a new network and
some route statements.
The Default Gateway used by machine is the default route from the client to get to the
master.
The Default Gateway used by Master is the default route from the master to get to the
client.
It's probably a good idea to rename the NIM network from the default shown to something
more meaningful to the client.
About the only thing not asked is if you want additional static routes for your network object
to be used to install this client. If so, you have to define them manually using the Manage
Network Install Routing screen. As a reminder again, NIM only cares about routes used for
INSTALLING clients, not additional static routes the client may care about later on.
Transition Statement — Let's see how to define a network manually in case we ever need
to do so.

V3.1.0.1
Instructor Guide
Uempty
Defining Networks Manually
smitty nim (or nim_mknet)
Manage Networks
Define a Network
Network Type
tok = token ring

ent = ethernet
fddi = FDDI
generic = generic (no network boot)
atm = atm
Define a Network
* Network Name [ent-Network1]

* Network Type ent
* Ethernet Type Standard +
* Network IP Address []
* SubnetMask []
Default Gateway for this Network []
Other Network Type +
Comments []
Figure 5-8. Defining Networks Manually AU086.0
Notes:
As you can see, defining a network is pretty straightforward. The only field that's not
obvious is the Other Network Type field. This is to define another network type if your
network uses a bridge between two different network types (that is, ent and tok) on the
same subnet.
There are counterpart screens to easily define default and static routes. And, of course,
there are also options to list, change, and remove all of these network definitions. You only
use these screens to define NIM installation networks and routes. If, for some reason your
client has additional interfaces and routes that aren't involved with the communication with
your NIM master or some other NIM server, than you would not use this facility to define
this type of network or route. NIM only desires to record and control networks and routes
that affect NIM installation activities.
Instructor Guide
Instructor Notes:
Purpose — To briefly show how to define a network manually if ever needed.
Details — There's no reason to spend too much time here. It's pretty obvious. Just point
out that there are simple smit screens that you can use if you ever need to manually define
or change network and route definitions.
By the way, if they ever want to delete a NIM network, it can be done pretty easily from the
command line if the network is not currently in use by a client: “nim -o remove
network_name”.
Transition Statement — Now that we know how to define NIM networking information that
NIM needs to perform a base install, let's see what additional networking information we
might want to set up for our client during its base install.

V3.1.0.1
Instructor Guide
Uempty
Client Install IP Configuration
Install Interface - NIM Internal
(From Client/Network Definition)
Extra Interfaces - FB Script

or
adapter_def/nimadapters
Hostname - NIM Internal

(From Client Definition)
Changing Hostname - FB Script
Route to Master - NIM Internal

(From Network Definition)
Additional Routes - FB Script
Figure 5-9. Client Install IP Configuration AU086.0
Notes:
Fortunately, your install interfaces are automatically configured for you.
If you plan to perform TCP/IP configuration on non-install adapters, you have to do that
yourself. You can either use the complicated adapter_def resource along with the
nimadapters command, or you can implement a simpler fb_script.
The install adapter has it's hostname set not only for itself, but for the whole system. NIM
does this on your behalf. If you decide you don't want to keep the system-wide hostname
as the install adapter's hostname, then you have to do some post customization.
Baseline routing is handled by NIM. It makes sure you can get back to the master.
However, if you want the client to use additional static routes once it’s up and running, you
need to configure these additional static routes yourself. This can be done by implementing
an fb_script.
Instructor Guide
Instructor Notes:
Purpose — To show what does and does not get automatically set up by NIM. And to show
what resource the student might use to accomplish those additional configuration steps.
Details — Students are pleased to know that a lot of the baseline TCP/IP configuration is
taken care of by NIM. In fact, when you install a mksysb, NIM overrides the current TCP/IP
configuration inside that image with your client's network information.
It appears that the only route that the client has after the install is the default route back to
the master. All other routes have to be set up manually by you via an fb_script.
Just introduce the concepts here. Refer to the next screen to discuss how to handle these
extra customizations in detail.
Transition Statement — Now that we see what type of TCP/IP configuration may need to
be done manually by us, let's look at a couple of commands that we can use to accomplish
this configuration.

V3.1.0.1
Instructor Guide
Uempty
fb_script IP Changes
Interface: chdev -l en1 -a netaddr=192.168.0.1 \
-a netmask=255.255.255.0 \
-a state=up
Hostname: chdev -l inet0 -a hostname=myhost

hostid `hostname`
other?
Additional
Static Routes: chdev -l inet0 -a .........
Figure 5-10. fb_script IP Changes AU086.0
Notes:
Remember, your install interface is already configured by NIM. So, we only have to
configure non-install interfaces. By the time your fb_script runs, your network interfaces
(that is, en0, en1, tr0, tr1) are already defined. However, they won't yet have IP attributes
assigned. So, use the chdev command to change this. You could use the ifconfig command
to do this, but this change would be temporary only, whereas the chdev command takes
place immediately and is permanent.
Changing your system's hostname might come in handy if you use a non-install interface
as your system's hostname. Remember, NIM causes your install interface's hostname to
be the system-wide hostname. Be careful. Changing a hostname could potentially affect
different things on your system. On a base install this is not a big ordeal. However, it's still a
good idea to review the smitty mkhostname screen and check with F6 the command that
smit generates on your behalf. Double check to see what other configuration files and so
forth on your system may be affected by a hostname change.
Instructor Guide
Let’s hope you won't have to add in any extra routes as this can be complicated. The best
way to figure out how to do this is to use the lsattr -E -l inet0 command output and compare
this output with the command behind the smitty mkroute screen. Good luck!!

V3.1.0.1
Instructor Guide

Purpose — To show the commands they may want to utilize to change common TCP/IP
settings.
Details — The hostname procedure and especially the static route procedure can get
complicated. It's listed here merely as a reference for your customer. You do not have time
in this class to discuss this in detail. Instead, get them started and point them where to look
for additional help.
In order to better understand what's involved, use the lsattr -E -l en0 command, the lsattr -E
-l inet0 command, and view the commands generated behind the smit screens listed.
The hostid is probably not used as much anymore. However, I've noticed some SUN
diehards want to refer to this the way we refer to the uname -m command to get a
machine's ID.
Transition Statement — Let's take a look now at how to set up your client's
/etc/resolv.conf file for DNS.
Instructor Guide
/etc/resolv.conf Configuration
1. mkdir /export/nim/resolv_conf
2. vi resolv_conf_network2
domain my.company.com
nameserver 192.168.0.1
nameserver 192.168.0.2
3. Define Resource to NIM
Define A Resource
* Resource Name [resolv_conf_network2]

* Resource Type resolv_conf
* Location of Resource [/export/nim/resolv_conf/resolv_conf_network2] /
Figure 5-11. /etc/resolv.conf Configuration AU086.0
Notes:
As you can see, defining a resolv_conf file works just like any other resource we've defined.
And, the contents are just like a normal /etc/resolv.conf file.
Command Line - The above definition can be run at the command line with:
nim -o define -t resolv_conf \
-a server=master \
-a location=/export/nim/resolv_conf/resolv_conf_network2 \
resolv_conf_network2

V3.1.0.1
Instructor Guide

Purpose — To show the procedure for creating a resolv_conf resource.
Details — Refer to the student notes. This is pretty straight forward.
Transition Statement — Let's look at one final network concept - distributing resources
throughout your NIM network.
Instructor Guide
Distributing Resource Concepts
Master Server Client
scripts SPOT
installp_bundles lpp_source
mksysb
Pro Con
Faster Install More Administration
Less Network Overhead
Can Use BOOTP Broadcast
Figure 5-12. Distributing Resource Concepts AU086.0
Notes:
If you have a big network environment, you may want to distribute your resources closer to
your clients. This probably promotes a faster install and uses less network overhead. This
is especially true if you're doing several installs at once over several different subnets. In
addition, as we find out later, it allows you to perform a bootp broadcast on a client that is
not on the same network as the master. The biggest hindrance is that this now requires
additional administration. Not only do you have to define resources on all these remote
clients, but now you have to maintain all of them. They don't sync themselves together
automatically.
The picture shows someone at the master choosing to install the client. In this particular
case, the client utilizes the resources assigned to it wherever they reside. Notice that the
biggest resources have been offloaded to a server on the local subnet. Distributing things
like installp_bundle definition files is probably not worth the effort.
The most common thing to distribute is a SPOT. This is because the SPOT deals with the
core part of the base install. Folks don't want to use BOOTP over a gateway or to send
boot images over a gateway and/or they want to use a bootp broadcast initiation method.

V3.1.0.1
Instructor Guide

Purpose — To show the concepts, pros and cons of distributing resources throughout your
NIM network.
Details — I hear mixed opinions about distributed resources. Most folks in smaller shops
don't want to deal with the hassle of keeping them maintained. Some folks choose to have
multiple NIM masters to handle multiple subnets versus using one master and distributing
resources across the subnets.
A somewhat common technique is to distribute just the SPOT.
Transition Statement — Let's see how to distribute a resource.
Instructor Guide
Setting Up a Distributed SPOT

1. Create and mount the /export/nim/spot FS on machine: lpar_on_network2
2. Define the Resource to NIM
Define A Resource
* Resource Name [spot530_network2]

* Resource Type spot
* Server of Resource [lpar_on_network2] +
* Source of Install Images [spot530] +
* Location of Resource [/export/nim/spot] /
3. Use it with your installs
* Installation Target another_lpar_on_network2

* Installation Type rte
* SPOT spot530_network2
....
Figure 5-13. Setting Up a Distributed SPOT AU086.0
Notes:
The first thing to do is to prepare a nim client out on your network to be a server. The only
thing they have to do is to prepare space to place the spot.
The second thing is to define a new spot using the old spot as the source. This provides a
fast, straight copy from the original spot on the master to the new spot on the nim client.
Notice the naming scheme. Make sure you can easily identify via the name which spot
you'll want to use. Once this step is done, lpar_on_network2 is now officially considered to
be a NIM server.
When ready to use this spot, merely choose it as your desired spot when you install other
clients on the same subnet.
Command Line - The command to do the same as the above definition screen is:
nim -o define -t spot \
-a server=lpar_on_network2 \
-a source=spot530 \

V3.1.0.1
Instructor Guide
Uempty -a spot530_network2
See the "lsnim -q define -t spot" command or the nim man page for more details.
Instructor Guide
Instructor Notes:
Purpose — To show the steps to both define a distributed resource and to see how easy it
is to use.
Details — Quite often students are surprised at how easily a NIM client can be transformed
into a NIM server. The only criteria to become a NIM server is to have a resource at your
site.
Students are also surprised at how easily they can see this new spot as one to pick from a
list when they go to install.
Notice that we picked a spot to distribute. We could have chosen many different resources,
but a spot is the most commonly used resource to distribute.
I quite often demonstrate this procedure so students can see this live. This might be
especially useful since this is the one unit that doesn't have an associated exercise. I
typically have one student create the filesystem on their client and then I demonstrate the
last two steps. You can even go to step 3 while the SPOT is still being created. Be careful!
Remove this SPOT before the students do the next exercise. You can't install a machine if
it has a resource on it.
Don't concentrate on the SPOT details as much this time. We have a whole unit on SPOTs
and lpp_sources that's coming up. I merely chose the SPOT as the distributed resource
because it's the most commonly distributed resource.
Transition Statement — Let's review our work with some checkpoint questions.

V3.1.0.1
Instructor Guide
Uempty Checkpoint Questions

1. T/F NIM Network definitions are used during resource allocation
and in choosing the right boot image for the client (that is, ent
versus tok).
2. T/F Each client is assigned to at least one network via its if1, if2
and so forth, attributes.
3. T/F The client can identify its default gateway by looking at the
routing attribute on its client definition.
Correct Answer: False. You must first look at the client's if1
attribute to find out what network it is associated with. Then, look at
the network's routing attribute to figure out what the default router
for that network is.
4. T/F When I define a new client on a remote network, NIM is
unaware or I will get not only a new client object but also a new
network object with a routing attribute that identifies the remote
network's gateway.
5. T/F The client's install adapter's IP and hostname are automatically
configured by NIM during a base install.
Correct Answer: True. NIM uses your client's definition and its
network definition to construct a script that runs after your base
install goes down.
6. List two advantages of distributing resources on your network.
_____________________________________________________
Correct Answer:
Bootp broadcast
Faster Install
Instructor Guide
Unit Summary
•Identify NIM network concepts
•Identify how NIM network objects get setup
•Handle simple IP/host configuration during install
•Distributed resources on the network
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 6. Implementing an Advanced Base Install

This unit discusses how to customize your base install, how to
automate it and implement machine groups. It will also discuss how to
reset the client after an installation failure.

• Customize your install
• Automate your install
• Implement machine groups
• Reset the client after an installation failure

Accountability:
• Checkpoint Questions
• Lab Exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-1
Instructor Guide
Unit Objectives
•Customize your install
•Automate your install
•Implement machine groups
•Reset the client after an installation failure
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Customizing Your Install

* Installation TYPE rte
* SPOT spot530
LPP_SOURCE [lppsource530] +
MKSYSB
BOSINST_DATA to use during installation [bosinst_base_rte] +

IMAGE_DATA to use during installation [] +
RESOLV_CONF to use for network configuration [network1_resolv_conf] +
Customization SCRIPT to run after installation [grab_data_script] +
Customization FB Script to run at first reboot [config_en1_fb_script] +
....
Additional Bundles to install [udb_bund] +
-OR-
Additional Filesets to install [] +
(bundles will be ignored)
For resource groups:

nim –o bos_inst –a group=<resgroup> \
-a accept_licenses=yes [-a no_client_boot=yes] lpar1
Figure 6-2. Customizing Your Install AU086.0
Notes:
Notice how easy it is to add all the resources we just created in the last two lectures.
If you've previously defined these resources, they should be available when you list them
using the F4 smit key.
Command Line - The command to accomplish the above smit screen operation is:
nim -o bos_inst \
-a spot=spot530 \
-a lpp_source=lpp_source530 \
-a bosinst_data=bosinst_base_rte \
-a resolv_conf=network1_resolv_conf \
-a script=grab_data_script \
-a fb_script=config_en1_fb_script \
-a installp_bundle=udb_bund \
-a installp_flags='-acNgX' \
lpar1

V3.1.0.1
Instructor Guide
Uempty Resource Groups - Resource groups can not be initiated from smit unless you're applying
them against a whole machine group. However, the command line, as shown, is easy to
implement. This command assumes that you already have a bosinst_data resource setup
that automatically accepts user licenses. The no_client_boot option determines whether a
push operation occurs from the master. Setting this to yes does not cause a push to occur.
Not using this attribute causes a push to occur.
Instructor Guide
Instructor Notes:
Purpose — To show how we can use the resources we've been defining in a live base
install.
Details — You can install multiple bundles, including several system defined bundles, but
there's no guaranteed order of install.
Remember the order is: Use bosinst.data to answer BOS questions
Use image.data to help in creating VGs/LVs/FSs
install base
install bundles/filesets
Run internal nim scripts (probably where resolv_conf goes)
Run scripts
reboot
Run fb_scripts
finish inittab
The resolv_conf file is not documented in the material I'm viewing. I sense it's done during
the internal nim scripts timeframe since that's where a lot of the internal TCP/IP
configuration is done.
Resource groups are a great way for folks to guarantee they have all the right resources to
utilize during an install. Notice how you don't have to spend as much time listing all the
resources on the bos_inst command line. That's because the resource group definition
takes care of all of that. Notice in smit that there's an option to temporarily take resources
out of a resource group in preparation for a unique install.
If you want to use smit and resource groups, you have to put your machine into a machine
group and then use the machine groups menus. You probably have to take the menu
option to allocate the resources to the machine group first. Then take the menu item to your
bos_inst install against this machine group.
Transition Statement — Let's now see how we can automate our install using the PUSH
procedure.

V3.1.0.1
Instructor Guide
Uempty
PUSH Automation Concepts
Master Client
Base Install Setup (PUSH) IPs set

Normal Bootlist - Install Adapter
Reboot
bosinst.data BOS Install Questions Answered
CAUTION: For live NIM clients only
Figure 6-3. PUSH Automation Concepts AU086.0
Notes:
A push along with using a bosinst_data resource is the best way to automate an install. The
only constraint is that it only works with AIX machines that are already up and running and
are NIM clients. It use either the master's rsh or a nim command to the receiving client's
nimsh daemon (depending upon the client's definition) to send the following commands:
1. bootlist -m normal entX bserver=…client=…[gateway=…] [speed=…] [duplex=…]
2. wall message to users
3. nimclient -S shutdown
4. reboot
This causes the client to issue a BOOTP request back to wherever your SPOT server is
located. Presuming you've got a bosinst_data resource, the operation should require no
intervention at all at the client side.
Instructor Guide
Instructor Notes:
Purpose — To show how to totally automate an install using the PUSH initiation technique
along with a bosinst_data resource.
Details — If you look at the bootlist man page, you see there are extra options on this
command to not only change the normal bootlist, but to set up IPs and speed as well.
An example command that NIM is probably running on your behalf is:
bootlist -m normal ent0 gateway=0.0.0.0 bserver=10.31.209.54 client=10.31.209.55
If you had put the speed and duplex settings in when you defined your client, it would also
add in:
speed=auto duplex=auto (or whatever was appropriate)
You might mention that they can also use this bootlist command themselves. This might
save someone from having to go into SMS mode at the client to adjust all these settings.
This obviously only works if the machine is currently up and running.
Transition Statement — Now that we can see how a PUSH conceptually works, let's see
how to physically use it during a normal install.

V3.1.0.1
Instructor Guide
Uempty
Using a PUSH During a Client Install

....
BOSINST_DATA to use during installation [bosinst_base_rte] +
....
FORCE PUSH the installation? [no] +
Initiate reboot and installation now? [yes] +

-OR-
Set the bootlist for installation at the [no] +
next reboot?
.....
Schedule a Job [no] +

YEAR [] #
MONTH [] +#
DAY (1-31) [] +#
HOUR (0-23) [] +#
MINUTES (0-59) [] +#
Figure 6-4. Using a PUSH During a Client Install AU086.0
Notes:
This screen is the same screen we've seen a lot of in this class. This time, we look at a few
new options. First of all, if you're going to do a push, you might as well include a
bosinst_data to answer all those BOS install questions.
Next, the only line you have to be aware of to do a push is the Initiate reboot line. Notice
that by default, it's set to yes. This does your push for you. Of course, this presumes that
your client is already up and running and is a NIM client at this time. Otherwise, a push
does the master setup, but then just timeout in trying to adjust your client.
Some folks like to do some or all of this operation later on. The Set bootlist field allows you
to issue the bootlist command, but not the shutdown command to start the operation now.
Hence, you can get your client ready now. Then, schedule a shutdown -r command using
your client's at facility to reboot and start the operation sometime later that night.
The third technique is to schedule everything later on, both the bootlist and the
shutdown/reboot command. These entries schedule the operation at the client site using
the at facility there.
Instructor Guide
Command Line - The equivalent of the above operation at the command line is to use the
native nim -o bos_inst command. Using the no_client_boot=yes attribute does not do the
push and instead relies on you to manually go to the client and start the install. If you want
to set just the bootlist at the client, then use the set_bootlist=yesattribute on the nim
command line. Evidently the scheduling piece is not a part of the normal nim command.
Refer to the lsnim -q bos_inst -t standalone command for more information.

V3.1.0.1
Instructor Guide

Purpose — To show the smitty nim_bosinst screen's fields that deal with a PUSH
automation.
Details — The force push is typically used if the client has chosen to disable push
operations via it's own smitty nim panel. It forces a non-attended push onto the client. It
requires that a bosinst_data resource is used.
Transition Statement — We've now seen how to do a manual initiation, and now a PUSH
initiation technique. Let's turn now to the third alternative to initiate your install: BOOTP
Broadcast.
Instructor Guide
Semi-Automating Your Installs with BOOTP Broadcast
Master Server Client
Put MAC in Client Defn
Setup SPOT on local

Subnet
Base Install Setup

(no push)
Set Bootlist (online or SMS)

reboot
SPOT bootp broadcast
bosinst.data BOS Install Questions Answered
Figure 6-5. Semi-Automating Your Installs with BOOTP Broadcast AU086.0
Notes:
If we were to use a bootp broadcast technique, there's some upfront work we need to do.
First of all, we need to put our client's MAC (hardware) address in our client's definition.
This is because the client identifies itself to the SPOT server using its MAC address. Next,
we need to make sure that either the master or some other NIM client that has the right
SPOT is located on the local subnet. This is because bootp broadcasts only work on the
local subnet. The last thing to do at the master is making sure we choose no on the Reboot
and Initiate Install Now? question on the smitty nim_bosinst screen. Of course this all
presumes that your server IP address field is still set to zeros.
If the client is running, you could use the bootlist command to set the boot device for this
client. Merely use your favorite remote command facility such as ssh to accomplish this.
When ready, issue the shutdown -r command at your client. This causes it to come up and
issue a bootp broadcast message to everyone on the local subnet. It is hoped that your
SPOT server is set up to reply and give your client its boot image. If for whatever reason
your client is brand new, chances are that your NIC adapter is on the normal bootlist
already. Merely boot up your client and it should start your bootp broadcast. If it's not, go
into SMS and change the temporary normal bootlist to your NIC adapter.

V3.1.0.1
Instructor Guide
Uempty Command Line - A potential set of commands to accomplish this whole scenario with a
live AIX client is the following.
1. nim -o change -a if1=network1 client1 MAC_ADDR_HERE ent0 client1
2. We'll assume you already have a SPOT on the local subnet
3. nim -o bos_inst -a bosinst_data=… [include your options here] \
-a no_client_boot=yes client1
4. ssh client1 bootlist -m normal ent0
5. ssh client1 shutdown -r
For a down client, don't do steps 4 and 5. Instead, go into the client's SMS menu to adjust
the bootlist (if needed) and exit out to start the boot.
Instructor Guide
Instructor Notes:
Purpose — Show how to do a BOOTP broadcast.
Details — When working with a brand new client, this bootp broadcast technique may
actually be useful. That's because the default bootlist on a brand new machine includes the
NIC adapters. Plus, the IP addresses are already set up as zeros. The only two things to do
are to get the MAC address of the client (under SMS's Remote IPL menu), put that in the
client's definition and then make sure you have a SPOT on the client's local subnet.
Transition Statement — Let's look at how to install your clients using a machine group.

V3.1.0.1
Instructor Guide
Uempty
Defining a Machine Group
smitty nim (or nim_mkgrp_standalone) • Same Installation Resources
Perform NIM Administration Tasks – bosinst_base_rte
Manage Machine Groups – lpp_source53ML1
Define a Group – spot53ML1
Define a Stand-alone Machine – And so forth
Group
• Same Boot Type
-spot53ML1.chrp.mp.ent
Define a Standalone Machine Group
* Group Name [Atlanta_530_chrp_ent]

* Group Type mac_group
Member Type standalone
* Group Members [lpar20 lpar21 ....] +
Comments []
Figure 6-6. Defining a Machine Group AU086.0
Notes:
Machine groups are a great way to install several clients at once. They're easy to define as
shown. The only caution is making sure that all clients in the group can use the same
installation image and resources. If not, you can temporarily exclude a client from a group
for a period of time. Refer to the Manage Machine Groups screen for details.
Command Line - The equivalent command for the above operation is:
nim -o define -t mac_group \
-a add_member=lpar20 \
-a add_member=lpar21 \
etc.
Atlanta_530_chrp_ent
Instructor Guide
Instructor Notes:
Purpose — To show machine group concepts and how to define a machine group.
Details —
Transition Statement — Let's see how we can use this machine group definition now on
performing a base install.

V3.1.0.1
Instructor Guide
Uempty
Installing Your Machine Group
Choose the BOS Install Menu option at the Master:
Select a Target for the Operation
lpar1
lpar2
....
* Installation Target Atlanta_530_chrp_ent

....
Group Controls (only valid for group targets):
Number of Concurrent Operations [6] #
Time Limit (hours) [5] #
Figure 6-7. Installing Your Machine Group AU086.0
Notes:
Notice how your machine group now shows up on the same screen where all your other
clients appear.
By default, machine groups are installed all at the same time. If installing many, this may
overload your network too much. Instead, consider limiting the number you install
simultaneously. In this case, we've set it to 6. If one machine would finish its installation,
another would immediately take its place. In other words, you always have six installing at
once.
The time limit is handy when you want to kick this off in the night and can't afford to run it
past a certain timeframe. If your time limit is reached, no new installs start, but the ones
installing at the time complete.
You could also use resource groups with machine groups, but you'll have to use a different
screen to make it work. Go to smit's Manage Groups screen. Take the option to allocate
Resources first. Use this to allocate your resource group to your machine group.
Instructor Guide
Then, from that same machine groups screen, take the menu option to Perform Operations
on Machine Groups. From here, choose the bos_inst operation. Notice on the final
dialogue screen that most of your fields don't exist because you've already assigned all
necessary resources.
nim -o bos_inst . . . \
-a concurrent=6 \
-a time_limit=5 \

V3.1.0.1
Instructor Guide

Purpose — To show how to invoke a machine group while doing a base install.
Details —
Transition Statement — Let's now view some normal output you might see.
Instructor Guide
Monitoring Your Machine Group Output

On your SMIT screen:
Initiating bos_inst operation on machine 7 of 30: lpar7...
Status: Pending: 23 Installing: 6

Complete: 1 Failed: 0
...
Target Result
lpar1 COMPLETE
lpar2 COMPLETE
...
lpar29 NOT_STARTED
lpar30 NOT_STARTED
Figure 6-8. Monitoring your Machine Group Output AU086.0
Notes:
Your smit screen continues to keep you apprised of the latest status. Notice that when the
first machine finished installing, NIM started installing the next one in the queue. The client
name that has most recently started to install is shown on the right. This screen refreshes
itself every several seconds and also as each new client starts an install. Obviously you'd
have to scroll back to see clients that have already started their install. When your installs
have completed (or your time limit is up), you see the result screen shown at the bottom.
If all of your machines did not complete when your time limit was up that's OK. NIM keeps
an internal record of what clients have already installed in the group versus which ones
have not. Merely re-issue the smitty nim_bosinst operation again against the entire
machine group. NIM picks up where it left off.
If you <ctrl-c> out of the smitty nim_bosinst operation prematurely and a client is already in
the midst of installing code, this client's operation completes and NIM records it as such.
Hence, the next time you go to re-install the group, NIM assumes this machine (and other
completed machines) does not need to be installed this time.

V3.1.0.1
Instructor Guide

Purpose — To show how to monitor your machine group output.
Details — The only problem I've heard about this is if you have a client that got hung up
during the install (that is, a power failure), you may have to reset that client and start it
again from scratch.
This facility actually works pretty nice.
Transition Statement — There's another NIM class you can take to identify problems
during a NIM install. However, it might be nice to identify a few quick things to check if your
installation doesn't go well.
Instructor Guide
Common Installation Problems

•Forgot smitty nim_bosinst at Master
•Wrong IPs/bootlist at Client
•Wrong Client Definition
•Hostname Mismatch
(Client Definition - DNS/Hosts_file)
•Media Speed Mismatch
•Gateway - BOOTP Forwarding not Configured
•Network Gear Malfunctioning
•Network Overloaded
•NFS Settings
Figure 6-9. Common Installation l Problems AU086.0
Notes:
This is not a problem determination class, but let’s hope it's useful to list some common
problems that happen during a base install. As you can see, most problems have nothing
at all to do with NIM. Instead, they deal with network issues. For most of these issues, you
need to reset the client before you can fix the problem. So, on the next screen we discuss
how to reset your client.

V3.1.0.1
Instructor Guide

Purpose — To briefly mention some things that the student can look for if they have
problems during a base install.
Details — There supposedly is a problem determination class coming, so we are not
suppose to concentrate on PD here. However, it's probably handy to spend just a minute
listing some common problems your customer may run across. It's probably not
appropriate to go into detail on all the symptoms for these problems here, but I list the
symptoms I've noticed here in the instructor notes:
1. Forgot nim_bosinst at master or wrong IPs at client - you typically see "S=1, S=2, S=3",
and so forth, at the client when booting. It can't find it's server.
2. Wrong bootlist - this can cause several things to happen including having the client boot
back up from disk.
3. A wrong client definition typically causes a wrong boot image to be chosen. You notice
that when the boot image loads your client stops and hangs.
4. Hostname mismatches between your NIM client definition and your DNS/hosts_file
cause all kinds of unusual symptoms. Typically you hang up on a 6XX LED. A lot of
times your client halts when it tries to mount the SPOT. It can't because it can't find the
right server. Be careful!! NIM requires that you use no aliases for your hostname on
your NIM client definition and that you match long.names (NIM) with long.names
(DNS/hosts_file) and shortnames(NIM) with shortnames (DNS/hosts_file.
5. Media speed mismatches are probably one of the most common problems in IBM
labrooms. A really slow install is typically because your media/duplex settings are
different between your client and server and their hub ports. Quite often auto/auto is
your best setting, but not always. You can view this setting in AIX with entstat -d en0 |
grep Media. This works for many adapters, but not all. You can also check the
media_speed attribute of the entX adapter. In SMS, look under the Remote IPL menu.
Make sure your client's SMS setting matches your master's software setting. Changing
the setting on your master is a bit involved. Do a smitty chinet to detach your interface.
Then, issue a smitty chgenet to change the speed/duplex, then smitty chinet to pull the
interface back up.
6. Some gateway/routers need to be configured to allow BOOTP forwarding. This affect
you if your SPOT server is on a different network than your client.
7. Other reasons for a really slow install are network problems. Commands like entstat
can help out here. Also, watch for low end hubs. Sometimes I can only install 2
machines at a time on a low end hub.
8. NFS read/write buffers if not carefully aligned with MTU sizes of adapters and other
routing gear can cause severe performance degradation. I've heard of a normal 1.5
hour install taking up to 30 hours to complete when read/write buffers were set up
incorrectly. This is obviously outside of the scope of this class. Refer the student to the
Performance Guide for more information.
Instructor Guide
Transition Statement — Now that we've briefly identified the types of problems you might
run across, let's see how to reset our client so that we can fix these problems.

V3.1.0.1
Instructor Guide
Uempty
Resetting Your Client
smitty nim (or nim_mac_op)
Manage Machines
Perform Operations on Machines
Choose your client and the "reset" operation
Reset the NIM State of a Machine
Target Name lpar1

Deallocate all Resources? yes +
Force yes +
lsnim -l <client>
Cstate = Ready for a NIM Operation
Figure 6-10. Resetting your Client AU086.0
Notes:
If you ever have problems during an install, you will probably need to reset your client to fix
the problem. Once the problem is fixed, start your install again from scratch. Be careful! If
you're trying to do a push operation and your client is now down, you can't repeat a push.
Instead, you have to use a manual pull or a broadcast bootp method.
Once you reset your client, deallocating all its resources and forcing it (just in case), your
Cstate field should say: Ready for a NIM Operation. And, no resources should currently be
assigned to this client.
Command Line - The equivalent set of commands for the above operation is:
nim -Fo reset lpar1
nim -Fo deallocate -a subclass=all lpar1
Instructor Guide
Instructor Notes:
Purpose — To show how to reset your client to aid in fixing an install problem.
Details — Restarting an operation once it's been terminated can sometimes be tricky. You
may not be able to do a push anymore (if your client is now down). Instead, the restart
probably requires a manual or bootp broadcast. Also, remember that you'll have to start
your operation again from scratch at your NIM master.
Additional Information — If you haven't already discussed the nimerr showlog yet you
might do so now. Be sure to point out that the students need to view the log at the master
versus the client if the operation was initiated at the master.
Transition Statement — Let's review our lecture material with a checkpoint activity.

V3.1.0.1
Instructor Guide

1. T/F You can augment your client's base RTE install by adding
bundles or filesets. You can also perform some post customization.
Correct Answer: True
2. T/F A push operation requires no intervention at your client.
Correct Answer: True, if done right. It also presumes that your AIX
machine is up and is already a NIM client.
3. T/F A bootp broadcast requires that your SPOT server is on the
same subnet as your client.
Correct Answer: True. It also requires that you have your client's
install NIC's MAC address defined in your client's definition at the
master.
4. T/F When using machine groups different clients in the group can
use different resources.
Correct Answer: False.
5. T/F In order to fix a base install problem, first reset the client, then
fix the problem, then re-initiate your install from scratch. If your
client is down, you also probably have to do either a manual or a
bootp broadcast on your client this second time.
Correct Answer: True. If your client isn't up to receive a PUSH,
then you have to resort to a bootp broadcast or a manual client
procedure when you re-initiate your install operation.
Instructor Guide
Unit Summary
•Customize your install
•Automate your install
•Implement machine groups
•Reset the client after a failed installation
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 7. Using NIM for Disaster Recovery

This unit discusses how to use NIM to back up and restore your
clients. It also addresses how to back up and restore your NIM data.

• Use NIM to back up and restore your clients
• Implement a back up strategy for NIM data

Accountability:
• Lab exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-1
Instructor Guide
Unit Objectives
•Use NIM to back up and restore your clients
•Implement a backup strategy for NIM data
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Disaster Recovery Overview
Master Client
Alternate Master Define mksysb Resource rootvg

and/or
Backup Media Define savevg Resource
uservg
Base Install (mksysb) rootvg
restvg uservg
Figure 7-2. Disaster Recovery Overview AU086.0
Notes:
The procedures for backing up and restoring your clients are shown above. Notice that
backup procedures actually define mksysb and savevg resources at your NIM master. The
restore procedures use a base install and a restvg command.
Your NIM master also needs to be backed up. In 5.3 there's a new procedure that allows
you to have an alternate NIM master. Implementing this feature is optional. It allows
another computer to take over your clients if the current master is unavailable. This does
not solve all of your NIM master backup needs. Instead, a backup of your NIM master to
media is typically your best backup alternative.

V3.1.0.1
Instructor Guide

Purpose — To show the overall techniques used to do all the backups and restores for
your NIM client and master data.
Details — Students are probably looking for backup and restore screens in NIM and they
don't exist. Point out the difference in terminology. Backing up means to Define a
Resource. Restoring your system means doing a Base Install with a mksysb.
Another thing to point out is that they also need to have a good NIM master backup. We
talk about this procedure later on. At first glance, one might think that the new Alternate
Master technique is a complete NIM master takeover. You might think that it would allow
immediate takeover of all of the NIM master's tasks. However, it does not. According to this
author's experience, the Alternate Master Takeover only does two major things: 1) it takes
over the NIM ODM database and 2) it points the clients to the new alternate master. Even
then, the procedure has some severe limitations. It doesn't take over the whole NIM
database. For example, it takes over the clients but then only takes over the resources that
don't physically reside at the master site. Hence, its primary purpose appears to be for
large shops that have all their resources distributed and need an immediate takeover of the
master's duties. If a student is interested, you can refer them to the appendix on this
procedure.
Most students probably prefer not to have an alternate master. Instead, they just back up
the master's NIM database and actual NIM data to media. If the master goes down, they
can afford to wait the 2-3 hours it may take to restore the NIM database and data back onto
the master. The only major limitation of this procedure is that it presumes the data, when
restored, goes back onto the same hostname/IP/MAC Address of the old master. If you
need to restore the NIM data onto another machine with another IP address then, after
restoring the data (as shown later on in this unit) you need to resort to the special
procedure in NIM's online documentation to change a master's IP.
Transition Statement — Let's see how to get a pre-installed machine to join our NIM
network.
Instructor Guide
Joining the NIM Network

"Defining a Client" -OR- "Join the NIM Network"
From Client: smitty nim (or niminit)
Configure Network Installation Management Fileset
* Machine Name [lpar1]

* Primary Network Install Interface [en0] +
* Host Name of Network Install Master [nimsrv]
Hardware Platform Type chrp

Ethernet Interface Options
Comments []
Alternate Port Numbers for Network Communications

(reserved values will be used if left blank)
Client Registration [] #
Client Communications [] #
Figure 7-3. Joining the NIM Network AU086.0
Notes:
Previously we talked about Defining a Client to the NIM master. This needs to be done for
clients that are installed from scratch. However, what about those clients that just want to
join your NIM network in order to get installation updates and/or to do system backups?
Well, welcome to smitty niminit.
smitty niminit is a procedure that's run at your client. Make sure this new machine isn't
already a client to another master or that your master hasn't accidentally defined them
already or this procedure won't work.
The information entered is very similar to what you would enter in defining your client at the
NIM master. The key difference is the Host Name field. Notice that you have to enter the
hostname of your master. Why? Because this information needs to be sent to your master.
When completed, your client appears to the NIM master as a full-fledged NIM client.
Command Line - The equivalent command for the above screen is:
niminit -a name=lpar1 -a master=nimsrv -a pif_name=en0 -a platform=chrp \
-a netboot_kernel=mp -a cable_type1="N/A" -a connect=nimsh

V3.1.0.1
Instructor Guide

Purpose — To show why and how to do a smitty niminit procedure.
Details — Let the port numbers default. Only change these if you have changed the nim
daemon TCP/IP server ports at the master site via it's /etc/services file.
Watch out for clients that are still in a semi-defined state. For example, a client may still
have an /etc/niminfo file out there pointing to another master. Or, the NIM master may have
the client defined at the master site already. For both scenarios, go to the NIM master
under Manage Machines and remove the machine. If you have a stray /etc/niminfo file
merely remove it.
Transition Statement — Now that we have a NIM client defined, let's see what we need to
do to prepare for our NIM client backups.
Instructor Guide
Getting Ready for Your Backups

•Determine Disk Space Needed for each Client
lsvg -l <vgname>
df -Im (Add up Used column for FSs seen above)
•Create Directories at Master

/export/nim/mksysb
/export/nim/savevg
•Determine Naming Schemes

client_name
client_name_12_20_2005
Figure 7-4. Getting Ready for Your Backups AU086.0
Notes:
Backups can take up a lot of space at the master. First of all, compute how much space you
need for all of these clients. The commands shown are handy to do this. Be sure to only
include the filesystem space on the df report that's in the VG you plan to back up.
The naming scheme can change depending on how much data you decide to store at the
NIM master. Most folks seem to keep just the prior night's backup at the master. The next
night, the new backup overwrites the prior night's backup. If you wanted to have multiple
backups at the master server, you could name the backup by client name and date.

V3.1.0.1
Instructor Guide

Purpose — To show the steps needed to prepare your NIM master for your client backups.
Details — Run the lsvg and df commands on each client you plan to back up. Be careful to
include JUST the filesystems on the df report that match the filesystems in the VG you plan
to back up. The I option is handy because it shows a used column. This allows you to use
easier math computations.
Remember, mksysb and savevg backups do NOT create the initial directory. You have to
do that yourself upfront.
Most folks use the first naming scheme. I've also seen some folks use just straight NFS to
do the backup. In this scenario, they back it up using a name like
client_name_12_20_2005. Then, they'll create a symbolic link called client_name that
points to this resource. Why do they do this? Well, NIM mksysb backups require that you
remove the old resource before defining the resource again for the next night's backup.
This can become a hassle. In using this NFS scheme, they only create the NIM resource
once and then use NFS to continually point NIM to the latest NFS backup. Another nice
outcome of this is that they can name their backup by the actual date. This might be helpful
in quickly identifying the right backup.
Transition Statement — Now, let's start out with a simple mksysb backup to our NIM
master.
Instructor Guide
Simple NIM Client rootvg Backup

Upfront: nim -o remove -a rm_image=yes lpar1_mksysb
Define a Resource
* Resource Name [lpar1_mksysb]

* Resource Type mksysb
* Location of Resource [/export/nim/mksysb/lpar1_mksysb] /
Comments []

-OR-
System Backup Image Creation Options:
CREATE system backup image? yes +
NIM CLIENT to backup [lpar1] +
PREVIEW only? no +
IGNORE space requirements? no +
EXPAND /tmp if needed? no +
Create MAP files? no +
Backup extended attributes? yes +
Number of BLOCKS to write in a single output [] #
(leave blank to use system default)
Use local EXCLUDE file? no +
(specify no to include all files in backup)
-OR-
EXCLUDE_FILES resource [] +
(leave blank to include all files in backup)
Figure 7-5. Simple NIM Client rootvg Backup AU086.0
Notes:
The nim -o remove command needs to be done if you have a mksysb backup from the
night before. This is because you can't RE-define an existing resource.
rootvg backups are done by merely defining a mksysb resource. You're probably already
familiar with the information at the top of this screen. Notice the additional information
below. This information is very similar to information you would see on a normal mksysb
backup screen. Notice you have the same options to choose from. Merely say yes to
Create system backup image and choose the NIM client you want to backup.
nim -o define -t mksysb -a server=master -a location=/export/nim/mksysb/lpar1_mksysb \
-a mk_image=yes -a source=client1 lpar1_mksysb

V3.1.0.1
Instructor Guide

Purpose — To show how to do a simple mksysb backup to the NIM master.
Details — If you have a backup from the night before, you have to remove it before you
can use this same mksysb resource name again for tonight's backup. You can also do this
in smit, but the command was easier to show on the screen.
Concentrate on the two top lines in the bottom section. You also may want to briefly point
out the exclude lines below as we discuss these options more in a minute.
Normal backups immediately give you a REQUIRED and AVAILABLE size. You can quickly
see if a backup does not succeed due to space limitations.
Don't get too detailed here. We want the student to see how easy it is to do a backup. We'll
show more advanced operations later on.
Transition Statement — Let's see how to restore this data on your client.
Instructor Guide
Recovering Your Client’s rootvg – Master Side

Perform a Base Install (smitty nim_bosinst)
Select the Target: lpar1

Select the Type: mksysb
Select the mksysb: lpar1_mksysb
Select the spot: spot530

* Installation TYPE mksysb
* SPOT spot530
LPP_SOURCE [] +
MKSYSB lpar1_mksysb
BOSINST_DATA to use during installation [] +

IMAGE_DATA to use during installation [] +
RESOLV_CONF to use for network configuration [] +
Customization SCRIPT to run after installation [] +
Customization FB Script to run at first reboot [] +
ACCEPT new license agreements? [no] +
Remain NIM client after install? [yes] +
....
Initiate reboot and Installation now? [no] +
Figure 7-6. Recovering Your Client's rootvg - Master Side AU086.0
Notes:
Restoring your system is just like doing a base RTE install, except you now be choosing a
mksysb installation type instead.
nim -o bos_inst -a source=mksysb -a mksysb=lpar1_mksysb \
nim -o bos_inst -a source=mksysb \
-a mksysb=lpar1_mksysb \
-a spot=spot530 \
-a no_client_boot=yes \
lpar1
CAUTION: Please make sure you use a SPOT that is at the same release level as the
image you're installing. Also make sure it's at the same fix level or higher. If you don't have
a SPOT at that level, then either create one from scratch or refer to the online
documentation on how to create a SPOT from a mksysb.

V3.1.0.1
Instructor Guide

Purpose — To show how to set up the master to do a basic restore of your client's mksysb.
Details — Concentrate on a base recovery at this point. We talk about cloning
considerations later on. In other words, keep it simple here.
Be sure to tell them not to do a push as your client is down and can't receive a master push
operation.
Transition Statement — Now let's see how to finish this recovery procedure at the client's
side.
Instructor Guide
Recovering Your Client’s rootvg – Client Side

•Get into SMS
–Set IPs (if necessary)
–Change bootlist to entX
–Exit out
System Backup and Installation Settings
1 Disk(s) where you want to install............... hdisk0
Use Maps................................... No
2 Shrink Filesystems.............................. No
3 Import User Volume Groups....................... Yes
4 Recover Devices................................. Yes
>>> 0 Install with the settings listed above.
>>> Choice[0]: 0
Figure 7-7. Recovering Your Client's rootvg - Client Side AU086.0
Notes:
Since your client is down, we have to manually go to the client and at least reset the normal
bootlist to your NIC adapter (for bootp broadcast) and also check your IPs (for manual).
Answer the typical initial BOS install questions such as choosing your console and install
language. Choose to double check your settings. You then see this screen come up.
The defaults you see are probably fine. If you don't import your user volume groups you
won't see them after you install. Hence say yes here. If you forget, you can always
manually re-import your user VGs with the importvg command later. Be sure to recover
your devices so that the prior TCP/IP settings and your defined devices appear. The only
time you wouldn't want to choose this is if you've been forced to restore your backup onto
another machine. If so, cfgmgr runs and do baseline configuration for you to handle this
install.

V3.1.0.1
Instructor Guide

Purpose — To see what settings need to be checked at the client side to finish this mksysb
restore.
Details — Some folks panic later on if they forget to do the importvg command from this
screen. This is because after a base restore, no user VGs are visible. One has to do the
importvg -y vgname hdiskX command to see that VG again. Fortunately this value defaults
to yes if it senses you're restoring back onto the same system.
You want to set Recover Devices to yes if restoring back on to the same machine. What
this literally chooses is whether to restore the Cu* files in the ODM database. This affects
what you see on your lsdev -C, lsattr -E -l <dev> and TCP/IP reports. If you say no, cfgmgr
still runs and finds all of your hardware. However, attribute changes and so forth that you
may have done, are lost. Fortunately this will be on by default is restoring to the same
machine and is off by default if restoring to a different machine.
Transition Statement — Now that we've seen how to do a basic backup and restore. Let's
start getting a little bit fancier.
Instructor Guide
Getting Fancy on Your rootvg Backups and Restores
•Excluding data from your backup
•Utilizing existing backups
•Using your mksysb for cloning
•Automating your BOS install questions
•Utilizing additional resources
Figure 7-8. Getting Fancy on Your rootvg Backups and Restores AU086.0
Notes:
You can get fancy on your backups and restores. Let's see on the next few screens what
we can do.

V3.1.0.1
Instructor Guide

Purpose — You can get fancy on your backups and restores. Let's see on the next few
screens what we can do.
Details —
Transition Statement — Let's take a look at the first option -- excluding data from your
backup.
Instructor Guide
Excluding Data from Your rootvg Backup

•Umount Filesystems
•Use Exclude Config File

–At Client: /etc/exclude.rootvg
–At Master: exclude_files Resource
•Contents
/myfs
/hisfs
Figure 7-9. Excluding Data from Your rootvg Backup AU086.0
Notes:
You can exclude data from your backup by either unmounting your filesystem before the
backup or by excluding the filesystem using an exclude resource or config file. Unmounting
the filesystem is typically not desired. This is because you typically want the restore
procedure to at least re-create your filesystem. Only those filesystems that are mounted
get put into the /image.data control file and are thus created during restore.
You can either use the standard AIX technique at the client site to exclude the file systems
and directories from your backup or you can create a NIM exclude_files resource at the
master to do this. The nice part about using this second technique is that you at the master
have control. You won't be affected by someone at the client site accidentally destroying
the /etc/exclude.rootvg file. Merely include the directories you don't want to backup one line
at a time inside.
Command Line - The equivalent command to create an exclude_files resource is:
nim -o define -t exclude_files -a server=master \
-a location=/export/nim/exclude_files/lpar1_rootvg_exclude lpar1_rootvg_exclude

V3.1.0.1
Instructor Guide

Purpose — To show different methods you can use to exclude data from your mksysb
backup.
Details — At this point students should understand how to define a resource. Merely show
them that an exclude_files resource is one more type. It's defined the same way as
installp_bundles, bosinst_data's, and so forth. If you use the exclude_files resource, then
NIM will transfer this file to the client right before it schedules the backup.
Transition Statement — What if you already have a backup on tape or CD, and so forth,
that you want NIM to use?
Instructor Guide
Utilizing Existing rootvg Backups

Get Data to Disk:
mksysb Tape/CD/File /export/nim/mksysb/lpar1_mksysb
Define File to NIM:
Define a Resource
* Resource Name [lpar1_mksysb]

* Resource Type mksysb
* Location of Resource [/export/nim/mksysb/lpar1_mksysb] /
Comments []

-OR-
CREATE system backup image? no +
NIM CLIENT to backup [] +
....
Figure 7-10. Utilizing Existing rootvg Backups AU086.0
Notes:
If you have an existing mksysb backup, you can transfer that under NIM's control. Again,
merely define a resource. However, this time, do NOT create a system backup image.
NIM double checks that the listed mksysb file is a valid mksysb file. Then, it defines this
resource to NIM.
Command Line - The equivalent command to the above procedure is:
nim -o define -t mksysb -a server=master -a location=/export/nim/mksysb/lpar1_mksysb \
-a mk_image=no lpar1_mksysb

V3.1.0.1
Instructor Guide
Uempty Use the following procedures to transfer prior mksysb backups to disk. Be sure to test your
images out, though, before you need to use them.
1. # tctl -f /dev/rmt0.1 fsf 3

2. # dd if=/dev/rmt0
Tape mksysbs:
of=/export/nim/mksysb/lpar1_mksysb \
bs=<multiple_of_tape_phys_blksize>
For CD backups with just one CD:
1. # mount -V cdrfs -oro /dev/cdrom /cdrom
2. # cp /cdrom/usr/sys/inst.images/<backup_file> \
/export/nim/mksysb/<client_name>
3. # umount /cdrom
For Multi-volume CDs:
Combining each bff file in each CD's /usr/sys/inst.images
directory is not an easy task. Consider re-generating a
new backup instead.
However, if you really do need to do this, try the following:
CD mksysbs: 1. Create a /stagedir file system big enough to hold all
the data.
2. # mount /stagedir
3. # cd /stagedir
4. # mount -V cdrfs -oro /dev/cdrom /cdrom
5. # restore -xvf \
/cdrom/usr/sys/inst.images/<backup_file>
6. # umount /cdrom
7. Repeat steps 4-6 for all CDs.
8. find . -print | backup -ivf
/export/nim/mksysb/<client_name>
1. # cp /dir/mksysb_backup \
NFS mksysbs:
/export/nim/mksysb/lpar1_mksysb
Instructor Guide
Instructor Notes:
Purpose — To show how to get existing mksysb backups into the NIM database to use for
a restore.
Details — As shown, the biggest challenge is to get the image to disk. If time is running
short, merely show the students the information is there for when they go back home.
Logically the CD technique should work. However, this author has yet to physically try this
technique out.
Transition Statement — Let's see how to use a bosinst_data resource for a restore of a
mksysb backup.

V3.1.0.1
Instructor Guide
Uempty
Automating Your BOS Install Questions
Define bosinst_data Resource to NIM
control_flow:
CONSOLE = Default
INSTALL_METHOD = Overwrite
PROMPT = no
EXISTING_SYSTEM_OVERWRITE = yes
...
RECOVER_DEVICES = yes
...
IMPORT_USER_VGS = yes
...
target_disk_data:
LOCATION =
SIZE_MB =
HDISKNAME = hdisk0
locale:
BOSINST_LANG = en_US
CULTURAL_CONVENTION = en_US
MESSAGES = en_US
KEYBOARD = en_US
Figure 7-11. Automating Your BOS Install Questions AU086.0
Notes:
The two key fields as mentioned before are RECOVER_DEVICES and
IMPORT_USER_VGS. Notice that the other fields are already set up the same way they
were set up for an RTE install.
If desired, you could utilize a current RTE bosinst_data as your template. Or, you could
choose to use the /var/adm/ras/bosinst.data file at the client to more closely represent the
settings that occurred at that client site during its initial install.
Instructor Guide
Instructor Notes:
Purpose — To show the major fields to watch out for in using a bosinst_data resource with
a mksysb restore.
Details — Don't spend too much time here. They're already familiar with this. Show them
that the fields listed are the ones they need to be concerned about for a base recovery of a
mksysb. They can probably let the other fields default from a bosinst_data they've already
created for a pure vanilla base install or from a bosinst.data in their /var/adm/ras directory
that came from their original base install.
Transition Statement — Let's look at some basic cloning issues that might affect our base
mksysb install.

V3.1.0.1
Instructor Guide
Uempty
Using Your mksysb for Cloning - Basic
Client A mksysb Backup Client B
10.0.0.1 10.0.0.1 10.0.0.2

clientA clientA ClientB
RouteA to Master RouteA to Master RouteB to Master
Install IP/Hostname - Internal NIM
Route back to master - Internal NIM
Devices - Use bosinst_data's RECOVER_DEVICES = no
DNS Server/Domain - Use resolv_conf
Figure 7-12. Using Your mksysb for Cloning - Basic AU086.0
Notes:
The biggest concern about using a mksysb for cloning is in handling the different TCP/IP
information. Fortunately, NIM handles this itself. Any information on an install adapter and
at least a route back to the master is automatically defined by NIM. NIM also adjusts the
hostname. It does this by referring to the client's definition and the client's network
definition.
If you feel you may not have the same devices on the new machine, merely set
recover_devices to no. Alternatively, if not using a bosinst_data, you could just answer the
BOS install question that comes up. In this case, the new machine gets its device list from
running cfgmgr.
If the new client is using the same DNS server and domain, then the original
/etc/resolv.conf on the original client's mksysb backup suffices. If you desire to change
these Domain or Server values from the original client or need to set them up for the first
time, you need to use a resolv_conf resource.
Instructor Guide
Instructor Notes:
Purpose — Show how to perform simple cloning customization.
Details — This is the simple stuff. The advanced things are yet to come.
Transition Statement — Now let's do some more advanced cloning.

V3.1.0.1
Instructor Guide
Uempty
Using Your mksysb for Cloning - Advanced
Non-install IP/Hostname - Use fb_script or nimadapters/adapter_def
Device/Arch - Use code in image or use lpp_source
Import User VGs - Use bosinst_data's IMPORT_USERVGS = yes
FS/LV Sizes - Use image_data
Add Software - Use bundles/filesets
Delete Software - Use script/fb_script
Other post config - Use script/fb_script
Figure 7-13. Using Your mksysb for Cloning - Advanced AU086.0
Notes:
Non-Install IP/Hostname - Non-install interfaces don't automatically get TCP/IP
configured. Refer to the prior unit on networks to see how to configure this. Remember,
setting RECOVER_DEVICES to no means deleting all of the old TCP/IP configuration
information from the old machine. The nimadapters technique might be handy to set up
TCP/IP configuration for large shops with lots of machines and lots of adapters. Refer to
the "Configuring Multiple NICs with nimadapters" appendix for more information.
Alternatively, view IBM's infocenter Web site.
Diff Device/Arch - If your new machine has a different architecture (that is, rspc) or has
different device fileset needs, you can take two approaches. The first one is the safest. Be
sure to load all device support (which includes different architecture) on your mksysb
backup image. The second alternative is to refer to an lpp_source at your master that has
the code in it.
Let's start with the first approach. The easiest way to get all the device support on your
original image is to choose this option when installing your original system. In fact, in 5.3,
this is now the default option. If you're not sure you have all device support necessary, you
Instructor Guide
can always manually install the rest of your device software by choosing all filesets that
begin with devices from your lpp_source (or AIX install media).
The lpp_source approach is not quite as safe. Since the lpp_source does have all device
support inside, it definitely handles all of your device inconsistencies. However, if your
lpp_source is not at the same level as your mksysb, you probably end up installing all the
updates on your lpp_source for all your software in your image. This may be an unintended
side result.
Import User VGs - If going to another machine, you may or may not want to import their
VGs. The default is no when installing on a different machine.
Delete Software - To delete software, you need to call a script to run a command such as
geninstall -u -f<file_of_filesets>.

V3.1.0.1
Instructor Guide

Purpose — To briefly point the student to the different resources to use to implement more
advanced cloning techniques.
Details — As you can see, it can get complicated. Let’s hope the student notes help them
when they get back home. Obviously they won't remember these details here.
Adding software is done easily on smitty's nim_bosinst screen.
Logically, they should be able to use either scripts or fb_scripts for most post
customization. If they need to transfer data or put something into the inittab file, then they
have to go with the script approach. This was already covered in more detail in a prior
lecture.
Transition Statement — Let's cover now how to do backups of your non-rootvg volume
groups.
Instructor Guide
User VG Backup
Define a Resource
* Resource Name [lpar1_udb_savevg]

* Resource Type savevg
* Location of Resource </nim/savevg/lpar1_udb_savevg] /
Comments []
-OR-
CREATE volume group backup image? yes +
NIM CLIENT containing volume group to backup [lpar1] +
VOLUME GROUP to backup [udb]
PREVIEW only? no +
IGNORE space requirements? no +
EXPAND /tmp if needed? no +
Backup extended attributes? yes +
Generate new VG.DATA file? no +
Create MAP files? no +
Number of BLOCKS to write in a single output [] #
(leave blank to use system default)
Use local EXCLUDE file? no +
(specify no to include all files in backup)
-OR-
EXCLUDE_FILES resource [] +
Figure 7-14. User VG Backup AU086.0
Notes:
If you're familiar with mksysb backups, then savevg backups should be easy to figure out.
The key difference is that you have to list the volume group to backup. Note the
exclude_files resource is also available. If done at the client site, you'd use an
/etc/exclude.<vgname> file.

V3.1.0.1
Instructor Guide

Purpose — To briefly show how to do a user volume group backup to the NIM master.
Details — Not as many folks use this. However, it's nice to quickly point out for those that
do.
Transition Statement — Let's see now how to do a user volume group restore.
Instructor Guide
User VG Restore
Clean Up Volume Group:
reducevg -d -f vg_name
Perform restvg (smitty nim_mac_op):

Perform Network Restore of a Volume Group
Target Name lpar1

* SAVEVG [lpar1_udb_savevg] +/
SHRINK the filesystems? no +
PHYSICAL VOLUME names []
(Leave blank to use the PHYSICAL VOLUMES listed
in the vgname.data file in the backup image)
Use existing MAP files? yes +
Physical partition SIZE in megabytes [] +#
(Leave blank to have the SIZE determined
based on disk size)
Number of BLOCKS to read in a single input [] #
(Leave blank to use a system default)
Alternate vg.data resource [] /
(Leave blank to use vg.data stored in
backup image)
Figure 7-15. User VG Restore AU086.0
Notes:
Restores work the same way in NIM as they do for a stand-alone machine. The restvg
operation presumes that your client's disks are totally cleaned up before the operation
begins.
You could use a vg_data resource defined at the NIM master to override the backup's
vg.data file. Remember that a user VG's control file is not image.data but vg.data. Hence,
this resource could be used to override VG/LVM/FS information on the restore.

V3.1.0.1
Instructor Guide

Purpose — To show how to do a user volume group restore.
Details — Again, hit this quickly. The key is to point out that you have to have a clean
environment at the client site before a restore can be done.
Watch out. Some folks think they can easily use this for individual disk restores. If they plan
to go this route, they'll want to augment the reducevg command to point to just the disk they
want to clean up. Then, they have to manually re-create the filesystems. Then, they have to
use the restorevgfiles command directly on the backup file in order to restore just the data
that's needed. You probably won't have time to cover this, but point out to the students that
this is meant for VG backups only. Tell them to think through a strategy to use this for
individual disk restores.
Transition Statement — Let's end this unit by talking about how to backup and restore
your NIM database.
Instructor Guide
Backing Up and Recovering Your NIM Master
NIM smit /etc/objrepos/<file> smit nim_unconfig NIM

DB nim_backup_db smit nim_restore_db DB
and and
Daemons Daemons
rootvg standalone backup standalone rootvg

mksysb media mksysb
restore
nimvg standalone backup standalone nimvg

savevg media restvg
restore
CAUTION: Different IP/HOSTNAME/MAC
Figure 7-16. Backing Up and Recovering Your NIM Master AU086.0
Notes:
mksysb and savevg Backup - Since your NIM master doesn't have its own NIM master to
backup to, you have to use normal AIX means to do your backup. Merely use the normal
mksysb (rootvg) and savevg (nimvg) techniques. The two key parts of NIM are its data
(which in our case is stored out in the nimvg volume group) and its internal database
structure (which is stored in rootvg). Both of these are backed up if you do a normal
mksysb (rootvg) and savevg (nimvg) backup.
NIM Database Backup - There may be times when you don't want to restore the whole
rootvg volume group. For example, this may come in handy if you desire to transport NIM
to another machine that's already up and running (as shown below) or if you just want to
restore your database back to what it was before you made a bad change. In this case, be
sure to back up your NIM database with the smit nim_backup_db panel. This panel backs
up the NIM ODM database, the /etc/niminfo file, the /etc/NIM.level file and the information
to remake the NIM SRC daemons. It might be a wise practice to back up your NIM
database before performing the normal nightly mksysb backup.

V3.1.0.1
Instructor Guide
Uempty Restoring Back to the Same Machine - If restoring to the same machine, merely restore
your mksysb and nimvg volume groups using normal AIX VG restore techniques. Be
careful in restoring just one volume group. For example, if just restoring your nimvg volume
group, it's possible that your NIM ODM database could be out of sync with your nimvg data.
Hence, if you want to just restore nimvg, then at least consider the following. First, make
sure that you can locate the NIM ODM backup that matches your nimvg level that you're
restoring. Then, issue the following commands. They unconfigure your NIM database and
restore it using the backup you've just identified. (CAUTION: make sure you have a good
backup to restore with before unconfiguring your NIM master).
# smitty nim_unconfig
# smitty nim_restore_db
Restoring to a Different Machine - Merely restore all both volume groups to the new
machine. The three key things to watch out for are a change in hostname, IP and/or MAC
address. Changing the MAC address after the install is easy. Use the smitty nim_chmac
panel to change the MAC address of the master to its new entX install interface. Changing
the IP and hostname is more complex. Please refer to NIM's online documentation to
accomplish this.
Restoring to a Different Machine that's Running - If you merely want to transport your
data to a machine that's already up and running, then you'll need to go through a more
comprehensive procedure. In this case, consider the following scenario:
1. Install bos.sysmgt.nim.master fileset
2. Physically move over nimvg disks
3. importvg -y nimvg an_hdisk_you_moved_over
4. restorevgfiles (for any resources in the original master's rootvg)
5. smit nim_restore_db
6. Follow the NIM online procedure to change NIM to point to the new IP/Hostname/MAC
of the new machine.
CAUTION: Please test out these procedures in your specific environment before you need
to use them.
Instructor Guide
Instructor Notes:
Purpose — To show how to backup and restore the NIM master.
Details — Changing the hostname or IP in your nim database might be used for folks that
need to transfer their stuff to a machine that is already running and doing other work. This
machine may already have a different IP/hostname. If so, use the procedure out at IBM's
infocenter Web site. This procedure basically undefines your clients, does a recovery
operation to change NIM's IP info, and then has you redefine your clients again to pick up
the changes.
If you need to restore the NIM Database then make sure you unconfigure it first. This, of
course, is only necessary if the database already existed on the designated machine. The
restore_nim_db operation will restore the NIM ODM database, the /etc/niminfo file, the
/etc/NIM.level file and will remake (mksrc) the NIM database server daemons
The alternate master procedure is documented out at the infocenter Web site. It
supposedly allows you an alternative to the cpu takeover piece. Once set up, supposedly
you just run a takeover command and the clients see the alternate as their NIM master.
However, this author has personally experienced some limitations using this facility. It did
not appear to take over the actual data. It only took over the NIM ODM database, and even
then, it only appeared to take over non-master resources. Hence, it appears to only work
well for environments where all resources are distributed. There's an appendix in the back
of the lecture guide on how to do this if you or a student is interested. NIM's online
documentation also explains this procedure a little bit.
Transition Statement — Let's review our lecture material by doing a checkpoint activity.

V3.1.0.1
Instructor Guide

1. T/F Performing a NIM mksysb backup of your client means you
need to define a mksysb resource.
Correct Answer: True if using NIM to do your backup.
2. T/F You can use an exclude_files resource to exclude data from
your client during a mksysb backup.
3. T/F Restoring a mksysb on your client means performing a Base
Install (smitty nim_bosinst) at your NIM master for this client using
the appropriate mksysb. It also means you probably need to do a
bootp broadcast or manual install at your client.
Correct Answer: True. Since your client is probably down, you
probably can't get away with doing a push.
4. T/F When restoring your mksysb to the same machine, you want to
set the RECOVER_DEVICES option to no.
Correct Answer: False. Set it to yes to restore the previously
defined devices and TCP/IP settings.
5. You're performing a mksysb restore on your client. You're using a
bosinst_data resource. What would you set your
INSTALL_METHOD variable to -- overwrite, preserve or migrate?
____________________________________________________
Correct Answer: overwrite.
6. T/F When using your mksysb for cloning purposes, you'll need to
create an fb_script to reset your new client's install interface's IP
and hostname.
Correct Answer: False. NIM already handles this by using your
client's definition and network definition to construct an internal
NIM script. This script automatically runs during post
customization.
7. T/F Backing up your NIM master means backing up rootvg, nimvg
and performing NIM's database backup.
Instructor Guide
Unit Summary
•Use NIM to back up and restore your clients
•Implement a backup strategy for NIM data
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 8. LPP_SOURCE and SPOT Management

This unit shows the students how to list, create, maintain, and delete
lpp_sources and SPOTs.

• Identify SPOT and lpp_source level issues
• List, create, and maintain lpp_sources
• List, create and maintain SPOTs

Accountability:
• Lab exercise
References
following:
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-1
Instructor Guide
Unit Objectives
•Identify SPOT and lpp_source level issues
•List, create, and maintain lpp_sources
•List, create and maintain SPOTs
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Code Level Issues

NIM Master
Keep me at latest fix level to:
Serve SPOTS
Handle Clients
LPP_SOURCE SPOT
Enough base, fix and optional lpp_sources Must equal client’s/image’s release
to satisfy your client’s needs Should be at highest client’s fix
One lpp_source per operation level
Don’t use with mksysb if mksysb is at lower
level
SAMPLE SOLUTION
One lpp_source and spot per maintenance level
Maintain additional fix lpp_sources as client needs arise
Keep the spot at the latest fix level within that ML
CHANGES
Update lpp_source, master, spot and client
Can distribute spots if don’t want master at the highest level
Figure 8-2. Code Level Issues AU086.0
Notes:
Master Dependencies:
The master must be at least at the same fix level as a client it serves. This is for two
reasons. First, if you choose to do the release nimadm command from the master to
upgrade a client's release level, then this needs to be true. Plus, it needs to be true as an
indirect result of the following:
1. SPOT <= Fix Level of Master
2. SPOT >= Fix Level of clients it serves
To alleviate some of these constraints, folks have chosen to distribute their SPOTs out to
remote NIM client locations. However, to do this, you then have to update that remote NIM
client without using your NIM master. In other words, this procedure gets a bit involved.
Hence, it's simple to just presume the following:
1. NIM Master >= NIM Client Fix Level
NIM Master - 53ML1 -NO- NIM Client 53ML2
NIM Master - 53ML2 -YES- NIM Client 53ML2

V3.1.0.1
Instructor Guide
Uempty NIM Master - 53ML2Fix1 -YES- NIM Client 53ML2

NIM Master - 53ML2Fix1 -YES- NIM Client 53ML2Fix1
NIM Master - 53ML2 -NO- NIM Client 53ML2Fix1
NIM Master - 53ML2 -YES- NIM Client 53ML1
NIM Master - 53ML2 -NO- NIM Client 52ML3
2. NIM Master's Fix Level >= NIM SPOT Fix Level on the master
NIM Master - 5.3ML1 -NO- SPOT 5.3ML2
NIM Master - 5.3ML2 -YES- SPOT 5.3ML2
NIM Master - 5.3ML2Fix1 -YES- SPOT 5.3ML2
NIM Master - 5.3ML2Fix1 -YES- SPOT 5.3ML2Fix1
NIM Master - 5.3ML2 -NO- SPOT 5.3ML2Fix1
NIM Master - 5.3ML2 -YES- SPOT 5.2ML1
NIM Master - 5.3ML2 -NO- SPOT 5.2ML3
LPP_SOURCE Dependencies:
We've already discussed the pros and cons of how to maintain all your lpp_sources.
Remember, though, you can only apply one lpp_source per NIM operation.
Watch the level of an lpp_source you use with a mksysb load. If the lpp_source is at a
higher fix level, then once the mksysb is installed, the additional fixes from the lpp_source
are applied. The only reason anymore that folks choose an lpp_source with a mksysb load
is that it's required (5.1 and below), or it's needed for device support that is not present in
the mksysb image.
lpp_source fix level (if used) = mksysb fix level
lpp_source - 5.3+fixes -NO- mksysb 5.3
lpp_source - 5.3 -YES- mksysb 5.3
lpp_source - 5.3 -NO- mksysb 5.3+Fixes
SPOT Dependencies:
The SPOT must be at the same release level and at or above the same fix level as clients
and/or images it serves. The major dependency here is on mksysb installs and stand-alone
maintenance (maint_boot) boots. You could also potentially have a problem with RTE
installs, but the dependencies aren't as noticeable as mksysb installs and maint_boot
operations).
1. SPOT Release level = client level
SPOT fix level >= client's fix level
SPOT - 5.3ML1 -NO- NIM Client - 5.3ML1+Fixes

SPOT - 5.3ML1+Fixes -YES- NIM Client - 5.3ML1+Fixes
SPOT - 5.3ML1+Fixes -YES- NIM Client - 5.3Base
2. SPOT Release level = install image level

SPOT fix level >= install image's fix level
Instructor Guide
SPOT - 5.3ML1 -NO- Install Image - 5.3ML1+Fixes

SPOT - 5.3ML1+Fixes -YES- Install Image - 5.3ML1+Fixes
SPOT - 5.3ML1+Fixes -YES- Install Image - 5.3Base
Sample Solution:
As shown previously you can have as many or as few lpp_sources to satisfy your clients'
needs. Many techniques can be used. We've chosen to have one base lpp_source for
every maintenance level our clients need. Then, we have additional fix lpp_sources to
handle individual client needs. In this way, a client only needs one operation to install the
base ML. However, the client would need two operations to apply the base ML and
subsequent fix updates.
You really only need one SPOT per release level. This would need to be kept at the same
fix level (or higher) as the highest level client within that release. Hence, whereas you may
need several lpp_sources at several maintenance levels, you could get away with only one
SPOT per release level. However, to keep maintenance simple, we've chosen to have one
lpp_source AND one SPOT per maintenance level. In this way, whenever one updates one
resource one needs to update the second as well. This sample solution is what we use
throughout the remainder of this unit to describe lpp_source and SPOT maintenance
activities.
Changes:
Be careful when updating your clients. Now, it's not just a matter of upgrading the client,
you must also keep the SPOT, lpp_source and typically the master up to date as well. Also,
when moving to a new maintenance level or release level, you probably create a brand
new SPOT and lpp_source to handle that new level of code.
IBM is also recommending keeping the NIM Master at the latest fix level of any SPOT it
serves. Hence it's probably a good idea that whenever an lpp_source is updated or a new
fix lpp_source is created to use that to update not only the SPOT and client but the master
as well. If this becomes a problem, then you could offload the high-level SPOTs onto a NIM
client. However, installing this NIM client would have to be done manually versus installing
it from the NIM master.

V3.1.0.1
Instructor Guide

Purpose — To briefly show code level dependency issues.
Details — Briefly cover the information on the screen. Leave the details in the notes for the
students to read later on. There are two main keys to hit on this page:
1. An easy implementation would be to have one lpp_source and one SPOT per
maintenance level (as shown in the solution).
2. Every time now that a client needs an update, you have other things to update as well:
the lpp_source, SPOT and the master.
Transition Statement — Now that we've seen what types of lpp_sources and SPOTs we
need, let's see how to work with these resources. Let's start out with the lpp_source
resource and see how to list its contents.
Instructor Guide
Listing Filesets in an LPP_SOURCE

smitty nim (or nim_list_media_sw)
List Software and Related Information
List Software on Media and Related Information
List Software on Installation Media
Choose your lpp_source
# nim -o showres lpp_source530
Fileset Name Level I/U Q Content

============================================================
Tivoli_Management_Agent.client.rte 3.7.1.0 I N usr,root

# Management Framework Endpoint Runtime"
bos.rte 5.3.0.10 S N usr

# Base Operating System Runtime
.....
bos.rte.devices 5.3.0.10 S b usr
# Base Device Drivers
bos.net.nfs.server 5.3.0.10 S Y usr

# Network File System Server
Figure 8-3. Listing Filesets in an LPP_SOURCE AU086.0
Notes:
You can either use the menu item shown or the corresponding command to look at filesets
and their levels that are found in your lpp_source. Be careful! If you use the command line,
you can not pipe this output to the more utility. Either narrow down your output using grep
or redirect it to a file and then view it.
For example, try:
# nim -o showres lpp_source530 | grep nfs
I/U Column - The I/U values are whether or not this is a base install fileset (I), versus a
single update fileset (S,SR or SF). Other values you might see here are M, which is a list of
all updates for this maintenance package, or ML which is a cumulative set of updates since
the last release. However, in many maintenance package updates you won't see the M or
ML listed.
Q Column - The Q (Quiescent) values indicate whether currently running programs are
affected while upgrading to this fileset. Installing a Y or B fileset affects currently running
programs. This field also indicates whether a bosboot is performed after the update is

V3.1.0.1
Instructor Guide
Uempty installed. Installing a B or b fileset causes a bosboot to occur. Plus, once the filesets are
installed, you need to perform a shutdown/reboot in order for those fileset changes to
totally take effect.
Content Column - The content values show what section of the AIX file system changes
by installing this fileset: /usr, /, or /usr/share (specified by usr, root, share). This is useful
information for diskless and dataless environments, but isn't as useful for stand-alone
environments as all information is typically kept local.
Refer to the installp command for more details.
Instructor Guide
Instructor Notes:
Purpose — To show how to quickly list information inside an lpp_source.
Details — lslpp - You could also use the nim -o lslpp lpp_source_name command.
However, this only shows you fileset names and not version levels or more specific
installation information. The nim -o showres lpp_name command is basically issuing the
installp -l -d /export/nim/lpp_source/lpp_name command under the covers.
If you do decide to show the nim -o lslpp command, then watch out for your attributes. The
developer that did this lslpp action did it a little bit differently than other nim actions. For
example, nim -o lslpp -a filesets=all lpp_source_name does not work but nim -o lslpp
-afilesets=all lpp_source_name does work.
Q Column - The quiescent column, if set to Y or B, should cause concern. If this fileset
update is applied while a lower-level version of this fileset is in use, it evidently could affect
the users. Fortunately, this rarely happens. The filesets that have this quiescent attribute
set appear to be TCP/IP, NFS, and NIS server code, NIS client code, atm code, and virtual
device code.
Other Listings - There are other listing options available on the smitty nim_list_media
menu, but they aren't as useful as the two options shown here.
Transition Statement — Now let's see how to list fixes available in an lpp_source.

V3.1.0.1
Instructor Guide
Uempty
LPP_SOURCE Management Techniques
Base Base Base Base
ML1 + ML1 ML1
ML2 ML1 ML2 ML2
+ + +
Fix1 Fix2 ML2 Fix1 Fix1

+ +
Fix1 Fix2 Fix2 Fix2
Optional Code
CAUTION: One lpp_source per operation

Figure 8-4. LPP_SOURCE Management Techniques AU086.0
Notes:
There are many techniques folks can use to manage their lpp_sources. Three key factors
affect which route you may decide to choose: space savings, flexibility and the ability to do
a quick install. The scenarios shown on the screen, though only a subset of possibilities
one can choose, represents the major types of lpp_source techniques that one can use.
Scenario One - This scenario is the one we use in class. It probably takes up the most
space on disk but is easier to do installs with. It adds all maintenance level updates to the
base code. It then uses separate fix lpp_sources to handle individual client needs on top of
the base lpp_source. In this scenario, one would probably have an lpp_source for each
maintenance level they plan to maintain. This could take up a little bit more space than
scenario two, though the lppmgr cleanup operation gets rid of any unnecessary
superseding updates. Since only one lpp_source may be used per operation this means
that at most only two operations are required to update any client.
Scenario Two - In this scenario, one desires to save on disk space and to have a clean,
segmented environment. Rather than creating a separate base lpp_source for each
maintenance level, the code is separated out into individual units. In this way, one might
Instructor Guide
save a little bit of disk space but has to perform at least three updates for each client to get
them up to the right level.
Scenario Three - This scenario keeps the actual code separated out into a directory
different from the lpp_source. When constructing the lpp_source, use hard links from any
original code into the desired lpp_source directory. This technique is similar to scenario
number one in that it allows you to install a client at ML2 in one step. In fact, you could
easily create another lpp_source at ML1 or the base level by just hard linking in the original
filesets desired. So why go through all the extra effort? Why not use scenario number one?
Well, it helps to save on disk space if several lpp_sources at several maintenance levels
are needed. Remember, the code is only physically stored once (shown on the left). When
constructing any desired lpp_source one merely hard links in the original code as desired.
Then, run lppmgr to clean up any extraneous links to superseded code.
Caution - Notice that we never put fixes into the base lpp_source. You can do this, but you
do it at your own risk. On rare occasions, developers put base-level (capital "i") filesets
versus single update (U) filesets into a fix. This causes a conflict with the true base-level
filesets and causes problems during the install. (Note: Supposedly this does not happen
during maintenance level updates as the development crew makes sure all filesets in the
ML update are single update filessets (U).)
Optional - You can choose to separate out your optional code (DB2, Tivoli, sysback . . .)
into a separate lpp_source. Some folks do this to create a nice clean environment. Each
optional lpp_source might represent different media. However, this means you can't install
the base and optional code in one step.

V3.1.0.1
Instructor Guide

Purpose — To show the students what techniques they can use to maintain their
lpp_sources.
Details — Watch out! This is a hot topic. And, the reason is because folks have had
problems with it. Plus, folks seem to be getting different advice from different areas of IBM.
Probably the biggest thing to stress is that they can choose one of many techniques. Also
stress that it's probably not a good idea to put fixes into their base code as it can cause
install problems. Finally, you may want to briefly mention the simages attribute and how it is
only placed on lpp_sources that can handle a base install.
Folks can have as many fix lpp_sources as they want. Each fix lpp_source would probably
reflect fixes above and beyond the latest maintenance level that a particular client or clients
have installed. Note that none of the fix lpp_sources would have the simages attribute.
Additional Information — After talking to the NIM development team, they said that ML
levels added into the base should work fine. They implied that any of the techniques shown
on the screen are valid techniques to use. However, if we want to be 100% safe, we might
consider getting a refresh CD for each ML level versus using ML update CDs or ML
updates from the Web. This refresh CD very safely combines base-level code with the ML
level requested.
As shown in the notes, fixes added into the base are less desirable than adding in ML
updates. It is possible that lppmgr could clear up any fix update problems for any fixes that
were added into a base lpp_source, but the NIM development team won't 100% guarantee
it. They typically recommend separating fixes out into another lpp_source.
The NIM development team said that anytime one adds any updates to a base lpp_source
that the installp command could potentially get confused. They highly recommended doing
an inutoc on the lpp_source whenever anything is added in. (Note: this is automatically
done when NIM update commands (or gencopy) is run.) However, even with inutoc run,
they seem to imply the installp command can still potentially get confused.
Transition Statement — Let's now take a look at the SPOT and how you might manage it.
Instructor Guide
SPOT Management Techniques

SPOT = Release level of clients/images it maintains
SPOT >= Fix level of clients/images it maintains
Input:
LPP_SOURCE530
LPP_SOURCE53ML1
LPP_SOURCE53ML1_Fixes1
LPP_SOURCE5ML1_Fixes2
Output:
SPOT530 OR SPOT53ML1+Fixes1+Fixes2
SPOT53ML1
SPOT53ML1+Fixes1
SPOT53ML1+Fixes2
Figure 8-5. SPOT Management Techniques AU086.0
Notes:
SPOT Levels - Make sure you maintain your SPOT at the highest fix level within the given
release for any clients or images it plans to support. You can choose to have several
SPOTs per release as shown on the left, but only the SPOT at the latest fix level should be
needed to serve the clients and images at that release level.
Sometimes folks may choose to have a base lpp_source and SPOT for every maintenance
level. Then, they update the SPOT within that maintenance level to handle all the
clients/images within that maintenance level.

V3.1.0.1
Instructor Guide

Purpose — To show what types of SPOTs need to be maintained in order to handle the
lpp_sources shown.
Details — What is shown is what's needed for a given release. If a customer also had more
lpp_sources at 5.2, then you'd need at least one spot for that release as well.
Again, this is a hot topic as folks have had mksysb restores and stand-alone maintenance
boot operations fail because they had a SPOT at a lower level than what was needed.
There for awhile the advice given was to keep the SPOT at the exact same level as the
mksysb. However, this advice is probably too stringent. You should be able to use a SPOT
at the given mksysb fix level OR higher. This author has personally restored a mksysb
using a spot that was two maintenance levels higher and there were no problems. I've also
had students and development confirm that this is an OK strategy. If in doubt, you can
always test out your SPOT by using it to put your client in standalone maintenance mode
(see the appendix article on this). If you can successfully get in you've tested the SPOT out
pretty thoroughly. Or, if all else fails, you can now create a SPOT from your mksysb
backup. Refer to NIM online documentation for details.
Additional Information — NIM developers have agreed with my above deductions on
what level a SPOT has to be. Again, it must be at the same release level and at or above
the same fix level as clients it supports.
Transition Statement — Before we begin showing you the screens you need to create
and update the proposed lpp_sources and spots, let's first double check code
dependencies. This may affect our maintenance strategy.
Instructor Guide
Listing Fixes in an LPP_SOURCE

smitty nim (or nim_list_media_fixes)
List Software on Media and Related Information
List Software Fixes (APARs) on Installation Media
Choose the lpp_source
# nim -o showres -a instfix_flags='-T' lpp_source530
IY58690 Cleanup for interrupts not done in shrinkps

IY58692 locale cannot handle QUOTATION MARK in currency symbol
IY58872 Incorrect fuser usage message
....
IY63302 Fixdata for 5300-01 Recommended Maintenance package
Figure 8-6. Listing Fixes in an LPP_SOURCE AU086.0
Notes:
Be careful!! The maintenance package line only shows up if you've used an update CD
versus pulling down code from the IBM Web site.
Also be careful when using the showres action with the more or pg utilities. Use the q key to
quit. If you accidentally use the <ctrl-c> to quit, you are forced to issue the stty sane
command to reset the keyboard back to normal format.
Sometimes it's handy to use the showres action with the grep utility. For example, try:
# nim -o showres -a instfix_flags='-T' lpp_source530 | grep IY58690
Another handy instfix_flag might be -s <keyword>. This searches the media for fixes with
the associated keyword.

V3.1.0.1
Instructor Guide

Purpose — To show how to quickly list APARs available in an lpp_source that you desire
to install on your SPOT or client.
Details — Notice the 5300-01 Recommended Maintenance package text that comes up if
you have that particular maintenance level available in the lpp_source. This is useful for
easily identifying the level of the lpp_source. However, if you download your code from the
Web you may not get this 5300-01 Recommended Maintenance package line. Instead, it
appears that the fileset fix numbers appear to be closely following the ML levels. For
example, many of the base filesets for ML level 1 appear to be at 5.3.0.10 maintenance
level. Those at ML level 2 appear to be at 5.3.0.20 maintenance level. I'm not sure if this
trend continues.
By the way, your oslevel -r command appears to reflect this 5300-01 Recommended
Maintenance Package line if the whole maintenance level is applied at the client.
Transition Statement — Now let's see how to create a new LPP_SOURCE.
Instructor Guide
Creating a New LPP_SOURCE

smitty nim (or nim_mkres)
Manage Resources
Define A Resource
Choose an LPP_SOURCE Type
Define a Resource
* Resource Name [lpp_source530]

* Resource Type lpp_source
* Server of Resource [master
or
nimclient] +
* Location of Resource [/export/nim/lpp_source/lpp_source530]
Source of Install Images [cd0] +
Names of Option Packages []
Comments []
New LPP_SOURCE New Optional/Fix

New LPP_SOURCE: from old LPP_SOURCE: LPP_SOURCE:
(for new releases) (for new ML levels) (for optional/fix code)
Source – cd0 Source – old lpp_source Source – cd0 or

(AIX install CD #1) top directory /stagedir
Names - let default Names - all Names - all

Figure 8-7. Creating a New LPP_SOURCE AU086.0
Notes:
New lpp_source - The entries used depend on what you're trying to accomplish. The first
scenario used is when you need to create a new lpp_source at a new release level.
New lpp_source from old lpp_source - The second scenario is quite often used when
upgrading ML levels. The first step in this scenario is to copy over your existing lpp_source.
Then, as we see later, we use the update command to put the new ML code into this new
lpp_source.
Optional/Fix lpp_source - The last scenario is used when you choose to put optional or fix
code into a non-base (non-simages) lpp_source. Don't use the default value for the Names
of Option Packages field. If so, then NIM gives you an error. That's because it expects you
to install all the code necessary to create a simages lpp_source and you may not have (or
want) all of that simages code. If, instead, you say all, then it presumes you know what
you're doing and it won't syntax check your code to make sure it satisfies simages criteria.
Your source code could come from an LPP product CD (probably in the case of optional
code) or from the Web (probably in the case of fix code). Notice how we mention that your
source field can either be cd0 or /stagedir to accommodate.

V3.1.0.1
Instructor Guide
Uempty SIMAGES CODE:

The code to satisfy the simages criteria in a 5.3 lpp_source is:
REQUIRED_SIMAGES="
${REQUIRED_COMMON_PPC} \
bos.mp \
devices.common.all \
bos.64bit"
REQUIRED_COMMON_PPC="\
bos \
bos.net \
bos.diag \
bos.sysmgt \
bos.terminfo \
bos.terminfo.all.data \
devices.graphics.all \
devices.scsi.all \
devices.tty.all \
xlC.rte"
DEFAULT LPP_SOURCE CODE:
The code that NIM will put into a base lpp_source (by using the default on the "names of
option packages" field), for 5.3 is the following:
SIMAGES_OPTIONS="\
bos.64bit \
bos \
bos.acct \
bos.adt \
bos.alt_disk_install \
bos.cdmount \
bos.diag \
bos.help.msg.en_US \
bos.iconv \
bos.loc.iso \
bos.mh \
bos.mp \
bos.mp64 \
bos.msg.en_US \
bos.net \
bos.perf \
bos.pmapi \
bos.suma \
bos.sysmgt \
Instructor Guide
bos.terminfo.all \
bos.txt \
csm.client \
csm.core \
csm.diagnostics \
csm.dsh \
csm.msg.en_US \
csm.msg.EN_US \
devices.all \
ifor_ls.base \
infocenter.aix.EN_US.commands \
invscout.com \
invscout.ldb \
invscout.rte \
perfagent.tools \
perl.libext \
perl.rte \
printers.rte \
rpm.rte \
rsct.core \
rsct.msg.en_US \
rsct.msg.EN_US \
Tivoli_Management_Agent.client \
xlC.aix50 \
xlC.cpp \
xlC.rte \
xlC.msg.en_US.cpp \
_SPOT._.pre_i.usr.1.0.0.0 \
_SPOT._.post_i.usr.1.0.0.0"
For more information, refer to the /usr/lpp/bos.sysmgt/nim/methods/c_sh_lib shell script.
This shell script lists the required and optional filesets needed for an lpp_source and a
SPOT at each release level.
Server field - Finally, notice the server field. If it's set to master, then your lpp_source ends
up at the master site. If, instead, you set it to a NIM client name, then this resource ends up
at the NIM client site.
Command Line - The command line to represent the above screen is:
nim -o define -t lpp_source \
-a source=cd0 \
-a server=master \
-a location=/export/nim/lpp_source/lpp_source530 lpp_source530
Note: By default the smit screen shown does not process all AIX install CDs. It, instead,
only processes most of the first AIX install CD. Or, if you set the names of option packages

V3.1.0.1
Instructor Guide
Uempty field to all, you would get all of the FIRST CD only. You can only download all AIX install
CDs by either using this smit screen along with the smit update screen (shown next), or by
defining your lpp_source from the command line with the -a packages=all and -a
multi_volume=yes attributes set.
Instructor Guide
Instructor Notes:
Purpose — To show the different techniques used to create lpp_sources.
Details — Key Points - Concentrate on the two fields shown: Names of Packages and
Source. Notice how changing these fields can adjust what type of an lpp_source you
create. By the way, you can also specify the actual names of packages you want to put into
your lpp_source by listing them one by one using spaces to separate the names of the
packages.
.toc file - NIM does a pretty nice job when creating lpp_sources and updating them. It
keeps the .toc file up to date. You can also do this manually by either running the running
the inutoc .command inside the <lpp_source>/installp/ppc directory or performing a nim -o
check <lpp_source> command.
Renaming lpp_sources - Some students want to rename a current lpp_source name to a
new maintenance level name. You can't do this. Instead, you have to create a new
lpp_source that has the new name you desire by using the old lpp_source as the source.
Then, add the maintenance level updates into this new lpp_source using the update utility.
Finally, get rid of the old lpp_source. Another alternative is to nim -o remove the old
lpp_source but don't physically remove the data. Then, create a new one, with a new name
pointing to this old data. Then, add in your ML updates.
Old lpp_source as source - When using an old lpp_source as your source, just use the
old lpp_source name or refer to it by using the top-level directory (that is,
/export/nim/lpp_source/lpp_source530).
Fileset listings - All the filesets shown in the student notes that are placed into an
lpp_source were filesets listed in the /usr/lpp/bos.sysmgt/nim/methods/c_sh_lib shell script.
Inside this script, you find what code is required for an lpp_source to gain the simages
attribute setting. You also find what code you get in an lpp_source if you let the names of
option packages field default. This script details this information not only for the 5.3 release,
but also for all releases. The 'REQUIRED_SIMAGES' variable contains what's required for
an lpp_source to gain the simages attribute. The 'OPTIONS_SIMAGES' variable contains
what is actually placed into an lpp_source if you let the names of packages field default.
Notice that NIM, by default, actually gives you more filesets in your lpp_source than are
required to turn the simages (support images) attribute on.
If you look into the c_sh_lib script, you also notice what filesets are needed to support a
spot. By looking at these lists, you can see that some of the non-simages software in the
lpp_source is needed to generate a spot. Hence, make sure you generate your lpp_source
by using the default or all value on the names of option packages field. This guarantees
you have enough code to generate a corresponding spot.
Getting more code into your lpp_source - Notice that the information put into a default
lpp_source is just about everything on AIX install CD #1. By default, NIM does NOT install
all eight AIX install CDs into your lpp_source. In fact, as just stated, it doesn't even load
everything from the first CD into your lpp_source.

V3.1.0.1
Instructor Guide
Uempty There are two techniques you could use to ensure you have all eight CDs loaded into your
lpp_source.
First, you could use the above screen using the default value for names of option
packages. Then, you'd have to update it with the NIM update utility (shown on the next
screen) by specifying all for Software Packages to Add and yes for Process Multiple
Volumes. The other technique involves using the command line. Issue the nim -o define -t
lpp_source command and make sure the -a packages=all and -a multi_volume=yes
attributes are set.
Optional/Fix lpp_sources - When creating an lpp_source and you don't want to include all
the simages code like bos, bos.rte and so forth, then don't let the Names of Option
Packages field default. Instead, either say all or list the filesets individually that you plan to
include. Be careful, though! If you're using a source that has the bos package in it, and you
don't plan on installing bos, you could run into problems. Refer to the c_mk_lpp_source
shell script for details.
Transition Statement — Sometimes it's handy to add in extra code or fixes into a
pre-existing lpp_source.
Instructor Guide
Updating an LPP_SOURCE
Original lpp_source --- subset of AIX install CD #1 only!
smitty nim (or nim_update_add)

Perform NIM Software Installation and Maintenance
Software Maintenance and Utilities
Add Software to an LPP_SOURCE
Choose your lpp_source
Select Software Source
Add Software to an lpp_source
TARGET lpp_source lpp_source530

SOURCE of Software to Add cd0
or
/export/nim/lpp_source/stagedir
SOFTWARE Packages to Add [all] +
-OR-
INSTALLP BUNDLE containing packages to add [] +
gencopy Flags
DIRECTORY for temporary storage during copying [/tmp]
EXTEND filesystems if space needed? yes +
Process multiple volumes? yes +
Figure 8-8. Updating an LPP_SOURCE AU086.0
Notes:
You can add extra code and ML updates to an lpp_source using this technique. Use the
corresponding Remove screen to remove code and fixes from this lpp_source.
Be careful! Your originally defined base lpp_source will only contain a subset of your AIX
install CD #1.
To add in the rest of the code on those AIX CDs, you have to process them by choosing to
process multiple volumes and then mounting them one at a time. Quite often a lot of
material after the first two CDs is just international language support. Hence, you can either
choose to add in just the first two CDs or you could add in all CDs, and then use the lppmgr
technique shown later to automatically remove just the international language support for
all languages other than your own.
If updating it with a new ML level, first unzip and untar your ML update into a stage
directory. Then use this stage directory as the SOURCE of Software to Add. The update
utility automatically changes all of the UXXXXX fix filenames in this stage directory to their
appropriate bos.rte and so forth filenames inside the lpp_source.

V3.1.0.1
Instructor Guide
Uempty Typically you'll choose all for Software packages to Add. This adds in all software from
that source. Alternatively, you can list just the software fileset names you want to add in.
The default is not to process multiple volumes. You need to change this if you plan to
process multiple CDs.
Command Line - The command line to accomplish the above is:
nim -o update -a source=cd0 \
-a packages=all \
-a gencopy_flags=X lpp_source530
The command line to accomplish a remove of the Java14.sdk fileset is:
nim -o update -a rm_images=yes \
-a packages="Java14.sdk" lpp_source530
Instructor Guide
Instructor Notes:
Purpose — To show how to add software and fixes to an lpp_source.
Details — If you ever need to manually mount a CD and process it that way, point the
update utility to the /cd_mnt_pt/usr/sys/inst.images directory.
Downloads for maintenance levels are downloaded as a tar.gz file. First unzip and untar
this archive into a stage directory. For example,
# mkdir /export/nim/lpp_source/stagedir
# cd /export/nim/lpp_source/stagedir
# gzip -c /tmp/530102.tar.gz | tar -xvf -
This labels all files inside according to their FIX ID (that is, U12345, and so forth). Use
/export/nim/lpp_source/stagedir as your source directory when using the update utility. NIM
automatically finds the information below and renames it to normal filesets as the
information is added into the lpp_source.
There is a corresponding screen to remove software and fixes from an lpp_source as
follows:
___________________________________________________________________________
Remove Software from an lpp_source

SOFTWARE Packages to remove [] +
-OR-
INSTALLP BUNDLE containing packages to remove [] +
___________________________________________________________________________
Transition Statement — Let's see what upfront activity needs to happen to put fixes or
maintenance level updates into your lpp_source.

V3.1.0.1
Instructor Guide
Uempty
Adding Fixes to an LPP_SOURCE
IBM Web site or SUMA
Fixes Maintenance Levels
/export/lpp_source/MLdir
unzip and untar
/export/lpp_source/stagedir /export/lpp_source/stagedir
Create new LPP_SOURCE Use Create or Update
Figure 8-9. Adding Fixes to an LPP_SOURCE AU086.0
Notes:
When retrieving selected fixes or maintenance level updates from either IBM's Web site or
by using the SUMA facility, you can download the selected fixes to a staging directory.
Then, use this staging directory as source to your desired NIM operation. For fix updates
you probably always generate a new lpp_source via the smitty nim_mkres panel. For
maintenance level updates you can either update your existing lpp_source or you can
create a separate lpp_source with just the ML update in it. Use the smitty nim_mkres or
smitty nim_update_add panel respectively to handle these operations.
Procedure to get a selected fix using IBM's Web site
At IBM's Fix Central Site (use the Fix Central link from your infocenter Web site).
1. Choose pseries, AIX, and 5.3
2. Choose Selected Fixes
3. Select APAR and IY26392 - add to download list
4. Choose your current ML level
Instructor Guide
5. Please choose the appropriate maintenance level that matches your highest
lpp_source's maintenance level. In this way, you only get the fixes that are beyond that
maintenance level. (Note: if you want to get fancy, you could run the following
command to generate our version of the lslpp -Lc file to reflect the level of code in our
highest maintenance level's lpp_source):
geninstall -L -d /export/nim/lpp_source/lpp_source530 > /tmp/geninstall.out
6. Download to /export/lpp_source/stagedir
(This assumes that the stagedir directory exists)
Procedure to get fixes using smit suma
1. Create a Task on the Custom/Automated Downloads Screen
Action: Download
Directory for Item Storage: /export/nim/lpp_source/stagedir
(presumes directory already exists)
Repository to Filter Against: /export/nim/lpp_source/lpp_source530
Type of item to request: APAR
Name of Item to request: IY26392
Processing ML updates - When retrieving maintenance level updates, download it to a
temporary directory. Then, unzip and untar it into your staging directory. Use this staging
directory as source for your NIM update operation on your lpp_source. See below for
details:
mkdir /export/nim/lpp_source/MLdir
Download to /export/nim/lpp_source/MLdir
cd /export/nim/lpp_source/stagedir
gunzip -c /export/nim/lpp_source/MLdir/530102.tar.gz | tar -xvf -

V3.1.0.1
Instructor Guide

Purpose — To show the extra steps required to get your fixes and maintenance levels into
a staging directory in order to do the update to your lpp_source.
Details — The stagedir shown is not the only stagedir you can use. It's merely set up as a
potential area to handle all temporary downloads. Students can choose any directory or set
of directories that they want to use for this procedure.
Whatever is not filtered at the Web site or via SUMA can always be cleaned up with lppmgr.
If students run into problems applying ML updates to their base they can always request a
refresh CD from the support center that has the base and ML update all on one CD as a
new base level of code.
Note: Remember, you only retrieve fixes and ML updates from the Web. Releases come
on CDs.
Transition Statement — Just in case you have too much code loaded into your
lpp_source, let's see how to clean it up.
Instructor Guide
Cleaning Up Your LPP_SOURCE

smitty nim (or nim_lppmgr)
Perform NIM Software Installation and Maintenance
Eliminate Unnecessary Software Images in an lpp_source
Choose the lpp_source
Eliminate Unnecessary Software Images in an lpp_source

PREVIEW only? no +
REMOVE DUPLICATE software yes +
REMOVE SUPERSEDED updates yes +
REMOVE LANGUAGE software yes +
PRESERVE language [en_US]
REMOVE NON-SIMAGES software no +
SAVE removed files no +
DIRECTORY for storing saved files []
EXTEND filesystems if space needed? yes +
Figure 8-10. Cleaning Up Your LPP_SOURCE AU086.0
Notes:
The lppmgr facility can be used to clean up an lpp_source that has superfluous filesets in it.
For example, you might have loaded all eight AIX install CDs into the lpp_source and yet
really don't want international language support other than your own language. Or, if
continuing to download ML updates into your lpp_source, you could have superseded fixes
that are no longer needed. Again, a cleanup would help to save some space.
If desired, you can choose to save off your cleaned up filesets by setting the SAVE
removed files field to yes.
Also, be sure to change the PREVIEW only? field to no.
Command Line - The equivalent of the above command is:
nim -o lppmgr -a lppmgr_flags="-ls -bu -x -k en_US -e -r" lpp_source530
The lppmgr_flags listed mean the following, respectively:
preview, remove dups, remove superseded updates, keep just the lang listed, extend FS,
do not save

V3.1.0.1
Instructor Guide

Purpose — To show how to clean up an lpp_source that has too many superfluous filesets
in it.
Details — See the notes for the details.
Transition Statement — Finally, let's see how to remove an lpp_source.
Instructor Guide
Removing an LPP_SOURCE
smitty nim (or nim_rmres)
Manage Resources
Remove a Resource
Choose an LPP_SOURCE
Remove a Resource
* Resource Name lpp_source530

Resource Type lpp_source
Comments
Figure 8-11. Removing an LPP_SOURCE AU086.0
Notes:
This removes the NIM database entry and the actual data.
nim -o remove lpp_source530
Make sure the lpp_source is not in use at the time or this operation fails.

V3.1.0.1
Instructor Guide

Purpose — To show the steps necessary to remove an lpp_source.
Details — This might be helpful for older release and maintenance levels you no longer
plan to support.
Transition Statement — Let's now turn our attention to some SPOT management.
Instructor Guide
Listing Filesets in a SPOT

smitty nim (or nim_list_installed_sw)
List Installed Software and Related Information
List Installed Software
Select the SPOT
(nim -o lslpp -alslpp_flags=’-La’ spot530)
* Target spot530
* Software Names [all] +
Show SUPERSEDED levels? [yes] +
Fileset Level State Type Description (Uninstaller)
bos.64bit 5.3.0.10 C F Base Operating System 64 bit Runtime

bos.rte.install 5.3.0.10 C F LPP Install Commands
5.3.0.11 C F LPP Install Commands
bos.diag.com 5.3.0.10 C F Common Hardware Diagnostics
bos.diag.rte 5.3.0.10 C F Hardware Diagnostics
bos.diag.util 5.3.0.10 C F Hardware Diagnostic Utilities
....
Figure 8-12. Listing Filesets in a SPOT AU086.0
Notes:
In the case of listing information inside a spot, it is presumed you want to list it all, including
superseded fix levels. Notice how similar this output is to a normal lslpp listing.
Command Line - The counterpart command line is partially listed on the screen. The full
command line is:
nim -o lslpp [-afilesets=all] [-alslpp_flags="-La" ] spot530
The L flag shows a listing of all applied and committed filesets. The a lslpp_flag shows
superseded levels. The default lslpp_flags used in smit are -La. The default from the
command line is -la.
Make sure, if using the command line, that you don't include a space between the -a
attribute and its associated value.

V3.1.0.1
Instructor Guide

Purpose — To show how you can easily view what's installed inside a spot.
Details —
Transition Statement — Now let's see how to find out what fixes are installed in a spot.
Instructor Guide
Listing Fixes in a SPOT

smitty nim (or nim_show_apar_stat)
Show Fix (APAR) Installation Status
Select the SPOT

(nim -o fix_query spot530)
* Target spot530
* Fix ID [] +
All filesets for IY58143 were found.

No filesets which have fixes for IY63301 are installed.
...
All filesets for 5.3.0.0_AIX_ML were found.
Not all filesets for 5300-01_AIX_ML were found.
Figure 8-13. Listing Fixes in a SPOT AU086.0
Notes:
This output is just like normal instfix -i output on a machine. You might want to issue this
task from the command line in order to get additional options to use. For example, you
might want to use the -v or -a fix_query_flag in order to get verbose output or abstract text
respectively.
Command Line - The actual command line is:
nim -o fix_query [-a fixes= . . .] [-a fix_query_flags= . . .] spot530
There are many other listings you can perform from smit that aren't shown here in this
course. Please see smitty nim_list_installed for details. Note that they reflect the typical
listings you would see in smit at any AIX client. However, in our case, we're listing
information about code installed in a spot and not what's installed at a client.

V3.1.0.1
Instructor Guide

Purpose — To show how to quickly list the fixes that are installed on a SPOT.
Details — Notice how to quickly identify maintenance levels as well. This spot happened to
have almost all of the filesets loaded for 530ML1, but was missing just a couple of updates.
Unlike the lpp_source listing, this listing shows you the appropriate maintenance level
regardless of whether the code was loaded down from a CD or the Web.
Transition Statement — Alright, let's now see how to create a new SPOT.
Instructor Guide
Creating a New SPOT

smitty nim
Manage Resources
Define a Resource
SPOT
Define a Resource
* Resource Name [spot530]

* Resource Type spot
* Server of Resource [master or nimclient] +
* Location of Resource [/export/nim/spot or /usr] /
Source of Install Images [lpp_source530 or SPOT_name] +/
Expand Filesystems if needed? Yes +
Comments []
Installp Flags
COMMIT software updates? Yes +
SAVE replaced files? No +
AUTO install requisite software? Yes +
OVERWRITE same or newer versions? No +
VERIFY install & ck file sizes? No +
Figure 8-14. Creating a New SPOT AU086.0
Notes:
Server of Resource - The Server of Resource field will determine what machine this
resource is placed on.
Location of Resource - The Location of Resource field determines if it is a /usr spot or
not. /usr spots may save you about 100 MB of space for your initial spot, but there are
constraints in using them.
SOURCE of Install Images - The SOURCE of Install Images field is typically either an
lpp_source or a pre-existing SPOT. Pre-existing SPOTs are only typically used when you
want to distribute a SPOT and copy a pre-existing SPOT as your source.
SPOT CODE:
The code installed in a spot for AIX 5.3 is:
DEFAULT_SPOT_OPTIONS="\
${DEFAULT_SPOT_COMMON_PPC} \
bos.mp \
bos.mp64 \

V3.1.0.1
Instructor Guide
Uempty bos.64bit"
DEFAULT_SPOT_COMMON_PPC="\
bos.sysmgt.nim.client \
bos.sysmgt.nim.spot \
bos.net.nfs.client \
bos.net.tcp.client \
bos.net.tcp.smit \
bos.diag \
bos.sysmgt.sysbr \
bos.sysmgt.smit \
bos.terminfo \
devices.all"
Command Line - The equivalent nim command to create the spot shown above is:
nim -o define -t spot -a server=master -a location=/export/nim/spot \
-a source=lpp_source530 -a installp_flags='-XacNg' spot530
Instructor Guide
Instructor Notes:
Purpose — Show how to set up a new SPOT.
Details — /usr SPOTS - Creating a /usr SPOT means that you use the existing /usr file
tree to locate your SPOT. This means you can use pre-existing /usr code and thus save
about 100 MB of space when creating this spot.
However, if you decide to create a /usr spot, you will have caused yourself some potential
problems. First of all, your SPOT must match the release and fix level of the machine it's
on. Next, for every update of your machine, your lpp_source and spot must match these
exact updates. In addition, it can become confusing to have all your other spots under the
/export/nim directory tree and to have just one spot under /usr.
Finally, if you plan to recover your NIM data on another machine, then the /usr SPOT is not
in the nimvg volume group and can't be as easily exported with the rest of your nim data.
This author has personally decided not to recommend /usr SPOTs anymore except for
those rare occasions where disk space is extremely tight.
SPOT Contents - By the way, NIM spots consist not only of the data in the spot directory
(that is, /export/nim/spot/spot530), but also the /tftpboot boot images that were constructed
from the code in this spot.
Notice the code installed in a spot. This information was retrieved by looking at the
/usr/lpp/bos.sysmgt/nim/methods/c_sh_lib shell script. Resort to this shell script for what
code might be installed in a spot for a non-5.3 release.
Location of Resource - Notice that the Location of Resource field value you use to define
a SPOT is one directory level higher than the Location of Resource field value to create an
lpp_source. For example, an lpp_source's location field value might be
/export/nim/lpp_source/lpp_source530 whereas a SPOT location field value will be
/export/nim/spot. The SPOT creation process automatically uses the Resource Name field
value (that is, spot530) as an extension to your location field and really places the spot's
contents in the /export/nim/spot/spot530 directory.
Transition Statement — Now let's see how to update a SPOT.

V3.1.0.1
Instructor Guide
Uempty
Updating SPOT Procedures
smitty nim
Perform Software Installation and Maintenance Tasks

Install Software
Update Installed Software to Latest Level (Update All)
Install Software Bundle
Update Software by Fix (APAR)
Install and Update from all Available Software

Commit Applied Software Updates (Remove Saved Files)
Reject Applied Software Updates (Use Previous Version)
Remove Installed Software
Figure 8-15. Updating SPOT Procedures AU086.0
Notes:
Notice how similar the screens are in NIM for updating a SPOT as they are for updating
normal AIX clients. The key difference is that you update your SPOT from an lpp_source
and have an option to run a post customization script when done.
Instructor Guide
Instructor Notes:
Purpose — To show the major options on the submenus shown that deal with SPOT
maintenance.
Details — We do not discuss all of these items in detail. Their operations are pretty
straightforward. We concentrare only on an operation that is probably used the most: an
update_all operation.
The Update Software by Fix menu item can be used to install individual APAR fixes or
fix_bundles (a file with IY..... APAR numbers in it versus fileset names in it).
Note: As of July 2005 there is a known bug in the Update Software by Fix smit screen. It
does not install prerequisite code well. This problem has just been identified and will be
fixed in the 5200-07 and 5300-03 maintenance levels.
Transition Statement — Let's now take a look at the most common operation you'll
perform - an update all.

V3.1.0.1
Instructor Guide
Uempty
Performing an Update All on Your SPOT
* Installation Target spot530

* LPP_SOURCE lpp_source530
Software to Install update_all

(not applicable to SPOTs)
Force no +
installp Flags
PREVIEW only? [no] +
COMMIT software updates? [no] +
SAVE replaced files? [yes] +
AUTOMATICALLY install requisite software? [yes] +
EXTEND filesystems if space needed? [yes] +
OVERWRITE same or newer versions? [no] +
VERIFY install and check file sizes? [yes] +
(AIX V5 and higher machines and resources)
Preview new LICENSE agreements? [no] +
....
Figure 8-16. Performing an Update All on Your SPOT AU086.0
Notes:
This screen allows you to do an update_all operation on your SPOT. Notice the two most
important options: whether or not to apply or commit your fix updates to this SPOT and
whether or not to save the prior version. The default is to apply the update. This works just
like it does in straight AIX. Verifying fileset installation is typically recommended as a good
extra precaution any time software is added to a spot or client.
When this operation completes, it automatically updates any boot images in the /tftpboot
directory. This is done by performing a NIM check on this spot.
Command Line - The equivalent command for the above procedure is:
nim -o cust -a lpp_source=lpp_source530 -a fixes="update_all" \
-a installp_flags='-agX' spot530
Instructor Guide
Instructor Notes:
Purpose — To show how to do an update all procedure on a SPOT.
Details — This procedure is used a lot. Every time you download maintenance level
updates or fixes into existing or new lpp_sources you'll have to also update your SPOT
using those lpp_sources. Make sure your SPOT is always at a high enough level to handle
any client in your network. That means that you may have to apply the base+ML
lpp_source and all fix lpp_sources at that ML level to your SPOT if using the strategy we're
presenting here in class.
The SPOT only contains a subset of what's normally stored in an lpp_source. It contains
only core base operating system types of filesets. Hence, if you're updating your
lpp_source with a miscellaneous fileset you won't have to update your SPOT. It never
hurts, though, to do an update all on a SPOT anytime you update your base lpp_source or
create a new fix lpp_source.
Transition Statement — Alright, now let's remove a SPOT.

V3.1.0.1
Instructor Guide
Uempty
Removing a SPOT
smitty nim (or nim_rmres)
Manage Resources
Remove a Resource
Choose your SPOT
Remove a Resource
* Resource Name spot530

Resource Type spot
Comments []
Figure 8-17. Removing a SPOT AU086.0
Notes:
This gets rid of the spot, its directory structure, and the corresponding boot images in the
/tftpboot directory.
Command Line - The equivalent command line approach to the above screen is:
nim -o remove spot530
Make sure this spot is not in use or this operation fails.
This operation takes a couple of minutes to complete.
Instructor Guide
Instructor Notes:
Purpose — To show how to get rid of a SPOT that's no longer needed by any of your
clients.
Details — See the student notes.
Transition Statement — Let's now view one last operation that may come in handy in
maintaining your spots and lpp_sources - the check operation.

V3.1.0.1
Instructor Guide
Uempty
Checking a Resource
nim -o check lpp_source530 nim -o check spot530
.toc updated checks if required code is

accessible
simages attribute checked boot images re-made if spot

was updated
Figure 8-18. Checking a Resource AU086.0
Notes:
Checking a resource does a reasonable check to make sure the resource is ready to be
used.
This procedure differs depending on the resource checked.
This procedure runs automatically when you update your resource.
Instructor Guide
Instructor Notes:
Purpose — To quickly remind the student of another important operation that takes place
when you perform a nim command to create or update your resources.
Details — You can always run these checks manually as shown on the screen if you
suspect a resource may not be functioning properly.
The functions performed on the screen are the major functions the student would care
about. Other miscellaneous checks may also occur.
Transition Statement — OK, now let's put this all together to solve some real-world
problems.

V3.1.0.1
Instructor Guide
Uempty
Resource Case Study
Strategy: Use separate lpp_source and spot per ML level
Keep MLs in base lpp_source
Keep Fixes in separate lpp_sources
Keep SPOT at latest fix level within ML level
Clients LPP_SOURCES SPOTS

530 530 (Base) 530
530ML1 530ML1(Base) 530ML1+Fix1+Fix2
530ML1+Fix1 530ML1(Base) + Fix1 (Delta) 530ML1+Fix1+Fix2
530ML1+Fix2 530ML1(Base) + Fix2 (Delta) 530ML1+Fix1+Fix2
Needed resources: __________________________________________
How would you create these resources?
Figure 8-19. Resource Case Study AU086.0
Notes:
The first thing you need to do is to identify your clients and what level of code they're using.
Then, figure out a strategy to use to handle those clients. Use any of the strategies
mentioned at the beginning of this unit. Finally, make a detailed list of resources you need
to satisfy this set of clients. Then, come up with a plan to create those resources.
The needed resources are: lpp_source530, lpp_source530ML1, lpp_source_fix1,
lpp_source_fix2, spot530 and spot530ML1 (with both fixes).
You probably want to create the base 530 level resources first. Then, to reflect a
maintenance level update, create the 530ML1 lpp_source and use it to create your 530ML1
spot. Then, to reflect fix updates, create the fix lpp_source resources and use them to
update your 530ML1 spot.
Instructor Guide
Instructor Notes:
Purpose — To introduce a potential resource scenario and get the student interested in
how they might solve this problem.
Details — What's presented on the screen is just ONE potential scenario and strategy to
solve that scenario. Make sure the students understand that they have the flexibility to
implement different strategies. However, there isn't enough time in class to go over a detail
solution for each possible strategy. Solving one strategy, though, should be helpful to them.
And, this is the strategy that is used in lab.
When thinking of how to create those resources get them thinking in terms of real life
upgrades. Create your base line resources first. Then, create your ML1 resources. Then,
create your fix lpp_sources and update your SPOT. This technique helps to prepare them
for the coming screens.
Transition Statement — Let's see first how to create your baseline 530 resources.

V3.1.0.1
Instructor Guide
Uempty
Handling New Releases
AIX Install CDs LPP_SOURCE530 SPOT530
•Create a New LPP_SOURCE (lpp_source530)

– SOURCE - cd0 (New AIX install CD #1)
– Packages - let default
•Update LPP_SOURCE (lpp_source530)

– SOURCE - cd0 (multi_volume=yes)
– Packages - all
•Update Master (with lpp_source530)
•Create a new SPOT (spot530)

– SOURCE - lpp_source530
Figure 8-20. Handling New Releases AU086.0
Notes:
Putting on a new release means creating a new lpp_source and SPOT using the CDs IBM
gave you.
You can potentially put all the CDs into the lpp_source when you create it, but that requires
using the nim -o define -t lpp_source command with the -a packages=all and -a
multi_volume=yes attributes set.
Instead, we've chosen here to show you what procedures you need to do if you plan on
using smit. In smit, you'll create the lpp_source using the smit field values shown. This
gives you most of the filesets on AIX CD #1 in our lpp_source. Then, you use smit's nim
udpate utility to add the rest of the CD #1 and the other CDs into your lpp_source.
Once you have all your CD code in your lpp_source, then use it to update your master and
SPOT. (We talk more about how to update a machine in the next unit.)
Instructor Guide
Instructor Notes:
Purpose — To show on one page the steps necessary to create the lpp_source and SPOT
needed to handle a different release than the one you already have on your machine.
Details — Refer to the lpp_source and spot screens earlier in the lecture for more detail if
needed.
Transition Statement — Now let's see what steps are required to handle an ML update.

V3.1.0.1
Instructor Guide
Uempty
Handling New ML Updates
stagedir
LPP_SOURCE530 LPP_SOURCE530ML1 SPOT530ML1
•Create a New LPP_SOURCE (lpp_source530ML1)

– SOURCE - lpp_source530
– Packages - all
•Update New LPP_SOURCE
– SOURCE - /export/nim/lpp_source/stagedir (from downloaded code)
– Packages - all
•Clean up LPP_SOURCE (lpp_source530ML1)
•Update Master (with lpp_source530ML1)
•Create a New SPOT (spot530ML1)
– SOURCE - lpp_source530ML1
Figure 8-21. Handling New ML Updates AU086.0
Notes:
An ML update typically means creating another lpp_source and SPOT. When creating the
lpp_source, use your original lpp_source first as your source. Then use smit's NIM update
utility to update your new lpp_source using the code you've just downloaded from the Web.
(This presumes you've already unzipped and untarred it and placed it in the stagedir as
shown.)
Once the lpp_source is ready to go, then merely use that as your source to update your
master and create a new spot. (We discuss updating a machine in the next lecture.)
Instructor Guide
Instructor Notes:
Purpose — To show the steps required to create a new lpp_source and spot needed to
handle a new maintenance level.
Details — You don't have to use this exact procedure. However, it is a nice simple
procedure to follow.
Additional Information — Again - if your customer feels at all uneasy about adding
maintenance level code into a base lpp_source they could choose instead to get a refresh
CD from the IBM support center. This refresh CD would have IBM's base and ML code all
combined into one source safely. Then, they would use the same technique as the Release
technique shown on the last page to create an lpp_source and spot at the new
maintenance level.
Transition Statement — Finally, let's see how to handle new fix updates.

V3.1.0.1
Instructor Guide
Uempty
Handling New Fix Updates
stagedir
lpp_source_fix1 SPOT530ML1
•Create LPP_SOURCE (lpp_source_fix1)

– SOURCE - /export/nim/lpp_source/stagedir
– Packages- all
•Update Master (with lpp_source_fix1)
•Do an Update All on SPOT530ML1

– SOURCE - lpp_source_fix1
Figure 8-22. Handling New Fix Updates AU086.0
Notes:
Notice that we create our fix1 lpp_source and use that to update our SPOT. We'd obviously
repeat this procedure with the fix2 lpp_source.
Instructor Guide
Instructor Notes:
Purpose — To show the steps necessary to make a fix lpp_source and apply that to the
master and SPOT.
Details — Remember, you no longer want to just apply a fix to a client. You must now also
create an lpp_source with the fix and update both your master and client.
Transition Statement — Let's complete this unit now with our checkpoint exercise.

V3.1.0.1
Instructor Guide

1. T/F You can have a SPOT at 5.3 on a NIM master at 5.2
Correct Answer - False. The NIM master must be at least at the
same release level as the SPOTs located there.
2. T/F You can use a SPOT at 530Base to manage a client at
530ML1.
Correct Answer - False. Always make sure your SPOT is at the
same release level and at least at the same fix level as the clients it
serves.
3. T/F When creating a new lpp_source, leave the Names of Option
Packages field blank in order to create a base level lpp_source
(simages) that can handle a base install.
Correct Answer - True. Be sure to change it to ALL or list the
packages if you plan to create a non-simages lpp_source.
4. T/F You can use NIM's update utility to add or remove software
from an lpp_source.
Correct Answer - True.
5. T/F When creating a distributed SPOT, change the Server field
from master to point to an existing nim client. This nim client is
where you want the spot to be placed.
6. T/F The lpp_source is the typical resource used to create and
update a spot.
7. What NIM utility can be used to make sure your spot is in a
good/known state? ________________
Correct Answer - check
Instructor Guide
Unit Summary
•Identify SPOT and lpp_source level issues
•Create and maintain lpp_sources
•Create and maintain SPOTs
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide

V3.1.0.1
Instructor Guide
Uempty Unit 9. Ongoing Client Updates

This unit shows the students how to add software to the client, update
the client, and perform an alternate disk install.

• Add software to the client
• Upgrade the client
• Perform an alternate disk install

Accountability:
• Lab exercise
References
following:
NIM from A to Z in AIX 4.3 (Redbook)
AIX Version 4.3 to 5L Migration Guide (Redbook)
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-1
Instructor Guide
Unit Objectives
•Add software to the client
•Upgrade the client
•Perform an alternate disk install
Notes:

V3.1.0.1
Instructor Guide

Purpose —
Details —
Instructor Guide
Listing Filesets at Your Client

smitty nim (or nim_list_installed_sw)
Select the Client

(nim -o lslpp -alslpp_flags=”-La” lpar1)
* Target lpar1
* Software Names [all] +
Show SUPERSEDED levels? [yes] +
Fileset Level State Type Description (Uninstaller)

Tivoli_Management_Agent_Client.rte
3.7.1.0 C F Management Framework Endpoint Runtime
bos.rte.install 5.3.0.10 C F LPP Install Commands
5.3.0.11 C F LPP Install Commands
bos.64bit 5.3.0.10 C F Base Operating System 64 bit Runtime
bos.acct 5.3.0.10 C F Accounting Services
bos.adt.base 5.3.0.10 C F Base Application Development Toolkit
bos.adt.include 5.3.0.10 C F Base Application Development
Include Files
.... © Copyright IBM Corporation 2005
Figure 9-2. Listing Filesets at Your Client AU086.0
Notes:
In the case of listing information at a client, it is presumed you want to list it all, including
superseded fix levels. Notice how similar this output is to a normal lslpp listing at the
standalone client site. By the way, the smit menu gives the information to using the -La
lslpp_flags by default where as the nim command gives information to you using the -la
lslpp_flag format by default.
Command Line - The counterpart command line is partially listed on the screen. The full
command line is:
nim -o lslpp [-afilesets=all] [-alslpp_flags=-La] lpar1
The L lslpp_flag shows a listing of all filesets. The a lslpp_flag shows superseded levels.
The default lslpp_flags used appears to be: -la. Remember, -l gives the report in three
phases: /usr/lib/objrepos, /etc/objrepos and /usr/share/lib/objrepos where -L combines all
filesets. Both the -l and -L show your committed and applied filesets, but only when
combined with the -a lslpp_flag do they show superseded updates.

V3.1.0.1
Instructor Guide

Purpose — To show how you can easily view what's installed at a client from the master
site.
Details — Notice that this is the same screen we saw when listing filesets in a spot. The
key difference is that you have more filesets installed at a client than in your spot.
Watch out for differences on the command line. The developer that did this code did not
follow the same pattern as the other developers. The attributes must immediately follow the
-a option or it won't work. In other words -a filesets=all will fails, but -afilesets=all will works.
Transition Statement — Now let's see how to find out what fixes are installed at a client.
Instructor Guide
Listing Fixes at Your Client

smitty nim (or nim_show_apar_stat)
Select the Client

(nim -o fix_query lpar1)
* Target lpar1
* Fix ID [] +

No filesets which have fixes for IY63301 are installed.
...
All filesets for 5.3.0.0_AIX_ML were found.
Not all filesets for 5300-01_AIX_ML were found.
Figure 9-3. Listing Fixes at Your Client AU086.0
Notes:
This output is just like normal instfix -i output on a machine. You might want to issue this
task from the command line in order to get additional options to use. For example, you
might want to use the -v or -a fix_query_flag in order to get verbose output or abstract text.
Command Line - The actual command line is:
nim -o fix_query [-a fixes= . . .] [-a fix_query_flags= . . .] lpar1
There are many other listings you can perform from smit that aren't shown here in this
course. Please see smitty nim_list_installed for details. Note that they reflect the typical
listings you would see at any AIX client. However, these listings allow you to view your
client from the NIM master.

V3.1.0.1
Instructor Guide

Purpose — To show how to quickly list the fixes that are installed at a client.
Details — Notice how to quickly identify maintenance levels as well. This machine
happened to have almost all of the filesets loaded for 530ML1, but was missing just a
couple of updates.
Again, this is the same screen you see when listing fixes in a spot, except now we're
choosing to view a client instead.
Transition Statement — Alright, we know how to do a base install on a client. Now, let's
see how to add software to your client.
Instructor Guide
Adding Software to Your Client

smitty nim (or nim_inst_latest)
Install Software
Select the Client
Select the lpp_source
Install Software
* LPP_SOURCE lpp_source530
Software to Install [Java14.sdk] +
Force no +
installp Flags
COMMIT software updates? [yes] +
SAVE replaced files? [no] +
ACCEPT new license agreements? [yes] +
....
Update your lpp_source if necessary

Figure 9-4. Adding Software to Your Client AU086.0
Notes:
Adding software via NIM is almost identical to doing it standalone. If you choose to view
your software with F4, then you'll be looking inside your lpp_source. Viewing your software
choices looks identical to what you would see in a stand-alone arena.
Be sure to accept new license agreements.
IBM's installation developers recommends verifying each installation.
If your code was not already in your lpp_source, then you need to update your lpp_source
first from your AIX install CDs.
Command Line - The equivalent command to the above smit screen is:
nim -o cust -a lpp_source=lpp_source530 -a filesets=Java14.sdk \
-a accept_licenses=yes -a installp_flags='-acNgXv' lpar1
Run the lsnim -q cust -t standalone or see the nim command for more details.
Note: the default installp_flags for the nim -o cust command are -agX, which mean to apply
only, install dependent software and expand file systems as necessary.

V3.1.0.1
Instructor Guide

Purpose — To show how to install new software onto a client using an lpp_source.
Details — Accepting license agreements is not a default.
The force option can be used if the client has the Network Install Master Push Permissions
disabled via their own smitty nim menu. In other words, the client can choose to stop the
master from performing installation operations on their client at any point in time. However,
the master has the ability to override that option with a force. You'll notice this option on
many of the NIM install screens.
Notice that you can also run post customization if desired on many of these screens.
Sometimes this is handy for setting up config files and so forth at your client once the install
has gone down. If you need to transfer data files from your master site to do any of this
configuration, you probably are not able to use the same mount points that were available
during a base install. This is because the SPOT is not mounted. Plus, the lpp_source and
script are mounted at a temporary directory that varies per operation. Hence, your best
choice is to store your data in another directory that's exported at your master. Then,
manually NFS mount this directory as one of the commands inside your script. Just be sure
to unmount it when finished using it.
Transition Statement — Now let's see how to update pre-existing code at your client.
Instructor Guide
Updating Software by Fix (APAR)

smitty nim (or nim_update_by_fix)
Select the Client
* LPP_SOURCE lpp_source530ML2
FIXES to Install [IY62732] +
-OR-
FIX_BUNDLE to Install [] +
Force no +
installp Flags
Figure 9-5. Updating Software by Fix (APAR) AU086.0
Notes:
As shown, you can update your client with individual fixes. The only major difference
between this screen and one you'd see on a standalone AIX machine is that your input
source is now a NIM lpp_source. Notice that you'd probably want to apply your updates
and commit them later on.
Potential Problems - Make sure you have the right prerequisite code in your lpp_source
and that you have the right level of code on your master. There are known problems with
the right installp_flag usage inside smit prior to 5200-07 and 5300-03. The g installp flag to
automatically install prerequisite code was accidentally left off of the code behind this smit
screen. Hence, you may want to use the command line instead.
Fixes or Fix Bundles - You can either install an individual fix or use a fix_bundle resource.
(A fix_bundle resource is a list of fix IDs (that is, IY15325) versus fileset names that you
would use in an installp_bundle resource.) You can not let both the fix and fix_bundle field
default. If you wish to apply all fixes then use the update_all screen instead shown on the
next screen.
Command Line - The corresponding command line version of this screen is:

V3.1.0.1
Instructor Guide
Uempty nim -o cust -a lpp_source=lpp_source53ML2 -a fixes='IY62732' \

-a installp_flags='-agXv' lpar1
Instructor Guide
Instructor Notes:
Purpose — To show that you can easily apply individual fixes as well.
Details — Be sure to point out the defect on most smit screens mentioned in the student
notes.
An example fix_bundle resource might look like the following:
IY57192
IY20385
IY12059
Transition Statement — Now let's see how to update your client with all fixes in an
lpp_source.

V3.1.0.1
Instructor Guide
Uempty
Updating Installed Software to Latest Level
smitty nim (or nim_update_all)
Select the Client
* LPP_SOURCE lpp_source530ML2
Software to Install update_all
Customization SCRIPT to run after installation [rebootit] +
Force no +
installp Flags
....
Good for ML updates
Update your lpp_source and SPOT too!!
Update Master as well
Figure 9-6. Updating Installed Software to Latest Level AU086.0
Notes:
Whereas the last screen allows you to apply individual fixes, this screen applies everything
in the lpp_source that matches code you already have installed. The lpp_source that you
use may have the latest ML code and may even have some fixes on top of that in it.
You could potentially run a customization script at the end to shut down and reboot after
any update requiring a reboot. However, make sure you use the at utility or you tie up the
NIM master procedure at the master. If you desire to do this, merely set it up as a normal
NIM script as discussed earlier in the class, and it shows up here as a valid option to select.
An example NIM script follows:
#!/usr/bin/ksh
at now +2 min <<-EOF
shutdown -Fr
EOF
Command Line - The equivalent command to the above screen is:
nim -o cust -a lpp_source=lpp_source530ML2 -a fixes="update_all" \
Instructor Guide
-a installp_flags='-agXv' -a script=rebootit lpar1

Run the "lsnim -q cust -t standalone" command or see the nim command for more details.

V3.1.0.1
Instructor Guide

Purpose — To show how to do an update_all procedure with NIM.
Details — Again, notice how similar this is to a native update_all procedure at a
stand-alone AIX client.
Supposedly, the master should be at the same maintenance level as the spots it serves,
and thus the clients it serves. So when updating a client, update your lpp_source, SPOT
and master as well. You can potentially offload your spots to other NIM servers to get
around this master level issue.
Notice the script in the student notes. After applying certain fixes a reboot may be required.
Your student may want to manually reboot their machine afterwards or you could use the
script shown. Neither a straight shutdown nor a nohup /usr/sbin/shutdown -Fr & command
works inside this script. Only the at facility appears to work well with a shutdown shell
script.
Remember you can use the nim -o showres lpp_source_name command to see which
filesets require a bosboot (and thus a reboot). Look for either a B or a b in the Q column.
Transition Statement — Let's now briefly look at some additional installation tasks you
might want to do with your client.
Instructor Guide
Other Common Client Installation Tasks

smitty nim
Perform Software Installation and Maintenance Tasks
•Install and Update Software

– Install the Base Operating System on a Stand-alone Client
– Install Software
– Update Installed Software to Latest Level (Update All)
– Install Software Bundle
– Update Software by Fix (APAR)
– Install and Update from all Available Software
•Software Maintenance and Utilities

– Commit Applied Software Updates (Remove Saved Files)
– Reject Applied Software Updates (Use Previous Version)
– Remove Installed Software
– Check Software File Sizes after Installation
– Verify Software Installation and Requisites
•List Software and Related Information

– List Installed Software and Related Information
• List Installed Software
• List Applied but Not Committed Software Updates
• Show Software Installation History
• Show Fix (APAR) Installation Status
• List Filesets Requisites
• List Filesets Dependents
• List Files included in a Fileset
• List Fileset Containing File
• Show Installed License Agreements
Figure 9-7. Other Common Client Installation Tasks AU086.0
Notes:
Notice that many of the standard AIX installation and listing procedures are available with
NIM as well.
We've already seen how to install the base, install software, install fixes and perform an
update all. From the menus shown, you can also see that we can also install bundles and
install code from all available software on the lpp_source media.
We can also commit applied software, reject it, or even remove it. Again, these screens will
look very similar to those seen on a standalone AIX machine.
In addition, we can list just about anything on our client that we could do on a standalone
AIX machine.
Command Line - The equivalent nim command to commit software is:
nim -o maint -a filesets="Java14.sdk" -a installp_flags="-cg" lpar1
The equivalent nim command to reject software is
nim -o maint -a filesets="Java14.sdk" -a installp_flags="-rBX" lpar1

V3.1.0.1
Instructor Guide
Uempty The equivalent nim command to remove software is:

nim -o maint -a filesets="Java14.sdk" -a installp_flags="-Iu" lpar1
The equivalent nim command to check software file sizes is:
nim -o lppchk -a lppchk_flags='-c' \
-a filesets='Java14.sdk' lpar1
The equivalent nim command to verify software is:
nim -o lppchk -a lppchk_flags='-v' \
-a filesets='Java14.sdk' lpar1
For more information, run the "lsnim -q cust -t standalone", "lsnim -q maint -t
standalone" and "lsnim -q lppchk -t standalone" commands.
In addition, the nim and installp man pages are useful.
Instructor Guide
Instructor Notes:
Purpose — To briefly show the other tasks available via NIM.
Details — There are other tasks available that are not shown. However, these are the most
common ones you'll use.
In particular, point out the Remove Installed Software menu item.
Transition Statement — Handling Version or Release upgrades requires a special
procedure. Let's take a look at that now.

V3.1.0.1
Instructor Guide
Uempty
Handling Version/Release Updates
•Update Master
•Create a new LPP_SOURCE and SPOT from AIX install CDs
•At Client: Run the pre_migration script from the master's NFS mounted
SPOT
•At Master: smitty nim_bosinst (RTE)

– Set INSTALL_METHOD to migrate
• In bosinst_data resource
or
• When Answer BOS Install Questions
– Use a PUSH
•At Client: Run the post_migration script from the client’s /usr/lpp/bos
directory
Figure 9-8. Handling Version/Release Updates AU086.0
Notes:
Your master always has to be at the latest release level in order to serve SPOTs at that
release level, and thus indirectly to serve install clients at that level. Hence, use your AIX
install CDs to update it first.
Use the procedure discussed in the last lecture to create a new lpp_source and spot at this
new release level.
The pre_migration and post_migration utilities are optional but recommended. If run, they
should be run at the client site. They put information into your client's
/home/pre_migration.<date> and /home/post_migration.<date> directories when run. The
pre_migration script is useful to identify what the migration does and if it foresees any
problems. The post_migration script makes sure the migration completed successfully.
The pre_migration script is located on your new release's CD and inside your new release's
spot. If using your spot, the pre_migration script is found in the <spotdir>/usr/lpp/bos
directory at your master. The post_migration script is found in the client's /usr/lpp/bos
directory after the migration has completed.
Instructor Guide
Merely manually NFS export the spot at your master and then NFS mount your SPOT at
your client. Run the script. Then, remember to unmount your spot and unexport it when
done.
Notice that the actual procedure used is a base install using the RTE install type. The key
difference between this migration install and a normal RTE install is in what you specify for
the INSTALL_METHOD variable. You can either do this manually by answering the right
question at the BOS Install Screen, or by setting this variable up in a bosinst.data file and
using that as a resource on your install. Notice that you also have the option of doing an
automated push versus a manual install. This is because you already have a running NIM
client to talk to.
Command Line - The equivalent nim command to perform the above bos_inst operation
is:
nim -o bos_inst -a lpp_source=lpp_source540 -a spot=spot540 \
-a accept_licenses=yes -a bosinst_data=bosinst_with_migrate \
-a installp_flags='-acgNX' lpar1
Run the lsnim -q bos_inst -t standalone command for help. Or, see the nim man page.

V3.1.0.1
Instructor Guide

Purpose — To show the steps required to do a version or release upgrade.
Details — Most students are unaware of the pre_migration and post_migration scripts.
These scripts are very helpful in identifying what the migration procedure does (pre) and
has done (post). They are of course optional.
A push is not required, but handy and useful since you should have a running NIM client at
this point.
Additional Information — The post migration script automatically verifies the software
filesets that were just installed. This verification step is recommended by NIM development
personnel after all installs.
Transition Statement — Now that we know how to do normal updates at our client, let's
look at a fancy feature to do updates: the alternate disk install method.
Instructor Guide
Alternate Disk Install – ML Updates

smitty nim (or nim_alt_clone)
Perform NIM Software and Installation Tasks
Alternate Disk Installation
Clone the rootvg to an Alternate Disk
Clone the rootvg to an Alternate Disk
* Target Machine / Group to Install [lpar1] +
* Target Disk(s) to install [hdisk1]
Phase to execute all +
IMAGE_DATA resource [] +/
EXCLUDE_FILES resource [] +/
BUNDLE to install [] +
-OR-
Fileset(s) to install []
FIX_BUNDLE to install [] +
-OR-
FIXES to install [update_all]
LPP_SOURCE [lpp_source530ML2] +
(required if filesets, bundles or fixes used)
….
Customization SCRIPT resource [] +/
Set bootlist to boot from this disk
on next reboot yes +
Reboot when complete? no +
....
Client needs bos.alt_disk_install* filesets

Figure 9-9. Alternate Disk Install - ML Updates AU086.0
Notes:
This procedure clones your current data in rootvg onto the hdisk1 disk for the client lpar1.
The update_all and lpp_source530ML2 fields ensure that once the clone is done, the latest
ML update is also applied to the data on hdisk1. When all is done, this procedure will have
created an alternate rootvg volume group called altinst_rootvg on hdisk1. It has set up the
bootlist to boot from hdisk1. However, it does not perform the actual reboot. It leaves that
up to you and your timing.
When you finally do choose to reboot, your old rootvg is called old_rootvg. Your new rootvg
is called rootvg.
Notice that you can come up on the old system at anytime by merely changing the bootlist.
You can also view the opposite side's data by issuing the alt_rootvg_op -W hdiskX
command where hdiskX is a disk on the opposite side. When done, your data on the
opposite side is viewable via the /altinst directory structure (that is, /altinst/usr, /altinst/var).
You can choose to put the opposite side to sleep again by issuing the alt_rootvg_op -S
command.

V3.1.0.1
Instructor Guide
Uempty When ready to get rid of your old volume group, type in: alt_rootvg_op -X rootvg. If
instead, you desire to get rid of the new volume group, type in: alt_rootvg_op -X
altinst_rootvg.
Even though the option is not shown on the screen, it is recommended to verify the
installation once it's done.
Some customers use this procedure for a quick rootvg backup by not applying any fixes or
filesets.
Some customers are more conservative and prefer not to set the bootlist until they're ready.
There is also a mksysb procedure you can use. This is probably not as useful in doing an
ML update unless you plan to standardize your shop's rootvg image.
Command Line - The equivalent nim command for the above operation is:
nim -o alt_disk_install -a source=rootvg -a disk=hdisk1 \
-a fixes=update_all -a lpp_source=lpp_source530ML2 \
-a phase=all -a installp_flags="-cNgXv" lpar1
The -a set_bootlist=no option would cause the bootlist not to be set.
The -a boot_client=yes option would cause the reboot to occur.
Run the lsnim -q alt_disk_install -t standalone command for more details. Also refer to the
nim and alt_disk_install man pages.
Instructor Guide
Instructor Notes:
Purpose — To show how to do an alternate disk install using NIM.
Details — The client needs the bos.alt_disk_install* filesets in order for this to work. Use
the bundle to install them.
This procedure takes place at the client. You may see some performance degradation.
This procedure is not meant to be used for migration purposes (that is, version/release
upgrades) as it takes the machine down to perform the upgrade.
Most folks execute all phases. Phase 1 brings the environment into a wakeup mode where
the new disk is available via the /altinst directory. It also copies the data from the original
disk to the new disk. Phase 2 is used to update your new disk using your lpp_source. It also
allows you to run customization scripts. Phase 3 does the sleep to shut down the new side
so it's no longer viewable.
Additional Information — In 5.3 it appears that IBM has changed some options
traditionally used on the alt_disk_install command to the alt_rootvg_op command. Although
you can still use the alt_disk_install command to do wakeup, sleep, and so forth, actions, it
gives you a warning.
Transition Statement — Now, let's see what alternate disk install procedure is available to
use for version and release updates.

V3.1.0.1
Instructor Guide
Uempty
Alternate Disk Install – Version/Release Updates
smitty nim (or nimadm_migrate)
Perform NIM Software and Installation Tasks
Alternate Disk Installation
NIM Alternate Disk Migration
Perform NIM Alternate Disk Migration
Perform NIM Alternate Disk Migration

* Target NIM Client [lpar1] +
* NIM LPP_SOURCE resource [lpp_source540] +
* NIM SPOT resource [spot540] +
* Target Disk(s) to install [hdisk1]
DISK CACHE volume group name [] +
NIM IMAGE_DATA resource [] +
NIM BOSINST_DATA resource [] +
NIM EXCLUDE_FILES resource [] +
NIM INSTALLP_BUNDLE resource [] +
NIM PRE-MIGRATION SCRIPT resource [] +
NIM POST-MIGRATION SCRIPT resource [] +
Phase to execute [all] +
NFS mounting options []
Set Client bootlist to alternate disk? yes +
Reboot NIM Client when complete? no +
......
Update NIM Master to Latest Level First

bos.alt_disk_install* levels of SPOT and LPP_SOURCE = MASTER
pre and post migration scripts are still recommended
Figure 9-10. Alternate Disk Install - Version/Release Updates AU086.0
Notes:
This procedure is used for version and release upgrades. It's been available evidently since
at least V5.1, but not many folks are aware of it. It can even be used to migrate 4.3
systems. You can typically migrate your machine beyond one release level. However, note
your documentation in case there are any issues with the level you're migrating from and
to.
Procedure - The initial procedure is the same as the procedure on the prior screen.
However, this time, the procedure is initiated from the master's SPOT that is NFS mounted
at the client. Once the clone is done, (in other words, in our case, hdisk1 holds the old 530
version), then the master takes over. The master exports the client's rootvg file systems so
that the master can access them. It mounts them at the master site and begins to do the
migration activity. This starts with running the pre-migration script if you specified one. It
then saves off appropriate config files, migrates filesets to the new level (using the
lpp_source you mentioned) and then runs your post-migration script if you specified one. At
this point, typical post-install activity occurs and NIM cleans up after itself.
Instructor Guide
Post Procedure Tasks - When done, your client should look just like it does after a normal
alt_disk_install. The new disk is altinst_rootvg. The old disk is rootvg. Rebooting your client
causes the same activity to occur that you would normally see on the alt_disk_install
procedure we talked about on the last screen. You can also wake your client up or put it to
sleep. Finally, you can remove your old disk with the same standard command when ready:
alt_disk_install -X old_rootvg.
Code Level Prereqs - It is recommended that you keep your master at the latest level.
Hence, you probably want to upgrade that first. Also, make sure that you have the same
bos.alt_disk_install* filesets installed on your master and your SPOT and your lpp_source,
or this procedure does not work. In fact, you may not even see the smit screens appear.
You can even install bos.alt_disk_install* filesets in an earlier release's spot or lpp_source.
This is required and causes no problems during a migration to a release lower than your
NIM master release level. For example, if your NIM master is at 5.3, and you want to
upgrade your client from 5.1 to 5.2, then make sure you install the 5.3 bos.alt_disk_install
filesets in your 5.2 lpp_source and spot at your master. Then, use these resources to
upgrade your client. If even the fix level is off, it could cause a problem.
Scripts - The scripts you see here on the screen are customization scripts YOU want to
run. These are not the standard pre_migration and post_migration scripts. Hence, it's still
recommended to run the pre and post_migration scripts before and after your migration to
double check your activity.
Please see the AIX Version 4.3 to 5L Migration Guide redbook for a more detailed analysis
of how to migrate from one release to another using this facility.
Command Line - The equivalent nimadm command for the above operation is:
nimadm -c lpar1 -l lpp_source540 -s spot540 -d hdisk1
Accepting new license agreements is -Y.

Not setting the bootlist is -B.
Rebooting the client is -r.
See the nimadm command and the alt_disk_install command for more details.

V3.1.0.1
Instructor Guide

Purpose — To show how to do a version or release upgrade using NIM's alternate disk
install mechanism.
Details — This procedure (according to the comments section in nim code) appears to only
use rsh to communicate with your client. Hence, you might have to change your client's set
up (if currently using nimsh) in order for your client to use this.
The Caching option has to do with NFS caching set up at the master. This option and all
NFS tuning is outside the scope of this class. Instead, refer them to the Performance and
Tuning AIX Guide and Redbook.
Cleanup should happen automatically if NIM senses the migration is failing. However, there
is a migration cleanup option available in smit as well. (Note: there is an option on the
nimadm command to even perform the "alt_disk_install -X" cleanup. However, smit does
not support this part of the cleanup. It only supports typical cleanup you'd want to perform if
the operation halted midstream.)
There's another option in smit to Synchronize Alternate Disk Migration Software. This is
what I was alluding to in the student notes. You can either manually ensure that your
lpp_source and spot match the level of bos.alt_disk_install* code installed at your master,
or evidently you can use this smit screen to accomplish the same thing.
Additional Information — It is assumed that you run the post_migration script in the
client's /usr/lpp/bos directory in order to verify your filesets after installation is complete.
Transition Statement — Let's look at one final screen - how do we install software if we're
at the client?
Instructor Guide
Handling Installs from the Client Side

At Client: smitty nim (or nim_client_inst)
Install Software
Install Software Bundle
Install and Update from all Available Software
Reinstall the Base Operating System
Figure 9-11. Handling Installs from the Client Side AU086.0
Notes:
Notice that you can do your installation activity at the client site as well. Notice how similar
your choices are.
There are other options available at the client to list software, disable pushes and to join a
nim network. Refer to smitty nim for details.

V3.1.0.1
Instructor Guide

Purpose — To show that you can install software from the client side as well.
Details — You can also use the nimclient -l command to list software at the client site.
You can use "nimclient -l -l <object>" to do a low-level listing of any object.
The client is using the nimesis daemon at the master to receive these requests.
Transition Statement — Let's review our lecture with a quick checkpoint activity.
Instructor Guide
1. T/F At the master, you can view installed software at the client.
Correct Answer - True
2. T/F The procedure to update your client to the latest fix level is very
similar to updating your spot to the latest fix level.
Correct Answer - True. The key difference is that your target is
different.
3. T/F When updating your client it is not necessary to update your
spot and lpp_source.
Correct Answer - False. Always keep your lpp_source and
especially your spot at the latest client level within the same
release.
4. Performing a version or release update means doing a normal RTE
Base install with the INSTALL_METHOD set to what value?
___________________________
Correct Answer - migrate
5. T/F You can use the alternate disk install procedure to update your
client while keeping your client up and running.
Correct Answer - True
6. T/F Many of the same installation options available at the master
are available at the client.
Correct Answer - True. Use smitty nim at the client to access them.

V3.1.0.1
Instructor Guide
Uempty
Unit Summary
•Add software to the client
•Upgrade the client
•Perform an alternate disk install
Notes:
Instructor Guide
Instructor Notes:
Purpose —
Details —

V3.0
Instructor Guide
Uempty Appendix A. NIM in a Cluster Environment

This unit looks at the way NIM operates in a Cluster/1600 and in an SP
environment. Although the concepts behind NIM remain the same, the
way in which we configure and manage it in an SP environment, is
fundamentally different. We briefly describe the components that make
up an SP environment before to see how NIM is used for this
environment.

• Distinguish different cluster architectures
• Explain the way NIM operates in a Cluster 1600 environment
• Transfer the CSM node information to NIM
• Explain the way NIM operates in an RS/6000 SP environment
• Describe the NIM objects
• Create the NIM environment using RS/6000 SP tools
• Manage NIM operations with those tools

Accountability:
References
SC23-4389 AIX 5L Version 5.2 Installation Guide and Reference
SC23-4117 AIX 5L Version 5.2 Commands Reference Volume 3
SC23-4118 AIX 5L Version 5.2 Commands Reference Volume 4
SG24-5524 NIM: From A to Z in AIX 4.3 (ITSO Redbook)
SG24-6859 An Introduction to CSM 1.3 for AIX 5L (ITSO
Redbook)
GA22-7347 PSSP Installation and Migration Guide
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-1
Instructor Guide
Unit Objectives
•Distinguish different cluster architectures
•Explain a Cluster 1600 environment
•Invoke CSM commands for NIM support
•List the different RS/6000 SP hardware components
•Explain the way NIM operates in this environment
•Describe the NIM objects related to an RS/6000 SP system
•Create the NIM environment using RS/6000 SP tools
•Manage NIM operations with PSSP tools
Figure A-1. Unit Objectives AU086.0
Notes:
A-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.0
Instructor Guide
Instructor Guide
A.1. NIM in a Cluster 1600 Environment
Instructor Topic Introduction

The new Cluster 1600 environment allows you to handle many AIX systems from one
single point of control. To install these systems the usage of NIM is a good choice. So let’s
see which support we have in this environment to get the cluster information to NIM.

V3.0
Instructor Guide
Uempty
Different Cluster Architectures
zHigh availability clusters
–If
a hardware or software component fails, a backup system or
device can take over
zHigh performance computing
–The
systems (nodes) work in parallel to apply more processing
power
zHorizontal scaling cluster
–Provide increasing (or decreasing) resources through a common

interface
Figure A-2. Different Cluster Architectures AU086.0
Notes:
What is a Cluster?
A cluster is simply defined as a group of two or more computers working together. This
arrangement could be as basic as two connected systems, with one providing the
computing needed, and one in idle standby, ready to take over the processing if the first
system fails, thus providing high availability. Or it could be as complex as having many
computers working together on the same problem, with the workload being coordinated
and run on multiple systems. This enables computing power greater than one system.
Small clusters, such as a high-availability design with one active system and one standby
system, are generally configured and controlled as individual systems. Scripts are set up to
react to certain alerts and cause predetermined actions. Large clusters with many nodes
cannot be easily managed as individual separate systems. It is therefore desirable and
almost required to have central management and control.
Instructor Guide
High-availability clusters
High-availability clusters are built to provide an environment where, if a hardware or
software component fails, a backup system or device can take over and provide the same
function. This process is called failover; when one system fails, the workload moves over to
another system.
There is generally some elapsed time associated with the failover, ranging from several
seconds to several minutes. High availability should not be confused with fault-tolerant
design, which has many redundant components that automatically take over for failing
components, with almost no down time.
High availability clusters can be very complex to design. There are many considerations
that determine how many and what kind of problems you actually prepare for. You need to
understand all the types of problems that are possible, economic consideration, and the
probability of each kind of problem. In addition to the one-to-one cluster configuration
(where one system is idle and one system active), you can have one-to-many clusters,
where one system is idle, but ready to back up any of several other systems.
High-performance computing
High-performance computing clusters are designed so that the systems (nodes) work in
parallel to apply more processing power to the solution of a problem. Scientific computing
programs are run this way with clusters of many nodes working together. Clusters of 128
nodes are not unusual, with some having even more than 1024 nodes (special bid
required).
Creating and managing a system this large can be very complicated. In this environment,
not only is it important to create, manage, and maintain many nodes, but it is also important
to effectively divide and manage the work so that multiple nodes work together and
produce the desired results.
Horizontal scaling cluster
Horizontal scaling clusters are used to provide increasing (or decreasing) resources
through a common interface. This is typical of Web server farms where there is one
interface to the world, the Universal Resource Locator (URL), yet there may be many
servers behind it where the requests are handled. Load balancing is important in this kind
of cluster.

V3.0
Instructor Guide

Purpose — Since there are a lot of possibilities to build a cluster, the students need some
understanding of the different cluster types.
Details —
Transition Statement — Now what’s a Cluster 1600?
Instructor Guide
What is a Cluster 1600?

pSeries
p690/p670
p655
with HMC xSeries
p630 with HMC servers
Managed nodes are servers

that are defined in a cluster.
Managed nodes may run AIX
Management Server is the single
5.1 or 5.2 or RedHat 7.2 or 7.3
point of control for the managed
on xSeries servers (330, 342,
nodes in the cluster. The cluster
335, and 345).
can be operated, maintained and
monitored from the management
server. The management server
must be running AIX 5.2.
Figure A-3. What is a Cluster 1600? AU086.0
Notes:
The IBM Eserver Cluster 1600 is a management cluster of nodes where the management
server is running AIX. The Cluster 1600 can contain many RS/6000 systems, pSeries
systems, or logical partitions (LPARs) as nodes, and may include Linux nodes. The
defining point of the cluster is where the management control resides. Even if the majority
of nodes in the cluster are xSeries nodes running Red Hat Linux, if they are managed by a
system running on AIX, it is considered a Cluster 1600.
There are currently only two management server programs supported on a Cluster 1600:
Parallel Systems Support Program (PSSP) and Cluster Systems Management (CSM) for
AIX. Each management server has its own hardware and software requirements.
CSM 1.3 for AIX 5L
Cluster Systems Management Version 1.3 for AIX 5L is an IBM program package that
contains a group of tools and utilities developed by IBM and by the open source software
community combined in a way to provide management functions for pSeries servers with
AIX and xSeries servers with Linux clusters in the same Cluster 1600.

V3.0
Instructor Guide
Uempty Having a cluster is more than just physically connecting nodes on a network. The point of a
cluster is to be able to manage multiple nodes. In a small network of only a few systems,
this can be done by simply logging in and administering the system, but this is not practical
with a large number of nodes. A cluster with 128 nodes or larger (special bid required) is
not uncommon.
Therefore, the need to manage the clusters in a simpler and consistent manner has
evolved. This is where a management server comes into play. Some of the roles that need
to be done in a cluster from a central point of control are:
• Install and update software on all machines in the cluster
• Detect and diagnose problems that can lead to system errors
• Handle problems that occur when no one is around
• Control or reboot servers remotely
• Keep administrative and system costs down
Instructor Guide
Instructor Notes:
Purpose — Describe a Cluster 1600 environment.
Details —
Transition Statement — Let’s see how this environment helps us with the setup and
usage of NIM.

V3.0
Instructor Guide
Uempty
Cluster 1600 and NIM
zWith Cluster 1600 NIM is not mandatory
zBut recommended
zAfter initial NIM setup there are some CSM commands to support the
NIM environment:
–csm2nimnodes Create NIM machine definitions
–csmsetupnim Configure CSM customization scripts as NIM
scripts
–netboot Starts network boot of the node
–lsnode Monitor and verify the installation
Figure A-4. Cluster 1600 and NIM AU086.0
Notes:
It is not mandatory for you to configure the management server as a NIM master or to have
NIM at all. There are many ways to set up NIM, depending on the environment. Below are
the steps to configure a management server as the NIM master.
Configuring the management server as a NIM master
Create NIM resources
• lpp_source
• Shared Product Object Tree (SPOT)
• bosinst_data
Instructor Guide
NIM installation of AIX and CSM on a cluster node

Step 1: Make the NIM master
You can make the NIM master just like you've done in class. The following series of steps
assume you've set up your NIM master on the same machine as the CSM master. The
netboot operation in particular fails if this is not the case. Instead, you have to manually go
to the client and initiate the install from SMS.
Step 2: Create NIM machine definitions
The csm2nimnodes command uses definitions in the CSM database to construct clients
and network definitions in the NIM database.
csm2nimnodes -N AIXnode1, AIXnode2….
Run the lsnim command to check whether the appropriate clients and network have been
defined on your behalf.
Step 3: Update/Make other Resources as Required
Use your NIM knowledge to make any other resources that you need. Also update any
resources as needed.
Step 4: Make NIM Machine Groups
Translate your CSM machine groups into NIM machine groups.
csm2nimgrps -N AIXnodes
This should construct a machine group called AIXnodes with all the appropriate clients
listed inside. Check this with lsnim -l AIXnodes.
Step 5: Prepares nodes for installations
csmsetupnim -N AIXnodes
This creates the /csminsall/csm/config/<node>.config_info file. It identifies CSM scripts as
NIM scripts. These scripts install CSM after the node is installed. It also picks up user
defined scripts in the /csminstall/csm/scripts directory.
Step 6: Setup openssl/openssh installp_bundles
In openssl bundle, include:
R:openssl*
In the openssh bundle, include:
I:openssh.base
I:openssh.license
I:openssh.man.en_US
I:openssh.msg.en_US
I:openssh.msg.EN_US

V3.0
Instructor Guide
Uempty Step 7: Enable BOS Install for the client(s)

Use your normal smitty nim_bosinst screen (or command equivalent) to enable your clients
for installation. Don't enable the push.
Step 8: Initiate the Install
netboot -n [-s server.IP [ -G gateway.IP]] AIXnode
This command, when issued from the master, resets the client's bootlist and by default
performs a broadcast BOOTP operation. You can augment this and create a directed
BOOTP request by entering in a server and optionally a gateway's IP. (Note: if your CSM
server is not your NIM Master machine then you manually have to go into SMS at the client
and change the bootlist and IPs yourself. In other words, you need to perform a normal
manual initiated install).
Step 9: Monitoring your install
rconsole -t -n AIXnode
csmstat -l AIXnode
lsnode -n AIXnode -a Mode
lsnode - p -n AIXnode
dsh -w AIXnode date
lsnim -l AIXnode
These commands perform the following:
1. Open a node's virtual console
2. Look at a node's LEDs
3. View whether a node is PreManaged, Installing or Managed. Managed of course means
the install is complete. This is basically equivalent to using the lsnim -l AIXnode
command in NIM and looking at the Cstate field.
4. View whether the client is alive yet or not. (It says alive if it's up). This is similar to
looking at the lsnim -l AIXnode information in NIM and viewing the Mstate field.
5. See whether dsh can run a command on the node. If so, the install must have gone
well.
6. Display normal NIM status information.
Please see the "Cluster Systems Management Cookbook for pSeries" Redbook for more
information.
Instructor Guide
Instructor Notes:
Purpose — Discuss the Cluster 1600 features concerning NIM
Details — See student notes and SG24-6859 An Introduction to CSM 1.3 for AIX 5L
Additional Information — You can also typically use the -a option versus -N AIXnode to
initiate the operation for all nodes for the csm2nimnodes, csmsetupnim and netboot
commands.
Some other common listings for the lsnode command are:
lsnode -l <node> - gives detail info such as showing whether or not it's in the PreManaged,
Installing or Managed state.
lsnode - lists all nodes.
lsnode -a - gives detail info on all nodes.
Transition Statement — Really that’s all for Cluster 1600, now let’s have a look at the SP
environment.

V3.0
Instructor Guide
Uempty A.2. NIM in an RS/6000 SP Environment
Instructor Topic Introduction

The instructor introduces briefly this topic in giving some words about:
• The different hardware configurations
• The role of the C.W.S. which is the Single Point Of Control (S.P.O.C.) in an RS/6000 SP
environment
• The role of the System Data Repository (S.D.R.) and how it interfaces with N.I.M.
• The characteristics of the N.I.M. environment in an RS/6000 SP complex or in a Cluster
Enterprise Server complex.
Instructor Guide
RS/6000 SP Overview - Components

Frames
yContain processor Nodes
– Tall - maximum of 4-16 nodes/frame SP-attached
– Low - maximum of 2-8 nodes/frame Standard Frame
Node
ySwitch (optional) Node
yPower S80
Nodes p680
yComplete RS/6000 processors
yStandard Nodes
–Three form factors : Thin/Wide/High
ySP-attached Server Nodes
–S80, pSeries 680, pSeries 660, pSeries
690, H80, M80
Control Workstation
ySingle Point Of Control. H80
ySystem management interface p660
M80 p690
Switch Control
yVery high performance interconnection Workstation
yHigh bandwidth and low latency
yMultiple path/High availability
Figure A-5. RS/6000 SP Overview - Components AU086.0
Notes:
SP system delivers solutions for some of the most complex large technical and commercial
problems. Customer uses include: mission-critical commercial computing solutions to
address data mining and data warehouse applications, online transaction processing
(OLTP) applications, server consolidation, and collaborative computing comprised of Lotus
Notes, Domino Server, Internet, Intranet, Extranet, and group ware application solutions.
Recognized in the industry as a high-capacity and reliable Web server, the SP system is an
ideal base for e-business applications. Technical computing users, including corporations,
universities, and research laboratories use the SP system for leading-edge applications
such as seismic analysis, computational fluid dynamics, engineering analysis, and
computational chemistry.
An SP system is made up of the following components:
• Nodes
• Frames
• Control Workstation (CWS) or Monitor And Control Node (MACN)
• Switch (optional)

V3.0
Instructor Guide
Uempty An SP system can consist of anywhere from two to over one thousand nodes. The nodes
are held within frames. Although an SP system can be viewed as a single entity and its
nodes configured to run in parallel on single large-scale jobs, it is important to remember
that each node is basically a stand-alone RS/6000 or pSeries system. Every node has, at
least, one internal disk, its own processors, memory, and a copy of the AIX operating
system. What each node does not have is a console, mouse, keyboard, or any type of front
panel display, such as a key switch or LED display.
Coordination of these computers is a major task. Each SP system has a stand-alone
RS/6000 or pSeries machine acting as a single point of control, the CWS and software
(PSSP) to let you manage tens or hundreds of nodes as a single system.
The Control Work Station (CWS) is the single point of control (SPOC) for the whole
RS/6000 SP system. It is the focal point for system administration:
• All SP hardware and software can be managed from the CWS,
• All system, frame, and node levels can be managed at a single point: the CWS,
• All software changes can be made from one place: the CWS, propagated to all (or
chosen) nodes,
• All system management and administration tasks can be performed just once: on the
CWS,
• Just one System Data Repository (SDR) can contain all this information in a single
place: the CWS.
The RS/6000 SP system provides a heterogeneous software environment: multiple levels
of AIX, PSSP and application software are ably supported. IBM Parallel System Support
Programs for AIX (PSSP), currently at Version 3 Release 2, is a product that provides
Single Point of Control (SPOC) and Monitoring (SPOM) of a clustered environment. Note
that we did not explicitly state that PSSP was for a classical IBM RS/6000 SP environment.
PSSP is now capable of managing many of the standard IBM Enterprise Servers and IBM
systems you see today, such as the 7017-S70, 7017-S7A, 7017-S80, 7026-M80,
7026-H80, pSeries 680, and pSeries 660 Model 6H1.
The Switch is a high-speed internal communication system with low latency and high
bandwidth between nodes; physically it supplies a minimum of four paths between any two
nodes and it supports TCP/IP and MPI. It offers linear scalability. Network performance
does not fall when the number of processors connected to the net and the traffic increase.
Instructor Guide
Instructor Notes:
Purpose — Before having a look at NIM in an SP environment, let us just make sure that
we have a common understanding of what an SP is.
Details — Many people know of Deep Blue and SP only through this event. But what is an
SP system, what are the most important features of the RS/6000 SP? What are the most
common applications it runs? How do these components relate to the most common
applications? Is this power just for chess?
The RS/6000 SP high-performance system uses the power of parallel processing to
expand application horizons. Designed for performance and scalability, this system makes
it feasible to process applications characterized by large-scale data handling and
computing intensity.
We should remember that the RS/6000 SP System is built with standard AIX and
RISC/6000 components. We must also note that it has its own components with associated
software for handling the following: frame, node, CWS, switch.
An SP system can be composed of one or many frames, each frame offering 8 or 16
drawer/slots to support node connections. What is a node? Each computer in the SP
system is called a node. Each standard node can contain from 1 to 16 processors
(UP/SMP). Additionally, it has its own memory, I/O, Operating System, and TCP/IP
addresses.
In this way, you can harness the power of hundreds of processors within the SP. An SP
system can have up to 128 nodes or 512 by special request integrated into frames
The CWS: The SP or Clustered Enterprise Server (CES) environment, described on next
foils, requires a customer-supplied RS/6000 or pSeries workstation with a color monitor.
This node is called a monitor and control node (MACN) or control workstation (CWS). It
serves as a single point of control for managing, monitoring, and maintaining the RS/6000
SP frames and individual cluster nodes. A system administrator can perform these control
tasks by logging into the MACN (CWS) from any other workstation on the network.
The optional SP Switch can be used in conjunction with the SP Switch Router to
dramatically speed up TCP/IP, file transfers, remote procedure calls, and relational
database functions. The SP Switch offers the following improvements over the high
performance series of switches: higher availability, fault isolation, concurrent maintenance
for nodes, improved switch chip bandwidth.
Transition Statement — Let's see the two configurations managed by the couple CWS /
PSSP: The RS/6000 SP configuration and the Cluster Enterprise Server.

V3.0
Instructor Guide
Uempty
RS/6000 SP Overview - SP Configuration
Midrange server
Homogeneous or heterogeneous
H80 /M80 and Model 6H1
configurations with:
SP frame
with internal nodes
POWER3 Thin, Wide and High Nodes
512 per system
SP-Attached S80, p680, p690

Functionally equivalent to SP managed nodes Switch
Up to 16 may be attached Cable
Ethernet
SP-Attached H and M Series
Functionallyequivalent to S Series Cluster RS232
support
Up to 32 systems may be attached
PSSP support consistent with SP managed SP-attached server

nodes 7017 enterprise server
S70 / S7A / S80, pSeries 680 and
Perspectives, monitoring, hardware control pSeries 690
Figure A-6. RS/6000 SP Overview - SP Configuration AU086.0
Notes:
The CWS is linked to the nodes in two ways:
1. The first is via a special RS-232 serial link to each frame, which attaches to a frame
supervisor card which, in turn, attaches to a node supervisor card in each node. This
allows the CWS to become a locally attached console when needed and also to perform
and monitor lower-level hardware tasks, such as turning the key switch or checking the
status of the LEDs.
2. The second connection is via the administrative Ethernet network. This is a dedicated
network between the nodes and the CWS and is used for installation and to carry SP
specific network traffic, such as the topology services daemons.
A little bit of history:
• Standard components:
- The SP2 was announced in 1994. It represents the high-end of the RS/6000 family.
Instructor Guide
- In 1996, IBM introduced a faster version of the switch, more than doubling the
bandwidth of its predecessor, new nodes, including Symmetric Multiprocessor
(SMP) versions, and more robust and functional PSSP software.
- In 1998, the first generation of SP nodes with PCI architecture were introduced: the
332 MHz thin and wide nodes, code-named Silver, were based on PowerPC
technology and are still very popular in the market because of their outstanding
integer performance.
- The next generation of PCI nodes were the POWER3 SMP nodes, code-named
WinterHawk-I, introduced in 1999. The POWER3 SMP thin and wide nodes were
the first scalable processor nodes that utilizes the POWER3 64-bit microprocessor,
which is based on IBM copper technology.
- In 2000, this node type has been upgraded to the POWER3 375MHz node,
code-named WinterHawk-II. This is the latest dedicated SP node, which works with
the new POWER3-II microprocessor that is based on IBM copper technology
enhanced by the silicon-on-insulator (SOI) technology.
- With the introduction of the POWER3 microprocessor, IBM also delivered new high
node models. The first generation of POWER3 SMP high nodes were introduced in
1999, code-named NightHawk-I, and based on the 222 Mhz POWER3
microprocessor.
- The latest high node model was also upgraded to the 375 MHz POWER-II
microprocessor in 2000, code-named NightHawk-II. These high nodes are the first
dedicated SP nodes that have a switch-based memory controller. They can be
upgraded up to sixteen 375 MHz POWER3-II processors, 64 GB memory, and the
I/O subsystem can be highly extended by up to six remote I/O expansion units.
Thus, the latest POWER3 SMP high node can reach an aggregate bandwidth of
nearly 36 GB per second. It is the most powerful and extensible node that has ever
been placed in an SP frame.
- Since the introduction of the new 375 MHz POWER3 SMP high node in 2000, the
new SP Switch2 has also been available for this node type. Numerous
enhancements has been implemented in the new SP Switch2, so that a latency of
14 micro s and a bandwidth of 460 MB per second is possible at the application
level.
• SP attached servers:
- In 1998, IBM introduced the 7017 enterprise servers S70 and S7A as SP-attached
servers. A new node type was born that changed the look of the SP. The next
generation of 7017 servers, the RS/6000 S80 and the IBM pSeries 680 also have
the capability to work as SP-attached servers.
- In 2001, IBM extended this tradition to the midrange servers RS/6000 H80, M80,
and IBM pSeries 660 Model 6H1. This allows a very smooth sizing of your
SP-attached server environment because you can choose a system (from a

V3.0
Instructor Guide
Uempty considerable number of models) that fits to your needs with all the advantages of the
SP cluster philosophy.
- All SP-attached servers have an optional connection to the SP Switch. Thus, they
can utilize the SP advantage of a high-speed interconnect. Therefore, they take
advantage of the whole SP philosophy and are regarded as complete SP nodes.
Instructor Guide
Instructor Notes:
Purpose — Have a look on how the SP family has expanded over the years.
Details — Why the introduction of the 7017 server into the SP cluster environment?
Because of its outstanding SMP architecture, the 7017 server is the most vertically
scalable AIX server. Thus it combines the outstanding horizontal scalability of the SP with
the outstanding vertical scalability of the 7017 server. This offers tremendous flexibility in
system scaling. It fits to all your business needs, for example, you may want either a
database server with high horizontal scalability and a Web application server with high
vertical scalability. You can have all that in one cluster solution with all the advantages in
manageability, availability and flexibility, which are offered by the SP cluster philosophy.
Transition Statement — IBM continues to follow this strategy, let us see the new (2000)
Cluster Enterprise Server strategy.

V3.0
Instructor Guide
Uempty
RS/6000 SP Overview - Cluster Enterprise Server
pSeries 680 and 690

Blue Hammer
Figure A-7. RS/6000 SP Overview - Cluster Enterprise Server AU086.0
Notes:
Clustered enterprise server (CES) In July of 2000, PSSP 3.2 was introduced. This new
version makes it possible to cluster the 7017 enterprise servers without an SP frame.
Although this announcement changed the face of traditional SP clusters, most of the SP
cluster philosophy is implemented in the first step of this Clustered Enterprise Server (CES)
strategy. The CES opens a variety of cluster scenarios and extend the SP cluster family:
SP cluster switched or non-switched, SP cluster with SP-attached servers switched or
non-switched, and clustered enterprise server can be implemented. Determine your
business needs and choose one of the cluster solutions that best fits your plans.
In 2001, the CES technology was further enhanced to incorporate server models that can
now be members of a CES environment: RS/6000 H80, M80, and pSeries 660 Models 6H1
and M81, pSeries 680, pSeries 690.
Instructor Guide
Instructor Notes:
Purpose — Describe what a CES system is.
Details — To complete the wide variety of clustering capabilities, this visual shows a pure
clustered enterprise server (CES) environment without an SP Frame. Up to 16 high-end
enterprise server (models 7017-S70/S7A/S80 and pSeries 680) and 32 midrange
enterprise servers (H80/M80 and Model 6H1) are supported in a CES. Requires AIX 4.3.3
+, PSSP 3.2 +. The MACN (CWS) is an F80 with one 128-Port Asynchronous PCI
controller and a chain of two necessary RANs. CES systems appear and are installed the
same way SP-Attached Servers would be installed on a normal SP system with physical
SP frames. However, a CES is not an SP, it is just a cluster of servers.
Transition Statement — Control of these computers in SP or CES configuration is a hard
task. The CWS with PSSP software is here to do help you.

V3.0
Instructor Guide
Uempty
RS/6000 SP - Centralized Management
Node
2
SDR Node
setup_server
3 Node
smit NIM NIM
enter_data install/customize Node
1
Node
CWS Node
or
MACN
0 Node
C WS
setti
ng u Node
p
Figure A-8. RS/6000 SP - Centralized Management AU086.0
Notes:
One of the more complex tasks within an SP system is the installation of the nodes. In
contradiction to stand-alone workstations which are usually equipped with tape and/or CD
devices, all the SP nodes are missing these devices. Therefore the ordinary installation
methods via tape or CD do not work. The solution for this dilemma is installation over a
network. The administrative Ethernet, the connection between the CWS and all the nodes,
is used for this installation method. That is one of the reasons why the Ethernet is
mandatory.
NIM provides the ability to install machines with software from a centrally managed
repository in the network. Looking at the NIM installation methods, we notice that the PSSP
software is only using a subset of the NIM capabilities (for example, only the installation of
standalone workstations is used). All of the NIM commands and options are being hidden
by PSSP scripts and commands. Because of this, and as long as the installation is
successful, some of the complexity appears to be transparent.
Instructor Guide
The installation process is divided into four areas:

1. Environment preparation:
The first part of the installation procedure deals with setting up the CWS and making
sure it has the necessary prerequisites to actually act in this capacity, the second part
with getting PSSP installed on the CWS. The steps involved in this phase will among
other things create an empty SDR Data Base that we have to populate before running
setup_server.
2. System Data Repository (S.D.R.) data entry
What is the SDR for? The System Data Repository (SDR) is something unique to the
SP. It contains SP-specific information in a central repository that resides on the CWS. It
is held in plain ASCII text format under the /spdata/sys1/sdr/ directory structure. The
reason we mention the SDR at this point is because it is crucial to the installation
procedure. In order to install our SP system, we must initialize and populate the SDR
with configuration information about the environmental details of the SP, the frame(s),
and the nodes. When we then run the setup_server script for the first time, it queries the
SDR in order to retrieve the relevant information to make and define the NIM objects
necessary to go ahead with the installation.
3. Boot / install server configuration: setup_server The crucial difference in managing
NIM in an SP environment is how the NIM objects are configured and managed.
Whereas, in a classic RS/6000 environment, each object is either defined manually via
smitty or nim -o define, in an SP environment, this is hidden behind the NIM wrappers,
most significantly, a large Perl script called setup_server. This script creates the NIM
environment, the NIM resources, the NIM clients. Also, it allocates NIM resources to
NIM clients inside the SP. After running this script, nodes are ready to be installed over
the network.
4. Node installation:
The ultimate step is to power on the nodes and boot them through the network to initiate
a NIM installation in pull mode.

V3.0
Instructor Guide

Purpose — To describe what is basically done in each task.
Details — Although it is possible to attach a tape or CD-ROM drive to an SP node,
generally speaking, it will have no means of installation other than its network interface.
This is why NIM is the only supported method of SP installation. However, because of the
environment in which the SP runs, there are some key differences in the configuration of
NIM and how an installation is performed.
There are basically five phases or tasks of installing the software environment of an SP
system. Each task is broken up into multiple steps and is dependent upon the proper
completion of all the steps in the previous task. To simplify, in student notes, the two first
phases have been grouped.
1. Task A basically sets up the environment needed to load PSSP on the control
workstation. It also begins to provide the framework necessary to load PSSP and AIX
on the nodes.
2. Task B continues to lay the foundation for loading the nodes from the control
workstation in addition to actually installing PSSP on the control workstation. It also sets
up client/server authentication, creates the SP configuration database called the SDR,
starts up many of the SP daemons including the sdr and hardmon daemons.
3. Task C has the largest number of configuration steps. It is here that the SDR created in
Task B gets populated with frame, node, switch and site environment information.
Finally, the nodes are setup to be installed and the control workstation configured as a
boot/install server. This sets up the NIM environment by which the nodes will be
installed in Task E.
4. Task D provides for updating node customization scripts, setting up the switch and
partitioning, if needed.
5. Task E installs the nodes. Once completed, installation verification is done.
This visual is meant to provide a basic road map of where we are headed in the SP
installation process. Each Task is represented by a separate foil.
Transition Statement — Let's begin by looking more closely at the steps involved in
accomplishing the CWS setting up.
Instructor Guide
Setting Up the Control WorkStation

•Basic AIX setting
•Software and hardware prerequisites checking
•Network preparation
/
•File Systems sizing
spdata
•/spdata directory preparation
sys1
install
aix421 aix433 images pssp pssplpp
bos.obj.ssp.433
lppsource lppsource bos.obj.ssp.421 PSSP-2.4 PSSP-3.2
noded103backup..
.
AIX CD AIX CD PSSP PSSP

CD CD
Figure A-9. Setting Up the Control WorkStation AU086.0
Notes:
Installation process 1: Environment preparation
The first part of the installation procedure deals with setting up the CWS and making sure it
has the necessary prerequisites to actually act in this capacity and then with getting PSSP
installed on the CWS.
Just for your information, following is a short listing of steps to do for an SP installation. The
initial steps are:
1. Update root's PATH so that it picks up SP-specific binaries.
2. Ensure that AIX, bos.net, and perfagent.tools are installed.
3. Connect the frames to the CWS, and configure the RS-232 serial link.
4. Configure and tune the network adapters.
5. Test network connectivity with ping.
6. Check that the necessary daemons are running.

V3.0
Instructor Guide
Uempty 7. Change the maximum number of runable processes per user to 256.
8. Tune various network options with no -o.
9. Define space for /tftpboot and the volume group for /spdata.
10. Create the /spdata directory structure (preferably in a separate volume group).
11. Copy over the AIX LPP images.
Of these initial steps, the most significant action, as far as our NIM configuration is
concerned, is the last one: Copying over the AIX LPP images. In performing this step, we
are moving the AIX LPP images over to our local disk ready to configure them as an
lpp_source NIM resource.
12. Copy the PSSP installation images from CD or tape over to disk.
This step has some relevance to NIM because the script, during nodes installation, a script
resource named pssp_script, remotely mounts the directory in which the PSSP images
reside and install PSSP on the nodes as part of the customization.
13. Copy a basic AIX (mksysb) image to disk.
Again, this step has particular relevance to NIM because the mksysb image is later defined
as a NIM mksysb object.
14. Install PSSP on the CWS.
15. Initialize SP Authentication Services.
16. Run install_cw script.
This completes the configuration of the CWS, and this final step, among other things,
installs the PSSP smitty panels, configures the SDR, and starts the SP daemons.
Instructor Guide
Instructor Notes:
Purpose — List the first steps of SP installation
Details — This is a condensed and very brief overview of the SP installation process
concentrating on the steps linked with creating the NIM resources; for detailed information
on the complete installation process, refer to the following guides:
• IBM RS/6000 SP: Planning Volume 2, Control Workstation and Software Environment,
GA22-7281
• PSSP: Installation and Migration Guide, GA22-7347
Don't enter in this description which is here only for instructor information. Try to stay in
NIM in the RS/6000 SP environment subject.
Directory structure: As part of configuring the CWS, the administrator needs to create a
directory structure under /spdata. The specific directories of interest to NIM lie under the
/spdata/sys1/install directory. As part of the installation process, we bffcreate the AIX
installation images from installation media, such as tape or CD-ROM. Under the
/spdata/sys1/install directory, we need to make a directory that corresponds to the level of
AIX we are copying over and place the installation images in the lppsource directory under
this. The /spdata/sys1/install/images directory holds the mksysb images. Minimum
installation images are shipped on the PSSP media, or you can add your own mksysb
images here for installation. mksysb images are of particular importance to the SP because
the NIM installation is based upon installing from an mksysb image and then customizing
the node with data the CWS holds in the SDR. The /spdata/sys1/install/pssplpp holds
sub-directories that contain bffcreated versions of the PSSP filesets. The naming
convention for these subdirectories is PSSP-<x.y>, where <x.y> is the level of PSSP. The
/spdata/sys1/install/pssp directory holds some additional NIM scripts, such as
pssp_script. It also holds the scripts that make the migrate, prompt, and noprompt
bosinst_data NIM objects.
Step 11: One example method of copying over the images would be to have an AIX
installation disk in the CWS CD-ROM drive and type smitty bffcreate. When prompted, use
/dev/cd0 as the INPUT device / directory for software, and, in the DIRECTORY for storing
software package, type /spdata/sys1/install/<name>/lppsource, where <name> is the name
you have called your lppsource directory.
Step 13: Copy a basic AIX (mksysb) image to disk. The SP hardware is shipped with media
that contains an spimg installp image. Alternatively, you can use your own mksysb image
(in which case, you must copy this into the /spdata/sys1/install/images directory).
Transition Statement — Now that the installation of the CWS is complete, we can go
ahead and enter our configuration details for the frames and nodes into the SDR.

V3.0
Instructor Guide
Uempty
SDR - Enter Data - SP Ethernet Definition
1
5
129.1.11.101
129.1.11.22
Figure A-10. SDR - Enter Data - SP Ethernet Definition AU086.0
Notes:
Installation process 2: System Data Repository (SDR) data entry
Now that the installation of the CWS is complete, we can go ahead and enter our
configuration details for the frames and nodes into the SDR. SDR is similar in concept to
the AIX Object Data Manager (ODM), it's a database containing Classes, Attributes, and
Objects. There are several ways of entering data: Through the command line, through the
Perspectives panel, or via smitty. In this brief overview of the installation process, we will
only cover the method using smitty.
The smitty panels showed on this foil are two of the steps you have to do, to fill all the
information relative to the SP in the SDR, they give you the possibility to enter:
• SP Frame information (step 20) Hardware information is directly kept from supervisor
cards using the tty connection. The only information you have to give in this step is the
combination tty number, frame number for each SP or non-SP frame.
• Ethernet interface configuration data into the SDR for all the nodes (step 22). The data
we enter here is used to add IP address information to the node objects in the SDR and
is used by NIM during the customization phase.
Instructor Guide
Here is a short list of all the steps for this SDR filling in phase:
1. Enter Site Environment Information which purpose a myriad of options.
2. Enter SP and non-SP Frame Information and reinitialize the SDR.
3. Verify System Monitor Installation.
4. Verify Frame Information (we can do this by starting Perspectives and opening up the
node pane, which should give us a visual representation of the frame(s) we have
defined along with the nodes within the frames that have been detected).
5. Update the State of the Supervisor Microcode.
6. Enter the required Node Information: SP Ethernet Information.
7. Acquire the Hardware Ethernet address: as previously discussed, part of the definition
of a NIM client is the MAC address of its primary adapter. On the SP, we must boot over
the administrative Ethernet network, but the same rule applies. One of the features of
the link between the CWS and the frame supervisor cards on the SP frame(s) is that we
can acquire these Ethernet addresses by running one simple command.
We have done almost everything necessary in order to start installing the SP system.
From this point on, most of the steps are optional and will depend upon your own
configuration.
8. Configure additional adapters for nodes: if you have additional adapters on the nodes
that you want configured during customization, for example, if you have a switched SP
system, perform this action. Entering data in fields is very similar to configuring the SP
Ethernet information.
9. Configure Initial Host Names for Nodes
10. Select and Enable authentication methods.
11. Start Partition-sensitive Subsystems.
There are many additional steps that can be followed to further customize the nodes, most
significantly setting up the switch. However, at this point of the installation, we now have all
the node and frame information in the SDR.

V3.0
Instructor Guide

Purpose — Have a look on entering data in SDR, which data is used by setup_server
script to generate NIM environment.
Details —
• Additional Information for the SP Frame Information: Enter your starting frame, the
number of frames you wish to define, and the starting tty port to use (each frame must
have a separate tty port into the CWS). Enter Yes in the Re-initialize the System Data
Repository option.
• Additional information for the SP Ethernet Information: There are a number of
ways of entering the node information: Start Frame, Start Slot, Node Count information,
Node Group, or Node List. In the foil, we have used the Start Frame, Start Slot, and
Node Count options to define a single-frame six-node machine.
The other fields of interest we changed are:
- Starting Node's en0 Hostname or IP Address - We have entered the first node's en0
IP address. PSSP will number the other nodes consecutively.
- Default Route Hostname or IP Address - We have given the en0 address of the
CWS, which will be used to create the default route on each node at customization.
- Skip IP Addresses for Unused Slots? As mentioned earlier, an SP node can take up
a single slot, but others can take two or four slots. PSSP numbers these nodes to
coincide with their starting slot number; so, answering Ye s to this option can be
useful if you are able to link an IP address to the node Number. For example, in the
5-node system we mentioned, if we skip IP addresses for unused slots and give our
first node an address of 129.1.11.101, node 3 would take the address 129.1.11.103,
node 5 would take 129.1.11.105, and so on. If we chose not to skip IP addresses,
node 3 would be assigned 129.1.11.102, node 5 would be 129.1.11.103, and so on.
• Additional information for the Get Hardware Ethernet Addresses operation: As
before, enter a start frame, start slot, node count option, node group, or node list.
Depending on the type of nodes you have and on how many nodes you perform this
action, you get the hardware Ethernet addresses back within a few minutes. This
should never be performed on a production SP because, in order to get these
addresses, the nodes are powered off/on and go partially through a network boot before
being powered off again.
There are many additional steps that can be followed to further customize the nodes, most
significantly setting up the switch. However, at this point of the installation, we now have all
the node and frame information in the SDR. The nodes default to the default mksysb and
lppsource we entered in the site environment information. They also default to install on
hdisk0 using the version of PSSP we installed on the CWS. We can change this
information with the spbootins or spchvgobj commands. We will see these operations on a
next foil, just after a SDR content checking.
Transition Statement — We see these operations on a next foil, just after a SDR content
check.
Instructor Guide
SDR - Display Node Information

{cws22} / #splstdata -f
List Frame Database Information
frame# tty s1_tty frame_type hardware_protocol
----------------------------------------------------------------------------------------------
1 /dev/tty0 "“ switch SP
{cws22} / #splstdata -n
List Node Configuration Information
node# frame# slot# slots initial_hostname reliable_hostname dce_hostname default_route processor_type processors_installed description
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 1 1 2 noded101 noded101 "" 1 29.1.11.22 MP 4 332_MHz_SMP_Wide
3 1 3 2 noded103 noded103 "" 129.1.11.22 MP 4 332_MHz_SMP_Wide
5 1 5 1 noded105 noded105 "" 129.1.11.22 MP 4 332_MHz_SMP_Thin
6 1 6 1 noded106 noded106 "" 129.1.11.22 MP 4 332_MHz_SMP_Thin
7 1 7 2 noded107 noded107 "" 129.1.11.22 MP 4 332_MHz_SMP_Wide
{cws22} / #splstdata -a
List LAN Database Information
node# adapt netaddr netmask hostname type rate enet_rate duplex other_addrs
--------------------------------------------------------------------------------------------------------------------------------------------------
1 css0 129.1.2.101 255.255.255.0 sw101 SP_Switch_MX NA NA NA ""
1 en0 129.1.11.101 255.255.255.0 noded101 bnc NA 10 half ""
7 en0 129.1.11.107 255.255.255.0 noded107 bnc NA 10 half "“
Figure A-11. SDR - Display Node Information AU086.0
Notes:
The splstdata command is an SP-specific command, which gives us the state of the
environment by interrogating the SDR; the command itself has many different switches
available to it that can list almost any detail of the SP.
• splstdata -f displays frame information, such as the frame number, the type of frame,
and the tty port it is attached to on the CWS.
• splstdata -n verifies that the node objects have been created and stored in the SDR,
and shows for each node, its physical references (node and frame number, number of
slots it occupies), hostname and default route ...
• splstdata -a will show for each adapter, the node number, adapter type, network
address, netmask, the hostname, and, if applicable, the type of physical connection and
the speed.

V3.0
Instructor Guide

Purpose — splstdata is one of the two commands we have to know (except smit) to
manage an SP installation. The second one is lsnim.
Details — All of this same information can be obtained through smit List Database panels.
The more useful splstdata options:
-n Displays information on the nodes
-s Displays the switch information from the SDR
-b Shows boot/install information (discussed on next foils)
-a Displays the SDR adapter information for the nodes
-v Displays the SDR volume group information for the nodes
-h Displays hardware data for each node by running the lscfg command remotely
-e Displays SP object attributes (Site Environment) and their values from the SDR
-f Displays frame information
-p Displays information about different SP partitions or just a single list if your SP is not
partitioned
Transition Statement — Now we have to see how to put in SDR what, how, who and so
on, we want to install.
Instructor Guide
SDR - Enter Data - Set Up Nodes to Be Installed
y# smit changevg_dialog 1
1
5
hdisk0
1
y# smit server_dialog
0
bos.obj.ssp.433
aix433
PSSP-3.2
1,3
Figure A-12. SDR - Enter Data - Set Up Nodes To Be Installed AU086.0
Notes:
smit changevg_dialog or spchvgobj command: This is an important command that is
used in conjunction with smit server_dialog (next step) in order to configure some other
booting options within the SDR, which is again used by setup_server when allocating
and/or building the resources for the node. Using this command, we can set which volume
group to install to, what disks to install to, the number of mirrors, whether quorum should be
on, the SPOT and lpp_source to use, what PSSP version to install, and a very important
information: the boot/install server to use for this node(s) installation. By default nodes use
node 0 (CWS).
At this point, we are still just configuring the data in the SDR; so, we still need to set the
nodes to install, run setup_server, and netboot them before they actually go ahead with the
installation.
smit server_dialog or spbootins command The spbootins command is used to enter
configuration or booting data for nodes into the SDR and, so, is normally used in
conjunction with spchvgobj. On the foil, we wanted to set only 2 nodes to install, using the
information relative to the object rootvg from SDR, and then let setup_server go ahead and
allocate the necessary resources.

V3.0
Instructor Guide

Purpose — Boot info information.
Details —
smit changevg_dialog or spchvgobj command: It is very useful to be aware of what this
command is capable of, because it could well save you a lot of manual node customization
later on.
smit server_dialog or spbootins command
• The response from server to bootp request field sets the bootp_response field (see
splstdata -b output on next foil)
nodes to the boot server:
- Install performs a network installation of AIX and a customization of the node.
- Migration performs an AIX and / or PSSP migration.
- Customization takes node-specific information from the SDR and puts it into the
node's local ODM.
- Disk instructs the server to ignore the bootp request. That is, the disk boots from its
internal disk.
- Maintenance has the node boot a maintenance kernel.
- Diag boots a node over the network in diagnostic mode.
• The field Volume Group Name specifies the SDR volume group object on which to
perform the operation.
• In the field Run setup_server we have a Yes/No choice to indicate Yes: setup-server
should be run now, using actual SDR information, No: we are only modifying SDR, and
for now we don't want to prepare the associated NIM environment. It is done later, with
the setup_server command, may be after last verifications.
Transition Statement — At this point, we are ready to run setup_server for the first time,
but before, just verify the information you've written in SDR.
Instructor Guide
SDR - Display Boot Information

{cws22} / #splstdata -b
List Node Boot/Install Information
node# hostname hdw_enet_adr srvr response install_disk last_install_image last_install_time next_install_image lppsource_name pssp_ver selected_vg
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 noded101 08005ABAE2C3 0 install hdisk0 bos.obj.ssp.433 Fri_Jul__6_12:49:50 bos.obj.ssp.433 aix433 PSSP-3.2 rootvg
3 noded103 0004AC712670 0 install hdisk0 initial "" bos.obj.ssp.433 aix433 PSSP-3.2 rootvg
5 noded105 08005ABAE661 0 disk hdisk0 bos.obj.ssp.433 Fri_Jul__6_12:50:12 bos.obj.ssp.433 aix433 PSSP-3.2 rootvg
6 noded106 08005ABAE9DF 0 disk hdisk0 initial "" bos.obj.ssp.433 aix433 PSSP-3.2 rootvg
7 noded107 08005ABAEAD4 0 disk hdisk0 bos.obj.ssp.433 Fri_Jul__6_16:03:08 bos.obj.ssp.433 aix433 PSSP-3.2 rootvg
Resources allocated by setup_server (next step) for different boot responses

bootp_response bosinst_data lpp_source mksysb spot pssplpp psspscript
install Y Y Y Y Y Y
migrate Y Y Y Y Y
customize Y Y
maintenance Y Y Y
diag Y Y
disk
Figure A-13. SDR - Display Boot Information AU086.0
Notes:
The splstdata command that proves most useful to us when looking at NIM is the splstdata
-b command. It is important to know how to interpret the output from this command since
setup_server uses the same SDR information to build and allocate NIM resources to the
clients as necessary.
Node The node number.
Hostname The node’s hostname (truncates if too long).
Hdw_enet_addr The node’s Ethernet MAC address.
Srvr The node’s Boot/Install server (0 indicates the CWS).
Response What the node does at next boot.
Install_disk hdisk to which to install.
Last_install_image mksysb resource that was previously installed.
Last_install_time Date and time of the last installation.
Next_install_image mksysb image to install at next netboot.
Lppsource_name The lppsource to use with the install.
Pssp_ver The pssp version currently installed or the one to migrate over to at
the next netboot.
Selected_vg The volume group to which to install.

V3.0
Instructor Guide

Purpose — Last verification before running setup_server.
Details — See student notes.
Transition Statement — What does setup_server, and how?
Instructor Guide
setup_server Wrappers
Check args
Read SDR
k4init/rcmdtgt
SDR setup_server NIM
Check prereqs
services_config
n
BIS ? delnimmast exit
CWS ?
n y
delnimmast mknimclient
y
setup_CWS
delnimclient mkconfig
mknimmast mkinstall
create_krb_files export_clients
mknimint allnimres
mknimres remove /tmp/tkt$ exit
Figure A-14. setup_server Wrappers AU086.0
Notes:
Installation process 3: Boot / install server configuration: setup_server The
setup_server command creates the NIM environment, the NIM resources, allocates NIM
resources to NIM clients inside the SP. When setup_server is run for the first time on a
CWS, all of these steps need to be performed. This can take up to one hour or more
depending on the CWS configuration and hardware environment. Creating the SPOTs
takes up the majority of this time.
When you run /usr/lpp/ssp/bin/setup_server to configure a boot/install server, it calls a
number of scripts and wrappers to perform the following tasks:
• Creates /tftpboot/node_name.install_info and /tftpboot/node_name.config_info for all its
client nodes
• Configures the server as a NIM master
• Defines among other items, the spot, mksysb, script, lppsource, bosinst NIM resources
• Defines nodes to be installed or booted in diagnostics or maintenance as NIM clients
• Allocates NIM resources to the NIM clients as needed

V3.0
Instructor Guide
Uempty • Copies the mksysb images (if any of its nodes need to be installed) to the boot/install
server that services the nodes.
• Creates required authentication files, Kerberos V4 keyfiles
• Executes the NIM bos_inst command which allocates the NIM boot and NIM script
resources, updating /etc/bootptab
Instructor Guide
Instructor Notes:
Purpose — Giving a listing of wrappers, have an idea about what is done.
Details — The main tasks performed by the setup_server command are setting up PSSP
services such as NTP, AMD and File Collections. This command ensures that the required
Kerberos files exist and then creates a list of known rcmd Principals. It creates the CWS as
a NIM master and gets information from the SDR to create the NIM environment including
network objects, NIM clients, SPOT and tftp boot images for the different platforms, and
stores them in the /tftpboot directory. These files are discussed later.
What are wrappers?
The PSSP uses a set of Perlscripts, called wrappers, to perform dedicated NIM
configuration tasks. This has the advantage that you do not have to perform each single
step during object definitions known from the original NIM operation. Instead, NIM can
easily be configured because most of the information it needs is already contained in the
System Data Repository (SDR) on the CWS. Even the existence of wrappers is shielded
most of the time when you are using the PSSP installation and maintenance mechanisms.
Use of these wrappers is optional; the installation and configuration commands use them to
do the necessary work when you perform the high-level functions.
NIM administration within the SP system means referring to the following wrappers located
in the /usr/lpp/ssp/bin directory:
allnimres Allocates NIM resources from a NIM master to a NIM client.
delnimclient Deletes a NIM client definition from a NIM master.
delnimmast Unconfigures a node as a NIM master.
mknimclient Makes a node a NIM client of its BIS.
mknimint Creates the necessary NIM interfaces on a NIM master.
mknimmast Configures a node as a NIM master.
mknimres Creates the necessary NIM resources on a NIM master.
unallnimres Deallocates NIM resources from a NIM master to one or more NIM clients.
Some wrappers are discussed with more details later in this unit.
Transition Statement — Now it is a good idea to have a look at what has been generated
by this script.

V3.0
Instructor Guide
Uempty
NIM Objects in an RS/6000 SP Environment
{cws22} / # lsnim
boot resources boot master
standalone
nim_script resources nim_script machines
diskless
spnet_en0 networks ent dataless...
psspscript resources script
prompt resources bosinst_data
noprompt resources bosinst_data ent,
migrate resources bosinst_data tok,
fddi, networks
lppsource_aix433 resources lpp_source
atm,
mksysb_1 resources mksysb generic
spot_aix433 resources spot
1_noprompt resources bosinst_data
1_migrate resources bosinst_data
mksysb_2 resources mksysb mksysb
script resources
noded101 machines stand-alone spot
noded103 machines stand-alone lppsource
noded105 machines stand-alone bosinst_data...
noded106 machines stand-alone
noded107 machines stand-alone
Figure A-15. NIM Objects in an RS/6000 SP Environment AU086.0
Notes:
As you know now, NIM needs information regarding the network, the machines (master,
client) and the resources (spot, lppsource, mksysb, bosinst_data, and so forth) to be
managed.
NIM organizes the install environment into object classes, object types, and object
attributes. There are three classes of objects and within each of the three classes, there
are object types:
• Machines with types master, stand-alone, diskless, dataless
• Networks with types ent, tok, Fiber Distributed Data Interface (FDDI)
• Resources with types files and directories such as lppsource, mksysb, script,
bosinst_data, spot
In the RS/6000 SP environment, all this information is stored in the System Data
Repository (SDR). The setup_server script uses the information stored in the SDR to
create the NIM environment.
Instructor Guide
Once setup_server creates the NIM objects, you can start the installation by using Node
Conditioning, but before doing that, it's more secure to have a look on setup_server results
with lsnim commands.
lsnim is still a very useful diagnostic tool within the SP environment and is, perhaps, the
very first command to use when looking at an SP NIM problem. Use this command to
check what objects have been defined, what resources have been allocated to machines, if
there is a problem with the Rstate, and so on.

V3.0
Instructor Guide

Purpose — Last verifications before initiating the effective node installation via network
boot.
Details — The NIM objects used in an SP environment are the same as in a classic
RS/6000 environment (it is, after all, the same version of NIM). The SP, however, has some
more rigid rules about what is and what is not supported. - Each node is defined as a
stand-alone machine; diskless or dataless nodes are not supported. - Nodes must be
installed over the SP's internal Ethernet network using the PULL mode. The boot of a node
over for example Token-Ring is not supported. - The resource objects remain the same,
though there are several scripts that are automatically allocated as resources when a node
is installed, which would normally be an option on a classic RS/6000 environment. - Finally,
the group resource is not used within the SP environment.
Transition Statement — More details on machine objects.
Instructor Guide
RS/6000 SP NIM Objects: Machines

master {cws22} / # lsnim -l master
master:
class = machines
type = master
comments = machine which controls the NIM environment
platform = rs6k
netboot_kernel = up
if1 = spnet_en0 cws22.pssc.mop.ibm.com 02070120E578
cable_type1 = N/A
clients Cstate
prev_state
= ready for a NIM operation
= ready for a NIM operation
Mstate = currently running
serves = 1_migrate
IBM
serves = 1_noprompt
serves = boot
serves = lppsource_aix433
serves = migrate
serves = mksysb_1
serves = mksysb_2
serves = nim_script
serves = noprompt
serves = prompt
serves = psspscript
{cws22} / # lsnim -l noded101
serves = spot_aix433
noded101:
...
class = machines
type = stand-alone
platform = chrp
netboot_kernel = mp
if1 = spnet_en0 noded101 08005ABAE2C3 ent
cable_type1 = bnc
Cstate = ready for a NIM operation
prev_state = in the process of booting
Mstate = not running
cpuid = 000523214C00
Cstate_result = success
Figure A-16. RS/6000 SP NIM Objects: Machines AU086.0
Notes:
Machine objects represent the machine configuration for a NIM client. Each machine object
contains attributes which define it. Examples of machine attributes are:
• Type of machine (stand-alone)
• Hardware address of the client's network installation interface (en0)
• TCP/IP host name of the client
• Name of the network object defining the network to which the client is connected
• Type of processor - Uniprocessor (UP) or Multiprocessor (MP).
mknimmast and mknimclients:
1. mknimmast
This wrapper initializes the NIM master. This is the first step for configuring a NIM
master. In order to configure the NIM master, the bos.sysmgt.nim.master and
bos.sysmgt.nim.spot filesets need to be installed. This wrapper is executed only on the
CWS and BIS as part of the setup_server script using information from the SDR to
configure the NIM master.

V3.0
Instructor Guide
Uempty 2. mknimclient
This wrapper takes input from the SDR to create the clients on the CWS and the BIS
that are configured as NIM masters. The SP node's reliable hostname configured in the
SDR is used as the NIM machine object name.
Instructor Guide
Instructor Notes:
Purpose — See the NIM machine (clients and master) objects generated by setup_server
in SP environment.
Details —
1. mknimmast
This script is called from setup_server, but can be run manually. Although there should
be only one NIM master per environment, the SP is somewhat of a special case. As far
as NIM is concerned, on the CWS, it only knows about the clients in its own database
and, thus, in a traditional NIM sense, has no knowledge or control over the nodes under
control of the other NIM masters - the boot/install servers. However, the SP has full
knowledge of its environment and its node from the data in the SDR, and, so, will simply
customize NIM the way the SDR dictates including configuring or unconfiguring other
NIM masters. In this way, the CWS still has full control over all the NIM clients, without
necessarily acting as the NIM master to all of them. There are some prerequisites that
must be met before the script configures the node as a NIM master:
- The node may not already be a NIM master.
- The node must be contactable via dsh.
- The node must be either the CWS or a BIS.
- The lppsource directory on the CWS must exist.
If the prerequisites are passed, the script will go ahead and mount the lppsource
directory from the CWS, if necessary, and install the NIM master filesets. It then
configures the master using nimconfig. This configures the master machine, the boot
and nim_script resources, and the network object. The network object is configured by
using the first active Ethernet interface detected on the node.
2. mknimclient
This script is called from setup_server, but can be run manually. There are a number of
prerequisites that must be met before a NIM client is created: The script checks that the
node and the node's BIS are valid SP nodes, that we have dsh access to the BIS (the
BIS is actually configured as a NIM master and has the appropriate filesets installed),
and that the client and BIS are on the same Ethernet subnet. If any one of these
conditions is not met, the node will be ignored, and processing continues on the next
one in the list. If the BIS is not the CWS, a route is added in to the BIS spnet NIM object;
so, it is able to reach the CWS. This is so the BIS can reach the NIM resources
available on the CWS.
Transition Statement — After machine objects, we can see NIM network objects.

V3.0
Instructor Guide
Uempty
RS/6000 SP NIM Objects: Network
{cws22} / # lsnim -l spnet_en0
spnet_en0:
class = networks
type = ent
Nstate = ready for use
network prev_state = information is missing from this object's definition
net_addr = 129.1.11.0
snm = 255.255.255.0
IBM
Figure A-17. RS/6000 SP NIM Objects: Network AU086.0
Notes:
A network object describes the network that can be used for the installation process.
Several networks objects can exist at the same time. Within the RS/6000 SP environment
the networks objects are named spnet_enX and are of the NIM object type of spnet. This
network object allows the installation of a node by use of the RS/6000 SP internal Ethernet.
Instructor Guide
Instructor Notes:
Purpose — See the NIM network object generated by setup_server in SP environment.
Details — Network objects represent information about the network interfaces required for
installing a client. The SP system uses the en0 Ethernet interface on the client for the NIM
installation. Although the SP System may support multiple Ethernet networks depending
upon the physical and defined subnets for your system, only the client's en0 interface is
supported for the NIM installation.
mknimint: This wrapper creates network objects on the NIM master to serve the NIM
clients. If there is more than one NIM master configured, mknimint creates network objects
to find the CWS. In cases where more than one NIM master is defined, dedicated nodes
become Boot/Install servers (BISs). The CWS remains as a resource center for other NIM
masters. Therefore, it is important to configure network paths for reaching the CWS. This is
the reason why the BIS, while executing mknimint, searches for network interfaces of the
CWS using the netstat command. To make sure that the BIS can reach every network
interface of the CWS, the route definitions must be in place.
Transition Statement — After machines and networks objects, we can see NIM resources
objects, and first the repository.

V3.0
Instructor Guide
Uempty
RS/6000 SP NIM Objects: Resources
/spdata/sys1/install
aix421 aix433 image pss pssplp

s p p
bos.obj.ssp.433 bosinst_data
lppsource spot lppsource spot bos.obj.ssp.421 pssp_script... PSSP-2.4 PSSP-3.2
noded103backup..
.
spot_aix421 spot_aix433
PSSP PSSP
AIX CD AIX CD CD CD
usr usr
{cws22} / # lsnim -c resources
boot resources boot

psspscript resources script
prompt resources bosinst_data
noprompt resources bosinst_data
migrate resources bosinst_data
mksysb_1 resources mksysb
mksysb_2 resources mksysb
1_noprompt resources bosinst_data
Figure A-18. RS/6000 SP NIM Objects: Resources AU086.0
Notes:
In an SP environment, for each AIX version, the following must exist:
1. an mksysb image:
All AIX mksysb images must be put in /spdata/sys1/install/images. The normal naming
convention for mksysb images is bos.obj.ssp.<aix version>. However, you can choose
your own name for the mksysb image. For multiple images, make sure the image name
is version-specific.
2. an lppsource:
A list of AIX filesets must be copied into the lppsource directory structure. This list is AIX
level dependant. It is possible to have multiple lpp_source objects. In other words, you
can have lpp_source objects according to the AIX version, for example, AIX 4.1, 4.2,
and 4.3. To distinguish these lpp_source objects, NIM uses a special naming
convention. It follows the scheme: lppsource_name where name is replaced by the
directory name.
3. and a corresponding spot
A SPOT resource contains basically all the files that are normally found in the /usr
filesystem. When you install new filesets in lppsource, you should then update the
Instructor Guide
corresponding SPOT. As with the lpp_source object, the NIM master can maintain
multiple spot objects. Each spot object corresponds to a different AIX version. To
distinguish these spot objects, NIM uses a special naming convention. It follows the
scheme: spot_name Where name is replaced by the lppsource_name directory.
All PSSP filesets must be copied in /spdata/sys1/install/pssplpp/<codeversion>, as shown
in the foil.
In preceding phases, the steps you have done for preparing this structure are:
• Create the /spdata filesystem
• Create lppsource and copied AIX filesets
• Copy the PSSP image
• Copy a basic AIX mksysb image
Then setup_server has created the corresponding spot directories (one for each AIX
lppsource), filled the pssp directory with bosinst_data, pssp-script files, more exactly, the
mknimres wrapper has done that. It has created all the NIM resources for installation,
diagnostics, migration and customization, depending SDR information. The resources
created will be used by the allnimres wrapper for allocation to the clients, depending on
the bootp_response field. When the mknimres command is executed the pssp_script file is
copied from the /usr/lpp/ssp/install/bin/pssp_script to the /spdata/sys 1/install/pssp
directory. This pssp_script is called by NIM after installation of a node and before NIM
reboots the node.

V3.0
Instructor Guide

Purpose —
Details — For the lppsource and PSSP filesets, the instructor must emphasize that it is not
a filesets installation. The appropriate filesets must be copied into the corresponding
directory.
Instructor Guide
RS/6000 SP NIM Objects: Resources
{cws22} / # lsnim -l mksysb_1 {cws22} / # lsnim -l noprompt

mksysb_1: noprompt:
class = resources class = resources
type = mksysb type = bosinst_data
Rstate = ready for use Rstate = ready for use
prev_state = unavailable for use prev_state = unavailable for use
location = /spdata/sys1/install/images/bos.obj.ssp.433 location = /spdata/sys1/install/pssp/bosinst_data
version =4 alloc_count =0
release =3 server = master
mod =3
alloc_count = 0
server = master
{cws22} / # lsnim -l lppsource_aix433 {cws22} / # lsnim -l spot_aix433

lppsource_aix433: spot_aix433:
class = resources class = resources
type = lpp_source type = spot
Rstate = ready for use Rstate = ready for use
prev_state = unavailable for use prev_state = verification is being performed
location = /spdata/sys1/install/aix433/lppsource location = /spdata/sys1/install/aix433/spot/spot_aix433/usr
simages = yes version =4
alloc_count =0 release =3
server = master mod =3
alloc_count =0
server = master
if_supported = chrp.mp ent
{cws22} / # lsnim -l psspscript Rstate_result = success
psspscript: mk_netboot = yes
class = resources mk_netboot = yes
type = script mk_netboot = yes
Rstate = ready for use plat_defined = chrp
prev_state = unavailable for use plat_defined = rs6k
location = /spdata/sys1/install/pssp/pssp_script plat_defined = rspc
alloc_count =0
server = master
Figure A-19. RS/6000 SP NIM Objects: Resources AU086.0
Notes:
The wrapper mknimres creates all the NIM resources for installation, diagnostics,
migration and customization. The resources created are used by the allnimres wrapper for
allocation to the clients, depending on the bootp_response field. When the mknimres
command is executed the pssp_script file is copied from the
/usr/lpp/ssp/install/bin/pssp_script to the /spdata/sys 1/install/pssp directory. This
pssp_script is called by NIM after installation of a node and before NIM reboots the node.
What is the lpp_source object?
This resource contains all AIX file sets used for NIM client installation. These file sets use
the AIX Backup File Format (BFF). Note, that PSSP file sets are not included in the AIX file
sets. The lpp_source object should only contain file sets belonging to the AIX itself. On the
NIM master, the lpp_source object file sets reside in the
/spdata/sys1/install/name/lppsource directory.
What is the spot object?
This resource contains the SPOT that is the essential NIM component involved in the
network installation process of the SP nodes. The SPOT is built using the file sets located

V3.0
Instructor Guide
Uempty in the lpp_source object directory for the specific AIX version. On the NIM master, the spot
object files reside in the /spdata/sys1/install/name/spot/spot_name directory. The spot
object is responsible for the creation of the network boot images (boot kernel) located in the
/tftpboot directory of the NIM master (see next foil).
What is the mksysb object? This resource contains the image to be installed on the
nodes. Along with the SP system, you get an spimg tape that contains the minimum BOS
filesets and PTFs in image file format. If you are not using this minimal image and want to
use the image you have created, then make sure that all the minimum PTFs are also
installed. This image is copied to the directory /spdata/sys1/install/images as part of the
installation steps.
What is the script object?
A script resource points to a program that you want to run on the NIM client after the
installation of the base operating system. You can use the script resource to perform any
additional tasks on the client that are not normally performed by NIM.
The customization of the SP nodes is performed by a Korn shell script called pssp_script.
This is used by NIM after a migration or installation of a node. setup_server defines this as
a NIM resource of the type script; therefore, it is run on the node before NIM reboots it, and
is also run on bootup if a node is set to customize in the SDR. During the customization
phase, pssp_script configures the node's environment based on the data in the two files in
the /tftpboot directory: <node>.config_info and <node>.install_info where <node> is the
hostname of the node in question. These two files are created by the setup_server
wrappers, mkconfig and mkinstall.
What is the bosinst_data object?
The less manual intervention is required, the quicker an installation will be. To this end, we
use a bosinst_data resource. This resource points to a preformatted file that specifies how
and where the BOS is to be installed on the client machine. The most important variable for
our purposes is the PROMPT variable in the control_flow stanza, which should be changed
to no for a non-prompted install.
• noprompt: Allocated when installing or migrating the node using full overwrite install
and you do not want the installation to prompt for any input on the console.
• prompt: Allocated when you want the node to prompt for the input from the console. It
is used to perform a maintenance or diagnostic mode of operation.
• migrate: Allocated when you want to perform a migration on the nodes to a newer
version of AIX.
Instructor Guide
Instructor Notes:
Purpose — Discuss lsnim -l outputs on the 5 NIM resources for an SP node.
Details — Additional information about pssp_script: Although the main function of
pssp_script is to install the PSSP software and configure it. The script has several more
notable functions. Among its extra tasks are configuring a separate dump logical volume,
updating the /etc/hosts file, and starting or stopping volume group mirroring.
The final part of node customization is performed after the node is rebooted.
As part of an installation or migration operation, pssp_script places an entry for a script
called spfbcheck in /etc/inittab. pssp_script copies this script, along with another called
psspfb_script from the directory /usr/lpp/ssp/install/bin on the BIS to the local /tftpboot di
rectory on the node.
On reboot, the /tftpboot/spfbcheck script is run, which renames the /tftpboot/psspfb_script
so that it is not run again accidently, and executes it. It then removes its own entry from
/etc/inittab to stop itself from being run on subsequent boots.
The main job of psspfb_script is to configure the network adapters that have previously
been defined in the SDR.
Once this has been done, the final stage is for the script to set the bootp response field of
the node back to disk in the SDR.
Transition Statement — Have a look now at info files and boot images.

V3.0
Instructor Guide
Uempty
NIM Environment - setup_server Results
{cws22} / # ls -l /tftpboot
firstboot.cust
script.cust
tuning.cust
...
spot_aix433.chrp.mp.ent
...
noded101 -> /tftpboot/spot_aix433.chrp.mp.ent
noded101.config_info
noded101.install_info
noded103 -> /tftpboot/spot_aix433.chrp.mp.ent
noded103.config_info
noded103.install_info
{cws22} / # tail /etc/bootptab

...
noded101:bf=/tftpboot/noded101:ip=129.1.11.101:ht=ethernet:ha=08005ABAE2C3:sa=129.1.11.22:sm
=255.255.255.0:
noded103:bf=/tftpboot/noded103:ip=129.1.11.103:ht=ethernet:ha=0004AC712670:sa=129.1.11.22:sm
=255.255.255.0:
Figure A-20. NIM environment - setup_server results AU086.0
Notes:
The spot object (preceding foil) is responsible for the creation of the network boot images
(boot kernel) located in the /tftpboot directory of the NIM master. These network boot
images follow the naming convention:
spot_name.platform.processor_architecture.network_adapter When an SP node is
installing, it transfers the network boot image matching its platform (platform), processor
architecture (processor_architecture), and network boot adapter (network_adapter) from
the NIM master using the Trivial File Transfer Protocol (TFTP).
The mkconfig wrapper creates the /tftpboot/<reliable_hostname>.config_info file, and
the mkinstall wrapper creates the corresponding install_info file for every node in the
SDR whose bootp_response is not set to disk. These two files are used during network
installation of the nodes by the pssp_script: - The config_info file exports all the required
environment variables during the installation phase. - The install_info file is taken for the
base configuration of the node.
Instructor Guide
The three files tuning.cust, script.cust and firstboot.cust are script files delivered with PSSP
product as samples and must be personalized to use them with efficiency. They are used
during node installation but they aren't managed by NIM directly.
/etc/bootptab file: An entry for nodes with SDR bootp_response field set to install is added
to the bootpd configuration file /etc/bootptab on the CWS.

V3.0
Instructor Guide

Purpose —
Details — Example of the config_info file:
©cws22¤ /tftpboot ¹ pg noded101.config_info
¹|/bin/ksh
export control_workstation="129.1.11.22"
export cw_hostaddr="129.1.11.22"
export cw_hostname="cws22.pssc.mop.ibm.com"
export server_addr="129.1.11.22"
export server_hostname="cws22.pssc.mop.ibm.com"
export rel_addr="129.1.11.101"
export rel_hostname="noded101"
export initial_hostname="noded101"
export netinst_boot_disk="hdisk0"
export netinst_bosobj="bos.obj.ssp.433"
export remove_image="false"
export sysman="true"
export code_version="PSSP-3.2"
export proctype="MP"
export lppsource_name="aix433"
export auth_ifs="cws22.pssc.mop.ibm.com/129.1.11.22"
export authent_server="ssp"
export cwsk4=""
export KF_PORT="32801"
export KF_TIMEOUT="150"
export sec_master=""
export sec_master_ip=""
export sec_master_short=""
export cds_server=""
export cds_server_ip=""
export cds_server_short=""
export node_syspar_name="cws22"
export node_syspar_ip="129.1.11.22,"
export node_syspar_short="cws22"
export lppsource_hostname="cws22.pssc.mop.ibm.com"
export lppsource_addr="129.1.11.22"
export platform="chrp"
export ssp_css="yes"
export ssp_jm="yes"
Instructor Guide
Example of the install_info file:

©cws22¤ /tftpboot ¹ pg noded101.config_info
1 noded101 129.1.11.101 129.1.11.21 0 1 5 3 2 yes rootvg true hdisk0 1 false
en0 129.1.11.101 255.255.255.0 NA bnc 10 half ""
css0 129.1.2.101 255.255.255.0 NA NA NA NA SP_Switch_MX_Adapter
When a node is installed, the three files tuning.cust, script.cust and firstboot.cust are
copied from server (generally the CWS) to the node and then they are executed on it:
Tuning.cust contains system performance tuning variable settings (no -o commands)
and will be executed on the node during each reboot.
Script.cust is a script in which you can put any command. It is executed during an
installation (before the node reboot) and during migration and customization phases.
Firstboot.cust is a script in which you can put any command. It is executed only one
time, during an installation on the first boot, and only here.
Transition Statement — Now how to initiate the node network boot?

V3.0
Instructor Guide
Uempty
Hardware Perspective GUI
Control WS cws22 Syspar cws22 System cws22
Figure A-21. Hardware Perspective GUI AU086.0
Notes:
PSSP offers two programs that assist in monitoring and administrating the SP system.
1. spmon is the older one that PSSP provides for monitoring and administering your SP
system. It is useful for quickly checking the status of the system, powering a node on or
off...
2. perspectives uses a Graphical User Interface (GUI) in order to provide a simple way of
performing some complex monitoring and administration tasks.
- Monitor and Control Hardware
- Create and Monitor System Events
- Define and manage Virtual Shared Disks (VSDs)
- Generate and save system partition configurations
- Set up performance monitoring hierarchies and archiving
Because we are concentrating on the configuration and management of NIM, the part of
perspectives that is of most use to us is called SP Hardware Perspective. Using Hardware
Perspectives, we can view a graphical representation of our full SP system, the LED
Instructor Guide
displays of the nodes if they are powered on, hardware status, and so on, thus, making
perspectives a valuable problem determination tool.
Netbooting: as we have already mentioned, one of the differences between SP nodes and
stand-alone RS/6000s is their physical attributes.
• Normally, to netboot an RS/6000or pSeries standalone system, we would turn a key
switch and go into SMS or use a ROM IPL disk, depending on the model.
• On the RS/6000 SP, this is all handled for us, thanks to our connection with the frame
supervisor card. In order to netboot a node, we simply need to click netboot on the
perspectives panel.

V3.0
Instructor Guide

Purpose — Just visualize the user interface with SP hardware.
Details —
Transition Statement — See the activated process on your network boot click.
Instructor Guide
NIM Install Flow: Pull Mode
nim -o bos_inst
1
bootpd 2 bootp request

/etc/bootptab
/tftpboot/node_name
spot file 3
NFS export
/mksysb
/bosinst_data 4 Execute
Script
/script
MASTER CLIENT
Figure A-22. NIM Install Flow: Pull Mode AU086.0
Notes:
When a node boots over the network,
• It issues a bootp request on that network specifying its network device hardware
address (for the RS/6000 SP, this is the node's en0 Ethernet). The boot/install server
has a list of nodes it boots and their associated hardware Ethernet addresses.
• The bootp daemon on the boot/install server gets the request and looks in its table
(/etc/bootptab) for this node's hardware Ethernet address. If it finds the address in its
table, it responds by sending the node's IP address.
• The node's IPL Read-Only Storage (ROS) requests a boot image transferred to the
node using tftp.
• The boot image is run, the rootvg gets created, and NIM performs the installation of the
mksysb image.
• After the mksysb installation is complete, NIM invokes the pssp_script script resource
which transfers the install information files from the boot/install server to the node and
performs the customization. These install files contain information necessary to

V3.0
Instructor Guide
Uempty successfully complete the netinstall, /tftpboot/node_name.install_info and

/tftpboot/node_name.config_info (used to define the adapters, set the hostname, define
the default route, and to customize the adapters with information such as host name
and default route).
• The PSSP file sets are installed if they are not already installed.
• As part of completing the network install, NIM modifies the boot/install server's
/etc/bootptab file so that the node does not perform a netinstall again on the next boot.
• PSSP changes the SDR node object bootp_response attribute to disk.
Instructor Guide
Instructor Notes:
Purpose — In final we install a node.
Keep in mind the only supported way to install the nodes is the use of the PULL mode.
Details — The process is already known (first units), but it would be an excellent step to
review the students knowledge. Remind them that the only supported method to install
nodes is the PULL mode.
Customization for Network Install: The customization of the SP nodes is performed by a
Korn shell script called pssp_script. This is used by NIM after a migration or installation of
a node. setup_server defines this as a NIM resource of the type script; therefore, it is run
on the node before NIM reboots it. pssp_script is also run on bootup if a node is set to
customize in the SDR. In order to detect this, the script, /etc/rc.sp, which is run from inittab,
checks the bootp response of the node in the SDR, and, if it is set to customize, spawns off
the pssp_script process.
pssp_script transfers the following netinstall information files from the boot/install server to
the node and then performs the customization. It is run under a single user environment
with the RAM file system in place. It installs the required LPPs and does the
post-installation setup. This script takes the input from the /tftpboot/<node>.config_info and
/tftpboot/<node>.install_info files
After customization, a bootable image is written to the node's disk. The node is then shut
down and rebooted. When it is rebooted, PSSP checks the SDR to determine if any of the
PSSP Site Environment options were chosen and configure it if selected.
Transition Statement — Just for information, look at what a node BIS.

V3.0
Instructor Guide
Uempty
Nodes as Boot/Install Servers
Subnet 2 Subnet 3 Subnet 4
BIS BIS BIS
Subnet 1
Control Workstation
Figure A-23. Nodes as Boot/Install Servers AU086.0
Notes:
By default, a single frame SP system configures the CWS as the only Boot/Install server
(BIS) - the NIM Master.
On a multiple frame SP system, by default, the CWS acts as the BIS for the first frame, and
then the first node in each additional frame is configured to act as a BIS for the rest of the
nodes in its own frame.
The reason for this is the bandwidth of the administrative Ethernet network. Though a limit
of thirty hosts per BNC segment exists, when netbooting multiple hosts over the same
physical network, it can become very congested and practically unusable. We recommend
a maximum netbooting limit of eight nodes simultaneously.
Instructor Guide
Instructor Notes:
Purpose — CWS and nodes are Boot/Install servers.
Details — As NIM installations utilize the network, the number of machines you can install
simultaneously depends on the throughput of your network (namely, Administrative
Ethernet). Other factors that can restrict the number of installations at a time are the disk
access throughput of the installation servers, and the processor types of your servers. To
overcome this bottleneck you can configure nodes in your SP as boot/install server so that
you get a hierarchy of installation servers. If your physical network structure supports such
a hierarchy, you can initiate an installation process in each of these trees. In this case more
nodes can be installed simultaneously than by using one flat network structure. A NIM
master makes use of the Network File System (NFS) utility to share resources with clients.
As such, all resources required by clients must be local file systems on the master.
As far as the SDR is concerned, a node is a BIS if another node is set to boot from it; so, it
need not be configured manually as a NIM master. You only have to change the field Boot
Install Server Node in the smit changevg_dialog panel (see SDR - Enter Data - Set Up
Nodes to be Installed foil).
Transition Statement — NIM helps us in the SP, environment for installation phase, and
also for maintenance and diagnostic operations.

V3.0
Instructor Guide
Uempty
Maintenance and Diag Modes
{cws22} / #splstdata -b -l 5
List Node Boot/Install Information
node# hostname hdw_enet_adr srvr response install_disk

-----------------------------------------------------------------------------------------------------------------------------------
5 noded105 08005ABAE661 0 maintenance hdisk0
Figure A-24. Maintenance and Diag Modes AU086.0
Notes:
Diag Mode:
Boot a node in diagnostic mode when you want to run diagnostics on any device, including
the hard disk attached to that node. When a node is booted in diagnostic mode, it brings up
the diagnostics menu just as if the diag command were issued from AIX. Because the
diagnostics are booted from the network and not the disk, the diagnostics against the hard
disk and disk adapters can be run.
Boot a node in diagnostic mode from the network if you suspect that there is a hard disk
problem so that diagnostics can be run against both the disk and disk adapters.
A tty console window in write mode gets opened for you so that you can continue with
running diagnostics after netboot has completed.
Instructor Guide
Maintenance Mode:
The maintenance boot option causes the node to boot a maintenance shell across the
network and open a tty console session in write mode. You should use this option when
you want to boot a node in single-user mode to perform system maintenance. The menu
that comes up is the same as would be seen on any AIX system that was booted from tape
or CD-ROM. This is a good starting point if you have a node that does not boot or has a
problem after booting. You can access the rootvg volume group to inspect and correct
system files such as /etc/inittab.

V3.0
Instructor Guide

Purpose — Explain to the students how to bring up a node in diagnostic mode without
using the hard disk, or in maintenance mode without having an AIX CD.
Details —
Diag Mode: This mode allows you to bring up your node in diagnostic mode. You have to
reboot it.
- Allocate SPOT
- Allocate bosinst_data
- Update /etc/inetd.conf
- Create <reliable_hostname>.install_info
- Create <reliable_hostname>.config_info
The difference between booting a node locally with the key in service position (service
mode) and booting from the network in diag mode is that in the first case, you are still
booting from your local disk and loading the diagnostic software from that disk, while in the
second case, the diagnostic software is mounted from the CWS to the node.
The diagnostic mode NFS mounts the SPOT from the boot/install server for use by the
diagnostic image running on the node. The advantage of network booting a diagnostic
image over the network is the ability to perform diagnostics on the hard disk. Because the
hard disk of the node is not used as the boot device, you can format, certify, diagnose or
download microcode to it.
Once diagnostics are completed, the nodes need to be set back to disk with setup_server
run to remove the appropriate entries from the /etc/booptab files and /tftpboot directory.
Then, power the nodes off and back on to get them booted in normal mode.
Maintenance Mode: This mode is useful when you encounter boot problems. You will get
a maintenance menu, from which you can initiate several actions. This mode also requires
a netboot.
- Allocate SPOT
- Allocate lpp_source
- Allocate bosinst_data
- Update /etc/inetd.conf
- Create <reliable_hostname>.install_info
- Create <reliable_hostname>.config_info
The process for going into maintenance mode is the same as any AIX system. For
example, if alternate boot disks were set up, when you ask to mount a rootvg it would
display both disks each as a separate volume group and ask you to select the desired
volume group to mount.
Transition Statement — Let's review what we have discussed about NIM in an RS/6000
SP environment.
Instructor Guide

V3.0
Instructor Guide
Uempty Checkpoint
NIM in a Cluster Environment

1. Which mode must be used for installation in an RS/6000 SP
environment?
a. Push
b. Pull
Answer: b
2. The setup_server script is used for:
a. Installing the nodes
b. Creating the /spdata structure
c. Creating and modifying the NIM environment in the CWS or in a
BIS
d. Building an mksysb of a node
Answer: c
3. Where are stored the information used to create and modify the
NIM environment?
a. In the /tftpboot directory
b. In the SDR
c. In the /etc/bootptab file
d. In the PSSP package
Answer: b
4. T / F The setup_server script is able to modify the attributes of
already created NIM objects.
Answer: False
5. In the following list, what are the resources types that are not part
of NIM environment in an RS/6000 SP?
a. bosinst_data
b. script
c. image_data
d. mksysb
e. spot
f. lpp_source
g. exclude_files
Answer: c, g
Instructor Guide
Unit Summary
zCluster definitions
–High-availability cluster
–High-performance computing
–Horizontal scaling cluster

zCluster 1600 interaction with NIM
zRS/6000 SP hardware components: CWS or MACN, frames,
nodes, switch...
zFour main tasks for an RS/6000 SP installation:
–Environment preparation on the Control WorkStation (CWS)
–System Data Repository setting (SDR)
–Boot install server configuration using setup_server script

–In final clients (nodes) installation
zRS/6000 SP NIM objects:
–Machines: master and stand-alone clients

–Network: ent type only
–Resources: script, bosinst_data, lpp_source, mksysb, spot
Figure A-25. Unit Summary AU086.0
Notes:

V3.0
Instructor Guide
Instructor Guide

V3.1.0.1
Instructor Guide
AP Appendix B. Change Bundle Location Script

##############################################################
# Usage: change_bundle_location #
# #
# Descr: This script will mv the installp_bundles generated during master #
# setup that are currently in the /export/installp_bundles directory #
# in rootvg to the /export/nim/installp_bundles directory in the #
# nimvg volume group, which is where all the other resources are. #
#############################################################
#!/usr/bin/ksh
mkdir /export/nim/installp_bundles
cp /export/installp_bundles/* /export/nim/installp_bundles
for bundle in $(lsnim -t installp_bundle | awk '{ print $1 }' )

do
nim -o remove $bundle
done
for f_bundle in $(ls /export/nim/installp_bundles )

do
bundle=$(echo $f_bundle | sed 's/\.bnd//' | sed 's/[+=.]/_/g')
nim -o define -t installp_bundle \
-a server=master \
-a location=/export/nim/installp_bundles/$f_bundle \
$bundle
done
rm -R /export/installp_bundles
© Copyright IBM Corp. 1996, 2005 Appendix B. Change Bundle Location Script B-1
Instructor Guide
B-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Appendix C. Command Line Introduction
Command Line Introduction

nimconfig Configures NIM master
Configures SSL
niminit Allows machine to join NIM network
nim Define/Change/List/Remove NIM objects

Perform NIM install activities
Other miscellaneous NIM activities
lsnim List NIM objects

Command line help
Listed above are the most common commands that you'll use in nim.
nimconfig - The nimconfig command is only used to initially configure the NIM master (yet
it doesn't construct the lpp_source or the spot) and to configure SSL.
niminit - This command is used to allow a pre-existing AIX machine to join the network
without having to install it. Notice that there are two ways to define a machine. 1) nim -o
define -t standalone ….." and 2) niminit. The first method is only used when you plan to do
an upcoming base install on an AIX machine in your network.
nim - This command does just about everything. We explore this command in more detail
on the following pages.
lsnim - lsnim is used to list objects in your network. It is also used to provide some quick
online help for the nim command.
© Copyright IBM Corp. 1996, 2005 Appendix C. Command Line Introduction C-1
Instructor Guide
nim Command Operation Codes – Object Definition

Define nim -o define -t <object_type> -a attr=value …object_name
Commonly Used types:
standalone (for client machines)
spot, lpp_source, mksysb, script
Change nim -o change -a attr=value….. object_name
Remove nim -o remove object_name
Examples: nim -o define -t standalone \

-a if1=’network1 myclient.my.com 10005aa925d ent0’ \
-a cable_type1=”N/A” -a platform=chrp \
-a netboot_kernel=mp -a connect=nimsh myclient
nim -o change -a connect=shell myclient

nim -o remove myclient
Define - The define command is simple. Once you've figured out what type of an object
you need to define (see the nim man page for help), merely issue the lsnim -q define -t
<typename> command. This shows you all of the attributes that are required and optional
for this type of definition. A good place to go with lots of good examples is the nim man
page. Look for the define operation code section.
Change - Merely change the attribute of interest. However, make sure the attribute listed
can be changed. Use the lsnim -q change <object name> command to see what attributes
are valid to use.
Remove - This is probably too simple. However, make sure the object is not in use or this
operation fails. For some resources you also have to physically remove the data.
C-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP
nim Command Operation Codes – Listing Operations
lslpp - Listing software at client or spot

showres - Shows contents of any Resource
fixquery - Shows fixes installed at client or spot

showlog - Shows recent install/boot activity of client/spot
Options lslpp_flags, installp_flags, instfix_flags

lsmksysb_flags, fix_query_flags
Examples nim -o lslpp myclient

nim -o showres -a instfix_flags=’-T’ mylpp_source
nim -o showlog -a log_type=bosinst myclient
The hardest part about using the listing utilities is knowing which one to use. Then, you
need to decide which operation codes to use (the commonly used ones for some of the
operation codes are shown). Again, use the lsnim -q <op_code> <object_name> command
to find out what options apply to your listing's operation code. Also, consider running the
appropriate listing in smit and then using the F6 key to identify the command really running
behind the scenes. Many of these commands are m_<cmd_name> commands that have
c_<cmd_name> shell scripts that perform the actual work. Investigating these shell scripts
shows you what options you need.
lslpp - This is handy for simple listings of what software is installed at a client or spot.
However, watch your lslpp_flags settings. The default lslpp_flags is -la. You also might
consider "-L" or "-La" or "-h" or "-f" and so forth to get different output. Refer to lslpp's man
page for help. By the way, make sure you don't include a space between the -a and
lslpp_flags or you get an error.
showres - This looks into just about any resource. For an lpp_source it lists the filesets
inside. With the -a instfix_flags="-T" option it lists the fixes inside the lpp_source. For a
spot, by default, it lists the software inside. For a mksysb, by default, it lists the filesets
inside. However, by using the lsmksysb_flags options you can get all kinds of interesting
listings. As you can see, this is a big topic. Hopefully the options shown in the last couple of
lectures are handy to refer to for common listings that you want.
Instructor Guide
fixquery - This is typically used to identify fixes installed on a client or spot. Use the
appropriate fix_query flag to get different output.
showlog - This is used to show recent installation activity on either a client or spot. The key
option is log_type. You can set this to bosinst, devinst, nimerr, niminst, script, and so forth
to view the different logs. The default log is niminst which shows recent software
installation and fix upgrade activities. (FYI - this command merely points to logs in your
client's /var/adm/ras directory).

V3.1.0.1
Instructor Guide
AP
nim Command Operation Codes – Client Install Management
bos_inst - Base Install or Ver/Rel Upgrade

-a installp_flags=’-acgdNX’
cust - Install Code, ML and fixes

-a installp_flags=’-agX’
maint - Remove/Commit/Reject
alt_disk_install - Alternate Disk Install
reset - Resets a client's Cstate back to "Ready"
deallocate - Deallocate resources from a client
Examples: nim -o bos_inst -a lpp_source=520ML1 \

-a spot=520ML1 -a accept_licenses=yes \
[-a no_client_boot=yes] myclient
nim -o cust -a lpp_source=530ML2 \

-a filesets=’bos.terminfo’ myclient
nim -Fo reset myclient
bos_inst - This does all base installs (including mksysb installs) and performs major
upgrades. Ver/Rel upgrades are achieved by setting bosinst_data's INSTALL_METHOD to
migrate. The installp_flags shown appear to be the default flags used for this command.
The no_client_boot option is whether or not a PUSH is done. View the nim man page for
additional help or view the lsnim -q bos_inst my_client_name command for valid options.
cust - This is used to apply software and fixes to a client or spot. The installp_flags shown
are apparently the defaults used. Again, use the lsnim -q cust my_client_name command
for help.
maint - This is used for removing software and applying and rejecting fixes for a client or
spot.
alt_disk_install - This is a way to do an ML upgrade on a client using the standard
alt_disk_install utility. Consider using the nimadm command instead for version or release
upgrades.
reset/deallocate - These are commonly used to reset a client that is hung on a particular
NIM activity.
Instructor Guide
nim Command Operation Codes – Resource Management
update - Adds/removes software/fixes from lpp_source

lppmgr - Cleans up lpp_source
check - Checks status of resource
cust - Installs software or fixes on spot

maint - Removes software/fixes from spot
allocate - Sometimes used to manually allocate resources to client

deallocate - Sometimes used to manually deallocate resources from
client
Examples: nim -o update -a packages=all \

-a source=/dev/cd0 lpp_source530ML1
nim -o cust -a fixes=update_all \

-a lpp_source=530ML1 spot530ML1
update - Used to add or remove packages from an lpp_source.

lppmgr - Used to clean up data inside an lpp_source.
check - Checks the current status of information inside a resource and sometimes
performs simple repair actions.
cust - Used to apply fixes, ML updates or just extra software in a spot.
maint - Used to reject/commit or remove software from a spot.
allocate/deallocate -Typically resources anymore are automatically allocated during
bos_inst/cust and so forth. However, there may be times where you want to control the
allocation or deallocation manually.

V3.1.0.1
Instructor Guide
AP
nim Command Operation Codes – Disaster Recovery
define - Creates mksysb backup

bos_inst - Restores mksysb backup
define - Creates savevg backup of user VG
restvg - Restores user VG backup
Examples: nim -o define -t mksysb -a server=master \

-a location=/export/nim/mksysb/clientA \
-a mk_image=yes -a source=clientA \
clientA_mksysb
nim -o bos_inst -a source=mksysb \

-a mksysb=clientA_mksysb \
-a spot=520ML1 [-a no_client_boot=yes] \
myclient
define - This is used to create a mksysb backup. The key attribute is mk_image. This
determines whether an actual backup is performed or not. The source attribute determines
which client to back up. You may need to remove a prior mksysb backup definition before
defining another mksysb backup the next night.
This can also be used to do a user VG backup. Information is similar. See nim's man page
for more information. The key difference between this and a mksysb definition is that the
type is savevg versus mksysb. Also, you have to supply the volume_group attribute.
bos_inst - This is used to restore a mksysb. Notice the source attribute. This shows you
that you're doing a mksysb install and not an RTE install. Another difference is that you
don't have to accept licenses.
restvg - This command is pretty simple. For example, you might use: nim -o restvg -a
savevg=uservg_clientA clientA. See the lsnim -q restvg -t standalone command for
possible attributes. Remember, the same rules apply with NIM for user VG restores as they
do for a native AIX machine. In other words, restvg presumes that the volume group has
been deleted at the client site before the restvg operation is performed.
Instructor Guide
nim Command Operation Codes – Client Diagnostics
maint_boot - Prepares client to perform stand-alone

maintenance
diag - Prepares client to perform stand-alone
diagnostics
Example: nim -o maint_boot -a spot=53ML2 myclient

Manually boot client from NIC using Service
bootlist
maint_boot - This enables a client to perform the equivalent of stand-alone maintenance

using an AIX mksysb resource. Make sure you reset your client when done.
diag - This is the same operation. This time, though, you load in stand-alone diagnostic
utilities.

V3.1.0.1
Instructor Guide
AP Appendix D. Configuring Multiple NICs with

nimadapters
nimadapters Concepts
1) Define adapter_def directory and define it to NIM as adapter_def resource.
3) # nimadapters -d -f /sourcedir/nimadapters.def
/export/nim/adapter_def
client1.adapters client2.adapters
2) vi /sourcedir/nimadapters.def
client1:
machine_type=secondary
subnet_mask=255.255.255.0 4) install client using
network_type=en adapter_def resource
cable_type=N/A
netaddr=192.168.0.10
{location=P2-I1/E1 |interface_name=en0}
media_speed=100_Half_Duplex
[secondary_hostname=client1_A]
client2:
machine_type=secondary
subnet_mask=255.255.255.0
....
nimadapters general concepts - The nimadapters command along with its configuration
file can help to automatically configure TCP/IP settings on your NIC adapters at your client
site for adapters that are not the original installation adapter. Remember, installation
adapters automatically get configured by internal NIM post customization scripts. The key
is to set up the configuration file shown for all secondary adapters for all clients. Notice
which fields are optional via the brackets. Then, when you feed this file into the
nimadapters command it generates a NIM configuration file for each client in a special
adapter_def directory that has already been set up. When the install occurs on the selected
client and the adapter_def resource is included on the install, then the appropriate client's
configuration file is looked at and the adapters inside are configured. This happens during
normal NIM internal post customization activities.
© Copyright IBM Corp. 1996, 2005 Appendix D. Configuring Multiple NICs with nimadapters D-1
Instructor Guide
Setting Up the adapter_def Directory

1. mkdir /export/nim/adapter_def
2. nim -o define -t adapter_def \

-a server=master \
-a location=/export/nim/adapter_def adapter_def
This is the first step in setting up your environment to handle the automatic install of
secondary client adapters. The adapter_def resource is a directory that contains all of your
client's secondary adapter configuration information. Later, when we go to install a client,
we refer to this adapter_def resource in order for NIM to configure the information inside for
your client.
D-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP
Creating the NIM Adapters Configuration Files
1. Edit Source File
vi /sourcedir/nimadapter.defs
2. Syntax Check the Source File

nimadapters -p -f /sourcedir/nimadapters.def adapter_def
3. Define Config File(s) in adapter_def directory

nimadapters -d -f /sourcedir/nimadapters.def adapter_def
4. View Client Config Files in /export/nim/adapter_def directory
Edit the Source File - Only put in the information you want. Refer to the first page of this
appendix to show which fields are required and which are optional. Create one stanza per
client. The stanza name should be the NIM name of the client. You can put multiple adapter
definitions per client inside this file.
Syntax Check the Source File - This makes sure you've included the right attributes and
there are no syntax errors. If errors exist, it tells you where they are.
Define Config File(s) in adapter_def directory - The -f attribute is your source file you
just created. The adapter_def is the name of an adapter_def resource that NIM already
knows about. NIM compiles your configuration information and places it into this
adapter_def directory.
View Client Config Files - You can view the configuration files in the
/export/nim/adapter_def directory, if desired.
Instructor Guide
Point NIM to This Information On Your Install

Command Line Only
Sample
nim -o bos_inst -a lpp_source=lpp_source530ML1 \
-a spot=spot530ML1-a accept_licenses=yes \
-a adapter_def=adapter_def client1
Use Command Line Attributes to Help Customize
Use lsnim for attribute help

(lsnim -q bos_inst client1)
Command Line Only - Unfortunately, using the adapter_def resource is available from the
command line only.
Sample - Notice the addition of the adapter_def resource. This causes NIM to look inside
this directory during post customization and TCP/IP configure the adapter information
inside your client's file.
Attributes - You need to supply the appropriate attributes in order to supply the information
you want on the bos_inst operation. The lsnim -q bos_inst <client name> command is
useful for identifying potential attributes. Also refer to nim's man page. Another area to go
to is looking in smitty nim_bosinst screen, pressing F6 and looking at which attributes were
chosen for all the fields you want to use.

V3.1.0.1
Instructor Guide
AP
Changing Hostname to Non-Install Adapter Hostname
Master’s Client1 -- Sys Hostname NICÆ World
Install NIC Install NIC
1) Repeat nimadapters procedure outlined earlier
2) Implement fb_script resource

chdev -l inet0 -a hostname=<secondary_hostname>
3) Install from Command Line

nim -o bos_inst -a lpp_source=lpp_source530ML1 \
-a spot=spot53ML1 -a fb_script=chg_hostname \
-a adapter_def=adapter_def -a accept_licenses=yes client1
1. Set up the adapter_def resource and run the nimadapters command as shown
previously in this appendix. Make sure the adapter you want to use is included in this
list.
2. Implement an fb_script that is run right after rebooting your client. At this time the
secondary adapter is already configured. We merely change the system's hostname to
point to it. Remember, changing a hostname can have wide implications. Check smitty
mkhostname panel out and also double check any other resource you have that may
depend on the hostname if changing this after the system has been up an operational
for awhile.
3. Install your client from the command line. Notice the adapter_def and fb_script that was
included on the command line to encompass the changes we want.
Instructor Guide

V3.1.0.1
Instructor Guide
AP Appendix E. Stand-alone Maintenance

Since you aren't backing up your mksysbs to tape or CD you probably don't have the code
necessary to do a stand-alone maintenance boot on your client. Remember, this is what
you need to use when your client won't boot at all. It allows you to go into single user mode
without having to use the normal boot image on disk.
To do this with NIM, you need to use your NIM master and it's SPOT. Refer to the following
directions to implement:
Preparing the Master:

1. # nim -o maint_boot -a spot=spot53ML2 myclient
Note: Make sure your spot is at the same release level and at least at the same fix level
as your client.
Preparing the Client:

1. Go to SMS, enter appropriate IPs and boot from your NIC (use the service boot)
2. Answer BOS Install Questions
a. 1 and Enter to use this as the console
b. 1 and Enter to use English during install
c. 1. Access a Rootvg Volume Group
d. 0. Continue at warning message
e. Choose the VG with hdisk0 in it.
f. Verify that this VG has hd5 on it.
g. Access the Volume Group and start a shell
(for just about every activity)
h. Set TERM variable.
Finishing Up at the Client:

1. # bootlist -m normal hdisk0
2. # shutdown -Fr
Finishing Up at the Master:

1. # nim -Fo reset myclient
© Copyright IBM Corp. 1996, 2005 Appendix E. Stand-alone Maintenance E-1

Instructor Guide
2. # nim -Fo deallocate -a subclass=all
E-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Appendix F. Implementing an Alternate NIM

Master
Purpose
To allow a different machine to take over the NIM environment as master if the original NIM
master is unable to do so.
Advantages
Traditionally, a takeover operation would require that the alternate machine have the same
IP address and hostname. If not, a comprehensive procedure in the online documentation
would have to be followed. With the alternate NIM Master takeover scenario, NIM works
well with an alternate machine that has a different IP and hostname.
Limitations
• All participating clients must be at AIX 5.3.
• It takes over the NIM Database and daemons only.
• Resources must all reside on remote NIM Servers.
Setup
At the Master:
Make sure the new alternate is not already a previous client to the NIM master.
• nim -o remove <client name of new alternate to be>
At the Alternate:
Give yourself NIM master code and register yourself as an alternate to the regular NIM
master. Note: at 5300-01, smit only seems to provide the shell communication protocol.
This is presumed to be in error.
• Install bos.sysmgt.nim.master
• smitty nimit_altmstr
This Machine Name: <alt_nim_name
_that_master_will_see>
© Copyright IBM Corp. 1996, 2005 Appendix F. Implementing an Alternate NIM Master F-1
Instructor Guide
Primary Network Install Interface: enX

Hostname of Master <hostname_of_master>
Hardware Platform Type <chrp or rspc>
Kernel to Use <mp or up>
Communication Protocol <shell or nimsh>
At the Master:
Register yourself as an alternate to the real alternate.
• smitty nimit_altmstr
This Machine Name: <master_desired_nim_name
_for_alternate_to_see>
Hostname of Master <hostname_of_alternate>
Communication Protocol <shell or nimsh>
At the Clients:
Re-register yourselves as a NIM client to the original master so that you now recognize the
new alternate. Note: lsnim -l <client> will show "sync_required=yes" until this is done.
• rm /etc/niminfo
• smitty niminit
This Machine Name: <client_nim_name>
Hostname of Master <hostname_of_master>
Communication Protocol <nimsh or rsh>
At the Master:
Synchronize the databases. This can be done inside smit or at the command line. The
force option is necessary because NIM is cautious. It sees the bos.sysmgt.nim.master
fileset on the proposed alternate master and doesn't know whether this is a real live NIM
master or not. This operation restores the NIM database onto the new alternate and start
up the nimesis daemon. It should only take a minute or so to run. Repeat this step anytime
you change your database at your master.
• nim -Fo sync alt_master_nim_name
• Repeat anytime you change your NIM master database.
F-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP At the Alternate:
Make sure you see the database entries from the master. Also, make sure you have your
nim daemon running.
• lsnim
• lssrc -g nim
Using the Alternate for NIM Takeover

At the Alternate:
Tell the clients (and NIM master if it's up) that you're taking over. Obviously this operation
can be done in smit or at the command line. This procedure only takes a couple of minutes
or so to accomplish for a reasonably small set of clients.
• nim -o takeover orig_master_nim_name_as_you_know_it
Using the Master to Re-Takeover When Ready

At the Master:
Tell the clients and NIM alternate that you're taking over. Obviously this operation can be
done in smit or at the command line. This procedure only takes a couple of minutes or so to
accomplish for a reasonably small set of clients.
• nim -o takeover alternate_nim_name
© Copyright IBM Corp. 1996, 2005 Appendix F. Implementing an Alternate NIM Master F-3
Instructor Guide
F-4 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Appendix G. Implementing nimsh with SSL
Purpose
Implementing SSL (with nimsh) allows communication between an initiating master and the
answering nimsh client to be encrypted.
Advantages
nimsh Advantages Over rsh
nimsh, even without SSL provides more security than rsh. This is because it only gives the
master access to client NIM tasks as opposed to total root authority to do anything on the
client system. Plus, using NIM with a receiving nimsh client daemon adds certain
restrictions that rsh didn't require. First, the master choosing to communicate with a nimsh
client daemon must have root authority at its originating site. Secondly the master must
supply the master's cpu_id and the client's cpu_id when requesting to perform a NIM task
at a client.
nimsh (SSL) Advantages Over Native nimsh
So, how does native nimsh fall short? Well, nimsh without SSL does not use encryption
and nimsh with SSL does. The encryption shields security-conscious information going
across the network. Plus, because nimsh with SSL uses certificates and keys, initiating
communication from a master to a nimsh client is much tougher to do. This is desirable
because hacker masters can cause a lot of destruction on a NIM client. For example, they
can reboot clients, install/de-install unauthorized code or even get the client in standalone
maintenance mode in order to gain blanket root authority.
SSL Implementation Used

NIM uses RSA keys with sha1 md5 1024-bit encryption by default. It also appears to utilize
X.509 extensions though the normal IBM cas.* filesets are not required. Certificates last for
one month.
Limitations
• NIM master must be at 5.3
• NIM clients must be at 5.3 and use nimsh.
• Certificates (and ideally passwords) need to be re-genned at least once per month.
• NIM uses somewhat of a pre-canned SSL implementation. Some of this is configurable
with changing the config files in the /ssl_nimsh/configs directory once initial setup is
© Copyright IBM Corp. 1996, 2005 Appendix G. Implementing nimsh with SSL G-1
Instructor Guide
made. Other changes may take a considerable amount of re-coding inside NIM's
makefile to accomplish and probably are not supported.
• SSL implementation only helps to secure master to client initiated communication. It
does not secure client to master initiated communication. This means it does not keep
unauthorized clients from becoming NIM clients and downloading unauthorized data
from the master. See smitty nim's other security environment options to secure this area
of interest.
Setup
At the Master:
The first step listed below installs openssl (on the AIX toolbox CD) and configures SSL at
the NIM master.
Note: this runs a make command to generate certificates, keys, and so forth and place
them in the newly generated /ssl_nimsh directory. It also puts a duplicate of the server.pem
file (to be downloaded by the clients) in the /tftpboot directory. Finally, it sets the
ssl_support attribute for the NIM master to yes. The second step edits those configuration
files and sets up an encrypted password. The third step regenerates all the keys,
certificates, and so forth, using the updated configuration files. At this point, we're ready to
transfer that /tftpboot/server.pem file to the clients.
1. smitty nim_ssl
Enable Cryptographic Authentication enable
Install Security Socket Layer Software (SSLv3)? yes
Absolute path location for RPM package /dev/cd0
OR-
lpp_source which contains RPM package: []
2.
a. cd /ssl_nimsh/configs
b. vi client.cnf
encrypt_key = yes
output_password = <password> (add this line in)
3. make -f /usr/samples/nim/ssl/SSL_Makefile.mk client
At each Client:
This step installs ssl, sets up the client to use nimsh communications (if not already set up),
and transfers the master's /tftpboot/server.pem file to the newly created client's
/ssl_nimsh/certs directory. It will also stopsrc and startsrc the nimsh daemon. Finally, it
changes the client's connect attribute on the master's lsnim command to nimsh (secure)
rather than just nimsh.
G-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Note the mistake on the smit panel that names the Media source line incorrectly.
1. smitty nim_config_services
* Communication Protocol used by client: nimsh
NIM Service Handler Options:
* Enable Cryptographic Authentication enable
for client communication
Install Secure Socket Layer Software (SSLv3)? yes

Install Secure Socket Layer Software (SSLv3)? /dev/cd0
OR-
lpp_source which contains RPM package: []
At the Master:
This step updates the NIM master facility so it is aware of the password that was set in the
above step. (Note: implementing passwords is optional. They are only used to work with
the master's client key. In fact, the whole topic of encrypting the client's key (in steps 2 and
3 above) and this step to decrypt it are meant to work together. Either the client's key is
encrypted and requires a password, or it's not.)
1. /usr/samples/nim/ssl/certpasswd
(enter in the new passwd as prompted to match the output_password password
set in step #2 above)
Verification
At the master:
1. lsnim -l master
Make sure you see: ssl_support = yes
2. lsnim -l <client>
Make sure you see: connect = nimsh (secure)
3. nim -o lslpp <client> | grep bos.rte.install
Make sure you see some output and no SSL errors.
Viewing a Certificate's Life

Certificates must be kept up to date to continue to use SSL with NIM. When viewing the
certificates below, note the Validity section at the top to see when the certificate's authority
starts and stops. It should be good for one month once generated with the make utility.
(Note: this 1 month period is non-negotiable within NIM's structure). If the certificates at the
Instructor Guide
client and master are no longer valid, then you have to regenerate new certificates and
keys. Refer to the Section below on Generating New Certificates and Keys.
At the Master:
1. /usr/samples/nim/ssl/certview /ssl_nimsh/certs/server.pem | more
Look for the Validity section at the top to see when the certificate's authority starts
and stops.
At the Client:
1. /usr/samples/nim/ssl/certview /ssl_nimsh/certs/<master_hostname>.0 | more
Generating New Certificates and Keys

Once done, the client's certificate will last another month.
At the master:
To generate the new certificates and keys.
At each client:
To transfer the new server.pem certificate down to the client's /ssl_nimsh/certs directory.
1. nimclient -c
Ongoing Change of the Password

Changing the password requires generating keys and certificates again. Hence, you might
consider doing this every month or so such that every time you have to generate new
certificates and keys you go ahead and update the password as well.
At the master:
To change the password and to generate the new certificates and keys.
1. vi /ssl_nimsh/configs/client.cnf
output_password = <new pass>
At each client:
To transfer the new server.pem certificate down to the client's /ssl_nimsh/certs directory.
1. nimclient -c
At the Master:
1. /usr/samples/nim/ssl/certpasswd
(enter in the same new passwd as above when prompted)

V3.1.0.1
Instructor Guide
AP Customizing SSL
You can change the server.cnf, client.cnf and root.cnf configuration files in the
/ssl_nimsh/configs directory to customize your NIM SSL implementation. You have to have
reasonable SSL skills in order to do this.
At the Master:
1. cd /ssl_nimsh/configs
2. vi client.cnf, server.cnf and/or root.cnf
At the Client:
1. nimclient -c
Disabling SSL
At the Master:
1. smitty nim_ssl
Choose to disable Cryptographic Authentication.
2. rm -R /tftpboot/server.pem
3. rm -R /ssl_nimsh
At the Client:
1. smitty nim_config_services
Choose to disable Cryptographic Authentication.
2. rm -R /ssl_nimsh
Instructor Guide
Normal Directory Structure Once Configuration is Complete

At master:
/tftpboot
|
server.pem
/ssl_nimsh
|
______________________________________________________________
| | |
certs configs keys
client.pem Makefile clientkey.pem
clientcert.pem client.cn f serverkey.pem
clientreq.pem server.cnf rootkey.pem
root.pem root.cnf
root.srl SSL_client.cnf
rootcert.pem SSL_server.cnf
rootreq.pem
server.pem
servercert.pem
serverreq.pem
At Client:
/ssl_nimsh
|
____________________________________
| | |
certs
master_hostname.0
(This is the /tftpboot/server.pem, which is the /ssl_nimsh/certs/server.pem file from the
master).
For More Information

1. Refer to IBM's infocenter Web site.
- Using NIM to Install Clients Configured with SSL Authentication
- NIM Service Handler for Client Communications

V3.1.0.1
Instructor Guide
AP - Certificate Viewing File

- Certificate Password Loading File
2. certview the /tftpboot/server.pem certificate.
3. View the /ssl_nimsh/configs configuration files to identify more low-level SSL
settings. (or view the /usr/samples/nim/ssl config files if SSL isn't yet setup).
4. See the /usr/samples/nim/ssl/SSL_makefile.mk makefile
5. See the openssl.1ssl man page (under /opt/freeware/man).
6. See the other openssl man pages.
Instructor Guide

V3.1.0.1
Instructor Guide
AP Appendix H. Getting Started Back Home

When returning home, you may have to implement your system from scratch. The following
steps show you a suggested series of basic steps to perform to get you started. You don't
have to follow these exact steps. However, they should be useful in helping you to identify
what basic types of activities are needed when you return home.
Upfront work:
1. Take an inventory to figure out what clients need what level of code.
2. Identify install media to handle those levels.
3. Figure out space needs at the master site. Review Unit 2 for help.
4. Make sure the chosen NIM master is secure.
5. Update the chosen NIM master to the latest level of code you plan to support.
6. Figure out where you want to place your nim data. Refer to Unit 2 for a suggested
plan. Also figure out naming schemes for at least your spots and lpp_sources at this
time.
7. Consider a backup policy to use on your NIM master. See the unit on Disaster Recovery
for additional help.
8. Set up a nimvg volume group to contain your nim data (optional).
9. Create an /export/nim filesystem on this VG to contain your nim data (optional).
Setting up the Master:

1. Install the bos.sysmgt.nim.master fileset on the master.
2. Figure out which interface you want to use as your master's primary install interface.
(You can add more later).
3. Set up your NIM master using smitty nim_config_env. Put an AIX install CD in your CD
drive. Make sure this is a level of code you plan to support. You can add other levels of
code later on. Refer to unit 2 for help on how to setup this screen.
4. Secure your NIM master with smitty nim_env_opts. Refer to unit 2 for help. You could
also implement SSL if desired.
5. Back up your NIM master as desired either at this time and/or after any of the additional
steps listed below.
© Copyright IBM Corp. 1996, 2005 Appendix H. Getting Started Back Home H-1
Instructor Guide
Setting up your Basic Resources:

1. At this point you probably need to add in more code into your lpp_source. Use NIM's
update utility to do this (smitty nim_update_add). If desired, add in all eight CDs and
later on clean out international language support with the smitty nim_lppmgr screen. Or,
you could choose the "q" (quit) option after just the 2nd or 3rd CD.
Note: if you're 5.2 or below, you may not have the option to add in all 8 CDs. You might
have to first bffcreate them to disk and then add them in.
2. Now, if needed, get your update CDs or downloaded Web code and use NIM's update
utility to add in all extra fix code. When done, use NIM's lppmgr facility to clean it up.
3. Use smitty nim_update_all to update your spot using the newly updated lpp_source.
Remember, not all code goes into a spot, so adding software is not needed. Just update
the spot to get the maintenance and fix updates in your lpp_source.
4. If necessary, define a new lpp_source and new spot to handle additional levels of code.
Refer to the LPP_SOURCE and SPOT Management lecture and lab for help here.
5. If desired, create a base bosinst_data resource for common RTE installs and mksysb
installs.
6. If desired, create a resolv_conf resource.
7. Consider running the change_bundle_location script in the appendix to put your
installp_bundles in the /export/nim directory versus their default location.
8. Other resources are typically optional. Set them up if desired.
Defining your Clients:

1. OK, you're now ready to start working with your clients. There are two ways to define a
client with NIM. You can define it at the master (smitty nim_mkmac) or you can initialize
it from the client (smitty niminit). The first method is used for clients you plan to install.
The second method is used for clients that are already up and running. You merely want
them to join your NIM network.
Before you define a client via either method make sure your master has their hostname
resolved. Refer to Base (RTE) Install unit for help here.
Installing Any Needed Clients from Scratch (optional):

1. Install any NIM client that you want. At the NIM master do smitty nim_bosinst. Make
sure you accept licenses and don't choose to reboot and initiate install now (since we're
assuming this is a brand new machine that isn't up and running yet). Then, if going with
the manual approach, go to the client's SMS menu and set up the IPs. Change the
install boot device (normal) to your NIC adapter. Exit SMS. This starts your boot.
H-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Back up your Client's rootvg Volume Group (optional):

1. You can only back up clients that are defined NIM clients. See the appropriate
procedure above to define you client if you haven't already done so.
2. Make a directory for your mksysb backups.
3. If desired, set up an exclude_files resource to use on the backup.
4. Use smitty nim_mkres to do your backup. Be sure to say you want to do a backup and
list your client's name.
5. Remember, you have to remove this object before doing another backup the next night.
6. See the unit on Disaster Recovery to see how to restore a client.
© Copyright IBM Corp. 1996, 2005 Appendix H. Getting Started Back Home H-3
Instructor Guide
H-4 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Appendix I. Checkpoint Solutions

Unit 1
1. True.
2. True. Much of the methods are similar. The biggest difference in
NIM is that it doesn't have a CD to use, so it compensates by using
NIM resources instead.
3. lsnim
4. True.
5. Push. However, this only works with AIX machines that are up and
running.
6. False. You must go to NIM's environment options at your NIM
master to adjust these security settings.
7. True.
Unit 2
1. An lpp_source probably takes up about 3 GB per level you plan to
support. The actual size depends on many factors. Your mksysb
backups also takes up a lot of space. Each backup take at least .5
GB (for just a native base install). SPOTs also take up about .5 GB
apiece. User VG backups take up a LOT of space if used.
2. False. They are placed in the rootvg volume group.
3. True.
4. Your AIX install CDs.
5. True.
Unit 3
1. True.
2. True. You also must make sure the client's install hostname is in
your hostname resolution database that the master accesses.
3. True.
4. False. You must also doublecheck the IP addresses of your client,
server and gateway.
© Copyright IBM Corp. 1996, 2005 Appendix I. Checkpoint Solutions I-1

Instructor Guide
5. False. If you didn't create a bosinst_data (or it has problems) you

have to answer the BOS install questions. Actually, common
problems can occur up until you've passed the BOS Install Screen.
6. lsnim -l <client_name>
Look at the Cstate field and info fields. There may also be an
info_err field that displays if there are problems.
Unit 4
1. True.
2. False. You also need to make sure the filesets listed inside the
bundle file are available in an accessible lpp_source.
3. True. You also have to answer those questions if you made an
error inside your bosinst.data file.
4. overwrite.
5. True. This of course assumes that you've set up these stanzas
correctly.
6. script, fb_script
7. True.
Unit 5
1. True.
2. True.
3. False. You must first look at the client's if1 attribute to find out what
network it is associated with. Then, look at the network's routing
attribute to figure out what the default router for that network is.
4. True.
5. True. NIM uses your client's definition and its network definition to
construct a script that runs after your base install goes down.
6. Bootp broadast
Faster Install
I-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
Instructor Guide
AP Unit 6
1. True
2. True, if done right. It also presumes that your AIX machine is up
and is already a NIM client.
3. True. It also requires that you have your client's install NIC's MAC
address defined in your client's definition at the master.
4. False.
5. True. If your client isn't up to receive a PUSH, then you have to
resort to a bootp broadcast or a manual client procedure when you
re-initiate your install operation.
Unit 7
1. True if using NIM to do your backup.
2. True.
3. True. Since your client is probably down, you probably can't get
away with doing a push.
4. False. Set it to yes to restore the previously defined devices and
TCP/IP settings.
5. overwrite.
6. False. NIM already handles this by using your client's definition and
network definition to construct an internal NIM script. This script
automatically runs during post customization.
7. True.
Unit 8
1. False. The NIM master must be at least at the same release level
as the SPOTs located there.
2. False. Always make sure your SPOT is at the same release level
and at least at the same fix level as the clients it serves.
3. True. Be sure to change it to ALL or list the packages if you plan to
create a non-simages lpp_source.
4. True.
5. True.
6. True.
7. check
© Copyright IBM Corp. 1996, 2005 Appendix I. Checkpoint Solutions I-3

Instructor Guide
Unit 9
1. True
2. True. The key difference is that your target is different.
3. False. Always keep your lpp_source and especially your spot at the
latest client level within the same release.
4. migrate
5. True
6. True. Use smitty nim at the client to access them.
Appendix A
1. b
2. c
3. b
4. False
5. c, g
I-4 Introduction to NIM © Copyright IBM Corp. 1996, 2005

V3.1.0.1
backpg
Back page
®

Au086inst PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Au086inst PDF

Hochgeladen von

Copyright:

Verfügbare Formate

V3.1.0.

Front cover

IBM Certified Course Material

September 2005 Edition

Instructor Course Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Unit 1. Introduction to NIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit 2. NIM Master Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

© Copyright IBM Corp. 1996, 2005 Contents iii

Unit 3. Base (RTE) Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit 4. Defining Additional Base Install Resources . . . . . . . . . . . . . . . . . . . . . . 4-1

iv Introduction to NIM © Copyright IBM Corp. 1996, 2005

TOC Resource Group Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36

Unit 5. Handling NIM Network Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit 6. Implementing an Advanced Base Install. . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit 7. Using NIM for Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

© Copyright IBM Corp. 1996, 2005 Contents v

User VG Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-32

Unit 8. LPP_SOURCE and SPOT Management . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Unit 9. Ongoing Client Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Appendix A. NIM in a Cluster Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B. Change Bundle Location Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Appendix C. Command Line Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

vi Introduction to NIM © Copyright IBM Corp. 1996, 2005

TOC Appendix D. Configuring Multiple NICs with nimadapters . . . . . . . . . . . . . . . . . . D-1

Appendix E. Stand-alone Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

Appendix F. Implementing an Alternate NIM Master. . . . . . . . . . . . . . . . . . . . . . . . F-1

Appendix G. Implementing nimsh with SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-1

Appendix H. Getting Started Back Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H-1

Appendix I. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1

© Copyright IBM Corp. 1996, 2005 Contents vii

viii Introduction to NIM © Copyright IBM Corp. 1996, 2005

© Copyright IBM Corp. 1996, 2005 Trademarks ix

x Introduction to NIM © Copyright IBM Corp. 1996, 2005

pref Instructor Course Overview

© Copyright IBM Corp. 1996, 2005 Instructor Course Overview xi

xii Introduction to NIM © Copyright IBM Corp. 1996, 2005

pref Course Description

© Copyright IBM Corp. 1996, 2005 Course Description xiii

• Define and utilize common NIM resources such as bosinst_data,

xiv Introduction to NIM © Copyright IBM Corp. 1996, 2005

© Copyright IBM Corp. 1996, 2005 Agenda xv

xvi Introduction to NIM © Copyright IBM Corp. 1996, 2005

Uempty Unit 1. Introduction to NIM

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

© Copyright IBM Corp. 1996, 2005 Unit 1. Introduction to NIM 1-1

© Copyright IBM Corporation 2005

Figure 1-1. Unit Objectives AU086.0

1-2 Introduction to NIM © Copyright IBM Corp. 1996, 2005

Uempty Instructor Notes:

© Copyright IBM Corp. 1996, 2005 Unit 1. Introduction to NIM 1-3

Network Installation Manager (NIM) Introduction

Base Install Disaster Recovery

Install Updates Diskless/Dataless

Figure 1-2. Network Installation Manager (NIM) Introduction AU086.0

1-4 Introduction to NIM © Copyright IBM Corp. 1996, 2005

Uempty Instructor Notes:

© Copyright IBM Corp. 1996, 2005 Unit 1. Introduction to NIM 1-5

Source Resources Installation Activity

Machine Firmware POST tests

CD Boot image Load boot image