Wednesday, July 2, 2008

Re: [BLUG] scp -p preserving ownership through root user

On Wed, Jul 02, 2008 at 01:05:01PM -0400, Brian Wheeler wrote:
> We use the UITS UID on our machines so we get some really large UIDs...I
> make it a point to always specify the new user uid just so I don't
> clobber a future employee by accident.

Do you use NFS? I also work at UITS, but don't make use of any remote
storage, so using a common network UID is just more work. It isn't
standard (particularly not standard for Debian or Ubuntu) so the
cost/benefit just isn't there for me.

Now, I've thought about automatically adding users as they appear in the
proper LDAP group. That may make it easier to use the UITS UID. That's
below a number of current priorities at this point, though.

At this point, I can basically run one command and the user ID is
added/removed from the majority of the services I control. Things
aren't perfect yet, but automation is a passion of mine, so things will
improve.

> Here's what I was doing: I booted a rescue CD and did a full system
> copy from a remote machine to the one I booted the rescue disk on. The
> system accounts had different uids (sendmail, in particular) so when I
> booted the resulting system, sendmail was broken because the uid suid
> binaries didn't match the sendmail uid in passwd.
>
> When I recopied it later I used the --numeric-uid option and the IDs
> were synced up properly.

Ah! I know why the --numeric-uid option made a difference. You were
copying the entire system, including passwd/group files. This means
that the first time you copied the files, midway through the process
passwd/group were over-written and what had earlier been the sendmail
user became someone else.

Using --numeric-uid prevents this problem as it ignores the destination
passwd/group files. (It doesn't need them, as they'll be over-written.)

This is totally the reason that --numeric-uid exists. However, the
reason it isn't the standard is that unless /etc/passwd is being
touched, it will only aggravate your trouble.

> I didn't explain it properly, but any time there are differences between
> source/dest password files there may be issues. Gnu tar does a pretty
> good job of getting it right, but there are still surprises lurking for
> the unwary.

I concur completely.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

No comments: