Bug#227232: apache: Overwrites own modules.conf on upgrade
On Tue, 20 Jan 2004, Jeroen van Wolffelaar wrote: > > > I'm now going to clean up the mess and restore config from backup, and I > > > will check out the postinst afterwards, if I find more problems, or a > > > patch for this, I will add to this report and/or open another one. > > > > No need to. I know where the problem is (unfortunatly). > > Ok, that's half of the reason I didn't yet do so (other reason: RL) > > I noticed the problem, IMHO is in the cp -f modules.conf > modules.conf.old without any checking wether old exists, so only keeping > one backup (and on postinst rerun original modules.conf is lost). Yes i have this in mind as well. I am evaluating the possibility to perform a full backup of the configs each time since now we have the tool to do so. > > > Above this, why modules-config? You cannot add comments next to the > > > loadmodule line like this?! > > > > sorry but i don't understand what you mean. > > Without modules-config, you can maintain a configuration fragment with > the LoadModule lines, and have comments above them, as a kind of > reminder for yourself: what is it, what's it relevance to my own system, > and why did I disable/enable this module. > > With modules-config, that is AFAICS impossible. that's correct because it is generated automatically. Maintaing comments inside isn't impossible just a lot more work for modules-config. I consider this as a wishlist but i will see if i can find the time to fix it after this bug that is more important. > Okay, I agree & understand here :), thanks for the explaination. > > So I understand you will in the future mimic apache2's way of handling > apache-modules? I believe that would greatly improve Debian's > consistency. Yes that's correct. As you might have noticed we already started introducing conf.d as a testbed and several packages are using it. Next steps will be to introduce the modules structure. > ... indeed, I don't blame anyone, my goal is to provide an as useful as > possible bugreport to assist apache-maintainers fixing it in order to > prevent this bug slip into sarge :) > > Sorry if I was unclear about this, and thanks for all the good work. Thanks to you! Fabio -- Our mission: make IPv6 the default IP protocol "We are on a mission from God" - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Bug#227232: apache: Overwrites own modules.conf on upgrade
On Mon, Jan 19, 2004 at 01:02:07PM +0100, Fabio Massimo Di Nitto wrote: > On Mon, 12 Jan 2004, Jeroen van Wolffelaar wrote: > > Amongst others, config files were already split up. For example, I had > > moved all LoadModules line to a file called /etc/apache/modules.conf > > > > After upgrade to this version, the postinst failed, because apache > > failed to start because some modules I enabled via modules.conf were > > missing. > > If they were all debian modules it is kinda strange otherwise yes.. > > > I'm now going to clean up the mess and restore config from backup, and I > > will check out the postinst afterwards, if I find more problems, or a > > patch for this, I will add to this report and/or open another one. > > No need to. I know where the problem is (unfortunatly). Ok, that's half of the reason I didn't yet do so (other reason: RL) I noticed the problem, IMHO is in the cp -f modules.conf modules.conf.old without any checking wether old exists, so only keeping one backup (and on postinst rerun original modules.conf is lost). > > Above this, why modules-config? You cannot add comments next to the > > loadmodule line like this?! > > sorry but i don't understand what you mean. Without modules-config, you can maintain a configuration fragment with the LoadModule lines, and have comments above them, as a kind of reminder for yourself: what is it, what's it relevance to my own system, and why did I disable/enable this module. With modules-config, that is AFAICS impossible. > > apache2's approach of a mods-available, and mods-enabled containing > > symlinks to the former, MUCH cleaner, and easier, and more > > straightforward, and non-causing-data-loss! And, it's more consitent > > within Debian > > The switch to modules-config and modules.conf is part of the transition. > There are several steps that needs to be done and cannot be done in one > shot. > > the first one was to get rid of the old apacheconfig that was pretty much > broken, replacing it with modules-config forcing all the apache modules to > clean up the way they were configured. Providing a standard (and only one) > way to enable/disable modules. Once this is completed we can change > modules-config and the underlaying structure without the other modules > even noticing it. the advantage is that at that point we can make a clean > transition without having to upload 200 packages together with 200 > different implementations to achieve the same task. For the disadvantegs > just check the BTS ;) Okay, I agree & understand here :), thanks for the explaination. So I understand you will in the future mimic apache2's way of handling apache-modules? I believe that would greatly improve Debian's consistency. My second issue with modules-config is in a different bugreport now on its way. > We can agree that the name modules.conf was not the best choise but (and i > accept my responsabilities for it) we endup in a urgent and broken upload > because of perl breaking the abi (at that time). I don't fully grasp perl's abi relevance here, but in fact, I disagree modules.conf is a bad name: _if_ it is decided to have a seperate file for the modules configuration, modules.conf seems very logical (this is emphasized by the fact that I personally had choosen that very name long time ago for this purpose). Unfortunately this clash caused this very problem to happen with me, but ... > well you are still running a testing/unstable system. things can break for > mistakes... tho noone want it. ... indeed, I don't blame anyone, my goal is to provide an as useful as possible bugreport to assist apache-maintainers fixing it in order to prevent this bug slip into sarge :) Sorry if I was unclear about this, and thanks for all the good work. --Jeroen -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl
Bug#227232: apache: Overwrites own modules.conf on upgrade
On Mon, 12 Jan 2004, Jeroen van Wolffelaar wrote: > Package: apache > Version: 1.3.29.0.1-3 > Severity: critical > Justification: causes serious data loss > > (I consider by home-made configuration also data - webserver will not > run without; and without backups I wouldn't have been able to recover > per module the reasons why I enabled/disabled that module) Yes that's correct. This problem was spotted in another bug that got lost/forgotten/closed (for what i can recall at least). > Amongst others, config files were already split up. For example, I had > moved all LoadModules line to a file called /etc/apache/modules.conf > > After upgrade to this version, the postinst failed, because apache > failed to start because some modules I enabled via modules.conf were > missing. If they were all debian modules it is kinda strange otherwise yes.. > I'm now going to clean up the mess and restore config from backup, and I > will check out the postinst afterwards, if I find more problems, or a > patch for this, I will add to this report and/or open another one. No need to. I know where the problem is (unfortunatly). > Above this, why modules-config? You cannot add comments next to the > loadmodule line like this?! sorry but i don't understand what you mean. > > apache2's approach of a mods-available, and mods-enabled containing > symlinks to the former, MUCH cleaner, and easier, and more > straightforward, and non-causing-data-loss! And, it's more consitent > within Debian The switch to modules-config and modules.conf is part of the transition. There are several steps that needs to be done and cannot be done in one shot. the first one was to get rid of the old apacheconfig that was pretty much broken, replacing it with modules-config forcing all the apache modules to clean up the way they were configured. Providing a standard (and only one) way to enable/disable modules. Once this is completed we can change modules-config and the underlaying structure without the other modules even noticing it. the advantage is that at that point we can make a clean transition without having to upload 200 packages together with 200 different implementations to achieve the same task. For the disadvantegs just check the BTS ;) We can agree that the name modules.conf was not the best choise but (and i accept my responsabilities for it) we endup in a urgent and broken upload because of perl breaking the abi (at that time). > --Jeroen > (apologies for my insecure wordings, my mood is currently a bit... you > can guess) well you are still running a testing/unstable system. things can break for mistakes... tho noone want it. Fabio -- Our mission: make IPv6 the default IP protocol "We are on a mission from God" - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Bug#227232: apache: Overwrites own modules.conf on upgrade
Package: apache Version: 1.3.29.0.1-3 Severity: critical Justification: causes serious data loss (I consider by home-made configuration also data - webserver will not run without; and without backups I wouldn't have been able to recover per module the reasons why I enabled/disabled that module) I have a very customized apache configuration because I run a lot of different things via apache. Amongst others, config files were already split up. For example, I had moved all LoadModules line to a file called /etc/apache/modules.conf After upgrade to this version, the postinst failed, because apache failed to start because some modules I enabled via modules.conf were missing. It turned out, that modules.conf was overwritten by some apache-modules (or such) script. There were quite some things that looked like backups, but none contained the old version (I grepped). modules.conf.old was the same modules.conf (I ran postinst multiple times). I'm now going to clean up the mess and restore config from backup, and I will check out the postinst afterwards, if I find more problems, or a patch for this, I will add to this report and/or open another one. Above this, why modules-config? You cannot add comments next to the loadmodule line like this?! apache2's approach of a mods-available, and mods-enabled containing symlinks to the former, MUCH cleaner, and easier, and more straightforward, and non-causing-data-loss! And, it's more consitent within Debian --Jeroen (apologies for my insecure wordings, my mood is currently a bit... you can guess) -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: None of your business Locale: LANG=nl_NL.ISO-8859-1, LC_CTYPE=nl_NL.ISO-8859-1 Versions of packages apache depends on: ii apache-common 1.3.29.0.1-3 Support files for all Apache webse ii debconf 1.3.22 Debian configuration management sy ii dpkg1.10.18 Package maintenance system for Deb ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii libdb4.14.1.25-10Berkeley v4.1 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii libmagic1 4.06-2 File type determination library us ii libpam0g0.76-14.1Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.23-1 MIME files 'mime.types' & 'mailcap ii perl [perl5]5.8.2-2 Larry Wall's Practical Extraction -- debconf information: apache/server-name: wolffelaar.nl apache/document-root: /var/www apache/server-port: 80 * apache/enable-suexec: false apache/init: true apache/server-admin: [EMAIL PROTECTED]
