Ross Boylan wrote: > Bob Proulx wrote: > > > 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. 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? > I presumed adduser does other stuff too, which would not be done > (aside from groups and passwords) if I skipped it. It is possible to provide local system specific hooks. But if you haven't provided any then there isn't anything else that is done. (When adduser creates a /home directory it copies in /etc/skel. But again if you are restoring /home from backup that doesn't apply.) The only thing done when creating a new user is /etc/passwd, group, shadow, gshadow and /home/$USER and copying /etc/skel there. Nothing else is done. You can always create user accounts yourself with an editor, mkdir, cp, and chown. > 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. > > For the very small number of packages and their system accounts just > > go ahead and use the old numbers and then chown the files on disk to > > match the new numbering. > > This is referring to restored files, right? I.e., restore them, which will > give them the old ids. Then chown/chgrp to match the new system. Yes. A restore could restore the old uid:gids but those are not the right ones for the new system. Or if after installing the new files you need to change the uid:gid because of changing the account numbers. In that case you need to change files owned by that account number. For example files for bind in /var/cache/bind. If you needed to renumber it then you would need to change the files appropriately. > > If you are sourcing passwd, group, shadow, gshadow from a very old > > system then you probably shouldn't just copy it into place. > > I think you mean if I restore the files from the old system (Lenny) onto a > new one (Wheezy), be careful. Being careful doesn't mean don't do it. It just means understand what is going on and make an informed decision about how to deal with it. Also for system things if you really get into trouble with something you could always purge the package entirely. Then if you feel like it remove the accounts from passwd et al. Then install the package again. That installation will appear as a pristine installation since other remnants were removed. That would clean up any lingering issue if you had a problem package. For example ntp, bind9, munin-node or some such. Just purge the package, remove the account, install it again. If you have configuration in /etc then save it use it to configure the new installation of that package. For simple things like the above that is very simple. Even for more complicated things like Apache, PHP, MySQL then if you have the previous /etc configuration for them then you should be able to use it to reconfigure the new installation easily. > I was actually thinking of trying to virtually reconstruct the old > machine, including the fact that it was running Lenny. That would work nicely. And then because it would be a restore of the same version then there is less problem with different versions of things. After you get the system going then you can upgrade it from Lenny to Squeeze and from Sqeeze to Wheezy. You should still be able to install Lenny. You will need to enter the repository url manually and select the archive.debian.org URL. For example this will work fine. deb http://archive.debian.org/debian lenny main contrib non-free > > Probably okay. > > meaning I might get away with just copying? Yes. If you had Lenny and you are recreating Lenny then you should be able to just copy the file into place. > > But perhaps a lot of differences in the system accounts and you > > would need to walk through each releases update-passwd script. > > > > Instead then I would merge the files. I would sort the file by uid to > > instead of what? Instead of copying. If you were restoring Lenny files but trying to work on a Wheezy machine then restoring Lenny system accounts would require working through the Squeeze base-passwd changes (if any). But if you are setting up Lenny and restoring Lenny then I would simply copy the entire file. > Are you thinking of retrieving the version-specific update-passwds > without actually putting the whole system through the upgrades.? > That's not what I meant. No. Sorry. The number of potential cases and the subtle differences is getting confusing. :-) > > make things easier. > > > > sort -t: -k 3,3n -k4,4n /etc/passwd > > > > Then all of the system accounts with small uids are at the top. All > > of the user accounts with large uids are at the bottom. Copy just the > > user accounts from the old to the new. Then repeat with group, shadow > > and gshadow. > > I think we're talking past each other. Possibly. Sorry. > When I said "restore the old system into a VM and upgrade it" I > meant that inside the VM I would be running the entire old system, > not just borrowing some of its files. So the VM would start as 32 > bit lenny with all my old files. I'd then upgrade to squeeze and > then wheezy. Somewhere along the way I'd need to switch to 64 bit. I approve! :-) That should work fine. > > > I think this needs to be done in a VM not a chroot, since the latter > > > will get its uid/gid info from the host system. > > > > 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. > > > This also has some uid syncronization issues since I must recreate > > > the system before putting the files onto it; these should be less > > > acute since a variant of 1 should work more cleanly. > > > > I didn't understand this part. > > Old dead system was Lenny. So I bootstrap a new Lenny and install the > packages that were present in the old system. To actually get the same > ids that I had before I must either install packages in the same order I > did before or setup the necessary id mappings (in /etc/passwdd et al) so > that as I install the packages they get the right ids. Yes. You have it. > Then the remark about this working more cleanly means doing an old Lenny on > top of a newly bootstrapped Lenny is likely to match accounts more smoothly > than old Lenny on top of newly bootstrapped wheezy. Which I think is what > you have been saying too. Yes! :-) > > > 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? 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. > > If it were me I would run through the debian-isntaller and install the > > absolute minimum system possible. > > Lenny or wheezy? Since you are restoring Lenny I would install Lenny. It makes things so much easier because there is a one to one match. Then upgrade it through Squeeze and to Wheezy. Good luck! I would be interested in hearing about snags you hit along the way or things that worked out well. Bob
Attachment:
signature.asc
Description: Digital signature