Ross Boylan wrote:
> Bob Proulx wrote:But you said you were restoring an old system and had backups of user
> > > I suppose it would be safer to have a script read the old files and
> > > do adduser/addgroup as appropriate, since that would assure the home
> > > directories existed (and maybe do other stuff I'm not aware of).
> >
> > Safer how? It seems much more complicated. Because you would need to
> > specify all of the parameters as options to adduser. Complexity leads
> > to the higher possibility of errors. Therefore I think it is more
> > dangerous.
>
> If I don't adduser then home directories won't be created, even though
> /etc/passwd will refer to them. I figured that would lead to
> problems.
data but not of /usr. Or did I read that wrong? I assumed you would
restore /home and therefore would need the on disk restore uid:gid to
match the accounts. Therefore /home $HOME directories will be created
by the backup restore. No?
System accounts are given options to make them simpler and to avoid
> Your later remarks indicate there may not be much more adduser does.
> Actually, some of the skeleton files it usually copies may be
> inappropriate for system accounts.
all of the niceties given to real users. Such as this example from ntp.
adduser --system --quiet --ingroup ntp --no-create-home ntp
Or this one from bind.
adduser --system --home /var/cache/bind --no-create-home \
--disabled-password --ingroup bind bind
You can browse through and see other examples.
> > A chroot does *not* get uid/gid from the host system.
>
> Thanks for the correction. I figured since the hostname in the chroot
> comes from the host (I think I've been told) that users and groups had a
> similar story.
Yes on the hostname. There is only one kernel. Therefore asking the
running kernel gethostname(2) can only return one name. But that
doesn't apply to getpwent(3) which matches uids up with passwd account
entries. It may seem similar. But one applies to the system, of
which there is only one. The other applies to users, of which there
may be many users.
Okay. You have convinced me. If you had already been using a
> > > Since I use VMs I should probably be using LDAP, but I think that's
> > > best left for later.
> >
> > Using or not using LDAP for accounts I see as completely orthogonal to
> > this question. (Same for using mysql too.)
>
> If a VM gets its account info from LDAP then it will use the same UIDs as
> elsewhere on the host and other VMs. So doesn't it provide a natural way
> to ensure the ids match, even if the virtual systems are different
> releases?
centralized database then it would be easier to restore. But if you
haven't then I don't think I would try to set one up just for doing
the restore.
Good luck! I would be interested in hearing about snags you hit along
the way or things that worked out well.