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/mgp00004.html
Reply to: