[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 {

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


721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F

Reply to: