Hey Wookey, In general, I think that we should aim for webapps being accessible (and usable) out-of-the-box after installation while still allowing later customization by admins. Wookey: > The app consists of one main program file (boc.pl), a config file, > and a set of resource files (html, images and some internal perl > modules). > > Upstream intends all the files to be dropped into one location which > is made cgi-executable (for *.pl), (and www-data readable) but this > doesn't really fit very well with debian policy/default config, where > the config file in in /etc and the the cgi-bin file is in > /usr/lib/cgi-bin and the rest is in /usr/share/package. Yeah, I would place the different parts of the webapp exactly the way you described it on the filesystem. > It also uses a git repo as a data store. (which needs to be r/w by > www-data). The root of that is set in the config file. > > So. To my questions: > > 1) This won't work without cgi enabled in apache. Cgi (mod_cgi or > mod_cgid) is installed but disabled in a fresh install of > apache. However none of the packages I looked at that install things > in /usr/lib/cgi-bin turns mod_cgi or mod_cgid on. Is it in fact policy > that packages should not enable webserver features like this, and it > has to be an admin task? Currently I have a postinst that works out > which module is needed (with a2query -M) and then enables it with > a2enmod. Should it in fact not do this? It's pretty common for webapps to activate/deactivate Apache2 modules in postinst. So I don't see a problem with your app doing it. Quite the contrary, the package would be useless without the module, so I think that you *should* activate it in postinst. I do the same in my (admitted rather rusty) package 'lurker'. > 2) Where should a default data dir for a web-app live? > /var/www/package? /var/lib/package? Somewhere else? And for the app > itself? dwww puts stuff in /var/www/dwww and /usr/share/dwww as well > as the binary in /usr/lib/cgi-bin. I'm really not quite sure how one > decides what goes where. That would be /var/lib/package. At least that would be the case if the data dir doesn't have to live in the webservers document root. > 3) There is some tension between heavily debianfying such a package > (so it just works after install and looks debian-packagey' and leaving > it more like upstream 'all in one dir, sort out your own config'. One > doesn't know how the webserver will be set up (vhosts etc). Especially > if having things in different dirs meand significnat patching of > upstream - that seems like a maintenance burden and potential > bug-source. I definitely think it's worth the effort nevertheless. If we aim for packaging webapps at all in Debian, then we should make it easier for the admin compared to installing the upstream version in a vhost docroot. > 4) It's nicer (in 2019) to have a URL like http://localhost/package/ > or http://localhost/package/boc.pl than one with cgi-bin in it: > http://localhost/cgi-bin/boc.pl Is there policy on this or other > guidelines? Other packages seem to do all sorts of things. I think there's no clear guideline on this and the decision is left to you. if it's a single CGI file, I would probably provide an Alias /package that points to this CGI file. In general, providing a webserver config include file (in case of Apache under /etc/apache2/conf-available/) is very helpful. Many webapps ask via debconf whether the webserver should be configured automatically. You might want to consider this. Again, you might want to take a look at lurker (or mailman-suite) source package for an example. If the admin decides to auto-configure the webserver during installation, then the config include file will be activated globally (therefore being available on all vhosts). If the admin doesn't want this, they can manually include the config include file in the desired vhost. > 5) Should a package support other web-server configs than apache? That'd be really nice! We try to do so for nginx at least in mailman-suite. Unfortunately, last time I looked, the tools to manage config include files where not in place yet in the Debian nginx packages. Maybe that changed in the meantime. Cheers jonas
Attachment:
signature.asc
Description: OpenPGP digital signature