lock manager pid not in hcilockmgr directory

When you say it creates the file in your home directory do you mean the hci home directory (ex: on AIX /home/hci) or do you mean another home directory for example /home/me?

You mentioned an upgrade of Cloverleaf, was that upgrade done in place or on a different Cloverleaf server using a scratch install and a NFS mount of the old cloverleaf root to the new box so hcirootcopy could be fooled into thinking both versions were on the same box?

If the Cloverleaf upgrade was done in place on the existing box that is a riskier proposition of one stepping on the other during transition.

Now that I’m asking about an in place upgrade is the timing of this problem just after the upgrade or long after the upgrade and 2 versions of cloverleaf are no longer running on the same box?

Humor me and try these 2 different methods of starting the lock manager and see if the outcome is the same, I’ve run into problems with setsite at the command line if not doing a setroot -clear first.

Method 1:

echo $HCIROOT ; # mine is /cloverleaf/cis6.0/integrator

setroot -clear
setroot [code]echo $HCIROOT ; # mine is /cloverleaf/cis6.0/integrator

setroot -clear
setroot

This will not help determine the problem but sometimes we just want to get things working and give up on problem determination.

I had such a case with the cloverleaf database directory

$HCISITEDIR/exec/databases

one rare occasion.

I ended up shutting down lock manager on broken site and renamed the broken site dabase directory to hide it.

Then tarred the database directory from a known good site (probably siteProto) with the lock manager shutdown and then untarred it to the broken site and then did a hcidbdinit on the broken site and then everything works fine.

In your case we have yet to determine if your siteProto database directory is the problem, so clone the database directory from a site you observed works.

If tarring and untarring are not second nature like English, then let me know if that needs to be spelled out but I’m assuming you probably do that all the time with out even thinking like dialing your phone number.

If the problem reoccurs when creating new sites with hcisiteinit then might be a problem with the database directory for siteProto.

In which case fixing it there will circumvent future sites inheriting the problem.

Are there any soft-links between /home/hci and any of the root/site directory(s) that may be causing an issue?

Jim Cobane

Henry Ford Health

I quickly gave up on using AD login and doing sudo to hci.

My show stopper was that I was unsuccessful at adding any AD account user IDs to my FTP group.

AIX would not let me do anything with user IDs that weren’t local to the box, and none of the AD accounts are local to the AIX box.

For me that means we just use our AD accounts to

sudo su –

to become root and do system admin.

It is strange to me because the AD user approach seems to be a useless pain in our AIX environment that reduces security.

I asked for a command or a way to tell me who has AD access to our box and all they could give me was a command that tells me if a specified user has access.

My question to them was if I can’t tell who has AD access to my box how is that more secure?

About all I have is to watch the /home directory to see what user directories get created when those that have access login.

So my early observations about AD accounts so far are not all that favorable and a bit of a head scratcher to me.

Seems like an effective way to move the security of your box to a place or group that has no vested interest in my box and are like ghosts.

My confidence level with AD is far less than when we used local accounts we could manage and control.

Now we are back to everyone logging in as hci user to do work since the rather useless AD accounts were forced on us.