PHP packaging guidelines

[Andreas Thienemann]

On Thu, 25 May 2006, Mike McGrath wrote:

> At this point my vote is for /usr/share/.
This point is not really open for discussion anymore.

We already talked about that at last weeks fesco meeting and 
/usr/share/%{name} was it for normal php-web-apps.

This of course means that the packager would have to fiddle a bit with 
selinux-permission, but it is managable.
There are some examples flying around and I plan to flesh out the 
packaging guidelines with them. Time permitting of course.

> Why does /var/www/* even exist?  Also, we should probably put in there
> a little note that says that just because its a web app doesn't mean it
> can break FHS.  (I've been guilty of this on more than one occasion).  

> Its the packagers job to put logs in /var/log, cache or any other files
> that get written to in their appropriate /var/ directory.  Exceptions to
> this should be rare.
Naturally. Especially as it is not such a big problem to do so.
A little patchfile and everything is fine.

Something else I want to strongly suggest when finishing the guidelines: 
There _SHOULD_ be a 'die("Please configure this application in 
/etc/%{name}")' at the start of the configuration file (as long as it's 
php-code and called via include() or something similar).

This prevents security problems in case the application is unconfigured.

The alternative would be to set the /usr/share/foo mapping to only accept 
connections from localhost for the webapp in question. This is done in 
/etc/httpd/conf.d/%{name}.conf.
This should probably be required for webapps which offer these darned 
"installation-wizards". (Ohhh, how I hate them...)
 
> We've talked about this a bit on the list before but should we also
> mention a "All web apps should be available to localhost only by
> default" guideline.  I know most of what I'm talking about is general
> web app guidelines, perhaps its time to re-evaluate them.  Unless
> they're already out there and I'm not seeing them :-D
See above.
My plans are actually going further than just localhost.

regards,
 andreas