Rename all GLEPs to .rst

1 files changed, 171 insertions, 0 deletions

diff --git a/glep-0020.rst b/glep-0020.rst
new file mode 100644
index 0000000..6db552e
--- /dev/null
+++ b/glep-0020.rst
@@ -0,0 +1,171 @@
+GLEP: 20
+Title: /srv - Services Home Directory Support
+Version: $Revision$
+Last-Modified: $Date$
+Author: Stuart Herbert <stuart@gentoo.org>, Rob Holland <tigger@gentoo.org>
+Status: Accepted
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 09-Feb-2004
+Post-History: 21-Feb-2004, 11-Nov-2004
+
+Note: This document needs to be relicensed to CC-BY-SA 3.0 after consulting
+with the original author
+
+Thanks To
+=========
+
+Thanks to Robin H. Johnson (robbat2@gentoo.org) for his assistance in writing
+this GLEP.
+
+Abstract
+========
+
+This GLEP proposes a new root-level directory - /srv - as an optional home
+for the data (and sometimes the software too) for software that provides
+services.
+
+/srv will be supported via a USE flag.  This gives users the choice
+of using a dedicated service home hierarchy or not.
+
+/srv is defined in FHS 2.3, which is part of the upcoming LSB v2.0 release
+(http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16)
+
+Motivation
+==========
+
+Gentoo currently does not provide sufficiently flexible support for
+sites which wish to consolidate the data for their service-orientated
+software under one simple, easy to administer, location.
+
+Adding optional support for the /srv directory structure will give
+sites increased flexibility on how to layout their machines.
+
+Specification
+=============
+
+A new global USE flag - srvdir - will be added to Portage.
+
+Ebuilds that choose to support the srvdir USE flag will configure the
+package to install and use their data under the /srv directory.
+
+Ebuilds that choose to support the srvdir USE flag - and which install
+packages that need write access to the same directories that the
+software is installed into - will configure the package to install
+the software under the /srv directory.
+
+All packages configured to support the srvdir USE flag will support
+this breakdown of /srv:
+
+	/srv/<fqdn>/<service>/<service-specific tree>
+	
+where
+	<fqdn> is the fully-qualified domain name
+	<service> is the name of the service
+	<service-specific tree> is unique to the package
+
+Ebuilds that install anything into /srv will install into /srv/localhost. 
+/srv/localhost - or any of the <service> directories underneath it - may be
+symlinks created by the local administrator.  
+
+Examples
+========
+
+For example, backup packages which support the srvdir USE flag could
+save backup data under the /srv/<hostname>/backups directory for each
+host on the network that they perform backups for.
+
+For example, web-based applications which support the srvdir USE flag
+could install their software under the /srv/localhost/www/htdocs directory.
+Ebuilds for web-based applications which also support the vhost USE flag
+will allow the user to install software under other service domains
+through the webapp-config package.  See GLEP #11 and the vhost-config tool for
+more information on how this works.
+
+There are many other packages that could support the srvdir USE flag -
+including Portage itself.
+
+For packages that do not support the srvdir USE flag, there is currently no
+recommended default location to use - although /var/localhost may prove a
+useful alternative.
+
+Rationale
+=========
+
+Introducing optional support for the /srv directory will benefit a number of
+groups of Gentoo users.
+
+* Users who wish to have /usr mounted read-only
+
+  /srv provides an optional alternative for packages that install writable
+  files into /usr.
+
+* Users who wish to isoloate services from /home utilisation
+
+  Services stop working when real users fill /home.  As many packages cannot
+  detect or robustly cope with this situation, services that write files
+  to disk normally end up corrupting those files.
+
+* Users who do not wish to export /var or its sub-directories
+
+  Exporting /var - or its subdirectories - via NFS et al is something that
+  some system administrators simply do not wish to do.  Providing these users
+  with the choice of installing into /srv fits with the published Gentoo
+  philosophy of allowing users as much choice as possible.
+
+* Users who share resources via NFS, or who use Network-Attached Storage (NAS)
+
+  Allowing system administrators to choose to configure service-providing
+  software to use a single file hierarchy will greatly simply the management
+  and maintenance of NFS exports - and imports - in clustered environments.
+
+* Service providers, who host more than one customer's services on a machine
+
+  Grouping all the storage (web, ftp, databases, IMAP, etc etc) under one
+  location greatly simplifies managing disk quotas on that host.
+  
+  It is common practice for shared hosted systems to place web sites,
+  ftp sites and so on under a user's actual home directory.  This practice
+  requires the user's home directory to be world-readable, which does not
+  promote strong security!
+
+* Users who wish to store service-orientated files onto a single logical 
+  volume to support future growth
+
+The Gentoo Philosophy clearly states that Gentoo Linux will be a
+highly-configurable meta-distribution.  Adding optional support for /srv is
+very much in keeping with our Philosophy.
+
+Implementation
+==============
+
+A new USE flag - srvdir - will be added to Portage.
+
+Ebuilds and eclasses will choose to support the srvdir USE flag or not on
+an individual basis.
+
+(Author's note: If this GLEP is approved, all web-based applications will
+support the srvdir USE flag through the work being carried out under GLEP #11)
+
+There has been some debate about whether the /srv directory should be provided
+by the basesystem package or not.  Because this support is optional, and
+because different sites will have different storage requirements, we believe
+that it should be left to the local Gentoo system administrator to manually 
+create the /srv directory.
+
+If baselayout feels that it must install a /srv, then we propose that
+baselayout installs /srv as a symlink to /var/srv.  This approach will support
+installations that mount the root filesystem read-only.
+
+Backwards Compatibility
+=======================
+
+Users who choose not to use the new srvdir USE flag will see little to no
+change.  It is likely that some ebuilds will change their non-srvdir directory
+layout to reduce the amount of effort required to support both options.
+
+Copyright
+=========
+
+This document is licensed under the Creative Commons - Attribution / Share
+Alike license. (http://creativecommons.org/licenses/by-sa/1.0)