Web app and httpd (apache2) reconfig questions

[Lars Wirzenius]

Greetings.

I am making a package for Koha (http://koha-community.org/), which I
will eventually hopefully be able to upload to Debian. For now, it will
remain a third-party package.

However, I would like to make the package to be as high quality as
possible. So I have some questions.

Koha wants (for now) to add a custom vhost, and installs an Apache
config file in /etc/koha/koha-httpd.conf, and symlinks that
to /etc/apache2/sites-available. What is the best way to get that
enabled?

* Install a symlink into sites-enabled, in the package?
* Call a2ensite in the postinst?
* Should this be enabled/disabled via a debconf question?

Koha needs the Apache rewrite module. How do I enable that?

If I make the package do the above Apache configuration changes, how do
I reload or restart Apache?

At the moment I don't enable things, but I include a README.Debian that
documents the necessary steps the sysadmin needs to take to enable
things.

Koha uses a database, and stores some sensitive information there. For
example, usernames and passwords of its users, and their reading habits.
It would be bad to leak that information to outsiders. Currently, Koha
runs as www-data, which means that its config file is available to all
other web apps, and that in turn means that they have access to the
database. What is best practice here?

Should I change Koha to run under a dedicated user and group? Should I
just document the situation and tell the user to not install any other
web apps if they care about the sensitive data?

[Tanguy Ortolo]

Hello Lars!

Post by Lars Wirzenius
However, I would like to make the package to be as high quality as
possible. So I have some questions.

I shall try to anwser them according to my (small) experience as a
webapp package maintainer. I am not a Debian developper, though, and I
am just a newbie packager, so take my advice with care. :-)

Post by Lars Wirzenius
Koha wants (for now) to add a custom vhost, and installs an Apache
config file in /etc/koha/koha-httpd.conf, and symlinks that
to /etc/apache2/sites-available. What is the best way to get that
enabled?
* Install a symlink into sites-enabled, in the package?

The Debian webapp packages I saw (PhpMyAdmin, RoundCube, DokuWiki) do
not add a custom virtual host, but rather an alias /webapp_name
/usr/share/webapp, installed in a conf.d/webapp.conf.

Post by Lars Wirzenius
* Call a2ensite in the postinst?

No need if it is in conf.d, I think.

Post by Lars Wirzenius
* Should this be enabled/disabled via a debconf question?

I do not think this is necessary for installing an alias. However, some
packages (DokuWiki) ask for the alias name.

Post by Lars Wirzenius
Koha needs the Apache rewrite module. How do I enable that?

Is that really needed or just optional to beautify some URLs?

Post by Lars Wirzenius
If I make the package do the above Apache configuration changes, how do
I reload or restart Apache?

I think force-reload is enough: this is what I do for DokuWiki.

Post by Lars Wirzenius
At the moment I don't enable things, but I include a README.Debian that
documents the necessary steps the sysadmin needs to take to enable
things.

I suggest that you:
* enable an alias in /etc/apache2/conf.d;
* do not enable the URL rewrite stuff unless it is really needed;
* keep the code for enabling it commented in the Apache HTTPD
configuration file;
* document how to:
+ enable a virtual host,
+ enable the URL rewrite process
in your README.Debian.

[sean finney]

hi lars,

Post by Lars Wirzenius
Koha wants (for now) to add a custom vhost, and installs an Apache
config file in /etc/koha/koha-httpd.conf, and symlinks that
to /etc/apache2/sites-available. What is the best way to get that
enabled?
* Install a symlink into sites-enabled, in the package?
* Call a2ensite in the postinst?
* Should this be enabled/disabled via a debconf question?

i don't know of too many other apps that install a vhost, but i guess
if you're gonna do it i'd ship the vhost file in sites-available, and
run a2ensite in the postinst and a2dissite in the postrm. throwing some
debconf never hurts but ultimately you have to pick a default behavior
that is taken if debconf is never seen, so it's more of an additional
feature than a requirement i'd say. the only thing that i think is important
is that everything behaves sanely when the package is unconfigured as well
as when it is removed but not purged (i.e. no broken symlinks or other
buggy behavior when the conffiles are present but not the app files).

Post by Lars Wirzenius
Koha needs the Apache rewrite module. How do I enable that?

throw an a2enmod in the postinst? a2enmod should be idempotent, and i
think it's fair to leave it enabled when uninstalling the pkg.

Post by Lars Wirzenius
If I make the package do the above Apache configuration changes, how do
I reload or restart Apache?

invoke-rc.d apache2 reload/restart in the postinst/postrm (installation,
upgrade, and removal paths), depending on whether the new config
directives require a full restart or just a reload. don't remember off
the top of my head whether vhost configs or rewrite configs require a
full restart, i'm kinda thinking they do.

Post by Lars Wirzenius
At the moment I don't enable things, but I include a README.Debian that
documents the necessary steps the sysadmin needs to take to enable
things.

honestly, i don't think a conservative approach is all that bad, especially
if there's anything complicated in the process. but that also might bring
a point for concern: that users of versions prior to any new "automatic foo"
version have probably already configured their system, and you don't want
to configure/reconfigure the installation on top of it. so maybe put in
a check in the config/postinst maintainer scripts for versions << the new
version and disable any of the behavior if it's an upgrade from such a
prior release.

Post by Lars Wirzenius
Koha uses a database, and stores some sensitive information there. For

i guess someone might have already pointed you at dbconfig-common?

