Lo all, There's been quite a bit of discussion [0][1] recently on the state of policy and where to place WebApps. Some very interesting points have come up from this: Useage of /usr/share/PACKAGE/www/ : ----------------------------------------------------------------------- <20050620125556.GA7945@starless.xtnet> - xtifr@debian.org ----------------------------------------------------------------------- [snip] And what happens if my WebApp package is named "doc"? Or "applnk"? Or "keymaps" or "locale" or "pixmaps" or "zoneinfo"? While /usr/share/* is not the world's most overloaded namespace, its overloaded enough to cause me some concern, and if there are any reasonable alternatives (and I think there are), I would recommend using one instead. [snip] ----------------------------------------------------------------------- So, it has been suggested that /srv/[webapps|www]/PACKAGE/ is used. However, this contains it's own problems: ----------------------------------------------------------------------- http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM ----------------------------------------------------------------------- Purpose: /srv contains site-specific data which is served by this system. Rationale: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. Distributions must take care not to remove locally placed files in these directories without administrator permission. ----------------------------------------------------------------------- <20050622095715.GB8824@riva.ucam.org> - cjwatson@flatline.org.uk ----------------------------------------------------------------------- [snip] Consider: it's common practice to have /srv/$HOSTNAME for services hosted by the system. Let's say somebody's internal web applications hostname happens to be 'webapps' (and they decided not to bother with the FQDN in the directory). Now you've just trampled over their local configuration. If anything, /srv/www is even more likely to be already in use. Once something has been declared to be site-specific, you can't go back on that. [snip] ----------------------------------------------------------------------- <1119429699.9166.11.camel@localhost.localdomain> - lukas@knup.de ----------------------------------------------------------------------- The FHS dictates: /src is site-specific. The Policy dictates: webapps-files in /usr/share/package/, which I strongly agree. Now, what prevents us writing helper-packages to maintain a subset of, say, /srv/webapps/? It could be, like Kai said, /srv/[webapps|www]/HTTP_HOST/ or whatever, that is managed by this helper-package. I mean, every Webapp which has to have the static (.inc.php or whatever) files _inside_ the webroot is seriously broken. We could instead just have everything static in /usr/share/package/whatever, everything configurable by the user in /etc/package/whatever, and assembling everything together via /srv/webapps/whatever. So, say, wordpress - has the programm in /usr/share/wordpress/, the per-site-configuration somewhere in /etc/wordpress/SITE (to be agreed upon), and /srv/webapps/whatever[1..inf]/ defining the site. ----------------------------------------------------------------------- What's the consenus on these options, and does anyone have any other good ideas on what to do with this? Cheers, Neil [0] http://lists.debian.org/debian-policy/2005/06/msg00100.html [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314808 -- __ .Ž `. neilm@debian.org : :' ! ---------------- `. `Ž gpg: B345BDD3 `- Please don't cc, I'm subscribed to the list
Attachment:
signature.asc
Description: Digital signature