[Pkg-nagios-devel] Bug#830941: Bug#830941: icingaweb2: don't mangle around in the Apache configs

[Christoph Anton Mitterer]

On Mon, 2016-07-18 at 10:00 +0200, Markus Frosch wrote:
> I don't get your point here...
> 
> Its common practice in Debian to enable the daemon / configure the
> application, so it runs after installation.

Well but first, this practise draws quite some criticism on it every
now and then… but apart from that, it's not that Icinga Web 2 would be
a standalone daemon that is just activated.

The package rather influences the configuration of another package
(apache httpd) in order to enable itself.


> Or at least gives you an easy way to let you set it up.
Which is great, but I think this is already fulfilled by the package
placing the example config in /etc/apache2/conf-available/

But actually enabling it, and also enabling required modules, should be
IMO a step done by the user.


> SSL is user choice and responsibility, there are hundreds of ways to
> configure it. (Redirect all, only some...)
And exactly because there are hundreds of ways the user may have
implemented his webservers (and Icinga[Web]'s) security, it would be
better if it's not enabled straight away.

Examples:
A user might have set up SSL on virtual host context only, which makes
sense if this is the only place where he actually serves content.
The conf example however, goes into the main server context, and would
thus be served without SSL.

Same for any other security mechanisms a local admin may have put in
place (password auth, etc. pp.).

Another admin might not have enabled SSL and any other password/etc.
auth/authz at all, simply because he may have put rules in place, which
allow access to security relevant context only from trusted IPs. Or
e.g. any such context may be in a vhost that listens only on a port,
which is by firewall restricted to the intranet.



> The user has always the choice to change configuration afterwards,
> without the package to overwrite that.
Well sure… but per default apache would be running and serving, and per
default installing icingaweb package would enable it.

So at least there is a certain amount of time where access to the
interface may be possible, which may already be quite undesired (e.g.
unveiling the internal network/hosts topology).


And lets face the truth, an admin that is so little into configuring
icinga/icingaweb/apache himself, that he even needs this two additional
commands:
# a2enconf icingaweb2
# a2enmod rewrite
is possibly also not well educated enough to realise, that he should
strongly wand to enable things like SSL, client auth, password auth
etc.


Well the whole thing is just a suggestion, I don't think it would be
such a bad advise :-)
Actually I though the whole a2enconf framework is mostly meant to give
the admin an easy way to enable the out-of-the-box configs put in place
by packages.

And I think there is no strong need to enable mod_rewrite for novice
users either:
Thanks to icingaweb2.conf, it would already tell the novice user what
to do if mod_rewrite is not loaded, by serving error_norewrite.html


Best wishes,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20160718/1ddb7699/attachment.bin>