Password file in a cluster

[mvr]

Hello,

We have two HP-UX 11i servers that are joined in a cluster. They are sharing one package. When ever server number one goes down and the server number two picks up, we have a problem with users login. Password file is not in a sink across two servers. I would like to get some suggestions how to copy (and maybe add date stemp to the name of copyed file), from one server to another. FTP and TELNET are closed, but SFTP is open.

Regards,
Miro Vran

[Kurt Beyers. · Accepted solution]

Miro,

place the password file on a LVOL owned by the cluster package and create a symbolic link on both nodes to the password file.

The information will always be in sync now.

Kurt

[Stuart Abramson_2]

Do you run trusted password file or just regular password file, /etc/passwd?

I guess you don't run NIS password file..

Let's say you just run the normal password file.

You could just rcp the file over, or sftp. but you have to take care that all users are defined on both sides and that they have the same uid/gid on both sides. And that all groups are the same on both sides. Probably you will have to copy the /etc/group file as well.

Here's an interesting fact:

1. Both of these password file entries are for the same password (on different servers):

# grep saroot /etc/passwd
saroot:OK4hGX3bM9gBE:0:3:PSEUDOROOT ...

# grep saroot /etc/passwd

saroot:RLNpquAEpxWr6:0:101:Stuart ...

2. They look different because the encryption algorithm uses the date
and/or time in the encryption process.

3. But they will decrypt to the same password.

4. And they will work properly if you copy them around from server to
server.

[Elmar P. Kolkman]

Main problem with copying the passwd file accross the two servers is that 1 of the servers will become leading: all changes to the file on the other server are ignored.

What I would do to make it work, is to mark one of the servers or perhaps a package as leading and then copy the passwd file using scp, sftp or something like that (rsync springs to mind) accross to all other cluster nodes. By making the package leading, the users can change their passwd even when the package has fail-overed. But mind that users in packages on the other node will loose any passwd changes...

If that is not what you want, there is another way if you can define a regex that only matches the users that need to be available for the package: at regular intervals, copy only those lines from the passwd files to a lvol for the package and when the package starts, copy them back into /etc/passwd and other places they should be (/etc/shadow, /tcb/..., etc.)

[mvr]

I like the idea to put the passwd file on a LVOL and create link to it, but is there a way to automate (with the cron) copying the file as well (as a backup solution)?
We are not running in a trusted system so we are using a regular passwd file.

Miro

[Stuart Abramson_2]

I DON'T like the idea of putting the /etc/passwd file any place but in /etc/.

If you boot in single user mode, which hopefully you don't do that often, you won't have a passwd file.

Shared disks are, by definition pretty much, not internal drives, and you can't always be sure that they will be there when you boot.

[A. Clay Stephenson]

You definitely don't want the passwd file in a VG that is not mounted at boot time. That means vg00 and leave it in /etc.

The real answer to your question is NIS, NIS+, or LDAP.

[Chris Watkins_1]

Why not simply make sure each username has the same uid/gid
on both machines? This is much simpler, if you want to
continue using the regular /etc/passwd file instead of NIS/etc...

If you don't have hundreds of usernames, I'd sure look into it.
Particularly if you only have a few usernames to "convert"
to a new uid or gid. You just have to seek out their files/dirs
and chown them to the new id/gid once you make changes.


We do this across many servers, including a 4 node cluster.
Just as root is uid "0" on every box, oracle is uid XXX,
my personal username is uid XXXX, etc... it really simplifies things.

[Laurie Gellatly]

What about copying passwd to shared disk
as part of the package shutdown (and via cron so even a crash will be catered for) and then copying it from shared disk
back to /etc on package startup?
This way passwd for the package is always in
sync for the "on-line" node and modifications are taken along with the package?
It also means that single user mode will still work and passwd is in its "normal" place
and there are no user passwords sitting around in clear text files that might be needed
for "ftp" type solutions.


HTH ...Laurie :{)