Re: sync apt/dpkg state between systems?
Hello Bob,
Excerpt from Bob Proulx:
-- <snip> --
>> 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.
>
> This is where our strategy of attack on the problem is different. I
> started from the idea that there are a lot of files in /etc but only a
> few of them need to be excluded from the restoration. Therefore
> identify the files that should be excluded. Then restore everything
> *except* for the files that should be excluded. Whereas I think you
> were started from the idea that there a lot of files in /etc and only
> the known okay files to restore should be restored. Identify the
> files that should be restored and only restore those files.
>
> Basically one strategy is include all but those excluded and the other
> strategy is exclude all but those included.
>
> I think we are in agreement that some files must be restored and some
> files must be excluded. We differ on the technique to get there.
Excellent summary!
It is like positiv vs. negativ logic in bollean algebra. If you know the rules
with both you can reach your goal, just the way in between is different.
-- <snip> --
>> Dpkg::Options {
>> "--force-confdef";
>> "--force-confold";
>> "--force-confmiss";
>> }
>> credits for this go to: http://raphaelhertzog.com
>
> That controls the behavior of dpkg when it would normally stop and
> interact with the user admin who is installing or upgrading a package
> about the handling of a conffile. Should you install the new package
> file, keep the existing file, or merge them? Or see the differences
> between them? The above answers those questions globally so that it
> never stops to ask a question.
>
> I fully agree with confmiss. I routinely set that too. But I have
> seen heated arguments from people who have argued (apparently
> successfully because the change went in) that removing a required /etc
> file is a desired configuration and that it must be preserved.
> (Regarding the /etc/network/interfaces file.) This adds yet another
> logical state to be considered.
>
> I use a system configuration management system similar to cfengine,
> puppet, chef that I have programmed to configure the system. I have
> directed it to read-modify-write various configuration files to set
> them as desired. In that type of environment it is advantageous to me
> to use confnew. With confnew I will always get the package version of
> the file with the package default configuration. Which will then
> immediately be reconfigured into my desired configuration by the
> system management tool.
I understand we do have a common understanding of handling such things.
As i do not have to administer a bulk of systems i differ in that i do not have
the need for an advanced configuration system as cfengine.
But apart from that my workflow to handle /etc is similar to yours.
With 'confold' dpkg by default keeps the configuration that is already in place
in production and installs new configurations from DMs as foo.dpkg-dist.
My VCS then notifies me about new or changed files and the i go through them and
merge them as i see fit.
-- <snip> --
>>> * Exclude /etc/fstab
>>> * Exclude /etc/lvm
>>> * Exclude /etc/mdadm
>>
>> + /etc/initramfs-tools/conf.d/resume
>
> Ha! I always use lvm and so for me the names in the
> /etc/initramfs-tools/conf.d/resume file are always logical names and
> would be the same across systems. But point taken. If that is a UUID
> then it should be excluded from the restore.
here on my system it does:
$ grep -o 'RESUME=UUID=..........' /etc/initramfs-tools/conf.d/resume
RESUME=UUID=7bb317c1-e
> Plus there is your note about ethernet addresses. In addition to the
> 70-persistent-net.rules file that may also affect people using
> "guessnet" or other such networking packages.
>
>> ..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.
>
> At the center between the strategies of include and exclude is the
> need to identify which files must be included in the restoration and
> which files must be excluded. Having that list then we would restore
> what should be included and avoid those that should be excluded.
>
> I think you and I would both identify these files on-the-fly by seeing
> the files, by looking at the file contents, by other dynamic decision
> making. But I fear that for many people that would be beyond their
> level of skill. Our discussion shows that it isn't trivial. It takes
> some experience.
>
> Can we document what we have learned from this discussion? Would
> someone be able to follow that documentation and successfully peform a
> restoration as described? Is it possible to create a script that
> would analyze the backup and the new system and would then identify
> the files that should be included and excluded? I think we can do all
> of this but am leaving it as an open question for the moment.
Nice idea. Although if one is willing to spend that time then it might also be
usefull to look into d-i pre-seeds more closely beforehand.
I imagine with cfengine and a somewhat dynamic d-i pre-seeds you are already
close to that.
About documentation:
Obvisouly i take notes when doing dist-upgrades. So that i do not the same
errors during each run on different systems.
One big notes of that is:
Upgrade the kernel and udev beforehand the rest of the system! Otherwise the
udev-maintainer pulls your plug in the middle of the dist-upgrade run.
I know he has a difficult job to do, but hey guy this is not nice! ;)
>
> Bob
>
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
Reply to: