On Thu, Jan 19, 2006 at 03:24:36AM +0100, Sergio Talens-Oliag wrote: > El Thu, Jan 19, 2006 at 12:57:23AM +0000, Jose Manuel dos Santos Calhariz va escriure: > > Hi, > > Hi, > > > Now I am working in a solution with small scripts and patchs files, > > and using dpatch. I know dpatch is to apply patches into upstream > > sources, but I have made it work, using "--workdir /", and a fake > > debian dir inside "/etc/package". The scripts will be executed by the > > admin and not by postint during installation, so violating one less > > rule of the Debian Policy :) > > > > I hope in the next days to present a working example. For now I would > > like to ask to the list: > > > > - Have anyone used patchs to change configuration files? Used > > something better than dpatch to manage them? > > I've used systems like changetrack to keep manual configuration file > changes on a revision control system, but not to configure systems; > IMHO patches are not well suited for customizing configurations, > there are a lot of things that can break if the configuration is > edited by hand or using package scripts that handle the debconf > answers. And I believe revision control systems are necessary when a team manage servers, but this another talk. My system is target for non-newbie admin, so it can break a little ;) They should know how to fix it. Or in the other end is for students that need to use Linux for the class but use mainly Windows. As I don't expect them to mess with configuration files, it should work. > > > - Have anyone other ideas, pro or cons, about my approach to the > > problem? > > I did an specification of how to handle configuration files using an special > kind of diversions; the idea is to remove customizations before package > installations, upgrades or removals and apply them again after installations > or updates. > > The specification is included on the cddtk docs: > > http://people.debian.org/~sto/cddtk/cddtk-apt.html > > but I have not worked on the tool for a while. > > Anyway, I've been working on a configuration system for our CDD that > uses some of the techniques I was thinking about, once I have it > finished I'll move the interesting bits to the cddtk (the system is > is already working, but I have to build a full set of configurations > for different services). > It's good to ear that, Debian is lacking on the area of automatic personalization, is good to have alternative systems until a good one is generally accepted by Debian. I believe the best bet is working on a library of functions to parse configuration files, make changes and exchange information between debconf and configuration files. > (...) > > A good example is the customization of the SAMBA or LDAP servers; my > current system provides a customized init.d script for each server > that executes the service using different configuration files (the > custom config for SAMBA is generated in /etc/CDDNAME/samba and for > LDAP in /etc/CDDNAME/ldap) and different /var dirs (the server PIDs > are stored on /var/run/CDDNAME and things like the LDAP database is > generated in /var/lib/CDDNAME/ldap instead of /var/lib/ldap). But this system will make it more difficult for the admins to understand what are the configuration files in use, as is on different location from what is documented. For me is a big _no_. > > (...) > > In any case, I don't plan to use patches to handle customizations, > maybe I'll try to support upgrades for modified conffiles using > diffs, but I'm sure that unless the changes are minimal the best > option when things don't work automatically will probably be the > same used by dpkg... that is, tell the user about the changes and > ask about keeping the current version or replacing it. Until now, I found that I need to make small changes, some of them suited to be done by patching, by scripts or pre-seeding. No need to replace configuration files because of massive changes. > > Greetings, > > Sergio. > Jose Calhariz -- Acreditarmos verdadeiramente naquilo que desejamos e o primeiro passo para que ele se torne realidade.
Attachment:
signature.asc
Description: Digital signature