[Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT

Alex Elsayed eternaleye at gmail.com
Sat Feb 18 05:11:06 UTC 2012


Could I get people's opinions on how sensible this is?


The current layout of a directory under CONFIG_PROTECT is somewhat
less than ideal. An update to a protected directory results in
._cfg0000_.* files strewn throughout, with no information as to their
origin. Also, this layout does not interact well with configuration
management tools such as etckeeper. Here I will propose an alternate
method for achieving the goals of CONFIG_PROTECT.

First, a different layout could bring many benefits both in terms of
functionality and performance. In all examples, we will be treating
/etc as the directory under CONFIG_PROTECT.

For a new layout, we should avoid splattering dotfiles all over the
directory tree. It would also be beneficial to record the package that
tried to merge the file, as well as a timestamp.  Conveniently,
exndbam already stores a timestamp.

This is how I imagine the new layout might look:

/etc/
    .config-protect/
        new/
        old/
        resolved/

When the package manager comes across a file with a destination that
is under CONFIG_PROTECT, it should create a directory of the form
${TIMESTAMP}---${CATEGORY}---${PN}:${SLOT}:${PVR} under 'new'. It will
then merge the file that has a CONFIG_PROTECT destination to the
newly-created directory as if it were the destination. Note that the
package manager will *never* merge directly to a CONFIG_PROTECT
directory, even if there is no preexisting file.

When the user next runs 'eclectic config', it will scan
/etc/.config-protect/new/ to see what action needs to be taken. This
should be a considerable performance improvement over the old system -
while still O(n), now n is 'the files that need updates' rather than
'all files in /etc.'

I see no need to change the user interface of 'eclectic config' at
all. It will behave exactly like before from the user's perspective.

However, in order to support configuration management properly, we
cannot have the user altering the original files in the course of
managing these updates. Therefore, when the user would perform an
action that could modify the original file, the original file is
instead copied to the 'old' directory and the action is performed on
the copy.

To give an example, if we have a config file /etc/foo/bar.conf which
has an update pending in
/etc/.config-protect/new/00000.00---foo---bar:0:0/foo/bar.conf,
and the user chooses to merge them, the original will be copied to
/etc/.config-protect/old/00000.00---foo---bar:0:0/foo/bar.conf
and the merge tool will be called on that copy.

As a resolution is decided upon, the final resolution is placed at
/etc/.config-protect/resolved/00000.00---foo---bar:0:0/foo/bar.conf

If there are multiple pending updates for a single file, then the
updates are applied serially in chronological order. The copying of
the old version uses the 'resolved' entry from the previous update to
that file.

After all updates have been addressed (which can be checked for by
testing whether for every file in 'new' there is a corresponding file
in 'resolved') eclectic config iterates over
/etc/.config-protect/resolved/ in order of timestamp from oldest to
newest. For each, it overwrites the original with the resolved
version.

At this point, if etckeeper or some other configuration management
system supported by eclectic is enabled (support is provided via
plugins), the files changed by that specific update are treated to the
equivalent of

git add /etc/foo/baz.conf
git commit

The default message would be something like
Conf update for ${CATEGORY}/${PNVR} from `date --rfc-3339=ns -d
"@${TIMESTAMP}"`

but would be open to editing.

It should be noted that /etc/.config-protect/ would be in the
equivalent of .gitignore for whatever system is being used.




More information about the Exherbo-dev mailing list