Originally posted by: robint

Hi

Our cluster has been running steadily for months on 5.3.0.0 TL4. Our NIM server is the same level. We do lots of application updates via NIM and they have always worked fine.

I've just performed an update of all the cluster members to 5300-12-01-1016 using NIM and it worked well. I also updated to 64bit(ahem). The cluster works fine and Oracel applications, including RAC, are all good.
I followed on by updating the NIM server to the same AIX level. This was fine too. I then updated the kernel. This was fine also.

My problem is that the NIM system has a problem with what looks like NFS. If I use NIM, for example to remove an test package from the itself, the master, all is fine. If I repeat the removal of a package on another cluster member I get the following message:

0042-001 nim: processing error encountered on "master":
0042-001 m_maint: processing error encountered on "INTDB2":
warning: 0042-175 c_installp: An unexpected result was returned by the
"/usr/sbin/mount" command:
level -
mount: 1831-011 access denied for intnimapa:/tmp/__smit_bundle_5912
mount: 1831-008 giving up on:
intnimapa:/tmp/__smit_bundle_5912
The file access permissions do not allow the specified action.
rc=175
0042-175 c_installp: An unexpected result was returned by the "/usr/sbin/mount"
command:
mount: 1831-011 access denied for intnimapa:/tmp/__smit_bundle_5912
mount: 1831-008 giving up on:
intnimapa:/tmp/__smit_bundle_5912
The file access permissions do not allow the specified action.

NFS appears to allow me to mount exported dirs onto other cluster nodes without a problem, but using NIM I just get the above issues.

I trawled the web and there are several refs to ptfs for similar sounding issues, usually related to the taking of mksysbs with NIM, but they all indicate they are rolled into TL12 or earlier, so I am assuming are loaded already.

I'm sure this must be a environment issue that I've got away with in the past, could someone help me out?

Thanks
Rob

Originally posted by: robint

This seems to be an NIM NFS issue.

If I use smit to export, then I can mount from other nodes happily. It seems to be when NIM organises the export of either a file or script.

I captured the exports file during the NIM operation and then used SMITY NFS to "change/mod" the exported directory. I noticed it asked me what version of NFS to export with. (This is new?)
Afterwards, I could mount the directory fine.

All my hostname/IP resolution appears fine.

Do I need to disable NFSv4 functionality? If so how is this done. MY NIM and NFS configs have just survived the AIX upgrade process. I haven't taken any other steps to account for the later versions.

Hopefully others are using 53 tl12 NIM?

Any pointers welcome

Thx
Rob

Originally posted by: robint

FWIW

I've reverted NIM to 5.3.0.4 and the issue remains.

Someone must have got NIM working! Are there any gotcha's I'm missing?

Rob

Originally posted by: DjRobin69

Two biggests gotchas for NFS are name resolution on both sides, and making sure the mount point exists and it exactly matches the permissions of the the exported directory and the export permissions

Originally posted by: robint

Thanks for the response.

I will check again the perms but NFS seems to be working fine if I do a regular export to the same nodes, I think this should mean the name resolution is good. It only fails when NIM sets up the export details itself. Any ideas?

Rob

Originally posted by: robint

Resolved!

Having spent the weekend making wild stabs in the dark I stumbled across the "solution". Please feedback as I'd like to understand what I'm doing.

I used SMIT NIM / Perform NIM Administration Tasks / Configure NIM Environment Options (This is sounding obvious, I know)
I then selected two options, the one that made the difference, I'm not sure. Maybe someone could point it out?
"Export NIM Resources Globally" and "Control Client Resource Allocation / Set Allocation Permissions for all clients".

Any help explaining appreciated.

Thanks

Rob