GLEP 20: /srv - Services Home Directory Support
Author | Stuart Herbert <stuart@gentoo.org>, Rob Holland <tigger@gentoo.org> |
---|---|
Type | Standards Track |
Status | Deferred |
Version | 1 |
Created | 2004-02-09 |
Last modified | 2018-09-12 |
Posting history | 2004-02-21, 2004-11-11 |
GLEP source | glep-0020.rst |
Contents
Status
Implementation not completed. Marked deferred by GLEP editor Michał Górny on 2017-10-13.
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 isolate 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 work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/3.0/.