Re: Right Way to make a configuration package
Hello I assume that my answer is a bit late as you wrote this in october. I have written a package, dysyco that do similar things to what you want. Take a look. I may have misunderstood you. // Ola On Thu, Oct 14, 2004 at 03:37:27PM -0400, Mark Roach wrote: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? ## warning, verbosity follows ## Perhaps I'm just approaching this the wrong way, so here is what I am doing (and where the problem comes in), and if anyone has a suggestion for a better approach, I would be happy to hear it. userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- ldap. In the postinst, it gets the samba domain name, the dns domain name, and the ldap master password out of debconf, and populates the necessary entries. One problem is that the user may not necessarily have ever configured samba or slapd through debconf. This package needs that info, but it's not possible to dpkg-reconfigure a package from within the postinst of another package. So we would have to tell them to manually dpkg- reconfigure the dependancies and then reinstall, or gather the information ourselves, but then there is potentially conflicting info in debconf... Another similar problem is that the user may reconfigure samba-common or slapd at any point and obviously my package wouldn't know about it. So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Thanks, Mark Roach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Right Way to make a configuration package
Ola Lundqvist [EMAIL PROTECTED] writes: Hello I assume that my answer is a bit late as you wrote this in october. I have written a package, dysyco that do similar things to what you want. Take a look. I may have misunderstood you. // Ola On Thu, Oct 14, 2004 at 03:37:27PM -0400, Mark Roach wrote: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? Actually that is forbidden by policy. A package may not change another packages conffiles. If that can be overlooked for a package which sole purpose is to overwrite configuration for other packages is a question you have to ask yourself. MfG Goswin
Re: Right Way to make a configuration package
[Goswin von Brederlow] Actually that is forbidden by policy. A package may not change another packages conffiles. Actually, the policy forbids the _maintainer scripts_ of a package to change another packages conffiles. It does not forbid a script in a package to change another packages conffiles. I'm not saying it is smart to change packages conffiles using a script in another package. It isn't. But as far as I know it isn't forbidden by policy. :) If that can be overlooked for a package which sole purpose is to overwrite configuration for other packages is a question you have to ask yourself. It can be done if the package A only provide the means to do it, and don't overwrite the configuration of package B when package A is installed. Providing a base-config fragment to be executed during first install is a common way to do it.
Re: Right Way to make a configuration package
On Fri, Oct 15, 2004 at 02:33:16PM +0200, Petter Reinholdtsen wrote: This do not scale well, and make it harder to share knowledge across several custom debian distros. If x and y have configuration utilities xcfg and ycfg then z should insofar as possible use xcfg and ycfg to make changes to x's and y's configurations. Agreed, when we are talking about configuration of already installed packages. When we are talking about configuring packages during installation, debconf is well suited. The problem being that X using Debconf to store information, Y modifying the info and then X getting an upgrade, the info stored by X using Debconf might be used again to set the values in the data file, which will break the initial purpose of Y. /me thinks -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 This was to be my final hit, but let's be clear about this. There's final hits and final hits. What kind was this to be? --Renton (Trainspotting)
Re: Right Way to make a configuration package
[Jesus Climent] The problem being that X using Debconf to store information, Y modifying the info and then X getting an upgrade, the info stored by X using Debconf might be used again to set the values in the data file, which will break the initial purpose of Y. Well, the solution to this problem is to _never_ use debconf to store information. The configuration info should be stored in the configuration files, and the current debconf values should be set based on the content of the configuration files. The values in the debconf database should only be used when no configuration file exist. (This is sometimes summarized using statements like 'debconf is not a registry'.)
Re: Right Way to make a configuration package
Am Monday 18 October 2004 02:01 schrieb Enrico Zini: One problem with diversion could also be that the original package's scripts won't probably edit the diverted conffile, but would probably edit the file in the traditional place instead. Same would be the case for admins and users, and their scripts, tools and utilities, right? Having only one authoritative config place is probably less prone to confusion. I suspect the only sensible way to do this is to implement multilevel configuration files in all applications we want to configure at install time. Multilevel config files would sure be nice, where the apps don't support them it might be sufficient to provide only multilevel *defaults*. Multilevel as application defaults, package defaults, system defaults (CDDs) and possibly admin defaults. That should be possible with any type of app configuration. Eeach level of authority could optionally provide a description of their defaults that are processed by a configuration helper as CFG that is designed to never interfere with user settings as described at http://freedesktop.org/Software/CFG Quickly brainstorming this, customizing a running system to a template (a CDD) could be a two step process of copying in the meta info and then interactively or not resetting to the new defaults. In new installations the settings could automatically default to the customization if the meta data is present early enogh. Kind Regards, Christian
Re: Right Way to make a configuration package
On Thu, Oct 14, 2004 at 10:32:38PM +0200, Jose Carlos Garcia Sogo wrote: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? Current trends are centered on debconf preseeding and on installing cfengine scripts. I'm at the moment at a mini italian mini debconf, discussing with Marco d'Itri about this topic. One of the suggestions that came out is using dpkg diversions. I remember diversions came out in the past, and I don't remember how come they didn't come out again. Was there something wrong with them? Thinking about them now, they will allow a package to take responsibility for the configuratin of another, and give the other package back its configuration when the former one is deinstalled. This would allow to do things like removing a CDD and having back the original behaviour, it would allow sane upgrades, switching from one CDD to the other... The only problem I can see is if I install A, then B[diverts cfg of A], then I change by hand that configuration, then deinstall B: in that case, my changes won't be fed back in A's configuration. However, that problem is not even addressed by the other approaches, and I may not be a problem at all (that is, I don't know how sane would he having this feature at all). Another possibility would be to make a small change to dpkg to ask what it should do when undiverting configuration files that have been changed by the user. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Right Way to make a configuration package
[Enrico Zini] One of the suggestions that came out is using dpkg diversions. I remember diversions came out in the past, and I don't remember how come they didn't come out again. Was there something wrong with them? I believe they are forbidden or don't work for conffiles. And we need to do this with conffiles. I suspect the only sensible way to do this is to implement multilevel configuration files in all applications we want to configure at install time.
Re: Right Way to make a configuration package
On Sun, Oct 17, 2004 at 10:38:06PM +0200, Petter Reinholdtsen wrote: [Enrico Zini] One of the suggestions that came out is using dpkg diversions. I remember diversions came out in the past, and I don't remember how come they didn't come out again. Was there something wrong with them? I believe they are forbidden or don't work for conffiles. And we need to do this with conffiles. From the dpkg-divert manpage: [...] System administrators can also use it to override some packages configuration file [...] In the policy, I find: 3.10. Maintainer Scripts [...] You should not use `dpkg-divert' on a file belonging to another package without consulting the maintainer of that package first. 10.7.4. Sharing configuration files [...] Packages which specify the same file as a `conffile' must be tagged as _conflicting_ with each other. (This is an instance of the general rule about not sharing files. Note that neither alternatives nor diversions are likely to be appropriate in this case; in particular, `dpkg' does not handle diverted `conffile's well.) [it also goes on about other ways of sharing configuration files] One problem with diversion could also be that the original package's scripts won't probably edit the diverted conffile, but would probably edit the file in the traditional place instead. This may not be a problem with many packages, though. My dear debian-devel public: is this an unsolvable problem in Debian, not even in the medium-long term? I suspect the only sensible way to do this is to implement multilevel configuration files in all applications we want to configure at install time. Is that applicable to all the various kinds of conffiles we have, and all possible customizations? I'll make a recap of configuration customization techniques (to be quoted and extended with pros, cons, dos, donts and gotchas): - debconf preseeding (can't de-install the customization) - cfengine (can't de-install the customization, problems during upgrades) - dpkg-divert (may not work for all packages) (may be good for packages which don't automatically edit their configuration) - multilevel configuration files (not all customizations are supported) (may be good for packages with complex and useful updated configuration) The last two could complement each other and cover a wide range of cases, allowing also upgrade and changing from one cdd to the other. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Right Way to make a configuration package
So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Debconf wasn't designed to serve the purpose to which you are trying to put it. Debconf is not a registry. Suppose you have packages x and y with configuration files xconf and yconf. Your package z should contain a program that reads xconf and yconf and writes them out again with new values. If x and y have configuration utilities xcfg and ycfg then z should insofar as possible use xcfg and ycfg to make changes to x's and y's configurations. -- Thomas Hood
Re: Right Way to make a configuration package
[Thomas Hood] Debconf wasn't designed to serve the purpose to which you are trying to put it. Debconf is not a registry. Actually, debconf was designed for first-time configuration of packages, and is well suited for the task. Your mantra debconf is not a registry does not apply here. Suppose you have packages x and y with configuration files xconf and yconf. Your package z should contain a program that reads xconf and yconf and writes them out again with new values. This do not scale well, and make it harder to share knowledge across several custom debian distros. If x and y have configuration utilities xcfg and ycfg then z should insofar as possible use xcfg and ycfg to make changes to x's and y's configurations. Agreed, when we are talking about configuration of already installed packages. When we are talking about configuring packages during installation, debconf is well suited.
Re: Right Way to make a configuration package
I think that you will find answers in debian-custom list. Adding it to CC field. El jue, 14-10-2004 a las 15:37 -0400, Mark Roach escribi: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? ## warning, verbosity follows ## Perhaps I'm just approaching this the wrong way, so here is what I am doing (and where the problem comes in), and if anyone has a suggestion for a better approach, I would be happy to hear it. userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- ldap. In the postinst, it gets the samba domain name, the dns domain name, and the ldap master password out of debconf, and populates the necessary entries. One problem is that the user may not necessarily have ever configured samba or slapd through debconf. This package needs that info, but it's not possible to dpkg-reconfigure a package from within the postinst of another package. So we would have to tell them to manually dpkg- reconfigure the dependancies and then reinstall, or gather the information ourselves, but then there is potentially conflicting info in debconf... Another similar problem is that the user may reconfigure samba-common or slapd at any point and obviously my package wouldn't know about it. So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Thanks, Mark Roach -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
