Hello,
I'm sorry for the time it took for me to respond to your report. The
start of the pandemic transformed me into a useless puddle of stress :S
On Wed, 12 Feb 2020 14:08:46 -0800 Matt Taggart <tagg...@debian.org> wrote:
> Maybe these things could be made into a README.apache that could be
> included. It could start with
That sounds like a good idea :)
And if you're up for it we could work out the document's wording via a
merge request on:
https://salsa.debian.org/debian/smokeping
> In addition to that, here are some things I had to do:
>
> * install alias module so that ScriptAlias and Alias work
> * setup SSL with letsencrypt
> - install the ssl module, and also the mime module since ssl uses
> AddType and socache_shmcb module
> - if you are doing this and using the webserver itself to provide
> proof of controlling the host you might need to exclude the
> .well-known dir with something like:
> RedirectMatch ^/(?!.well-known.*)$
> https://example.com/smokeping/smokeping.cgi
> * install authz_core module since "Require all granted" is used
things currently "just work" with the smokeping package on a fresh
install, but I guess that's just because the alias, authz_core and ssl
modules are enabled by default.
it would be good to document them as requirements for running smokeping
with apache.
> * I also password protected mine which required: auth_basic,
> authn_core, authn_file
The redirect for .well-known above and the password protection sound
more like peripheral additions. They could be mentioned in the document
with fewer words, just to mention that one might want/need to think
about those aspects
> The important thing is, to have a webserver which allows you to run
> CGI and preferably FastCGI scripts. If you are using Apache I
> strongly recommend using the suexec system for running CGI scripts as
> a particular user.
>
> It would be nice to document how to do this and maybe switch the
> conf-available to use that method.
The thing is I don't think this package should start imposing enabled
modules, let alone an mpm on an apache setup.
Already, the fact that the package installs and enables a global apache
configuration has the tendency to raise eyebrows with some other package
maintainers -- it's not the currently agreed upon best practice for a
package shipping a web application; usually the httpd configuration is
left to the admin of that box since setups can vary widely.
So in that sense I don't think we can switch the default apache config
file to using suexec since it would require to enable another apache module.
But it would be great to document how to achieve this!
* install mpm_prefork and cgi modules (is there a way to use event or
worker?)
that's a pretty valid question since e.g. I believe mpm_event is
required in order to enable http2.
There's a good amount of documentation out there about how to setup
php-fpm with mpm_event and mod_fcgid -- our setup here should possibly
look similar to those. I just wonder if we can keep the same kind of
setup without an external fcgid wrapper.. we'll have to experiment a bit
here.
https://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html
we should probably include that URL in the document's preamble for
context, but also to mention that upstream doesn't have much info about
the apache setup for smokeping, thus the reason for the existance of the
document.
"The smokeping package includes an apache config at
/etc/apache2/conf-available/smokeping.conf that is enabled by default."
and the talk about the needed modules and maybe how to a2disconf it and
Include it in another conf instead, etc.
yes that's an interesting tidbit. not everyone will want the /smokeping
URL to become visible on all of their vhosts (which is another
eyebrow-raising point wrt enabling a global apache configuration for a
webapp)
I've actually been wondering if the smokeping package should take a step
back with regards to automatically enabling the apache configuration
file. The current "just works" method is OK for sampling the webapp but
it doesn't work in all environments.
It would make more sense in an httpd-agnostic package to let admin set
things up by themselves maybe by copying a sample vhost from examples,
but current users of the package are used to how things have been for
many years.. So I don't think I'm ready to take it out just yet, but it
might come at some point.
Cheers
