Re: Web app and httpd (apache2) reconfig questions
Thanks sean and Tanguy, for your quick answers. I am responding to both
of you in the same mail, to avoid unnecessary list traffic.
On Mon, 2010-04-19 at 20:05 +0200, sean finney wrote:
> 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.
> > 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.
> > 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.
> > 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".
> > 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.
> 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...)
Reply to: