[Mageia-dev] Proofreading web applications policy

[Remy CLOUARD]

Hello there,

I started to have a look at the webapps policy.

There’s something that has been bugging me for a while, that’s the
apache-centric way of thinking of this policy.

To me, there are valuable alternatives to apache that deserve to be
treated equally.
Here are the packages that provides webserver

apache-ssl|apache-mpm-event|apache-mpm-peruser|nginx|lighttpd|
cherokee|apache-mpm-itk|apache-mpm-worker|thttpd|apache-mpm-rsbac|
apache-mpm-prefork|boa

“These are the files that are susceptible to change during the
application's lifetime. They go in /var/lib/foo. If they are supposed to
be editable by the application directly from the web interface, they
should be owned by apache user and apache group.”

Could we create a generic group (webserver for instance) to allow
webapps to play nice with these webserver ?

Same goes for logfiles and config files containing sensitive
informations.

I would also be in favor of creating subpackages for webapps that
provides better integration with apache such as files in
/etc/httpd/conf/webapps.d/.

That way, webapps should have a Requires on webserver, and the
subpackage should have one on apache.

Another issue is the owner of /var/www. This directory is owned by
apache-conf. Could we instead make a generic package called
webserver-data for instance that would provide it ? This way each
package providing webserver would have to require webserver-data.

Finally, that may be a little cosmetic detail, but I would prefer
template files for apache to be in a separate file in SOURCES/ that’s
included instead of creating it in the spec like:
cat > %{buildroot}%{_webappconfdir}/%{name}.conf <<EOF
-- 
Rémy CLOUARD
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110118/d03ff77a/attachment.asc>