Chris's AIX Blog

with Tags: nimsh

nimsh and SAP

cggibbo Tags: aix nim chris sap 3901 gibson nimsh 8 Comments 34,229 Views

Here’s a problem I’ve encountered more than once.

Someone installs SAP onto an AIX system and decides to use TCP port 3901 as an SAP service port. This is the same port used by nimsh. In some rare cases, nimsh may not be active on the LPAR, which makes it easy for the SAP installation to hijack port 3901. If nimsh is active, the person installing SAP may consciously stop nimsh and use port 3901 for SAP anyway. Hopefully that doesn’t happen. Hopefully, they will talk to the AIX administrator and discuss the best way forward. Hopefully...

In either case, if the port is taken by SAP, nimsh will no longer work. If you love using NIM as much as I do, this is a real problem! We could revert back to using rsh but no-one will do this anymore because of concerns around security. And rightfully so!

The ports used by nimsh (3901 and 3902) are registered to Internet Assigned Number Authority (IANA). These port numbers appear in the /etc/services file.

nimsh 3901/tcp # NIM Service Handler

nimsh 3901/udp # NIM Service Handler

nimaux 3902/tcp # NIMsh Auxiliary Port

nimaux 3902/udp # NIMsh Auxiliary Port

Considering these port numbers are registered with IANA, we can usually persuade our SAP colleagues to change their SAP installation to use a different port number. However, depending on the skills/experience of the SAP resource, one of two things usually happens 1) They take an outage, re-install SAP and choose a different port number or 2) The more experienced/confident SAP basis resource will take an outage and modify the instance to use a different port: without reinstalling SAP.

Perhaps SAP need to include a warning in their install notes, advising customers not to use port 3901 on AIX systems (i.e. best practice)?

Now, if you must change nimsh to use a different port number, it is possible. But not recommended.

To do this, you must change the /etc/services file on the NIM master and the NIM client to reflect the same port numbers for nimsh. This will work until the NIM master or the NIM client have their services file overwritten by way of install or fileset updates. After which, the default values for nimsh will be reinstated.

You would also need to change the services file on all of your NIM clients. Every time you performed a NIM fileset update, you would need to remember to change the /etc/services file again. This is painful and bound to catch someone out eventually!

In the following example I’ll demonstrate how to change the port number used by nimsh.

We start with a typical nimsh configuration using port 3901. On the NIM client, nimsh is listening on port 3901.

nimaix / # lsof -i tcp:3901

Value of I :77 np:0

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

nimsh 2883740 root 4u IPv6 0xf1000e0006f843b0 0t0 TCP *:nimsh (LISTEN)

On the NIM master we can connect to the NIM client on port 3901.

nimmast / # nim -o lslpp nimaix | head -10

Fileset Level State Description

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

Path: /usr/lib/objrepos

Firefox.base.rte 2.0.0.20 COMMITTED Firefox Web Browser

ICU4C.rte 6.1.4.0 COMMITTED International Components for

Unicode

6.1.4.1 COMMITTED International Components for

Unicode

6.1.6.0 COMMITTED International Components for

Unicode

...

The /etc/services file on both the NIM client and the master have the same port number for nimsh.

nimmast / # grep nimsh /etc/services

nimsh 3901/tcp # NIM Service Handler

nimsh 3901/udp # NIM Service Handler

nimaix / # grep nimsh /etc/services

nimsh 3901/tcp # NIM Service Handler

nimsh 3901/udp # NIM Service Handler

To change the port number for nimsh, first we select an unused port number, in this case 39011.

nimaix / # lsof -i tcp:39011

Value of I :77 np:0

We update the /etc/services file on the master and the client to reflect the new port number.

nimaix / # grep nimsh /etc/services

#nimsh 3901/tcp # NIM Service Handler

#nimsh 3901/udp # NIM Service Handler

nimsh 39011/tcp # NIM Service Handler

nimsh 39011/udp # NIM Service Handler

nimmast / # grep nimsh /etc/services

#nimsh 3901/tcp # NIM Service Handler

#nimsh 3901/udp # NIM Service Handler

nimsh 39011/tcp # NIM Service Handler

nimsh 39011/udp # NIM Service Handler

We stop and start nimsh on the client and confirm that nimsh is now listening on the new port number, 39011.

nimaix / # stopsrc -s nimsh

0513-044 The nimsh Subsystem was requested to stop.

nimaix / # startsrc -s nimsh

0513-059 The nimsh Subsystem has been started. Subsystem PID is 2883742.

nimaix / # lsof -i tcp:39011

Value of I :77 np:0

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

nimsh 2883742 root 4u IPv6 0xf1000e0006f85bb0 0t0 TCP *:nimsh (LISTEN)

From the NIM master we connect to the NIM client using the nim command.

nimmast / # nim -o lslpp nimaix | head -10

Fileset Level State Description

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

Path: /usr/lib/objrepos

Firefox.base.rte 2.0.0.20 COMMITTED Firefox Web Browser

ICU4C.rte 6.1.4.0 COMMITTED International Components for

Unicode

6.1.4.1 COMMITTED International Components for

Unicode

6.1.6.0 COMMITTED International Components for

Unicode

....

We can confirm that we have connected to the NIM client on port 39011 by looking at the output from lsof and netstat. There is a TCP session established between the master and the client on port 39011.

nimmast / # lsof -i tcp:39011

Value of I :93 np:0

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

m_showlog 430080 root 8u IPv4 0xf1000700047693b0 0t5 TCP nimmast:1023->nimaix:nimsh (ESTABLISHED)

nimmast / # netstat -na | grep 39011

tcp4 0 0 172.29.144.167.1023 172.29.152.241.39011 ESTABLISHED

nimaix / # lsof -itcp:39011

Value of I :75 np:0

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

nimsh 2293836 root 0u IPv6 0xf1000e0004d313b0 0t5 TCP nimaix:nimsh->nimmast:1023 (ESTABLISHED)

nimsh 2293836 root 1u IPv6 0xf1000e0004d313b0 0t5 TCP nimaix:nimsh->nimmast:1023 (ESTABLISHED)

nimsh 2293836 root 2u IPv6 0xf1000e0004d313b0 0t5 TCP nimaix:nimsh->nimmast:1023 (ESTABLISHED)

nimsh 2293836 root 4u IPv6 0xf1000e0006f85bb0 0t0 TCP *:nimsh (LISTEN)

nimsh 2293836 root 5u IPv6 0xf1000e0004d313b0 0t5 TCP nimaix:nimsh->nimmast:1023 (ESTABLISHED)

nimsh 2883742 root 4u IPv6 0xf1000e0006f85bb0 0t0 TCP *:nimsh (LISTEN)

nimsh 2883742 root 5u IPv6 0xf1000e0004d313b0 0t5 TCP nimaix:nimsh->nimmast:1023 (ESTABLISHED)

If the /etc/services file on either the NIM client or master is incorrect we would see error messages similar to the following:

0042-006 m_lslpp: (From_Master) connect A remote host refused an attempted connect operation.

nconn: connect() failed, errno is 79nimaix: A remote host refused an attempted connect operation.

Would I recommend this approach? No. This is not a good, permanent solution to the problem.

Do I think IBM would support this configuration? No.

Why am I writing about it then? Because it might help someone caught in a bind. You could use this method temporarily until you’ve sorted out your SAP port problem.

0042-358 niminit: The connect attribute may only be assigned a service value of "shell" or "nimsh".

cggibbo Tags: chris nimsh gibson nim 3902 3901 aix 5 Comments 36,040 Views

I was working at a client site today, on a NIM master that I configured a month or so ago. I was there to install the TSM backup client software on about 30 or so LPARs. Of course I was going to use NIM to accomplish this task.

