From c6fe2071a2e83be2203196ad7f9459941821a034 Mon Sep 17 00:00:00 2001 From: Michał Górny Date: Thu, 14 Sep 2017 23:14:39 +0200 Subject: Rename all GLEPs to .rst --- glep-0020.rst | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 glep-0020.rst (limited to 'glep-0020.rst') 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 , Rob Holland +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/// + +where + is the fully-qualified domain name + is the name of the service + is unique to the package + +Ebuilds that install anything into /srv will install into /srv/localhost. +/srv/localhost - or any of the 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//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) -- cgit v1.2.3-65-gdbad