Re: Tweaking configurations
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 20-05-2005 03:39, Micah Anderson wrote:
>>The three main technical challenges each CDD faces are:
>>
>>1. select the packages for the CDD
>>2. tweak them (adapt the package configuration to the CDDs need)
>>3. create a package archive and install media
>
>
> I would like to spend some time fleshing out #2 since this one keeps
> me up at night,
I think my model of "5th config layer" has not yet been presented here,
and I think it is relevant for this discussion.
In the Unix world before distributions we had 3 layers of configuration.
The imprtant thing here is not presedence of each layer, but who is
responsible for them:
1) Author (defaults hardcoded into the app/tool/daemon/whatever)
2) Admin (system-wide defaults below /etc )
3) User (dot-config files at each home)
Admins and users should RTFM and that's that.
Distributions introduced an additional layer of configuration:
1) Author
2) Distro (Tweaks done for more sane behaviour within distro)
3) Admin
4) User
Authors (mostly) expect distro and admin working closely together.
Admins and users expect distro and author working closely together.
The fine art of the distro "packaging" is (when looking at config
responsibility) to hack "just enough and not more". Just enough to make
the code integrate nicely with whatever is defined as "distro". Not more
than the admin and users still experience the software as coming from
the author.
Helper "glue" like autotools was invented for authors to ease the job of
distros, but when authors fail to use those tools correctly, distros
fall back to hacking again, and lots and even today lots of Debian
packages still need a few "distro tweaks" to compile neatly for the
Debian distro.
CDDs introduce a fifth layer of configuration:
1) Author
2) Distro
3) CDD (tweaks applied to distro before/while maintained by admin)
4) Admin
5) User
The fine art of tweaking is similarly to that of a distro: hack "just
enough and not more". Current state of CDD hacking is different in one
important way, though: The hack is not (yet?) recognized either upstream
by distro or downstream by admin. So the hack has to be _extremely_
small - virtually invisible: By the distro it must look like work of the
admin (for maintainance routines like upgrade to work properly), and by
the admin it must look like the work of the distro (to avoid surprises
like questions about changes the admin didn't even know about).
Keep that last sentence in mind for the following...
>>- use plain debian if possible
>
> This one is useful for some packages, only those that are set with
> good defaults and do not need any local changes on any level.
Still we must mention this always when listing possibilities - to remind
ourselves that the ultimate goal gotta be to convince upstream to adopt
our hacks, however clever we make them.
The alternative is way more complex: Convince Debian to separate
configuration maintainance from packaging, to ease CDD creation without
repackaging binaries. Not insane, but certainly not as easy or quick!
>>- use debconf preseeding if possible
>
> This one is limited in a number of ways, in scope and scalability,
> this depends on the package maintainer who could potentially be a
> roadblock refusing to adopt low-priority questions, or may become
> innundated with too many (in fact I would argue that this puts the
> configuration side too much on the maintainer, when the maintainer
> should just be doing as little as possible to enable as much
> configuration as possible on the CDD's side), and the final reason
> being one that Sergio illuminated in a recent email: good for initial
> installation, but bad for maintenance
What was that mail from Sergio?
Sounds like what I describe above as a "stealth" requirement of CDD
hacks, no?
The proposed routines in the cddtk of saving original config and
comparing md5 of an additional layer seems to solve this, but is quite
complex and (I think) still breaks for upgrades requiring larger changes
to config files: For some problematic upgrades the maintainer scripts
parse the active config files and generate new ones based on them (like
when switching from flatfile to XML-based syntax).
>>- use tweaks - see http://wiki.jones.dk/DebianTweaks
>
>
> This is not flushed out at all, and needs a lot more discussion,
> cfengine is the only real option presented thus far. Many people end
> up making custom scripts, or special packages that modify
> configuration files, thus breaking debian policy. I have heard hints
> in the original thread that perhaps FAI could accomplish some of these
> in the form of "FAI-Classes". However, this seems to require debconf,
> cfengine and scripts.
The project tweaks is just the working place for collecting tweaks and
defining a common set of rules for their coding style and organisation.
Each tweak depends on the scripting language it is written in. CFEngine
seems to me (and to the FAI folks) like the most obvious scripting
language for writing "intelligent patching" of configuration files. If
you have concerns about dependencies for "yet another scripting
language" then let's discuss if it is worth the trouble to write shell
code to accomplish same intelligence as cfengine has already.
CFEngine is a scripting language written explicitly to "massage"
configuration files on heterogenous computer systems. It can be used as
a daemon as well, but that's irrelevant for use with tweaks, and is not
done by default with the Debian package "cfengine". NB! The old cfengine
is used, not the newer "cfengine2". Also, mostly to those already
familiar with CFEngine, beware that while CFEngine encourages a
hierarchical structure of interdependence betwence CFEngine scripts,
what is used by FAI and intended as policy for the "tweaks" project is
self-contained individual scripts.
What FAI classes accomplishes is to cleverly group tweaks. FAI also use
CFEngine (and other languages) as interpreter for each individual,
self-contained tweak.
>>- repackage
>
>
> We all know what this means, way too much work. It solves the
> problem, but breaks policy and people's backs.
Agreed :-)
> There is also the multi-layered configuration approach, which I
> believe was discussed in Spain, this too is a good possibility.
I haven't investigated CFG or Electra yet, but one thing important to me
is wether or not they need adoption by Debian developers or can be
applied as a "5th config layer".
Personally I do not want a 5th config layer in the long run, but believe
it is important for progress: Demonstrate to Debian by working examples
why technologies needs adoption. And most importantly we can reach the
goals of our pet projects while demoøing instead of having to wait for
the adoption to take place.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCklREn7DbMsAkQLgRAjKWAJwN5Vig+sO59cAs2hKNyNH9KS7t4gCdF8Dp
JUedKglf27pPmf7saPpKpcg=
=rORA
-----END PGP SIGNATURE-----
Reply to: