[Webapps-common-discuss] webapps-common/doc Webapps-Policy-Manual-DRAFT.txt,1.12,1.13
sukria-guest@haydn.debian.org
sukria-guest@haydn.debian.org
Update of /cvsroot/webapps-common/webapps-common/doc
In directory haydn:/tmp/cvs-serv27806/doc
Modified Files:
Webapps-Policy-Manual-DRAFT.txt
Log Message:
some more stuff for the 4.1 section
Index: Webapps-Policy-Manual-DRAFT.txt
===================================================================
RCS file: /cvsroot/webapps-common/webapps-common/doc/Webapps-Policy-Manual-DRAFT.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- Webapps-Policy-Manual-DRAFT.txt 9 May 2005 13:35:29 -0000 1.12
+++ Webapps-Policy-Manual-DRAFT.txt 9 May 2005 15:52:59 -0000 1.13
@@ -125,7 +125,7 @@
2.1 Web applications and the FHS
-web applications should follow the same guidelines as any other
+Web applications should follow the same guidelines as any other
software. most specifically, they should not make any assumption about
how the administrator has arranged the file hierarchy outside of the FHS
by placing files in non-standard places such as /var/www or /usr/local.
@@ -139,7 +139,6 @@
dynamically interpreted web pages /usr/share/PACKAGE/www*
persistent application data /var/lib/PACKAGE
dynamcially executed web pages /usr/lib/cgi-bin/PACKAGE**
-dynamically executed web pages /usr/lib/cgi-bin/PACKAGE**
application-specific libraries /usr/share/PACKAGE/include***
site configuration (settings/passwords) /etc/PACKAGE
locally modifiable/overridable content /etc/PACKAGE****
@@ -147,6 +146,7 @@
Architecture independant Perl libraries /usr/share/perl5/PACKAGE
Architecture dependant Perl libraries /usr/lib/perl5/PACKAGE
rrd, mrtg and other database files see database application policy
+Template cache files /var/cache/PACKAGE/templates
*: also acceptable are "htdocs", "site", or any other name, as long as
it is clearly identifying and a subdirectory of /usr/share/PACKAGE. this
@@ -158,19 +158,20 @@
else, as long as it is identifiable, outside the documentroot, and in
a subdirectory of /usr/share/PACKAGE.
+
2.2 Configuration Files and Customizable Content
-in-line with standard FHS policy, any files that require being edited by
+In-line with standard FHS policy, any files that require being edited by
the local administrator (for information such as "themes" or credentials
to a database) must be located under /etc, in a directory specific to
the package in question.
-often the upstream authors of software will ship a configuration file
+Often the upstream authors of software will ship a configuration file
that is located underneath the web root of the application. the admin
must not be required to edit these files because package upgrades could
lead to loss of this configuration.
-the best way to work around such a problem is by using whatever is
+The best way to work around such a problem is by using whatever is
the appropriate "include" construct for the language in question (in
PHP this would be "require_once", in perl "use") to include a smaller,
trimmed down configuration file from underneath /etc.
@@ -180,13 +181,13 @@
Webapp configuration files will likely need to have permissions and ownership
different from the standard root:root ownership and 644 permissions. The most
notable reason for this is that the webserver usually needs the ability to
-read some of these configuration files. note that some applications provide
-the ability to edit their configuration via a web-based interface. in such
-a case, the files should be writable by the www-data group. the local
+read some of these configuration files. Note that some applications provide
+the ability to edit their configuration via a web-based interface. In such
+a case, the files should be writable by the www-data group. The local
administrator should always be able to prevent this behaviour by changing the
file permissions via dpkg-statoverride.
-the following table reflects the requirements for configuration file
+The following table reflects the requirements for configuration file
permissions and ownership
FIXME: maybe we should add this to the above table, with specs for all files?
@@ -275,6 +276,8 @@
3.2.2 Registering and unregistering a php module
+FIXME sukria : should such a piece of code be provided by a webapps-common package?
+
An entry should be placed in the relevent php.ini using postinst, if this is OK by the admin.
--- SAMPLE CODE ---
for pkg in apache cli cgi; do
@@ -297,6 +300,8 @@
done
--- SAMPLE CODE ---
+FIXME sukria: same question as above
+
Upon removal, the relevent entry in php.ini should be removed by prerm, if OK-ed by the admin
--- SAMPLE CODE ---
for pkg in apache cli cgi; do
@@ -332,6 +337,29 @@
---------------------------------------------------------------------
4.1 Registering a web application with the server
+
+4.1.1 Symlinking the document root
+
+One of the easiest way to register the web application with the web server is to
+symlink the document root of the web application under /var/www.
+
+For instance, a web application is likely to put its document root under
+/usr/share/bugzilla/www (as suggested on section 2.1) and should then add a
+symlink like that:
+
+ /var/www/package -> /usr/share/package
+
+This is the easiest way to make the web site visible from the web server
+(accessing http://host/package/ is now possible).
+
+4.1.2 Adding a Location to the webserver configuration
+
+There is a more complex way of regitering the web application which may be
+better than the previous one
+
+FIXME sukria: ... to be continued ...
+
+FIXME sukria: find other ways ...
4.2 Unregistering a web application with the server