Re: sync apt/dpkg state between systems?
Hello Bob,
Thank you for your answer!
Excerpt from Bob Proulx:
-- <snip> --
>>> # rsync -av /mnt/backup/etc/ /etc/
>>> # rsync -n --delete -av /mnt/backup/etc/ /etc/
>>> # rsync --delete -av /mnt/backup/etc/ /etc/
>>
>> I believe this not to be a good idea. When you do this you mess around with
>> config files under the control of dpkg. With all the mess that creates.
>
> Thank you for the review comment! However I respectfully disagree.
I gather we do have different opinions and workflows in this regard which is
absolutely fine.
Maybe i am too worried about this rsync method. Probably due to past
experiences. But it is just too easy to overlook s.th. see below.
> And apparently you do as well because you immediately suggested
> etckeeper which does exactly the same thing of managing files in /etc.
> It is the same thing but simply using a different tool.
In this regard i do have an other POV then you. I do believe that etckeeper does
not change any file in /etc without manually intervention.
(Obviously files in '/etc/.vcs' are excluded from this rule.)
So i think this is different from the rsync operation you suggested.
Let me tell you why i suggested etckeeper.
Here i use it to commit /etc into $VCS on a regularly basis. This helps me to
keep track of what is going on in /etc.
Being able to compare my modifications with the original is a feature you surely
will not miss anymore, after you get used to it.
> Most files in /etc are "conffiles". They are within the realm of
> control of the user. Changes to them are understood and respected by
> the package manager. There isn't any "mess" caused by interaction
> with dpkg.
I do have to commit that i did not spent time yet to understand that "conffiles"
system deeply.
I do have this snipped in my '/etc/apt/apt.conf.d/99local' though:
/-------------------------------------------------------------------------------
// --force-confold:
// do not modify the current configuration file, the new version is installed
// with a .dpkg-dist suffix. With this option alone, even configuration files
// that you have not modified are left untouched. You need to combine it with
// --force-confdef to let dpkg overwrite configuration files that you have not
// modified.
// --force-confdef:
// ask dpkg to decide alone when it can and prompt otherwise. This is the
// default behavior of dpkg and this option is mainly useful in combination
// with --force-confold.
// --force-confmiss:
// ask dpkg to install the configuration file if it’s currently missing (for
// example because you have removed the file by mistake).
Dpkg::Options {
"--force-confdef";
"--force-confold";
"--force-confmiss";
}
-------------------------------------------------------------------------------/
credits for this go to: http://raphaelhertzog.com
> However that isn't true of all files. And in particular there are
> uuids associated with lvm and md. The /etc/lvm and /etc/mdadm
> directories and any other UUIDs in /etc/fstab contain UUIDs and other
> information specific to the new machine and new filesystems. Those
> would need to be avoided when restoring from backup. Otherwise the
> new system would have the UUIDs from the old system and that wouldn't
> work.
>
> * Exclude /etc/fstab
> * Exclude /etc/lvm
> * Exclude /etc/mdadm
+ /etc/initramfs-tools/conf.d/resume
..and maybe some more. This is why i would look into the difference prior to
rsyncing. After i had become confident i would use rsync, too.
>> I would reinstall everything you had/need again and then diff prior to mass
>> overwriting the files.
>
> It is certainly a safe procedure to diff and review and merge from the
> old to the new. And making that the smallest possible set of merges
> by installing the smallest possible system first is easiest.
>
> Alternatively if working on the configuration files in /etc causes
> stress then it is certainly reasonable to avoid any merging at all and
> simply re-install what you had before and and re-configure whatever
> you want again. It won't be an exact copy then but everything will be
> freshly installed and fresh in your mind.
>
> Bob
>
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
Reply to: