Prior to AIX 5.3 TL7 and AIX 6.1, there was an 8 character limit on AIX user passwords. If you need passwords of greater than 8 characters then you must enable one of the supplied Loadable Password Algorithms (LPAs). The following table lists the available algorithms and the limitations of each:

 

 

For example, to enable the MD5 algorithm I can modify /etc/security/login.cfg file with the chsec command as follows:

 

# chsec -f /etc/security/login.cfg -s usw -a pwd_algorithm=smd5

 

# tail -2 /etc/security/login.cfg

        pwd_algorithm = smd5

 

This algorithm (smd5) will allow a password limit of 255 characters. Each of the available algorithms is listed in the /etc/security/pwdalg.cfg file.

 

# head -50  /etc/security/pwdalg.cfg

*******************************************************************************

*

* Loadable Password Algorithm (LPA)

*

* The format of a LPA stanza is:

*

* lpa:

*       lpa_module = /any/program

*       lpa_options = options_list

*

* lpa           Corresponds to a password hashing algorithm that can be

*               specified in the "usw" stanza of /etc/security/login.cfg

*               as the system-wide password hashing algorithm.

*

* lpa_module    Specifies the path of the password hashing load module.

*               In the above example, /any/program is the path to the load

*               module that is used to do the password hashing in 32 bit

*               mode. The load module that is used to run in 64 bit mode

*               is /any/program_64.

*

* lpa_options   Is an optional attribute that provides a means of

*               communicating run-time configuration options to the load

*               module. The value is a comma separated list of items.

*               Please refer to the documentation for the load module for

*               appropriate values.

*

*******************************************************************************

*

* /usr/lib/security/smd5 is a password hashing load module using

* the MD5 algorithm.

*

* It supports password length up to 255 characters.

*

* To generate smd5 password hash compatible to standard salted MD5,

* add the following option line for smd5 stanza.

*       lpa_options = std_hash=true

*

* Note : password hash generated with this option won't be compatible with

* hash generated without this option.

*

*******************************************************************************

smd5:

        lpa_module = /usr/lib/security/smd5

 

*******************************************************************************

*

* /usr/lib/security/ssha is a password hashing load module using SHA and

* SHA2 algorithms. It supports password length up to 255 characters.

*

* This LPA accepts three options. The options are separated by commas.

...etc...

 

 

Once you’ve enabled the LPA of your choice, and you set/change a users’ password, you’ll notice that the /etc/security/passwd stanza for that user will look different when compared to the stanzas of users that have not had their password set/changed using the new LPA:

 

fred:

        password = E7nOaTrrz9Q16

        lastupdate = 1330986703

        flags = ADMCHG

 

joe:

        password = {smd5}z9JrHDJB$Oq/cZXr0jUyAWvfFyjt161

        lastupdate = 1330987903

        flags = ADMCHG

 

 

 

In the example above, user joe’s password has been set using the smd5 algorithm.

 

For those of you who run PowerHA (HACMP) and are thinking about using one of the LPAs with the clpasswd utility, you may want to review this APAR first:

 

IZ40362: HACMP PASSWD UTILITY FAILS WHEN LONG PASSWD ALGORITHM IS ENABLED

https://www-304.ibm.com/support/docview.wss?uid=isg1IZ40362

 

The APAR states “HACMP cluster-wide C-SPOC password administration does not support use of the feature allowing passwords longer than 8 characters which became available with the Loadable Password Algorithm as part of AIX 53 TL 7.”

 

The last time I tested this with PowerHA, the problem was that the password entry in /etc/security/passwd was corrupted/truncated when a users password was changed using the clpasswd utility.

 

For example, if the passwd utility is linked to clpasswd and I changed a users password, the password field appeared to be corrupted/truncated and the user could not log in successfully:

 

# ls -l /usr/bin/passwd

lrwxrwxrwx   1 root     system           39 Dec 22 11:30 /usr/bin/passwd -> /usr/es/sbin/cluster/utilities/clpasswd

 

# passwd tom

Changing password for "tom"

tom's New password:

Enter the new password again:

 

# grep -p tom passwd

tom:

        password = {smd5}FU2MWa.N.

        lastupdate = 1229910298

        flags =

 

 

Login no good!

tom@aix16's password:

Access denied

 

But if we use the original passwd command (stored in /usr/es/sbin/cluster/etc/clpasswd), the users password is changed successfully and the user can log in OK.

 

root@aix16 /usr/es/sbin/cluster/etc/clpasswd # ./usr_bin_passwd.orig tom

Changing password for "tom"

tom's New password:

Enter the new password again:

 

root@aix16 /usr/es/sbin/cluster/etc/clpasswd # grep -p tom /etc/security/passwd

tom:

        password = {smd5}PcBK/5QW$RE09Q0xz4TGQFp98KjxSs.

        lastupdate = 1229910818

        flags =                   ADMCHG

 

Login OK!

$ id

uid=10003(tom) gid=1(staff)

 

usr_bin_passwd.orig  password = {smd5}HcMHTTu3$BWkU8JVCWgT8szAN8TGCF1

clpasswd             password = {smd5}6z61fiIn/070

 

I’ve not tried this again recently but I am curious if the same behaviour can be expected on a PowerHA system today. When I first encountered this problem (in 2008) I opened a PMR for the issue. In that call I was told that the “clpasswd utility is corrupting the encrypted password when distributing to the nodes, so that a login fails”. I’ll configure a HA cluster soon and try it again with PowerHA 6.1 and AIX 6.1 and report back with the results.

 

UPDATE: I built a HA 6.1 cluster (on AIX 6.1) this afternoon in my lab and tested this successfully. Based on the tests I’ve performed so far, it appears that this limitation no longer exists. Thanks to hafeedbk@us.ibm.com for the help on this one.

 

The following IBM tech note has more information on the available Loadable Password Algorithms and support for longer than 8 character passwords on AIX:

 

AIX support for passwords greater than 8 characters

http://www-01.ibm.com/support/docview.wss?rs=111&context=SWG10&q1=pwd_algorithm&uid=isg3T1010741&loc=en_US&cs=utf-8&lang=en

 

 

Starting with AIX 7.1, CSM is no longer supported or available. It has been replaced by Distributed Systems Managment (DSM).   Section 5.2 of the IBM AIX 7.1 Differences Guide Redbook provides details of the new DSM capabilities.

 

Fortunately DSM still provides access to the dsh command.  I’ve written about how I’ve used this utility in the past. The new dsh command (and other tools) are provided in the new DSM filesets named dsm.core and dsm.dsh.

 

root@nim# lslpp -L dsm*

  Fileset                      Level  State  Type  Description (Uninstaller)

  ----------------------------------------------------------------------------

  dsm.core                   7.1.1.2    A     F    Distributed Systems Management

                                                   Core

  dsm.dsh                    7.1.0.0    C     F    Distributed Systems Management

                                                   Dsh

 

root@nim# lslpp -w /usr/bin/dsh

  File                                        Fileset               Type

  ----------------------------------------------------------------------------

  /usr/bin/dsh                                dsm.dsh               Symlink

 

 

These filesets are NOT installed by default. You must manually install them. They can be found on your AIX 7.1 media.

 

If dsh is something you use, then I recommend you read the section on DSM in the Redbook. Also take a look at section 5.2.7 Using DSM and NIM, in which it describes how you can integrate DSM and NIM and completely automate the installation of AIX:

 

“The AIX Network Installation Manager (NIM) has been enhanced to work with the Distributed System Management (DSM) commands. This integration enables the automatic installation of new AIX systems that are either currently powered on or off.”

 

Although I’ve written about the dsh command before, there’s one usage I’ve not covered.  And that is using dsh to manage users across a group of LPARs. In particular, changing a user’s password.

 

Before I go any further, I should state that for the following to work you must first configure ssh keys on your NIM master (or central mgmt AIX system) so that you can communicate with all of your AIX systems via SSH, as root,  without being prompted for a password. Read my article on dsh to find out how to do this if necessary.

 

In the following example, I use dsh from my NIM master. It is my central point of control for my AIX environment.

 

My ssh keys for root on my NIM master have been generated and distributed to all of my LPARs.

 

root@nim# ssh-keygen -d

Generating public/private dsa key pair.

Enter file in which to save the key (/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /.ssh/id_dsa.

Your public key has been saved in /.ssh/id_dsa.pub.

The key fingerprint is:

ed:18:e9:00:37:13:7c:7c:74:6a:a9:e0:ad:c0:09:a9 root@nim

The key's randomart image is:

+--[ DSA 1024]----+

|     ... .. .    |

|   .  ..o .+     |

|  o . =. .+      |

| . o = = =       |

|E   + o S .      |

|     . + +       |

|      . o .      |

|                 |

|                 |

+-----------------+

 

root@nim# ls -ltra

total 40

-rw-------    1 root     system          214 17 Sep 2010  authorized_keys

drwxr-xr-x    7 root     system         4096 16 Nov 11:43 ..

-rw-r--r--    1 root     system         3615 16 Nov 12:04 known_hosts

-rw-r--r--    1 root     system          601 16 Nov 12:06 id_dsa.pub

-rw-------    1 root     system          672 16 Nov 12:06 id_dsa

drwx------    2 root     system          256 16 Nov 12:06 .

 

On my AIX LPARs, the authorized_keys file has been updated with the public ssh key from my NIM master:

 

root@aixlpar1 [/.ssh]# chmod 600 known_hosts authorized_keys

root@aixlpar1 [/.ssh]# ls -ltr

total 0

-rw-------    1 root     system          406 Sep 29 15:30 known_hosts

-rw-------    1 root     system          601 Nov 16 12:07 authorized_keys

 

root@aixlpar1 [/.ssh]# cat authorized_keys

ssh-dss AAAAB3NzaC1kc3MAAACBAPJpekVQgV2CTu5tCOsukwXwMrkfBabLAN7vwjgPk3S2p65COJkFwaDRWwBoK87cnMrrc7/GuOLdk/RiqYw1K8Z0d9RWnsymYrNm0MBALWioGGXwQ+YlLiYHIQsSArnajZOH6Ye36qz81uWNoj6u4xIxi/iGSYoU4x3UE/c/H833AAAAFQDKEtWVFk3G+KAyxUsI6FcpbJZqDQAAAIAVUVRak/s+X0mMElCaEs8Rh96GDfhorXWV1YzI0nbRo8QX2AMix+3LSdEmYCRn8TYpk1Udln3GG4gzy5oI/3Rd1RTWgAo+067LwytR6IJfwYt219Pwh2ktrm5iZu3c+yDBqQj6hsga2YIun5lxqYFy39CZNtslnR1wTx9uCcYkowAAAIEAuVFTsW9ugVM76CgluspNo0faz9xFo4DCOjCgye+k/ZqSDaNq6Xrvxktw+dkHuKHbhvofPgeiMrlqhdbrE0ovLUr8aadxArRhitnu10CFYbRwlrjAxyAaRwjD2pXG8M3a5D1XXAWDCDm6bEs5yxJqcl1wq+8UAhpKiS5yj2pwApk= root@nim

 

 

On the NIM master, the root user was configured for the DSH environment. The following entry was placed in roots .profile:

 

root@nim# cat /.profile

ENV=$HOME/.kshrc

 

The following entry was placed in roots .kshrc file:

 

root@nim# cat /.kshrc

export DSH_NODE_RSH=/usr/bin/ssh

export DSH_NODE_LIST=/usr/local/etc/nodes

 

A /usr/local/etc/nodes file was created on the NIM master. This file contains a list of each of the nodes that dsh can communicate with from NIM:

 

root@nim# cat /usr/local/etc/nodes

aixlpar1

aixlpar2

aixlpar3

aixlpar4

aixlpar5

aixlpar6

aixlpar7

aixlpar8

aixlpar9

aixlpar10

aixlpar11

 

The first time that the dsh command is run against a new host, the following message will be displayed. dsh uses the FQDN, and the FQDN needs to be added to the known_hosts file for ssh. Therefore you must make an ssh connection first with FQDN to the host:

 

root@nim# dsh uptime

aixlpar1.cg.com.au : Host key verification failed.

dsh:  2617-009 aixlpar1.cg.com.au  remote shell had exit code 255

 

It is necessary to ssh directly to each node using its FQDN. This step is only required once for each node. For example:

 

root@nim# ssh aixlpar1.cg.com.au

The authenticity of host 'aixlpar1.cg.com.au  (172.1.6.17)' can't be established.

RSA key fingerprint is 83:13:1d:cb:97:ee:00:7a:04:75:62:98:bd:e8:30:79.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'aixlpar1.cg.com.au ' (RSA) to the list of known hosts.

Last unsuccessful login: Tue Sep 27 03:04:33 GMT+10:00 2011 on ssh from 172.1.6.15

Last login: Wed Nov 16 12:08:08 GMT+11:00 2011 on /dev/pts/3 from nim

 

 

root@aixlpar1 [/root]# exit

Connection to aixlpar1.cg.com.au  closed.

 

Now we can use the dsh command to run a command across all the nodes defined in the DSH_NODE_LIST. For example, the following command will run the uptime command on all nodes:

 

root@nim# dsh uptime

aixlpar1.cg.com.au :   12:14PM   up 10 days,  22:32,  3 users,  load average: 0.47, 0.53, 0.64

aixlpar2.cg.com.au :   12:14PM   up 21 days,  21:13,  1 users,  load average: 0.11, 0.31, 0.51

aixlpar3.cg.com.au :   12:14PM   up 15 days,  20:33,  5 users,  load average: 0.17, 0.43, 0.54

...etc...

 

With dsh now configured, we can use it to perform several admin tasks from a central location. For example, the following commands will do the following:

 

1.       Create a user, named cg, on all nodes.

2.        Set cg’s password to abc123 using the chpasswd command.

3.        Remove the ADMCHG flag for the user cg. This will stop them from being prompted to change their password on their first login attempt.

 

First I check that user does not exist on the AIX systems.

 

root@nim# dsh lsuser cg

aixlpar1: 3004-687 User "cg" does not exist.

aixlpar2: 3004-687 User "cg" does not exist.

aixlpar3: 3004-687 User "cg" does not exist.

aixlpar4: 3004-687 User "cg" does not exist.

aixlpar5: 3004-687 User "cg" does not exist.

...etc...

 

I create the user with the mkuser command.

 

root@nim# dsh mkuser cg

 

I confirm that the user has been created on all the AIX systems, with the lsuser command.

 

root@nim# dsh lsuser cg

aixlpar1: cg id=204 pgrp=staff groups=staff home=/home/cg shell=/usr/bin/ksh login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=

aixlpar2: cg id=204 pgrp=staff groups=staff home=/home/cg shell=/usr/bin/ksh login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=

aixlpar3: cg id=204 pgrp=staff groups=staff home=/home/cg shell=/usr/bin/ksh login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=

 

I set the users password to abc123, using the chpasswd utility. I also remove the ADMCHG flag so that the user is not prompted to change their password on their first logon attempt.

 

root@nim# dsh 'echo cg:abc123 | chpasswd -c'

 

I confirm that I can logon with the new user with the specified password, on one of the AIX LPARs.

 

root@nim# ssh cg@aixlpar1

cg@aixlpar1’s password:

Last login: Thu Mar  1 20:05:01 CST 2012 on /dev/pts/1 from aix71

$ id

uid=204(cg) gid=1(staff)

 

Another nice feature of dsh is the dshbak utility. This utility presents formatted output from the dsh command. For example:

 

root@nim 520 [/.ssh]# dsh errpt | dshbak

HOST: aixlpar1.cg.com.au

------------------------------------

IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION

AA8AB241   1116110811 T O OPERATOR       OPERATOR NOTIFICATION

A6DF45AA   1104135011 I O RMCdaemon      The daemon is started.

2BFA76F6   1104134111 T S SYSPROC        SYSTEM SHUTDOWN BY USER

9DBCFDEE   1104134111 T O errdemon       ERROR LOGGING TURNED ON

 

HOST: aixlpar2.cg.com.au

-------------------------------

IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION

DE9A52D1   1111012611 I S rmt10          AAA1

4865FA9B   1111012211 P H rmt10          TAPE OPERATION ERROR

DE9A52D1   1110233511 I S rmt0           AAA1

4865FA9B   1110225511 P H rmt0           TAPE OPERATION ERROR

DE9A52D1   1109180311 I S rmt0           AAA1

4865FA9B   1109180011 P H rmt0           TAPE OPERATION ERROR

DE9A52D1   1108180411 I S rmt2           AAA1

4865FA9B   1108180211 P H rmt2           TAPE OPERATION ERROR

DE9A52D1   1108165711 I S rmt6           AAA1

4865FA9B   1108165111 P H rmt6           TAPE OPERATION ERROR

A2205861   1102085311 P S SYSPROC        Excessive interrupt disablement time

F7FA22C9   1031134111 I O SYSJ2          UNABLE TO ALLOCATE SPACE IN FILE SYSTEM

DE9A52D1   1030163411 I S rmt0           AAA1

4865FA9B   1030163411 P H rmt0           TAPE OPERATION ERROR

....etc....

 

WARNING: Please be VERY CAREFUL when using the dsh command. Issuing the wrong command can cause damage to all your AIX LPARS!

 

The dsm.dsh package contains the following utilities:

 

# lslpp -f dsm.dsh | grep /usr/bin

                        /usr/bin/dcp -> /opt/ibm/sysmgt/dsm/bin/dcp

                        /usr/bin/dsh -> /opt/ibm/sysmgt/dsm/bin/dsh

                        /usr/bin/dping -> /opt/ibm/sysmgt/dsm/bin/dping

                        /usr/bin/dshbak -> /opt/ibm/sysmgt/dsm/bin/dshbak

 

If you are a fan of the dping command, you are going to be disappointed. Although the command is currently included in the dsm.dsh fileset, it probably won’t be for much longer.

 

The command works, “sort of”:

 

root@nim# dping aixlpar1

aixlpar1: ping (alive)

 

But if you run ‘dping –a’:

 

root@nim# dping -a

dping: 2651-095 CSM license has expired or has not been accepted. Run csmconfig -L if you have installed a new release.

 

According to the developers, dping is no longer supported and will eventually be removed from the DSM package. The response from the  developers was as follows:

"The reason "dping -a" is failing with the license check is because the command is calling “/usr/bin/runact-api –c IBM.DmsCtrl::::isLicenseValid" and the license is not set. So the command fails.  Since CSM is not supported anymore and went end of life. "

“... please consider the dping command as being "deprecated" code pending removal from the dsm.dsh package.”

When I asked why the command was listed in the AIX 7.1 online documentation if it was no longer available, I was informed: “We are  in the process of working with component owner regarding the DOCs and updating them.”. At this stage I’ve not been able to find an alternative command (in AIX). If I find one, I’ll update this post.

 

If you are planning on migrating to AIX 7.1 please be aware that CSM is no longer supported or available with AIX 7.1. CSM is now ‘end of life’.

 

 

http://www.ibmsystemsmag.com/aix/tipstechniques/systemsmanagement/DSH-Simplifies-the-Task-of-Managing-Multiple-Syste/

 

http://www.redbooks.ibm.com/abstracts/sg247910.html?Open

 

http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.cmds/doc/aixcmds1/chpasswd.htm

 

It’s no secret that I like NIM. I’ve written about NIM on several occasions, in Redbooks, technical articles and on my blog. It’s a great tool for installing and maintaining AIX. Occasionally though, it can throw you an unusual error or two when things go wrong. For the uninitiated resolving these errors can be challenging.

 

Here’s a couple of NIM related questions I received recently. Both are troubleshooting queries.

 

“I'm getting the following error when trying to create a NIM lpp_source for AIX 6.1”:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

...

Preparing to copy install images (this will take several minutes)...

 

0042-001 nim: processing error encountered on "master":

   0042-081 m_mk_lpp_source: a resource already exists on "master" at

location "/export/eznim/bid_ow"; due to NFS export restrictions, the

        new location "/export/eznim" may not be used

...

 

I could see what could be causing the issue but I first asked to see the contents of the /etc/exports file. Just to make sure that /export/eznim was not explicitly exported. It wasn’t.

 

# grep eznim /etc/exports

/export/eznim/vios/mksysb_image -ro,root=vio1,access=vio1

/export/eznim/bid_ow -ro,root=nim1,access=nim1

 

I suggested they re-try the operation again but this time specify the full path to the lpp_source directory, like so:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim/6100-06_lpp]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

This worked fine. And the lpp_source was created successfully.

 

#  lsnim -l 6100-06_lpp

6100-06_lpp:

   class       = resources

   type        = lpp_source

   locked      = 26738726

   Rstate      = unavailable for use

   prev_state  =

   location    = /export/eznim/6100-06_lpp

   alloc_count = 0

   server      = master

 

The second issue related to down-level filesets after an AIX 6.1 migration with nimadm.  There was also an issue with disk space that generated an error during NIM operations.

 

“Hi Chris,

 

Thanks for replying back to my post. I am a newbie to AIX/pSeries world.

I was following your document on upgrading AIX 5.3 to 6.1 using nimadm, it seemed to have worked partially for me, as I got to AIX 6100-00-00. The mksysb and the SPOT I created were for AIX 6100-06-05.

 

Before I re-attempt the upgrade, is there anything I need to be clean up on AIX 5.3 side that could have perhaps caused issues with the upgrade.

 

Thanks”

 

I recommended that the following command be run on the NIM client, to determine which filesets were down-level after the migration.

 

# oslevel -s

# instfix -i | grep AIX

# instfix -i | grep SP

 

If the output contained messages like "Not all filesets for 6100-06_AIX_ML were found", or something similar, then they should run the following command against each line (there could be more than one).

 

# instfix -icqk 6100-06_AIX_ML | grep ":-:"

 

This will tell you which filesets were not updated.

 

The output from ‘oslevel –s’and ‘instfix –i | grep AIX’ looked OK.

 

# oslevel -s

6100-06-04-1112

 

# instfix -i | grep AIX

    All filesets for 6100-00_AIX_ML were found.

    All filesets for 6100-01_AIX_ML were found.

    All filesets for 6100-02_AIX_ML were found.

    All filesets for 6100-03_AIX_ML were found.

    All filesets for 6100-04_AIX_ML were found.

    All filesets for 6100-05_AIX_ML were found.

    All filesets for 6100-06_AIX_ML were found.

 

But the output from ‘instfix –i  | grep SP’ indicated an issue with 61-06-051115_SP.

 

# instfix -i | grep SP

    All filesets for 61-00-010748_SP were found.

    All filesets for 61-00-020750_SP were found.

    All filesets for 61-00-030808_SP were found.

    All filesets for 61-00-040815_SP were found.

    All filesets for 61-01-010823_SP were found.

    All filesets for 61-00-050822_SP were found.

    All filesets for 61-00-060834_SP were found.

    All filesets for 61-01-020834_SP were found.

    All filesets for 61-00-070846_SP were found.

    All filesets for 61-01-030846_SP were found.

    All filesets for 61-02-010847_SP were found.

    All filesets for 61-02-020849_SP were found.

    All filesets for 61-00-080909_SP were found.

    All filesets for 61-01-040909_SP were found.

    All filesets for 61-02-030909_SP were found.

    All filesets for 61-03-010921_SP were found.

    All filesets for 61-00-090920_SP were found.

    All filesets for 61-01-050920_SP were found.

    All filesets for 61-02-040920_SP were found.

    All filesets for 61-00-100939_SP were found.

    All filesets for 61-01-060939_SP were found.

    All filesets for 61-02-050939_SP were found.

    All filesets for 61-03-020939_SP were found.

    All filesets for 61-04-010944_SP were found.

    All filesets for 61-04-021007_SP were found.

    All filesets for 61-04-031009_SP were found.

    All filesets for 61-00-110943_SP were found.

    All filesets for 61-01-081014_SP were found.

    All filesets for 61-02-060943_SP were found.

    All filesets for 61-03-030943_SP were found.

    All filesets for 61-03-041014_SP were found.

    All filesets for 61-04-041014_SP were found.

    All filesets for 61-05-011016_SP were found.

    All filesets for 61-01-091015_SP were found.

    All filesets for 61-02-081015_SP were found.

    All filesets for 61-03-051015_SP were found.

    All filesets for 61-04-051015_SP were found.

    All filesets for 61-01-070943_SP were found.

    All filesets for 61-02-071014_SP were found.

    All filesets for 61-02-091034_SP were found.

    All filesets for 61-03-061034_SP were found.

    All filesets for 61-04-061034_SP were found.

    All filesets for 61-05-021034_SP were found.

    All filesets for 61-06-011043_SP were found.

    All filesets for 61-02-101036_SP were found.

    All filesets for 61-03-071036_SP were found.

    All filesets for 61-04-071036_SP were found.

    All filesets for 61-05-031036_SP were found.

    All filesets for 61-06-021044_SP were found.

    All filesets for 61-06-031048_SP were found.

    All filesets for 61-05-041048_SP were found.

    All filesets for 61-04-081048_SP were found.

    All filesets for 61-03-081048_SP were found.

    All filesets for 61-03-091112_SP were found.

    All filesets for 61-04-091112_SP were found.

    All filesets for 61-05-051112_SP were found.

    All filesets for 61-06-041112_SP were found.

    Not all filesets for 61-06-051115_SP were found.

 

