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

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

El Thu, Feb 03, 2005 at 05:58:56PM -0800, Vagrant Cascadian va escriure:
> >   r> Alle 11:24, mercoled? 26 gennaio 2005, Sergio Talens-Oliag ha scritto:
> >   >>After all packages are installed, we copy the original file to a place we
> >   >>can recover it from, like:
> >   >>
> >   >>/etc/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
> >   >>
> > 
> >   r> I think that for Policy compliant the original config files must go 
> >   r> in /var/lib/cdd/CDDNAME/orig_conffiles/orig_package/ORIGINAL_PATH
> > 
> >   r> it seems a good keep-it-simple-stupid  approach, i like it.
> > 
> > Yes, good idea Sergio. I like it too. I  feel it satisfies most of the
> > needs of CDDs.  This is just first  impression though.. need to digest
> > it a little bit :)
> one thing i wonder is how to be sure it's the original configuration
> file?  whatever is there when the CDD gets installed?  can we compare
> against the package's configuration file somehow?

  Well, we are sure that we will have the file the user had before installing
  the CDD and generally we can know if it has been modified or not:
  - If it is a file included on a package we have the original md5sum on the
    /var/lib/dpkg/info/PACKAGE.md5sums, so we can verify if it has been
    modified or not and warn the user if it was.

  - If the file is generated by debconf we probably have the md5sum on
    /var/lib/ucf/hashfile (that is, if the package uses ucf) and we can do the
    same as above.

  - If the file was generated by the user the original version is the current
    file ... ;)

> what if we have multiple CDDs on one machine- one CDD may see the other
> CDD's configuration file as the "original".

  Yes, we have a problem then, I'm aware that the model is mainly appropiate
  for a single CDD or, at least, for not conflicting tasks, but anyway we have
  some options:

  - Apply only one customization to each file: when the user chooses CDD tasks
    he does it assigning priorities and once a task changes a configuration file
    other tasks don't do it... that is problematic, but can work if we warn the
    user about the conflicting files.

  - Apply multiple customizations in order (lower priority tasks first): if we
    detect that a file has already been modified we can try to customize the
    modified version, generate a new file based on the original one or leave
    it with the previous customization. Depending on how the user wants to
    handle this issues we can let him choose interactively or leave the system
    with the first option that succeeds (of course we will have a tool to
    report how the configurations are in a given moment).

  Anyway, keep in mind that this problem is also present for the debconf
  preseeds, and on that case we are forced to decide which preseed wins
  (presseding twice overwrites old values).

  My idea is that, in the future, we will only need to define a CDD choosing
  from a set of task templates that can use special tools to resolve this kind
  of problems by package or, at least, try to avoid problems providing tasks
  that we can install for multiple CDDs at once (our CDD Description package
  can depend on another CDD Description and have our tasks depend on other
  CDD) ... I'll update my CDD Description file format to include this option.
> it might be good, though maybe complicated, to provide CDDs with some
> mechanism to know if it's a CDD-tweaked configuration file... something
> similar to dpkg-diversions(at least in concept, i have no idea how it is
> implemented).

  The idea is to have something similar to the functionality provided by
  diversions and alternatives, keeping checksums of all configuration files
  modified or generated by CDD tasks and a history of the customizations
  To be able to detect user modifications, undo changes or warn him before
  upgrading modified files, we will need, for each file modified using this
  technique, which file was the original one, who has modified it and in which


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: