Académique Documents
Professionnel Documents
Culture Documents
cover
AIX 5L Network
Installation Management
(NIM)
(Course Code AU08)
Instructor Guide
ERC 6.0
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.
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
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
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.
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
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.
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
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.
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
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
Unit Objectives
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
Notes:
AIX Only
Master
Client/Server
Client Client
(Resource)
© Copyright IBM Corporation 2005
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.
CD Installation Concepts
Upfront Intervention: Power On/Activate
Service Bootlist CD
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.
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.
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.
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
…
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.
SPOT
Directory of installed code used by client during installation process
<spotdir>
usr
/tftpboot
spot53ML1.chrp.mp.ent
spot52ML3.chrp.mp.ent
spot52ML1.rspc.up.tok
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.
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.
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.
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.
RTE MKSYSB
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.
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
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.
Master Client
Define Resources N/A
Base Install Base Install
Install Updates Install Updates
Force Push Disable Push
lsnim -l lpar1
control = master
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.
Security Considerations
•Any user can join your network
•Firewalls
–NFS shouldn't be used over a firewall
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.
•smitty eznim
•wsm
•scripts
–nim_setup_master
–nim_setup_client
–nim_update_all
•Command line
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.
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.
Introducing WSM
Network Installation Manager
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.
Example:
nim -o bos_inst -a spot=spot530 \
-a lpp_source=lpp_source530 \
lpar1
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.
Release Considerations
5.3 - nimsh
Alternate NIM master
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.
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
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.
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.
Correct Answer: True.
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.
Correct Answer: True.
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
Notes:
Instructor Notes:
Purpose —
Details —
Additional Information —
Transition Statement —
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 2. NIM Master Configuration 2-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Identify NIM master requirements
•Configure/unconfigure NIM master
•Set up important initial security options
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
3. .5 GB per spot
1 GB = spot520ML3, spot530ML1
10 GB = 10 client mksysbs
5 GB = Buffer
______
25 GB
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.
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now that we know the space required, let's look at a possible
disk layout.
Uempty
Possible NIM Master Disk Layout
rootvg nimvg
/export/nim
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's check out other guidelines in setting up your NIM master
before we actually set it up.
Uempty
Other Requirements for the NIM Master
No Official Guidelines
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — OK, let's get started with setting up our NIM master.
Uempty
Laying the Groundwork for Your NIM Master
• smitty install_latest
Network Installation Manager - Master Tools
(bos.sysmgt.nim.master)
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's look at a quick overview of what the NIM master
configuration process requires and what setup it accomplishes for us.
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?
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — We're ready now to configure your NIM master in SMIT.
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)
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's look at the rest of the fields on this screen.
Uempty
Setting Up Your NIM Master Using SMIT (2 of 2)
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"
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
# 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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
lsnim
Notes:
These are the objects that are generated from configuring your nim master. Not all
installp_bundles are shown.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
....
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.
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.
Additional Information —
Transition Statement — Let's review our lecture by doing a checkpoint activity.
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Checkpoint
Exercise -- Unit 2 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.
Correct Answer: True.
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.
Correct Answer: True.
Uempty
Unit Summary
Having completed this unit, you should be able to:
•Identify NIM master requirements
•Configure/unconfigure NIM master
•Set up important initial security options
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 2. NIM Master Configuration 2-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose —
Details —
Additional Information —
Transition Statement —
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 3. Base (RTE) Install 3-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Identify different RTE install parameters
•Define a client
•Set up master and client for install
•Initiate and monitor a base RTE install
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
/etc/bootptab
client:bf=/tftpboot/<client>
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
One Time
Ongoing
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define a Machine
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define a Machine
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.
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Uempty Transition Statement — Let's move on to step #2 -- setting up the master to install the
client.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 \
Uempty lpar1
Issue the lsnim -q bos_inst <client_name> command for quick help. See the nim manpage
for more thorough help.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's take a look at what we just generated.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see what else our operation affected.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now that the server side is ready to go, let's turn our attention to
the client side.
Uempty
Client Summary Setup
•Access console and SMS
–Setup IPs
–Exit out
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — To briefly summarize what is covered on the next several screens.
Details —
Additional Information —
Transition Statement — Let's first look at how to access our console and SMS in a
stand-alone arena.
Uempty
Stand-alone: Accessing SMS
Power On
IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see how to access SMS in an HMC/LPAR environment.
Uempty
HMC/LPAR: Accessing Your Partition
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now let's see how to access our partition's console.
Uempty
HMC/LPAR Opening Up Your Client’s Console
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-35
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now that we've identified our partition and opened up a console,
let's see how to access SMS.
Uempty
HMC/LPAR: Accessing SMS (1 of 2)
View Partition State
Shutdown if necessary
(Immediate)
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-37
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Uempty
HMC/LPAR: Accessing SMS (2 of 2)
Notes:
Choose SMS off of the boot mode field and press OK twice.
This should bring up your SMS main menu.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-39
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's take a look at our SMS main menu.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-41
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's take a look at the Remote IPL menu in order to set up our
IPs.
Uempty
Setting Your IPs (1 of 2)
NIC Adapters
Device Location Code Hardware Address
Network Parameters
Interpartition Logical LAN: U9111.520.100288E-V3-C2-T1
1. IP Parameters
2. Adapter Configuration
3. Ping Test
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-43
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's take option #1 - IP Parameters.
Uempty
Setting Your IPs (2 of 2)
IP Parameters
Interpartition Logical LAN: U9111.520.100288E-V3-C2-T1
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-45
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
Uempty
Setting Your Bootlist
Select Boot Options
1. Diskette
2. Tape
3. CD/DVD
4. IDE
5. Hard Disk
6. Network
7. List all Devices
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-47
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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 —
Additional Information —
Transition Statement — Now let's see how to choose the actual NIC adapter we want.
Uempty
HMC/LPAR: Setting Your Bootlist
Select Device
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-49
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — To show how to select the right NIC and select to use the normal bootlist.
Details —
Additional Information —
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.
Uempty
Starting Your Boot
1. Yes
2. No
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-51
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see what your initial output should look like.
Uempty
Initial Output
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-53
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see how to monitor the remainder of our installation.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-55
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — To show what to monitor during a typical install.
Details —
Additional Information —
Transition Statement — Let's review the important options on the Main BOS Installation
Menu.
Uempty
Main BOS Installation Menu
Notes:
It's typically a good idea to double check your settings before you start the install process.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-57
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — To show what to choose to double check our settings before we start the
install.
Details —
Additional Information —
Transition Statement — Now let's double check our settings.
Uempty
Installation and Settings Screen
1 System Settings:
Method of Installation.........................New and Complete Overwrite
Disk Where You Want to Install.................hdisk0
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-59
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's view the final client screen and how to monitor it.
Uempty
Monitoring the Rest of the Install
At the Client:
Installing Base Operating System
Please wait…
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
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-61
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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 —
Additional Information —
Transition Statement — Now let's see how to view the progress of your install once it has
completed.
Uempty
Showlog Screen
smitty nim (or nim_mac_op)
Perform NIM Administration Tasks
Manage Machines
Perform Operations on a Machine
Target: lpar1
Operation: showlog
Display Installation Log
OR
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-63
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's review this unit with a checkpoint activity.
Uempty Checkpoint
Exercise -- Unit 3 Checkpoint
1. T/F A native RTE install is similar to an AIX install from CD.
Correct Answer: True.
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.
Correct Answer: True.
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.
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-65
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
Having completed this unit, you should be able to:
•Identify different RTE install parameters
•Define a client
•Set up master and client for install
•Initiate and monitor a base RTE install
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 3. Base (RTE) Install 3-67
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 4. Defining Additional Base Install Resources 4-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•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:
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Resource Type
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define a Resource
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
installp_bundle ONE
I:bos.net.nfs.server SIMPLE CLIENT
R:openssl INSTALL
LPP_SOURCE
bos.net.nfs.server
openssl
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
2. vi /export/nim/installp_bundles/my.bnd
I:bos.net.nfs.server
R:openssl
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
1 System Settings:
Method of Installation................New and Complete Overwrite
Disk Where You Want to Install........hdisk0
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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>
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
3. cp <spotdir>/bosinst.data \
/export/nim/bosinst_data/bosinst_base_noprompt
4. vi /export/nim/bosinst_data/bosinst_base_noprompt
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.
Command Line - The equivalent NIM command for the above would be:
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
image_data use:
Mirroring rootvg
Change PP size
Shrink FSs
Change LV/FS policies
Other
Used a lot more for mksysb restores
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
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
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
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Use the lsnim -q define -t image_data command for more details or see the nim man
page.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
© Copyright IBM Corporation 2005
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.
Command Line - The equivalent NIM command for the above would be:
nim -o define -t script \
-a server=master \
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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.
Additional Information —
Transition Statement — Let's take a look at our last resource category -- resource groups.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-35
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Manual:
spot530
Install has problems
lpp_source520
bosinst_for_mksysb_install
Resource Group:
spot530
lpp_source530 Install works great
bosinst_for_base_RTE_install
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-37
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
Command Line - The equivalent NIM command for the above would be:
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.
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-39
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Checkpoint Questions
Exercise -- Unit 4 Checkpoint
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.
Correct Answer: True.
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.
Correct Answer: True.
Uempty
Unit Summary
Having completed this unit, you should be able to:
•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:
© Copyright IBM Corp. 1996, 2005 Unit 4. Defining Additional Base Install Resources 4-41
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose —
Details —
Additional Information —
Transition Statement —
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 5. Handling NIM Network Issues 5-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Identify NIM network concepts
•Identify how NIM network objects get setup
•Handle simple IP/host configuration during install
•Distribute resources on the network
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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-
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's look at a couple of NIM network object listings that would
match the above given scenario.
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
master: lpar10:
if1 = network1 nimsrv 26D780002002 if1 = network2 lpar10 0 ent0
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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 —
Additional Information —
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.
Uempty
Defining a Client on a Previously Defined Subnet
Define a Machine
Define a Machine
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
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now, let's see what happens when NIM defines a client on a
network that your NIM database does not yet recognize.
Uempty
Defining a Client on a New Network (1 of 2)
Define a Machine
Define a Machine
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
Uempty
Defining a Client on a New Network (2 of 2)
Define a Machine
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see how to define a network manually in case we ever need
to do so.
Uempty
Defining Networks Manually
smitty nim (or nim_mknet)
Perform NIM Administration Tasks
Manage Networks
Define a Network
Network Type
Define a Network
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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”.
Additional Information —
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.
Uempty
Client Install IP Configuration
Install Interface - NIM Internal
(From Client/Network Definition)
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
Uempty
fb_script IP Changes
Interface: chdev -l en1 -a netaddr=192.168.0.1 \
-a netmask=255.255.255.0 \
-a state=up
Additional
Static Routes: chdev -l inet0 -a .........
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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!!
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
Define A Resource
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
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
scripts SPOT
installp_bundles lpp_source
mksysb
Pro Con
Faster Install More Administration
Less Network Overhead
Can Use BOOTP Broadcast
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.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define A Resource
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 location=/export/nim/spot \
-a source=spot530 \
Uempty -a spot530_network2
See the "lsnim -q define -t spot" command or the nim man page for more details.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's review our work with some checkpoint questions.
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
Having completed this unit, you should be able to:
•Identify NIM network concepts
•Identify how NIM network objects get setup
•Handle simple IP/host configuration during install
•Distributed resources on the network
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 5. Handling NIM Network Issues 5-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 6. Implementing an Advanced Base Install 6-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Customize your install
•Automate your install
•Implement machine groups
•Reset the client after an installation failure
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's now see how we can automate our install using the PUSH
procedure.
Uempty
PUSH Automation Concepts
Master Client
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now that we can see how a PUSH conceptually works, let's see
how to physically use it during a normal install.
Uempty
Using a PUSH During a Client Install
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's look at how to install your clients using a machine group.
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
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
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — To show machine group concepts and how to define a machine group.
Details —
Additional Information —
Transition Statement — Let's see how we can use this machine group definition now on
performing a base install.
Uempty
Installing Your Machine Group
Choose the BOS Install Menu option at the Master:
Select a Target for the Operation
lpar1
lpar2
....
Atlanta_530_chrp_ent
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Command Line - The equivalent command for the above operation is:
nim -o bos_inst . . . \
-a concurrent=6 \
-a time_limit=5 \
Atlanta_530_chrp_ent
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
...
Target Result
lpar1 COMPLETE
lpar2 COMPLETE
...
lpar29 NOT_STARTED
lpar30 NOT_STARTED
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
•Hostname Mismatch
(Client Definition - DNS/Hosts_file)
•Network Overloaded
•NFS Settings
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Additional Information —
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.
Uempty
Resetting Your Client
smitty nim (or nim_mac_op)
Perform NIM Administration Tasks
Manage Machines
Perform Operations on Machines
lsnim -l <client>
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
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
Having completed this unit, you should be able to:
•Customize your install
•Automate your install
•Implement machine groups
•Reset the client after a failed installation
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 6. Implementing an Advanced Base Install 6-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 7. Using NIM for Disaster Recovery 7-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Use NIM to back up and restore your clients
•Implement a backup strategy for NIM data
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Master Client
restvg uservg
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define a Resource
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.
Command Line - The equivalent command for the above operation is:
nim -o define -t mksysb -a server=master -a location=/export/nim/mksysb/lpar1_mksysb \
-a mk_image=yes -a source=client1 lpar1_mksysb
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Notes:
Restoring your system is just like doing a base RTE install, except you now be choosing a
mksysb installation type instead.
Command Line - The equivalent command for the above operation is:
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Use Maps................................... No
2 Shrink Filesystems.............................. No
>>> Choice[0]: 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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
•Contents
/myfs
/hisfs
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
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Define a Resource
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see how to use a bosinst_data resource for a restore of a
mksysb backup.
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
© Copyright IBM Corporation 2005
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's look at some basic cloning issues that might affect our base
mksysb install.
Uempty
Using Your mksysb for Cloning - Basic
Client A mksysb Backup Client B
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now let's do some more advanced cloning.
Uempty
Using Your mksysb for Cloning - Advanced
Non-install IP/Hostname - Use fb_script or nimadapters/adapter_def
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
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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>.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
User VG Backup
Define a Resource
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
User VG Restore
Clean Up Volume Group:
reducevg -d -f vg_name
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-35
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's review our lecture material by doing a checkpoint activity.
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-37
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
Having completed this unit, you should be able to:
•Use NIM to back up and restore your clients
•Implement a backup strategy for NIM data
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 7. Using NIM for Disaster Recovery 7-39
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 8. LPP_SOURCE and SPOT Management 8-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Identify SPOT and lpp_source level issues
•List, create, and maintain lpp_sources
•List, create and maintain SPOTs
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
.....
bos.rte.devices 5.3.0.10 S b usr
# Base Device Drivers
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now let's see how to list fixes available in an lpp_source.
Uempty
LPP_SOURCE Management Techniques
+ + +
Optional Code
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Input:
LPP_SOURCE530
LPP_SOURCE53ML1
LPP_SOURCE53ML1_Fixes1
LPP_SOURCE5ML1_Fixes2
Output:
SPOT530 OR SPOT53ML1+Fixes1+Fixes2
SPOT53ML1
SPOT53ML1+Fixes1
SPOT53ML1+Fixes2
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Comments []
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.
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 \
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
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.
Additional Information —
Transition Statement — Sometimes it's handy to add in extra code or fixes into a
pre-existing lpp_source.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Updating an LPP_SOURCE
Original lpp_source --- subset of AIX install CD #1 only!
gencopy Flags
DIRECTORY for temporary storage during copying [/tmp]
EXTEND filesystems if space needed? yes +
Process multiple volumes? yes +
© Copyright IBM Corporation 2005
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.
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
Uempty
Adding Fixes to an LPP_SOURCE
/export/lpp_source/MLdir
/export/lpp_source/stagedir /export/lpp_source/stagedir
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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 -
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Removing an LPP_SOURCE
smitty nim (or nim_rmres)
Perform NIM Administration Tasks
Manage Resources
Remove a Resource
Choose an LPP_SOURCE
Remove a Resource
Notes:
This removes the NIM database entry and the actual data.
Command Line - The equivalent command for the above operation is:
nim -o remove lpp_source530
Make sure the lpp_source is not in use at the time or this operation fails.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
* Target spot530
* Software Names [all] +
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-35
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
* Target spot530
* Fix ID [] +
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-37
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 \
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-39
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now let's see how to update a SPOT.
Uempty
Updating SPOT Procedures
smitty nim
Perform Software Installation and Maintenance Tasks
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-41
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's now take a look at the most common operation you'll
perform - an update all.
Uempty
Performing an Update All on Your SPOT
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] +
ACCEPT new license agreements? [no] +
(AIX V5 and higher machines and resources)
Preview new LICENSE agreements? [no] +
....
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
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-43
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Alright, now let's remove a SPOT.
Uempty
Removing a SPOT
smitty nim (or nim_rmres)
Perform NIM Administration Tasks
Manage Resources
Remove a Resource
Choose your SPOT
Remove a Resource
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-45
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's now view one last operation that may come in handy in
maintaining your spots and lpp_sources - the check operation.
Uempty
Checking a Resource
nim -o check lpp_source530 nim -o check spot530
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-47
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — OK, now let's put this all together to solve some real-world
problems.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-49
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see first how to create your baseline 530 resources.
Uempty
Handling New Releases
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.)
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-51
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now let's see what steps are required to handle an ML update.
Uempty
Handling New ML Updates
stagedir
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.)
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-53
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Uempty
Handling New Fix Updates
stagedir
lpp_source_fix1 SPOT530ML1
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.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-55
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's complete this unit now with our checkpoint exercise.
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-57
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
Having completed this unit, you should be able to:
•Identify SPOT and lpp_source level issues
•Create and maintain lpp_sources
•Create and maintain SPOTs
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 8. LPP_SOURCE and SPOT Management 8-59
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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 (Redbook)
AIX Version 4.3 to 5L Migration Guide (Redbook)
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Objectives
After completing this unit, you should be able to:
•Add software to the client
•Upgrade the client
•Perform an alternate disk install
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
* Target lpar1
* Software Names [all] +
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
* Target lpar1
* Fix ID [] +
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Install Software
* Installation Target lpar1
* LPP_SOURCE lpp_source530
Software to Install [Java14.sdk] +
Customization SCRIPT to run after installation [] +
(not applicable to SPOTs)
Force no +
installp Flags
PREVIEW only? [no] +
COMMIT software updates? [yes] +
SAVE replaced files? [no] +
AUTOMATICALLY install requisite software? [yes] +
EXTEND filesystems if space needed? [yes] +
OVERWRITE same or newer versions? [no] +
VERIFY install and check file sizes? [yes] +
ACCEPT new license agreements? [yes] +
(AIX V5 and higher machines and resources)
Preview new LICENSE agreements? [no] +
....
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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:
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
Additional Information —
Transition Statement — Now let's see how to update your client with all fixes in an
lpp_source.
Uempty
Updating Installed Software to Latest Level
smitty nim (or nim_update_all)
Perform NIM Software Installation and Maintenance Tasks
Install and Update Software
Update Installed Software to Latest Level (Update All)
Select the Client
Select the lpp_source
Update Installed Software to Latest Level (Update All)
* Installation Target lpar1
* LPP_SOURCE lpp_source530ML2
Software to Install update_all
Customization SCRIPT to run after installation [rebootit] +
(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] +
ACCEPT new license agreements? [no] +
(AIX V5 and higher machines and resources)
Preview new LICENSE agreements? [no] +
....
Good for ML updates
Update your lpp_source and SPOT too!!
Update Master as well
© Copyright IBM Corporation 2005
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" \
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Handling Version or Release upgrades requires a special
procedure. Let's take a look at that now.
Uempty
Handling Version/Release Updates
•Update Master
•At Client: Run the pre_migration script from the master's NFS mounted
SPOT
•At Client: Run the post_migration script from the client’s /usr/lpp/bos
directory
© Copyright IBM Corporation 2005
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
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
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
Reinstall the Base Operating System
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.
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Checkpoint Questions
Exercise -- Unit 9 Checkpoint
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.
Uempty
Unit Summary
Having completed this unit, you should be able to:
•Add software to the client
•Upgrade the client
•Perform an alternate disk install
Notes:
© Copyright IBM Corp. 1996, 2005 Unit 9. Ongoing Client Updates 9-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose —
Details —
Additional Information —
Transition Statement —
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
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
Notes:
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-9
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Instructor Notes:
Purpose — Describe a Cluster 1600 environment.
Details —
Additional Information —
Transition Statement — Let’s see how this environment helps us with the setup and
usage of NIM.
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
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-11
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-13
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-15
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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)
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-17
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Let's see the two configurations managed by the couple CWS /
PSSP: The RS/6000 SP configuration and the Cluster Enterprise Server.
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
Ethernet
SP-Attached H and M Series
Functionallyequivalent to S Series Cluster RS232
support
Up to 32 systems may be attached
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-19
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-21
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — IBM continues to follow this strategy, let us see the new (2000)
Cluster Enterprise Server strategy.
Uempty
RS/6000 SP Overview - Cluster Enterprise Server
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-23
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-25
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-27
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
install
bos.obj.ssp.433
lppsource lppsource bos.obj.ssp.421 PSSP-2.4 PSSP-3.2
noded103backup..
.
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.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-29
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
Uempty
SDR - Enter Data - SP Ethernet Definition
1
5
129.1.11.101
129.1.11.22
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-31
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-33
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
{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 ""
3 css0 129.1.2.103 255.255.255.0 sw103 SP_Switch_MX NA NA NA ""
5 css0 129.1.2.105 255.255.255.0 sw105 SP_Switch_MX NA NA NA ""
6 css0 129.1.2.106 255.255.255.0 sw106 SP_Switch_MX NA NA NA ""
7 css0 129.1.2.107 255.255.255.0 sw107 SP_Switch_MX NA NA NA ""
1 en0 129.1.11.101 255.255.255.0 noded101 bnc NA 10 half ""
3 en0 129.1.11.103 255.255.255.0 noded103 bnc NA 10 half ""
5 en0 129.1.11.105 255.255.255.0 noded105 bnc NA 10 half ""
6 en0 129.1.11.106 255.255.255.0 noded106 bnc NA 10 half ""
7 en0 129.1.11.107 255.255.255.0 noded107 bnc NA 10 half "“
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-35
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
y# smit changevg_dialog 1
1
5
hdisk0
1
y# smit server_dialog
0
bos.obj.ssp.433
aix433
PSSP-3.2
1,3
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-37
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
install Y Y Y Y Y Y
migrate Y Y Y Y Y
customize Y Y
maintenance Y Y Y
diag Y Y
disk
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-39
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-41
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Now it is a good idea to have a look at what has been generated
by this script.
Uempty
NIM Objects in an RS/6000 SP Environment
{cws22} / # lsnim
master machines master
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
© Copyright IBM Corporation 2005
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-43
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-45
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
© Copyright IBM Corporation 2005
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.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-47
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — After machine objects, we can see NIM network objects.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-49
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — After machines and networks objects, we can see NIM resources
objects, and first the repository.
Uempty
RS/6000 SP NIM Objects: Resources
/spdata/sys1/install
spot_aix421 spot_aix433
PSSP PSSP
AIX CD AIX CD CD CD
usr usr
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-51
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-53
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-55
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
Transition Statement — Have a look now at info files and boot images.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-57
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-59
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Uempty
Hardware Perspective GUI
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-61
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-63
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
nim -o bos_inst
1
NFS export
/mksysb
/bosinst_data 4 Execute
Script
/script
MASTER CLIENT
© Copyright IBM Corporation 2005
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
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-65
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
Additional Information —
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.
Uempty
Nodes as Boot/Install Servers
Subnet 2 Subnet 3 Subnet 4
Subnet 1
Control Workstation
© Copyright IBM Corporation 2005
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-67
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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).
Additional Information —
Transition Statement — NIM helps us in the SP, environment for installation phase, and
also for maintenance and diagnostic operations.
Uempty
Maintenance and Diag Modes
{cws22} / #splstdata -b -l 5
List Node Boot/Install Information
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-69
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-71
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Uempty Checkpoint
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-73
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Unit Summary
zCluster definitions
–High-availability cluster
–High-performance computing
nodes, switch...
zFour main tasks for an RS/6000 SP installation:
Notes:
© Copyright IBM Corp. 1996, 2005 Appendix A. NIM in a Cluster Environment A-75
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
#!/usr/bin/ksh
mkdir /export/nim/installp_bundles
cp /export/installp_bundles/* /export/nim/installp_bundles
rm -R /export/installp_bundles
© Copyright IBM Corp. 1996, 2005 Appendix B. Change Bundle Location Script B-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
AP
nim Command Operation Codes – Listing Operations
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.
© Copyright IBM Corp. 1996, 2005 Appendix C. Command Line Introduction C-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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).
AP
nim Command Operation Codes – Client Install Management
maint - Remove/Commit/Reject
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.
© Copyright IBM Corp. 1996, 2005 Appendix C. Command Line Introduction C-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
AP
nim Command Operation Codes – Disaster Recovery
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.
© Copyright IBM Corp. 1996, 2005 Appendix C. Command Line Introduction C-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
....
© Copyright IBM Corporation 2005
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
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
AP
Creating the NIM Adapters Configuration Files
1. Edit Source File
vi /sourcedir/nimadapter.defs
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.
© Copyright IBM Corp. 1996, 2005 Appendix D. Configuring Multiple NICs with nimadapters D-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
Sample
nim -o bos_inst -a lpp_source=lpp_source530ML1 \
-a spot=spot530ML1-a accept_licenses=yes \
-a adapter_def=adapter_def 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.
AP
Changing Hostname to Non-Install Adapter Hostname
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.
© Copyright IBM Corp. 1996, 2005 Appendix D. Configuring Multiple NICs with nimadapters D-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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>
Primary Network Install Interface: enX
Hostname of Master <hostname_of_alternate>
Hardware Platform Type <chrp or rspc>
Kernel to Use <mp or up>
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>
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 <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.
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
© Copyright IBM Corp. 1996, 2005 Appendix F. Implementing an Alternate NIM Master F-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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.
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
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.
© Copyright IBM Corp. 1996, 2005 Appendix G. Implementing nimsh with SSL G-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
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
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
3. make -f /usr/samples/nim/ssl/SSL_Makefile.mk client
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
© Copyright IBM Corp. 1996, 2005 Appendix G. Implementing nimsh with SSL G-5
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
______________________________________________________________
| | |
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).
© Copyright IBM Corp. 1996, 2005 Appendix G. Implementing nimsh with SSL G-7
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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).
© Copyright IBM Corp. 1996, 2005 Appendix H. Getting Started Back Home H-1
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
© Copyright IBM Corp. 1996, 2005 Appendix H. Getting Started Back Home H-3
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Instructor Guide
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.
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
Less Network Overhead
Faster Install
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
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
backpg
Back page
®