On Sun, 2006-05-07 at 13:26 -0500, Mike McGrath wrote: > On 5/7/06, Michael A. Peters <mpeters@xxxxxxx> wrote: > > > The apache stuff in /var/www probably should be in /usr/share (except > > the default DocumentRoot root which IMHO should be in /srv/www/html ) > > the whole /var/www/ thing has puzzled me as well. I think we should > have a partitioned place for web applications. Perhaps just because I > use a lot of web apps. /usr/share/www/packagename/ seems very > reasonable to me. That's not too unreasonable. I don't think it is necessary but I don't think it is objectionable. > > > You shouldn't need to patch anything to get it to work from /usr/share > > instead of /var/www - it should be done with a config file > > in /etc/httpd/conf.d/ > > I've run into issues with config files for the actual application > which, according to FHS, should be in /etc. But the web apps don't > like it when we just move stuff on 'em. And then if you have a web > app that does polling and stores files those shouldn't be in > /usr/share but in /var/something depending on the type of content. > Some web apps also have their own logs. Yes - those require patching though even if put in /var/www. Config files should never be in the web app root for security reasons. With php - I know you can make a php includes directory that php can see what apache can't. That's what I do for things like database passwords etc. The /var/something is important also for security reasons - especially with SELinux. > > > What type of patching are you required to do for FHS guideline > > compliance? > > Basically just letting apps know that they will be storing files > (logs, config's, spools, cache, misc) in /var/whatever instead of a > path relative to the app which its used to. Try to get those patches upstream, as upstream is broken in those cases. Where to put log files and cache etc. should be in the configuration file and not in the web app code itself. -=- I personally don't do a lot with web applications (I did in a former job) - but maybe we need a web app SIG to come to a consensus on how they should be done, and submit docs to FESCO for approval or rejection, so that people packaging them can have somewhere to look. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
