Bug#226833: apache: modules-config fails on unrelated .so files
Salut Fabio!
On Sat, Jan 10, 2004 at 08:23:54AM +0100, Fabio Massimo Di Nitto wrote:
> On Thu, 8 Jan 2004, Simon Huggins wrote:
> > modules-config is overzealous in its parsing of /usr/lib/apache/1.3 on
> > upgrades.
> >
> > My previously working config caused it to die during configuration.
> >
> > I had an old libperl.so lying around in there (I'm still not sure why -
> > I don't have mod_perl installed now).
> >
> > It didn't have a .info file so modules-config barfed.
> The error is generated on purpuse. It doesn't barf.
It printed an error and refused to continue on a previously working
apache config (albeit a not very likely corner case). That's what I'd
call barfing.
> > I don't think modules-config should just barf on such things. I'm not
> > sure if you're allowed to prompt during configuration I believe it's
> > frowned upon but as you're going to barf anyway perhaps it would be
> > permissible to prompt the user to override its choices.
> >
> > Otherwise perhaps it could limit itself to complaining about currently
> > active modules or just discard modules from its own calculations which
> > don't have an info file (and warn presumably).
> There are reasons why we stop upgrading if the relation between .so and
> .info is incosistent. The problem is simple, without info file we cannot
> build the list on modules that needs to be loaded. If for example we
> ignore a module, and some directives of this module are in the
> configuration files, apache will complain at a later stage that the
> configuration is broken (when we perform the restart) and it will not
> attempt a restart.
If you're doing a restart then you can test $? to judge if the config is
broken or not and this will be more easily understood than the
modules-config message to admins of apache who are used to seeing such
errors yet unused to Debian specific configuration magic.
> This can lead to a situation in which the user will think that the
> upgrade was smooth when it wasn't, with an old apache running and the
> new one not completely configured. Or that apache is not running and
> it will not restart "without an explicit reason" that is not the
> simplest to debug.
If it died based on a configuration directive and immediately above was
a *warning* from modules-config about a related missing .info file that
I would be very easy to debug.
e.g.:
# apt-get dist-upgrade
...
Error: libsome_module.so does not have a corresponding .info file.
Ignoring module libsome_module.so
...
/usr/sbin/apachectl restart: configuration broken, ignoring restart
/usr/sbin/apachectl restart: (run 'apachectl configtest' for details)
... (dpkg fails etc)
#
apachectl configtest will then indicate the offending directives which
will no doubt have some relation to libsome_module.so which is still in
the admin's mind. Sounds easy to me.
> Fixing this problem would make user life more complex in terms of
> understanding what is wrong.
No, I believe it would make it easier to debug if something /did/ go
wrong and in the majority of cases (i.e. working existing apache config
files when upgrading) it will mean fewer bugs reported to you and a more
useful upgrade path.
> > Either of these would have given me a nicer upgrade path.
> In your specific case this is possibly true but not for common cases
> therefor is much better to stop upgrading with an error and let the
> user know that something is missing or broken and that the upgrade is
> not complete other than just hide things from him.
Yes, you should test that the restart works and stop if it does not.
--
----------( "Somebody's poisoned the waterhole!" )----------
Simon ----( )---- Nomis
Htag.pl 0.0.22
Reply to: