Ross Boylan wrote: > Bob Proulx wrote: > > Ross Boylan wrote: > > > 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. > > > > But you said you were restoring an old system and had backups of user > > 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? > > Good point. But some of the system accounts have home directories in /var, > /usr (/usr/games) or elsewhere: /bin, /root, /dev. Interesting: several > accounts share /bin as a homedir; I'm a little surprised the system permits > that. When the package installs if a home directory for a system account is needed then it will create it at that time. When the package is purged most packages will delete the home directory while leaving the acount information in the passwd et al files. So no problem with restoring account information to /etc/passwd et al and not creating a home directory and then installing a package that creates that user. That reinforces my point that trying to get the options to adduser correct for each of the users is more trouble and error prone. You would need to browse the postinst script from the package that creates the user and manually figure out what it is doing and then do the same thing ahead of time. Lots of possibility for mistakes there. Better to let the package postinst script do it. It will be more reliable. > Since my backup of /var was somewhat selective, I might have missed some of > them. Then again, I might be fine. The others outside of /var should be > there anyway. Also a little surprising that some are in /var/run (identid > and jabber). Dirs for system processes that don't need a $HOME dir for files but for need a place to chdir to that isn't shared. > > > 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. > > > > System accounts are given options to make them simpler and to avoid > > 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. > > That reinforces your point that simply going through the old passwd file > and executing adduser will not necessarily recreate things exactly as they > were. Right. You would need to examine each postinst script in turn and do the right thing based upon what is there. Ugh. Too much trouble. Better to let the package postinst script do its thing itself. > There is an /etc/hostname just as there is an /etc/passwd, , and so I find > the difference in behavior suprising. I know: the hostname can be set > dynamically and so /etc/hostname isn't as authoritative as /etc/passwd. The differences are deeper than that. /etc/passwd is a database. It is queried routinely by many commands. 'ls -l' queries it. Change the passwd file and 'ls -l' output will be different because it queries the database. But /etc/hostname is a boot time configuration file of the /etc/init.d/hostname.sh script. Like many other boot time configuration files. You specify system configuration and at boot time scripts read that and set things up as configured. The system reads /etc/hostname once at boot time to load it into the kernel for use by later gethostname(2) calls and never again reads that file again after that point. (The kernel is like a daemon that only ever starts once.) > > Okay. You have convinced me. If you had already been using a > > 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. > > Yes, I have enough go on without changing my account management system at > the same time! :-) > On balance, do you think the restore lenny and upgrade option is better > than restore direct onto wheezy? It isn't a completely black and white issue. I would say 60% for restoring Lenny and upgrading and 40% for merging the changes into a fresh Wheezy installation (more merge work but avoids two upgrades). I would personally go for restore of Lenny to Lenny and then upgrade. Feels safer. Less merging and more on the documented and well tested upgrade path. But upgrades have some effort needed too. Like cleaning "find /etc -name '*.dpkg-*'" files at each major release point and ensuring LSB headers in all /etc/init.d scripts. But if you had not had the problem and had the working Lenny system to begin with then you would have that exact same upgrade work to do regardless. If you really want to have a really scrubbed clean system then restore Lenny to Lenny, upgrade to Squeeze, upgrade to Wheezy. Then install a fresh Wheezy on a second system (or VM) and migrate tasks and data one by one from your old system now upgraded to the new system freshly installed. At that point things should be mostly the same between them so the migration should be easy. But then you will know *exactly* what is going into the new pristine installation and will be absolutely guarenteed that it is all fresh and newly installed with no possibility of lint from previous actions. Only you can decide what you want to do. > > Good luck! I would be interested in hearing about snags you hit along > > the way or things that worked out well. > > I notice you didn't say *if* I hit snags! Haha! No. (chuckle.) Unfortunately there is bound to be something. But I think you have a good handle on things and will be able to deal with anything that comes up okay. Now get to work! :-) :-) Bob
Attachment:
signature.asc
Description: Digital signature