I'm hoping for a bit of advice on this...we have a need to synchronize users/groups between a couple servers in widely separated locations (our main DC and a disaster-recovery DC). This only has to happen, at this stage, with one server in each location, and the synchronization only has to happen in one direction (from main to disaster-recovery). We don't want to use directory authentication...this needs to be a synchronization based on the /etc/passwd and /etc/group files.
This seems to me something that others would have needed to solve in the past. Has anyone here implemented a solution for this?
Do you mean synchronizing users and all that goes with it (home directories, passwd and if exist shadow or trusted db and group files)?
To start, have a look at rdist or rsync! I dont think you will find them installed by default (but ofter in HA...) in which case you would have to go to your favorite HP porting and archive site.
The most important bit (that I'm having trouble with) is the one way, non-destructive, sync of usernames, numeric user ids (so that NFS mounts have no issues), passwords, and group memberships. The home directories and files are a much lesser concern.
If I remember rsync (and rdist but not sure anymore... long time) had a possibility on not overwiting if files were indentical...Now the question is more when you are syncing, it is more to update for all users (concerned) their passwd they have changed on the master server, then update modifications like new users and groups... Till here you should not have any issues.
Removing users is different for you find yourself having to decide what to do with users files all over the system(s) so it is not wise to remove them on the master before you have decided what to do and cleanup on all slaves then master.
What we used to do e.g. new user: create on master then create the accounts where needed in urgence so the user could work immediatly not having to wait for synch...
Have a script ready for synchro you can use anytime if needed and schedule a synchor when there is minimum activity
I would go with rsync...
I think you should have in mind that wherever NFS is used, "the right UID" is always the major concern - and THAT's why NIS was invented in the first place (then NIS+ and now we use LDAP) ;
if you have a legacy environment where NFS was deployed without taking the various UID into account - then ... sorry - you're doomed. :wall:
but if you have a chance to do a fresh setup, then REMEMBER :
1) every username MUST have the same UID on ALL servers suitable to NFS perusal ;
2) it does not matter if you will accomplish this task 'manually' or thru NIS/NIS+/LDAP - the choice will only change the amount of work to see it done ;
We have had to do this. At first it seemed impossible because the oldest users on the master system had UIDs which clashed with system users the backup system.
Do not embark on this sort of exercise without an Ignite backup and a full backup of your system and a decent amount of booked downtime.
To cut a long story short, and working on a non-Trusted system:
Used "vipw" on the master system to move any system accounts to be definitely before any user accounts in /etc/passwd. This is only needed if system software was installed after any user accounts. i.e. what normally happens.
Created a cross-reference table of before-and-after UIDs and changed every non-system UID to a new range well clear of the system accounts (I chose 1001+). The choice of 1001 for the base was because I did not have any UID higher than 1001 on the master system or the backup system. This is not trivial because after changing the passwd file with "vipw" it involves issuing the correct "find" and "chown" command for every file owned by every non-system user.
Once you have got all your user accounts in a section of /etc/passwd which definitely does not contain any system accounts you can copy files at will to your backup system and periodically replace the "user" section of the /etc/passwd file with the user section from your source system using "vipw" (which can be scripted).
I must stress again that this technique does not work at all on Trusted systems.
There was a hint earlier. Never delete a user account. Lock it, remove data files, whatever, but do not delete it from /etc/passwd. It will mess up you backup system big time the moment you allow two different users to have the same UID.
Imho. In a D.R. backup scenario, never let two different users have the same UID.