The software install via NIM worked for the majority of the LPARs but I noticed a few of them were failing. This was very odd, as the last time I’d use the same NIM method to install software, everything was fine.

I suspected that perhaps something had changed on the client LPARs...maybe with their /etc/niminfo file for instance. So I performed the following steps to reconfigure the /etc/niminfo file and configure the nimsh subsystem on the client LPAR.

lpar1# mv /etc/niminfo /etc/niminfo.old

lpar1# niminit -a master=nim1 -a name=`hostname`

lpar1# stopsrc -s nimsh

lpar1# smit nim_config_services

Configure Client Communication Services

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

[Entry Fields]

* Communication Protocol used by client [nimsh] +

NIM Service Handler Options

* Enable Cryptographic Authentication [disable] +

for client communication?

Install Secure Socket Layer Software (SSLv3)? [no] +

Absolute path location for INSTALLP package [/dev/cd0] /

-OR-

lpp_source which contains INSTALLP package [] +

Alternate Port Range for Secondary Connections

(reserved values will be used if left blank)

Secondary Port Number [] #

Port Increment Range [] +#

The last step failed with the following error message:

0042-358 niminit: The connect attribute may only be assigned a service value of "shell" or "nimsh".

I checked the NIM client and confirmed it was configured for nimsh and it was fine. However, I did notice something odd when I ran the following command:

lpar1# egrep 'nimsh|nimaux' /etc/services

lpar1#

The entries for nimsh were missing from the /etc/services file!

Somebody had decided that these entries were not required and had simply removed them! Gee, thanks so much for that!

After adding the following entries back into the services file, everything started working again!

nimsh 3901/tcp # NIM Service Handler

nimsh 3901/udp # NIM Service Handler

nimaux 3902/tcp # NIMsh Auxiliary Port

nimaux 3902/udp # NIMsh Auxiliary Port

I’ve also encountered this error when there is another process (other than nimsh) using port 3901 or 3902.

Another error message you might confront, if those entries are either missing or commented out, is on the NIM master:

nimmast# nim -o showlog -a log_type=lppchk lpar1

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

0042-006 m_showlog: (From_Master) connect Error 0

poll: setup failure

I thought I’d also mention another error message that can potentially drive you insane (especially if you haven’t had your morning coffee!). The error doesn’t relate to nimsh at all but I thought I’d describe it anyway. The message appears when running the nim –o showlog command against a client LPAR.

nimmast# nim -o showlog lpar1

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

0042-006 m_showlog: (From_Master) connect Error 0

0042-008 nimsh: Request denied – wronghostname

I’ve modified the output a little to make it easier to identify the problem. Can you see it? I thought so! Upon investigation you may find that the IP address for the NIM master is resolving to a different hostname on the client. For example:

On the NIM master:

nimmast# host nimmast

nimmast is 172.29.150.177

nimmast# host 172.29.150.177

nimmast is 172.29.150.177

nimmast# grep 177 /etc/hosts

172.29.150.177 nimmast

On the NIM client:

lpar1# host nimmast

nimmast is 172.29.150.177

lpar1# host 172.29.150.177

wronghostname is 172.29.150.177

lpar1# grep 172.29.150.177 /etc/hosts

172.29.150.177 wronghostname

172.29.150.177 nimmast

In this example, someone placed two host entries in /etc/hosts with the same IP address. The client was resolving the IP address to an incorrect hostname. This resulted in our nim –o showlog command failing.

NIMSH, SSL and LPM.

cggibbo Tags: error processing aix blog encountered on ssl lpm chris "master": nim: gibson nimsh nim 0042-001 4 Comments 8,580 Views

Do you use SSL with nimsh on AIX? No? Well, you might want to consider it. If you regularly use LPM to migrate AIX partitions from one server to another, you may have found that, on occasion, your NIM master has trouble communicating with its NIM clients afterwards. This is by design, as nimsh uses the NIM clients cpuid to authenticate with the NIM master. During an LPM operation, the cpuid of the NIM client changes and its possible the NIM master may reject the client as a result. This problem can occur even when CPU validation is disabled on the NIM master.

In the example below, I’ve LPM’ed a NIM client (750lpar1) to another server. Immediately afterwards, I’m able to execute a NIM command against the NIM client, from the NIM master (750lpar4). At this point the NIM client is configured with standard nimsh authentication i.e. no SSL.

NIM CLIENT (AFTER LPM):

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F603CD4C00

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F627664C00

[root@750lpar1]/var/adm/ras# echo HELLO > /var/adm/ras/nim.installp

NIM MASTER:

[root@750lpar4]/ # nim -o change -a validate_cpuid=no master

[root@750lpar4]/ # lsnim -l master | grep -i cpu

validate_cpuid = no

[root@750lpar4]/ # lsnim -l 750lpar1

750lpar1:

class = machines

type = standalone

connect = nimsh

platform = chrp

netboot_kernel = 64

if1 = 10_1_50 750lpar1 0

cable_type1 = N/A

Cstate = ready for a NIM operation

prev_state = not running

Mstate = currently running

cpuid = 00F603CD4C00 << Notice that the cpuid is different.

[root@750lpar4]/ # nim -o showlog 750lpar1

HELLO

The cpuid is cached by the nimsh daemon, so the previous system id is retained in memory and passed to the NIM master, which allows the operation to complete successfully. But, if I restart the nimsh daemon, on the NIM client, I find that the NIM master is no longer able to communicate with the client.

[root@750lpar1]/ # stopsrc -s nimsh

0513-044 The nimsh Subsystem was requested to stop.

[root@750lpar1]/ # startsrc -s nimsh

0513-059 The nimsh Subsystem has been started. Subsystem PID is 6160610.

[root@750lpar4]/ nim -o define -t mksysb -a source=750lpar1 -a mksysb_flags=-e -a mk_image=yes -a server=master -a location=/export/mksysb/cg/750lpar1-mksysb 750lpar1-mksysb

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

0042-006 m_mkbosi: (From_Master) connect Error 0

0042-008 nimsh: Request denied - 750lpar4

[root@750lpar4]/ # nim -o showlog 750lpar1

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

0042-006 m_showlog: (From_Master) connect Error 0

0042-008 nimsh: Request denied - 750lpar4

[root@750lpar1]/var/adm/ras# grep match nimsh.log | grep CD

Wed Apr 27 20:51:12 2016 error: local value passed, '00F603CD4C00', does not match environment value '00F627664C00'

One way to work around this problem is to use the procedure outlined at the following link:

http://www.ibm.com/support/knowledgecenter/api/content/ssw_aix_71/com.ibm.aix.osdevice/lpm_nim.htm

“Migrating a NIM client by using LPM

When Live Partition Mobility (LPM) is used to move a machine from one physical server to another and the machine is defined as a Network Installation Management (NIM) client, the NIM administrator must update the cpuid attribute for the NIM client to reflect the new hardware value after the LPM migration completes. To update the cpuid attribute, complete the following steps:

On the NIM client, acquire the new cpuid ID by running the following command:

uname –a

On the NIM master, run the following command:

nim -o change -a cpuid=cpuid client”

However, there is a better way. Using nimsh, with SSL-enabled authentication, will prevent the checking of cpuid during nimsh service handling. This is considered the recommended choice of operation (since the client/server can agree upon identity using the certificate information passed during the ssl handshake). Once the certificate is in place, the NIM master will disregard any cpuid validation and instead rely on the success of the SSL-handshake. This configuration will work well with LPM. If using standard nimsh, the limitation of cpuid updating would still apply (because NIM has no way of automatically updating a client once the value has changed).

Both the NIM master and client must be configured to support SSL-enabled authentication. To configure SSL-enabled authentication, we can use ‘nimconfig -c’ on the NIM master.

[root@750lpar4]/ # oslevel -s

7100-04-01-1543

[root@750lpar4]/ # nimconfig -c

0513-029 The tftpd Subsystem is already active.

Multiple instances are not supported.

NIM_MASTER_HOSTNAME=750lpar4

x - /usr/lib/libssl.so.0.9.8

x - /usr/lib/libcrypto.so.0.9.8

Target "all" is up to date.

Generating a 1024 bit RSA private key

.................++++++

....................................++++++

writing new private key to '/ssl_nimsh/keys/rootkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

Getting Private key

Generating a 1024 bit RSA private key

...++++++

....++++++

writing new private key to '/ssl_nimsh/keys/clientkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com

Getting CA Private Key

Generating a 1024 bit RSA private key

.....................++++++

..........++++++

writing new private key to '/ssl_nimsh/keys/serverkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com

Getting CA Private Key

[root@750lpar4]/ # lsnim -l | grep -i ssl

ssl_support = yes

[root@750lpar4]/ # /usr/samples/nim/ssl/certview -I /ssl_nimsh/certs/client.pem

certname= /ssl_nimsh/certs/client.pem

subject= /C=US/ST=Texas/L=Austin/O=ibm.com

issuer= /C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

notAfter=Apr 28 10:25:17 2017 GMT

[root@750lpar4]/ # /usr/samples/nim/ssl/certview -I /tftpboot/server.pem

certname= /tftpboot/server.pem

subject= /C=US/ST=Texas/L=Austin/O=ibm.com

issuer= /C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

notAfter=Apr 28 10:25:17 2017 GMT

To enable SSL nimsh on the NIM client, we can use the ‘nimclient –c’ command. You can fall-back to non-SSL nimsh, with ‘nimclient –C’.

[root@750lpar1]/# oslevel -s

7100-04-01-1543

[root@750lpar1]/var/adm/ras# nimclient -c

x - /usr/lib/libssl.so.0.9.8

x - /usr/lib/libcrypto.so.0.9.8

Received 2784 Bytes in 0.0 Seconds

0513-044 The nimsh Subsystem was requested to stop.

0513-077 Subsystem has been changed.

0513-059 The nimsh Subsystem has been started. Subsystem PID is 14942422.

[root@750lpar1]/var/adm/ras# cat nimsh.log

Fri Apr 29 23:10:45 2016 /usr/sbin/nimsh: NIM Service Handler started from SRC

Fri Apr 29 23:10:45 2016 no environment value for NIM_SECONDARY_PORT

Fri Apr 29 23:10:45 2016 value for hostname is 750lpar1

Fri Apr 29 23:10:45 2016 value for netaddr is: 10.1.50.31

Fri Apr 29 23:10:45 2016 value for route is net,-hopcount,0,,0 and gateway is 10.1.50.1

Fri Apr 29 23:10:45 2016 value for netif is en0

Fri Apr 29 23:10:45 2016 value for netmask is 255.255.255.0

Fri Apr 29 23:10:45 2016 obtained master's hostname: NIM_MASTER_HOSTNAME=750lpar4

Fri Apr 29 23:10:45 2016 obtained master's id: NIM_MASTERID=00F603CD4C00

Fri Apr 29 23:10:45 2016 value for machine id is 00F603CD4C00

Fri Apr 29 23:10:45 2016 Refreshing archive member /usr/lib/libssl.so.0.9.8 from /usr/lib/libssl.a ..

Fri Apr 29 23:10:45 2016 Refreshing archive member /usr/lib/libcrypto.so.0.9.8 from /usr/lib/libcrypto.a ..

Now I can LPM the NIM client to another server and even if I restart nimsh, the master can still communicate with the client. All thanks to SSL.

NIM MASTER:

