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

RFC: How to handle configuration files and updates on the cddtool

  Hello again to all,

  As I've said on a previous mail I'm already working on the cddtool and while
  working on the parser for the cdd description and learning about current
  tools (apt is great, but it is better when you look at all the options it
  has ;) I've been thinking about my original proposal and have additional
  ideas I would like to comment with people on the list.

  The current proposal for the CDDTool:

  talks about Task and Package paragraphs, but the idea is that each task is
  one entity, so debconf preseeds and configuration scripts are used for all
  the packages of the task.

  On the proposal I said that the cddtool could be used to install, update and
  remove packages, but there is no indication of how that could be integrated
  with the usual Debian tools (that is, with apt).

  After thinking about it I believe that we could support CDD updates using
  apt and a common system for the cfg-scripts I talk about on the proposal.
  The idea is to install hooks for apt with the cddtool. i.e. install the file

    DPkg::Post-Invoke { "test -x /usr/sbin/cddtool && /usr/sbin/cddtool apt-pre-install-pkgs"; };
    DPkg::Pre-Install-Pkgs { "/usr/sbin/cddtool apt-pre-install-pkgs"; };
    DPkg::Tools::Options::/usr/bin/cddtool::Version "2";
  The *Pre-Install-Pkgs* is called when the packages are already available but
  before calling dpkg to unpack and configure them (the 'DPkg::Tools::Options'
  is used to get a list of the actions that are going to be done on the
  standard input of the cddtool invocation).

  The *Post-Invoke* script is called after all packages are installed and

  My idea is to use those scripts to *disable* non-policy compliant
  customizations while installing or upgrading packages and reaply
  customizations after installation. Note that this system's usage has to be
  kept to a minimum, and that all files related to a customization that are
  not going to conflict with the normal system should be handled using normal
  debian packages.

  Basically the system could be implemented using a library of scripts and
  defining a policy:

  1. If a configuration file can be customized using debconf, use preseeding
  and avoid this system.

  2. If a customization simply needs to change some variables of the original
  config file, send a bug report asking the maintainer to add debconf support
  for them.
  On the meantime put the questions on your cdd-desciption package and handle
  the configuration file yourself.
  After all packages are installed, we copy the original file to a place we
  can recover it from, like:
  later we use a script (tha uses sed, cfengine or whatever we agree on)
  against the original file to replace the needed variables and generate the
  customized version.
  The customized file is stored on:


  An later it is copied to it's original path and the customization is done.

  To undo our changes we simply have to move all files on:

  to their original locations before installing or upgrading packages.

  We can do it for all the customizations or only for the afected packages
  that are going to be installed or updated (preferred, as it is more
  - The customized files have to be re-generated for each updated package or
    for all packages after each cdd-description update or reconfiguration.
  - The customized file is stored on two places to be able to detect if the
    customization has been modified by the local administrator and let him
    know that manual modifications have been done to the customized version.
    To do it the files on '/etc/cdd/CDDNAME/custom_conffiles/ORIGINAL_PATH'
    can be handled using 'utf' or a similar system.

  3. If a customization needs a different configuration file as a base, do the
  same as on option 2 with the original files and apply your scripts against
  templates stored on:


  4. If the configuration needs something more complicated than a value
  replacement, do the same as on options 2 and 3 with the original file and
  generate the new configuration file using your own script.

  Comments, Doubts, Suggestions?
Sergio Talens-Oliag <sto@debian.org>   <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69

Attachment: signature.asc
Description: Digital signature

Reply to: