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

On Wed, 2008-07-02 at 13:45 -0400, Steven Black wrote:
> 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.
>

We're not using NFS, but when the policy got set we were using DFS so we
had to keep in sync with UITS. Now its more habit than anything else.

> 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.
>

Rumor has it that the posixUID field in Active Directory will be made
available in the not-too-distant future. Also, I believe there may be a
SOAP interface available.

> 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.
>

With our servers I have one machine that has a master copy of
passwd/group/shadow and I have cron jobs on the other machines which scp
it over and merge it with the system accounts on those machines (it also
determines if an account is locked and sets the .ssh directory to mode
000 so public/private keypairs aren't available for the locked user). I
use pam + groups to determine actual access to the machine.

> > 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.
>

Yep. I was making a physical machine into a virtual machine with a
different sized disk :)

> 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

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