[SunHELP] RE:making UID's match between boxes
Les Brigance
brigance at us.ibm.com
Mon Aug 26 09:27:29 CDT 2002
We generally do this using NIS, but do have
about 6 boxes which are not under NIS or NIS+
which have the uids manually matched.
It IS a pain when adding a user to have to manually select and
match the uid on all 6 machines.
It is MORE of a pain when the user(s) change a password on one or two
machines and forget to do it on others. That always results in calls to
the
sysadmin to "FIX" the problem.
It is a requirement that the uid(s) match however since the /home
directories
are NFS mounted from one box to the other 5 thus the first ID has to be
created
on the box which actually has the filesystem.
The other boxes have to be manually matched so the
user(s) can do things within their home directories.
Those are the only problems I have really encountered with doing this.
It is done on boxes running Solaris 2.5.1, Solaris 2.6 and Solaris 8.
Don't think it matters but the /home directories are on a Sol 8 box.
Might be somewhat of a problem if it were a 2.5.1 O/S
Les
Subject: [SunHELP] re: making UID's match between boxes
On Sat, 24 Aug 2002 sunhelp-request at sunhelp.org wrote:
> From: "Markham, Richard" <RMarkham at hafeleamericas.com>
>
> Hi I want to make the UID's for a particular user match between boxes. If
I
> change
> the UID in /etc/passwd then every file that the users owns will now
reflect
> the
> owner's previous UID. I belive I can resolve this with:
>
> find ${workdir} -user ${olduid} -exec chown ${the_owner}:${the_group} {}
\;
>
> Does anyone know of anything more to consider? This user owns a large
> amount of
> files.
i've always heard that it is a _very_ bad idea to make UID's match on
different machines. but i can't make a justification for that.
can someone comment on the issues and if it's only a bad idea to have
two UID's match if the usernames are different.
-ron
We run a small branch office that way - 3 unix boxes (15 users).
UID/Username are identical on all boxes. Only observed problem is
administrative - it would be a big pain if we had more user churn there.
~brian
More information about the SunHELP
mailing list