[root@750lpar4]/ # lsnim -l 750lpar1

750lpar1:

class = machines

type = standalone

connect = nimsh (secure)

platform = chrp

netboot_kernel = 64

if1 = 10_1_50 750lpar1 0

cable_type1 = N/A

Cstate = ready for a NIM operation

prev_state = not running

Mstate = currently running

cpuid = 00F603CD4C00

NIM CLIENT (AFTER LPM):

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F603CD4C00

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F627664C00

[root@lpar1]/ # stopsrc -s nimsh

0513-044 The nimsh Subsystem was requested to stop.

[root@lpar1]/ # startsrc -s nimsh

0513-059 The nimsh Subsystem has been started. Subsystem PID is 6160616.

[root@750lpar1]/var/adm/ras# tail -f nimsh.log

Fri Apr 29 23:13:33 2016 passing OpenSSL setting of 1

Fri Apr 29 23:13:33 2016 set symbol table

Fri Apr 29 23:13:33 2016 cert filename discovered: /ssl_nimsh/certs/750lpar4.0

Fri Apr 29 23:13:33 2016 ** OpenSSL FIPS mode enabled successfully

Fri Apr 29 23:13:33 2016 seed_prng

Fri Apr 29 23:13:33 2016 Loading certificates..

Fri Apr 29 23:13:33 2016 Loading private key file..

Fri Apr 29 23:13:33 2016 create BIO

Fri Apr 29 23:13:33 2016 - SSL Connection verified successfully -

Fri Apr 29 23:13:33 2016 sending ack to client

Fri Apr 29 23:13:33 2016 setting descriptors to include 2nd port

Fri Apr 29 23:13:33 2016 command to exec __ /usr/lpp/bos.sysmgt/nim/methods/c_nimpush "/usr/lpp/bos.sysmgt/nim/methods/c_showlog" "-alocation=/var/adm/ras/nim.installp"

[root@750lpar4]/ nim -o define -t mksysb -a source=750lpar1 -a mksysb_flags=-e -a mk_image=yes -a server=master -a location=/export/mksysb/cg/750lpar1-mksysb 750lpar1-mksysb

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

System Backup Image Space Information

(Sizes are displayed in 1024-byte blocks.)

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

Required = 9457741 (9237 MB) Available = 51653640 (50444 MB)

Creating information file (/image.data) for rootvg.

..etc..

Using NIM to install clients configured with SSL authentication

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.install/nim_install_ssl.htm

Using the certificate viewing file

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.install/sample_files_certificate.htm%23sample_files_certificate?lang=en

Modified by cggibbo

NIM Master, NIMSH and SSL on AIX 7.1 TL4 SP3

cggibbo Tags: nimsh sp3 nim hang lslpp chris 7.1 ssl tl4 7100-04-03-1642 aix gibson iv93152 -o libssl.so 3,347 Views

Whilst working with one of my AIX customers recently I discovered a problem with NIMSH and SSL. The customer had updated their NIM master from AIX 7.1 TL4 SP1 to AIX 7.1 TL4 SP3. After the SP update, any attempt to connect to a NIM client (over NIMSH+SSL), from the NIM master, would simply hang. For example, we tried to list the filesets on the NIM client with this command, which never returned any output.

[root@750lpar4]/ # nim -o lslpp 750lpar9

The /var/adm/ras/nimsh.log file, on the NIM client, showed that the NIMSH session stopped here:

…

Thu Jan 12 14:31:49 2017 Loading certificates..

Thu Jan 12 14:31:49 2017 Loading private key file..

Thu Jan 12 14:31:49 2017 create BIO

…

NIM master: 750lpar4

7100-04-03-1543

NIM client: 750lpar9

7100-04-02-1614

[root@750lpar4]/ # lsnim -l 750lpar9

750lpar9:

class = machines

type = standalone

connect = nimsh (secure)

platform = chrp

netboot_kernel = 64