Post by Lars Wirzenius
example, usernames and passwords of its users, and their reading habits.
It would be bad to leak that information to outsiders. Currently, Koha
runs as www-data, which means that its config file is available to all
other web apps, and that in turn means that they have access to the
database. What is best practice here?

there really isn't a good way to get around this unless you are running your
own app server which is proxied by the web server. i think a number of apps
just do it as www-data, leaving it as an exercise for the local admin for
how to strap it down. if the server supports being run via something like
fcgi or wsgi, then it's much easier and i'd recommend trying to run it as
a seperate user, but otherwise i think it might be a bit out of scope of
the packaging, or at least highly dependant on the application/platform.

Post by Lars Wirzenius
Should I change Koha to run under a dedicated user and group? Should I
just document the situation and tell the user to not install any other
web apps if they care about the sensitive data?

i think providing some information in that regard would be a good idea,
like mentioning that the app's configuration/db credentials can be read
by other applications, and if any kind of cgi/scripting support (i.e. php) is
enabled for userdirs then any user could effectively get the info too. but
at the same time i kinda think of this as common sense...


sean

--

[Lars Wirzenius]

Thanks sean and Tanguy, for your quick answers. I am responding to both
of you in the same mail, to avoid unnecessary list traffic.

Post by sean finney
i don't know of too many other apps that install a vhost, but i guess
if you're gonna do it i'd ship the vhost file in sites-available, and
run a2ensite in the postinst and a2dissite in the postrm. throwing some
debconf never hurts but ultimately you have to pick a default behavior
that is taken if debconf is never seen, so it's more of an additional
feature than a requirement i'd say. the only thing that i think is important
is that everything behaves sanely when the package is unconfigured as well
as when it is removed but not purged (i.e. no broken symlinks or other
buggy behavior when the conffiles are present but not the app files).

Looks like the following would work best for the vhost setup:

* ship the vhost file in /etc/koha/koha-httpd.conf (the package is
called koha)

* in postinst, create symlink from koha-httpd.conf to sites-available,
and run a2ensite, and restart or reload apache

* in prerm, run a2dissite (site should be disabled before files are
removed, hence prerm instead of postrm)

I'm still pondering whether to do that automatically or not.

In response to Tanguy, I would like the vhost to be unnecessary, but at
the moment it isn't. I hope to make it unnecessary during the next
development cycle.

Post by sean finney

Post by Lars Wirzenius
Koha needs the Apache rewrite module. How do I enable that?

throw an a2enmod in the postinst? a2enmod should be idempotent, and i
think it's fair to leave it enabled when uninstalling the pkg.

a2enmod in postinst is obviously the way to do that, if it is done at
all. I was wondering more about whether it would be acceptable for a
Debian package to go re-configure the local Apache setup at all. It
makes me a bit nervous, and I am not sure I would want it to happen if I
was a user of the package.

In response to Tanguy, the URL rewrites are needed right now, as far as
I can tell. At some point I am going to talk upstream into avoiding
them, but that's potentially going to touch many places in the code and
templates, so it's not an easy change to make right now, when the next
version is being stabilized.

Post by sean finney

Post by Lars Wirzenius
At the moment I don't enable things, but I include a README.Debian that
documents the necessary steps the sysadmin needs to take to enable
things.

honestly, i don't think a conservative approach is all that bad, especially
if there's anything complicated in the process.

It's not complicated, but as a user I would be concerned about packages
that change my carefully crafted Apache configuration, open up new ports
for it to listen to, and enable new modules I do not like to have
enabled (which might be any module).

So I guess I am leaning towards the README.Debian solution.

Post by sean finney

Post by Lars Wirzenius
Koha uses a database, and stores some sensitive information there. For

i guess someone might have already pointed you at dbconfig-common?

I used dbconfig-common for the first time for this package. The short
version of my reaction can be summed in the word "wow".

Post by sean finney

Post by Lars Wirzenius
example, usernames and passwords of its users, and their reading habits.
It would be bad to leak that information to outsiders. Currently, Koha
runs as www-data, which means that its config file is available to all
other web apps, and that in turn means that they have access to the
database. What is best practice here?

there really isn't a good way to get around this unless you are running your
own app server which is proxied by the web server.

Right. I will add some explanation of this to README.Debian.

Post by sean finney
at the same time i kinda think of this as common sense...

Common sense fails when you don't understand the system. And that's the
case for many people installing a web app, I fear. (It certainly is the
case for me...)

[Tanguy Ortolo]

Post by Lars Wirzenius
It's not complicated, but as a user I would be concerned about packages
that change my carefully crafted Apache configuration, open up new ports
for it to listen to, and enable new modules I do not like to have
enabled (which might be any module).
So I guess I am leaning towards the README.Debian solution.

Does that mean that, after installing the package, it will just not work
until the admin has looked to README.Debian and applied the suggested
configuration? That is not cool


I would rather use a debconf question to explain that this package needs
the mod_rewrite to be enabled in order to be usable, ask whether the
admin accepts it or not, and another question – conditional to the first
one – to ask whether the module should be disabled on uninstalling the
package.

[Romain Beauxis]

Post by Tanguy Ortolo
I would rather use a debconf question to explain that this package needs
the mod_rewrite to be enabled in order to be usable, ask whether the
admin accepts it or not, and another question – conditional to the first
one – to ask whether the module should be disabled on uninstalling the
package.

Unfortunately this is not what debconf is meant for:
http://www.debian.org/doc/developers-reference/best-pkging-practices.html#s6.5.1

Based on the feedback I had, most user know that the relevant information
is located in README.Debian.


Romain