The culprit was the csm.hc_utils fileset from TL6 SP5. It was still at level 1.7.1.0 instead of the expected 1.7.1.1.

 

# instfix -ciqk "61-06-051115_SP" |grep ":-:"

61-06-051115_SP:csm.hc_utils:1.7.1.1:1.7.1.0:-:AIX 6100-06-05 Service Pack

 

I recommended that the csm.hc_utils 1.7.1.1 fileset be added to the AIX 6.1 lpp_source. The migration was attempted again and the client migrated to AIX 6.1 TLP6 SP5 successfully.  I also suggested they determine if this fileset was really used and/or needed (CSM is no longer supported/available starting with AIX 7.1 anyway).

 

And just when I thought all his problems were resolved, he replied with: “however upon trying to install these from the NIM server, I get errors on NIM”.

 

*********************************************************

errors:

0042-001 nim: processing error encountered on "master":                |

 |      0042-001 m_showres: processing error encountered on "master":       |

 |      0042-185 c_ch_nfsexp: Failed to link or copy /etc/.tmp.nim.exports. |

 |   12451894 to /etc/exports                                               |

 |           Check permissions and filesystem space

*********************************************************

 

Fortunately a quick look at the output from the df command highlighted the problem immediately.

He was out of space in the root file system. The very place that /etc/exports, and the NIM database (/etc/objrepos), reside.

 

# df -g

Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on

/dev/hd4           2.50      0.00  100%     3388     1% /

/dev/hd2           4.50      1.74   62%    42150     4% /usr

/dev/hd9var        1.00      0.52   48%     3262     2% /var

/dev/hd3           4.00      3.84    5%       74     1% /tmp

/dev/hd1           0.50      0.37   27%      479     1% /home

/proc                 -         -    -         -     -  /proc

/dev/hd10opt       0.75      0.21   73%     5698     3% /opt

/dev/livedump      0.25      0.24    4%       17     1% /var/adm/ras/livedump

/dev/exportlv    136.25    124.03    9%    20128     1% /export

 

After cleaning up unwanted files in / and making sure there was plenty of free space, the error no longer appeared in future NIM operations.

 

 

So you’re configuring a new PowerHA 6.1 cluster and you decide to check if the clinfoES subsystem is running. You run the following command:

 

# lssrc -a | grep cluster

clstrmgrES       cluster          2883628      active

 

Hmmm, clinfoES is not listed. To ensure that is clinfoES is shown in lssrc output, in both inactive and active states, run the following command on all nodes in the cluster:

 

# chssys -s clinfoES –d

 

And now clinfoES is shown:

 

#lssrc -a | grep cluster

clstrmgrES       cluster          2883628      active

clinfoES         cluster                       inoperative

 

There was also a time when you had to do the same for clstrmgrES, however this subsystem is now always active (very rarely/never inactive) on a HA node e.g.

 

# chssys -s clstrmgrES -d

 

The chssys command can make changes to a subsystems definition on AIX:

 

http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.cmds/doc/aixcmds1/chssys.htm

 

The –d flag to the chssys command specifies that an inactive subsystem is displayed in lssrc output.

 

I found a very old reference to something similar in this old HACMP/ES Redbook, but only the clinfoES recommendation still applies:

 

For a better understanding and to avoid problem determination, it is recommended to make all relevant HACMP subsystems visible with the lssrc command, independent of whether they are active or not.

 

# chssys -s clinfoES -d # modify subsystem definition

# chssys -s cllockdES -d

# chssys -s clsmuxpdES -d

# chssys -s clvmd –d

 

http://ps-2.kev009.com/rs6000/redbook-cd/SG245526.pdf