if1 = 10_1_50 750lpar9 0

cable_type1 = N/A

Cstate = ready for a NIM operation

prev_state = not running

Mstate = currently running

cpuid = 00F603CD4C00

Cstate_result = success

The root cause of the problem become apparent when we ran truss against the nim –o command.

[root@750lpar4]/ # truss -adef -o truss.lsnim.out -w all nim -o lslpp 750lpar9

[root@750lpar4]/ # cat truss.lsnim.out

…

13959372: C o u l d n o t l o a d m o d u l e / u s r / l i b / l

13959372: i b s s l . s o .\n S y s t e m e r r o r : N o s u c h

13959372: f i l e o r d i r e c t o r y

…

19267612: C o u l d n o t l o a d m o d u l e / u s r / l i b / l

19267612: i b c r y p t o . s o .\n S y s t e m e r r o r : N o s u

19267612: c h f i l e o r d i r e c t o r y

The required shared library object files were missing on the NIM master.

[root@750lpar4]/usr/lib # ls -ltr libssl.so libcrypto.so

libssl.so not found

libcrypto.so not found

We fixed this issue by extracting the missing files from the (existing) /usr/lib/libssl.a and /usr/lib/libcrypto.a archives.

[root@750lpar4]/usr/lib # slibclean

[root@750lpar4]/usr/lib # /bin/ar -v -x /usr/lib/libssl.a /usr/lib/libssl.so

x - /usr/lib/libssl.so

[root@750lpar4]/usr/lib # /bin/ar -v -x /usr/lib/libcrypto.a /usr/lib/libcrypto.so

x - /usr/lib/libcrypto.so

[root@750lpar4]/usr/lib # ls -ltr libssl.so libcrypto.so

-rwxr-xr-x 1 root system 724913 Jan 18 09:08 libssl.so

-rwxr-xr-x 1 root system 3031337 Jan 18 09:08 libcrypto.so

After that, the nim –o commands started working again.

[root@750lpar4]/usr/lib # nim -o showlog 750lpar9

HELLO

So, the question is why did this happen? Well, in the past, the libssl.so.0.9.8 shared object was extracted by NIM, but more recent updates by the OpenSSL version has forced IBM to move to libssl.so. Usually, the extracted shared library object is added (if not currently present) when nimconfig -c is run. But given that this is an existing NIM master, we did not want to run this again (as we would lose all of the current SSL key access). So extracting the objects is preferred. The problem is due to the fact that the libssl.so and libcrypto.so files are not populated when the AIX 7100-04-03 update is applied. This is a bug and will be officially addressed, soon, under APAR IV93152 NIM push operation to client hang on nimsh over SSL.

I believe this issue may also occur when you migrate your NIM master from AIX 7.1 to 7.2 (with nimadm for example). But I need to do more testing to reproduce and confirm the issue.

Here’s one good reason to setup NIMSH over SSL.

NIMSH, SSL and LPM

https://www.ibm.com/developerworks/community/blogs/cgaix/entry/NIMSH_SSL_and_LPM?lang=en

The following link is a great reference guide for configuring NIMSH over SSL.

NIMSH over SSL

http://www-01.ibm.com/support/docview.wss?uid=isg3T1024615

Modified by cggibbo

Feed for Blog Entries ▼

Blogs

Chris's AIX Blog

▼ Tags

▼ Similar Blogs

AIX Down Unde...

Application P...

Asset Managem...

Application I...

AIXpert Blog

▼ Similar Ideation Blogs

IBM PureData-...

IBM Forms Exp...

WebSphere App...

Rational Soft...

IBM Configura...

▼ Archive

▼ Blog Authors

Chris's AIX Blog

nimsh and SAP

0042-358 niminit: The connect attribute may only be assigned a service value of "shell" or "nimsh".

NIMSH, SSL and LPM.

NIM Master, NIMSH and SSL on AIX 7.1 TL4 SP3