You can, but there are a few things you need to track along with the
files.
My list consists of 4 files: /etc/passwd, /etc/shadow, /etc/group, and
/etc/login.defs in a pure SuSE environment -- I don't know (haven't
looked)
if Red Hat systems depend on these same files (/etc/login.defs in partic-
ular). Besides syncing all these files, make sure you check for:
- Proper uid/gid assignments to filesystem objects. Sounds
painful,
but find and xargs are your friends -- keep the previous files
around until all are reconciled (who was UID=562 again?). The
particularly thorny problem of userids deleted through
replication
will have to be tackled here: what are you gonna do with their
filesystem objects? I don't think you can just let them exist
under the extant uid/gid number; otherwise you might have "rogue
owners" of filesystem assets whose confidentiality properties
are
unknown to you.
- Any uids/gids affected by changes are kicked off the system
until
you've updated them. You might want to consider doing this in
single user mode once you've transferred the files in (under
different names).
- Review cron tables to be sure all userids who implement them
have
uids & gids _after_ replication. Delete any crontabs for those
who don't. You might want to shutdown crond while you do this.
- Review your mail aliases to ensure that any "to" userids still
exist following replication. You may need to re-run the program
that creates aliases.db if there are any changes.
These need to be examined on every system to which you replicate these
files, every time you replicate. It's not pretty, but it works. It helps
to keep passwd & group sorted in ascending numeric id order, too, so that
you can pre-assess the "damage" you're going to do through replication.
Also, grpck and pwck are your friends, too -- run these on the master
system before you even think of replicating.
As others have noted, it's a lot easier (and safer) to run LDAP or NIS.
This should only be considered a stopgap measure until you can do
something site-wide. If you personally don't administer all replication
targets, be sure you talk with other admins before you do this: any
user/group ids they might have created are likely to be dead meat once
you replicate.
If you can come up with default policies about what to do with assets
owned by replication-deleted uid/gid entities, this could pretty easily
be scripted. There are other things to consider too, like should uid=1221
belong to gid=502 on ALL systems? Or are there group-connected assets
that any specific user/group might need permissions to on a specific
system. A lot depends on how politically-controlled your network is, and
which machines play which roles in your business process.
z/OS is (or at least, used to be) ignorant of the "system & daemon uid
values must be < 100" rule. Be careful if you allow z/OS to be the master;
I got badly burned on this one.
--Jim--
James S. Tison
Senior Software Engineer
TPF Laboratory / Architecture
IBM Corporation
"If dogs don't go to heaven, then, when I die, I want to go where they
do." -- Will Rogers
Linux on 390 Port <[EMAIL PROTECTED]> wrote on 04/21/2004 10:57:37:
> I ultimately want to go the LDAP route, but I'm having issues with our
> security folks on the 'native' Linux IDs, and things installed by
vendor
> software such as DB2. They are fine with things that conform to our z/OS
> ID's and passwords... but this left field stuff is causing them pain.
>
> For my own sanity and consistency, I was hoping that I could simply copy
> /etc/shadow and /etc/password to a new system and have a common base of
> users and process ID's in place until such time as I can resolve the
LDAP
> requirements with those who control security.
>
>
>
>
> Adam Thornton
> <[EMAIL PROTECTED]
> mine.net> To
> Sent by: Linux on [EMAIL PROTECTED]
> 390 Port cc
> <[EMAIL PROTECTED]
> IST.EDU> Subject
> Re: /etc/passwd and /etc/shadow -
> synchronized on multiple images
> 04/21/2004 09:48
> AM
>
>
> Please respond to
> Linux on 390 Port
> <[EMAIL PROTECTED]
> IST.EDU>
>
>
>
>
>
>
> On Wed, 2004-04-21 at 08:24, James Melin wrote:
> > What is the best method to duplicate the user list, GID/UID
assignments
> for
> > users on multiple Linux guests and keep them consistent?
>
> NIS is the traditional way to do this, but I find it to be a pain. Many
> sites prefer to keep user information in an LDAP directory, which also
> has its issues but if you use an encrypted transport isn't too bad, and
> interoperates a lot better with Active Directory and RACF. There's no
> really *easy* way to do it, though.
>
> Adam
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
