webapp packaging

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

webapp packaging

wookey-4
I have been packaging a small cgi webapp (for accounting). This has
generated some queries about webapp packaging.

Do we have policy on this? Or a place to disuss such things other than here?

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.

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?

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.

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.

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.

5) Should a package support other web-server configs than apache?

That'll do for now. not-quite finished package is here:
http://wookware.org/files/bankofcucc/

Cheers for any clues.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: webapp packaging

Paul Wise via nm
On Sun, Jun 16, 2019 at 9:44 AM Wookey wrote:

> I have been packaging a small cgi webapp (for accounting). This has
> generated some queries about webapp packaging.
>
> Do we have policy on this? Or a place to disuss such things other than here?

Debian webapp policy stuff is fairly dead, some links:

https://lists.debian.org/debian-webapps/
https://wiki.debian.org/Proposals/Webapps
https://wiki.debian.org/webapppolicy
https://wiki.debian.org/CGI
https://wiki.debian.org/SummerOfCode2007/WebAppsTools
https://wiki.debian.org/SummerOfCode2015/Projects/AutoConfigWebApps
https://web.archive.org/web/http://webapps-common.alioth.debian.org/draft/html/
https://alioth-archive.debian.org/cvs/webapppolicy.tar.xz
https://alioth-archive.debian.org/cvs/webapps-common.tar.xz
https://alioth-archive.debian.org/svn/webapps-common.tar.xz

My personal opinion is that a webapp package author cannot know where
the person installing the package intends for it to be available on
the web, where on the filesystem data for that website should live,
which web server the sysadmin prefers etc. So those things need to be
determined dynamically at postinst time or at a later website setup
time.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: webapp packaging

Jonas Meurer
In reply to this post by wookey-4
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


signature.asc (849 bytes) Download Attachment