What files do I need to synchronize to ensure that my user-defined roles are being propagated to all nodes of my PowerHA cluster?

I'm using HACMP file collections to synchronize the files comprising the RBAC facility on my IBM PowerHA cluster. I've discovered that my user-defined roles are not being propagated to the other node(s). The following is a list of the files specified in the collection:

/etc/passwd
/etc/group
/etc/security/passwd
/etc/security/user
/etc/security/group
/etc/profile
/etc/environment
/etc/security/.ids
/etc/security/.profile
/etc/nscontrol.conf
/etc/security/authorizations
/etc/security/privcmds
/etc/security/privfiles
/etc/security/privdevs
/etc/security/limits

I've noticed a file named roles in the /etc/security directory; which is conspicuously absent from my collection. Are there any other files I've omitted?
babyb00merAsked:
Who is Participating?
 
woolmilkporcConnect With a Mentor Commented:
Well,

I can clearly see  that you already consulted the RBAC part of the AIX  Infocenter docs,
and you already discovered that /etc/security/roles is missing (this file should not change very often though).

Are you aware that the (updated) text databases must be (re)loaded into the kernel security tables area (KST) to make them work?

The command to use is "setkst". Invoked without parameter it sends all security databases to the KST.

If you invoke the file propagation by script you could add a "cl_nodecmd" call to run "setkst".

You could also add "setkst" to the application server startup script(s), of course.

wmp
0
 
babyb00merAuthor Commented:
Hey there!

So I guess the question is, where are my user-defined roles being stored? That's the stuff that's not being propagated! What is /etc/security/user.roles? Should I be synchronizing that instead of /etc/security/roles?

Yes I am familiar with setkst, and I do propagate this collection from the application shutdown script. What is the syntax of the cl_nodecmd?

By the way, have you been on vacation?
0
 
babyb00merAuthor Commented:
So I guess the question is, where are my user-defined roles being stored?
Oops, I apologize for asking the obvious.
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
woolmilkporcConnect With a Mentor Commented:
"roles" contains the defined roles, "user.roles" contains the user/role assignments.


cl_nodecmd

For particular nodes:

/usr/es/sbin/cluster/sbin/cl_nodecmd -cspoc "-n node_1,node_2,node_n" setkst

For all nodes:

/usr/es/sbin/cluster/sbin/cl_nodecmd setkst

Did I miss a question of yours? If so, sorry!
0
 
babyb00merAuthor Commented:
No. I was apologizing for a dumb question that I asked.
0
 
babyb00merAuthor Commented:
On an related matter...

I'm getting the following message when running a sync/verify...

Waiting on node nodename data collection, 2940 seconds elapsed

The verify has been running for an hour without even updating the log.
0
 
woolmilkporcConnect With a Mentor Commented:
Doesn't verify/sync work at all, or just the file collection transfer?

The  processes involved in file collection processing are clcomd and clconfd (now part of CAA) on PowerHA, and clcomd on HACMP.
Are these processes running?

If you are on PowerHA, is the multicast communication set up properly?

On PowerHA:

Find out the mcast address:

lscluster -c

(last line)

Issue on one node:

mping -r -a <configured multicast address> -v

On the other node:

mping --s a <configured multicast address> -v

Does it work?

If you have communication problems (PowerHA or HACMP) please check the configuration of your network switches (speed negociated/fixed, multicast enabled etc.)
0
 
babyb00merAuthor Commented:
Yes, I walked through some exercises with IBM to check the things you mentioned - although the mping command was not among them. Everything seemed to  check out okay. In the meantime, /etc/security/roles and /etc/security/user.roles did get propagated. I believe the technician wanted to rerun the verify with debugging turned on, but we never got around to it. I suspect he abandoned the idea after we discovered that the snap -e command also hung.
0
 
woolmilkporcConnect With a Mentor Commented:
mping is for PowerHA, not HACMP.

Which version do you run?

Could it be that one of your filesystems (/ , /tmp , /var) is full?

Could it be that there is a stale NFS mount?

Do you see something in errpt or the console log ("alog -t console -o")?

Perhaps a corrupt filesystem?

Hanging "snap -e" could indicate a stale or missing clcomd on one of your nodes. Did you check this process?

A good check for clcomd could be

/usr/es/sbin/cluster/sbin/cl_nodecmd date

Do all nodes respond?
0
 
babyb00merAuthor Commented:
We're running PowerHA 6.1.

Actually, we tried cl_rsh. We did check the error report, in which I saw a number of disk operation errors. The tech didn't seem to feel that they were significant. Perhaps that was because the verify didn't seem to be doing anything. It's not like it was generating a lot of messages - only the one. Don't forget, in ninety minutes, absolutely nothing was written to clverify.log. I'm thinking we should bounced clcomd and/or clcomdES (SP?).
0
 
woolmilkporcConnect With a Mentor Commented:
lssrc -a | grep clcom

stopsrc -s clcomd
startsrc -s clcomd

or

stopsrc -s clcomdES
startsrc -s clcomdES

according to what you found with the lssrc command.

Only one version can exist (clcomd or clcomdES), they never run in parallel.
0
 
babyb00merAuthor Commented:
As it turns out there was SAN maintenance underway at the time I attempted the verify. The one that runs at midnight ran without incident.
0
All Courses

From novice to tech pro — start learning today.