Re: Re: Best way of restoring /etc from backups after fresh install?
Thanks everyone for the tips. I restored the backup successfully
(it's actually fast and easy when done properly - I spent more time
thinking what the right order is than the actual restore itself).
Looking back, the best way probably is to restore /etc and /home
from backups after a minimal install (nothing selected in tasksel
during installation), and only then aptitude install everything.
One must only be careful with PAM: my configuration uses a few PAM
modules that are not installed by default, so I could end up locking
myself out of the system if I only restore /etc but don't install the
other required PAM modules in the same login session (even so, it
might still happen than some of the installation scripts will fail
if PAM initially denies access to the daemon users). Well, that's a
possibility I really didn't want to check...
Since I wanted to clean up my config (I've been tracking Lenny
long before it became stable, so I missed all changes to the default
config from package maintainers), I went the etckeeper route:
- minimal Lenny install
- aptitude update after first boot
- installed etckeeper and initialized the /etc repo
- batch-install everything via aptitude
- cloned the repo, cp -a the previous config from backup in the clone repo
(since a restore with rdiff-backup would have deleted the repo directory)
- edited the new config files, cherry-picking some nice new defaults
from the package maintainers (together with my changes)
- merged the cloned repo back to the original in /etc
- restored the other backups (/home, /usr/local, GRUB's menu.lst)
- rebooted to the fully restored system
Well, the reboot was actually broken: cron and syslog-ng wouldn't start,
and init dropped me to an emergency shell since e2fsck was unable to run
(it found the partitions already mounted, so it couldn't check them). This
was due to the parallel booting, it seems the symbolic links were not
sanely restored (I haven't yet understood why), but dpkg-reconfigure
insserv fixed that, and the system is fully functional now.
Jesús M. Navarro" <jesus.navarro@undominio.net> wrote:
> Now, your restore process created some users which turned
> out with different UIDs because it needed. Don't give it
> the chance to need creating those users and you'll be OK.
> How can you acomplish that? Easy: just restore /etc/[passwd,
> group, shadow, gshadow] *BEFORE* the "xargs aptitude install"
> step. This way, by the time a package needs certain user it
> will find it already there with the proper UID/GID.
Right. I wasn't sure back then, but it was the only reason
I could think of. Now I have the confirmation from etckeeper,
most numerical ids are different now from the previous ones.
> You could restore the whole /etc tree before the aptitude step
> too. It certainly will ask what to do with conflicting files
> but it's just a matter to always choose the option "retain edited
> version" (or something to that meaning) which is the default option,
> so it's a matter of ENTER,ENTER,ENTER,ENTER...
Indeed, keeping the customized version of the config files is the
default, so ENTER would suffice (about 800 times :). An "export DEBIAN_FRONTEND=noninteractive" before aptitude install should
produce the same result (I didn't try, but that's what the debconf docs
say).
Best regards,
Laurentiu
Reply to: