Syncing password files

[Klaas D. Eenkhoorn]

Ok, so using usermod.sam is no option and simply copying the password file results into problems.

An other question: Is there a way, or a script, witch compares two files and syncs them ?

My idear: use a cron job witch copies the both passwd files to a temp location, compares them and combines them to a new one and this new password file will be placed back to the both systems and important !! retries if either one of the original files have not been changed in the mean time.

Fact is that no user is using the both systems at the same time, ok user root but he has no password expieration time set and i'm root so i know what i'm doing (most of the time ;-) and service accounts are locked.

I'm not bad at scripting but this one goes biond my abilities i'm afraid . . .

Kl@@S

[Klaas D. Eenkhoorn]

Sorry, this is a follow-up on message
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=616005

[Elmar P. Kolkman · Accepted solution]

If you have a way to determine which line is the newest one...But I don't know a way to determine which line in a password file is the newest. Do you?
But the script would become something like this:

(cat passwd.serverA passwd.serverB) | sort -u | while read line
do
newuser=$(echo $line | cut -d: -f1)
if [ "$olduser" = "$newuser" ]
then
if [ $prevline newer $line ]
then
echo $servA
else
echo $servB
fi
olduser=""
prevline=""
else
echo $prevline
olduser=$newuser
prevline=$line
fi
done

if [ -n "$prevline" ]
then
echo $prevline
fi

[Klaas D. Eenkhoorn]

Ok, you've got a point there . . .
I was thinking about using 'diff -e file1 file2 > script' and then 'ed file1 < script'

But indeed how can you tell witch line is newer . . .

Is it an option to exchange modifications on the passwd file to the other system based on diff ?

[Elmar P. Kolkman]

I still think using the tcb files is the better way to do it. Then looking at the modification time is enough to determine which entry is newer... But it would mean changing the system to trusted mode.

[Geoff Wild]

Try implementing NIS or look at a third party solution - like Unix Control:

http://www.tfstech.com/solutions/unixcontrol/index.htm

Rgds...Geoff

[Elmar P. Kolkman]

Klaas, thanx for the sleepless night. But I think there is a solution...

By keeping track of the last passwd file you generated, you can compare both current passwd files to it and all changes need to be copied to the current passwd file on the other server. Then you copy the file from one of the servers to the last generated one and after some time do it again. So, the current passwd files are always the newer ones.

There is one possible problem: changes on both servers. In that case you can't be sure which one is the newest, but that can be ignored as a user error. And in most cases the password is then changed to the same new password on both servers, even though the encrypted one looks different. But that's due to a different salt.

[Sridhar Bhaskarla]

Klaas,

Elmar got good points and ideas.

If it is a trusted system, the job will be lot easier. The password change time will be recorded in the tcb file corresponding to the user and you can have a cron that compares the change times on both the servers and sync'up the passwords accordingly. I do not see any problem using usermod.sam to sync the passwords. Manually editing or manipulating the password file is not a good idea.

On non-trusted systems, as you already experienced, it is difficult. I would think of a wrapper script that actually calls the passwd program. But there are issues with that approach too as patches can overwrite the binaries in addition to the headache of writing such a program.

You can think of products like control-SA, LDAP etc., that can do the job for you.

-Sri

[Klaas D. Eenkhoorn]

Elmar,

Yesterday i'v been brainstroming and the attatched script was born.
It's not finished yet but can you all take a look at it and tell me if this is a way to do it or if it is suicide.

The idear is to use a patch meganism to sync the passwd files knowing that a user is loged-on on only one system at a time.
And service accounts are locked and have no password-aging activated.

Hope to hear from you all,

Kl@@s

[Klaas D. Eenkhoorn]

All,

Allthough NIS and LDAP would be the better solution, i know, the problem is we have only 2 clusternodes.
If i make one of them NIS(+) master or the keeper of LDAP if that node fails i have a problem.
And the financial recources are not big enough to buy a third or more nodes.

Using LDAP in combination with Windows 2003 AD would mean i have to handover control to the Windows boy's and they have to by Windows services for UNIX to make it work.
Not that i do'nt trust them . . . but you all will know what i mean.

Converting to a trusted system is probably an option but i do'nt know what i'm getting my self into when i do that.
Those who installed our cluster adviced not to do this conversion.
I hav'nt seen them making a mistake so far so i trust there judgment on this matter.

Kl@@S

[Simon Hargrave]

Trusted hosts would be the best option.

If you want to keep the passwd files on the 2 servers in sync, why not dedicate one server as the "master", and do all password changes/creations etc on that server. Then have this periodically sync onto the other host. If you do this there's no need to worry which will be newer, as the master will always be newer.

Clearly this would need a process in place such that users always change their passwords on the master server only, but with the correct procedures in place it shouldn't be too difficult.

As an example, on the secondary server, you could replace the "passwd" binary with a script to inform the user they must change the password on the master server. On the master server, you could have a shell wrapper around the "passwd" binary that changes the password, then copies the passwd file to the secondary server.

Needs some thinking about, but definately doable.


Sy

[Klaas D. Eenkhoorn]

Thanks for all the replies and thinking !!
But . . . i'm going to stop this discussion.
Not because i don't like the the replies on my question but it is to complicated at the moment.

Kl@@s Eenkhoorn