hi lars, On Mon, Apr 19, 2010 at 02:35:47PM +1200, Lars Wirzenius wrote: > 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). > 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. > 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. > 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. > Koha uses a database, and stores some sensitive information there. For i guess someone might have already pointed you at dbconfig-common? > 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. > 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 --
Attachment:
signature.asc
Description: Digital signature