en/glep/glep-0020.txt

GLEP: 20
Title: /srv - Services Home Directory Support
Version: $Revision: 1.1 $
Last-Modified: $Date: 2004/02/22 02:09:07 $
Author: Stuart Herbert <stuart@gentoo.org>, Rob Holland <tigger@gentoo.org>
Status: Approved
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Feb-2004
Post-History: 21-Feb-2004, 11-Nov-2004

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)
1	g2boojum	1.1	GLEP: 20
2			Title: /srv - Services Home Directory Support
3	g2boojum	1.2	Version: $Revision: 1.1 $
4			Last-Modified: $Date: 2004/02/22 02:09:07 $
5	g2boojum	1.1	Author: Stuart Herbert <stuart@gentoo.org>, Rob Holland <tigger@gentoo.org>
6	g2boojum	1.2	Status: Approved
7	g2boojum	1.1	Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 09-Feb-2004
10	g2boojum	1.2	Post-History: 21-Feb-2004, 11-Nov-2004
11	g2boojum	1.1
12			Thanks To
13			=========
14
15			Thanks to Robin H. Johnson (robbat2@gentoo.org) for his assistance in writing
16			this GLEP.
17
18			Abstract
19			========
20
21			This GLEP proposes a new root-level directory - /srv - as an optional home
22			for the data (and sometimes the software too) for software that provides
23			services.
24
25			/srv will be supported via a USE flag. This gives users the choice
26			of using a dedicated service home hierarchy or not.
27
28			/srv is defined in FHS 2.3, which is part of the upcoming LSB v2.0 release
29			(http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16)
30
31			Motivation
32			==========
33
34			Gentoo currently does not provide sufficiently flexible support for
35			sites which wish to consolidate the data for their service-orientated
36			software under one simple, easy to administer, location.
37
38			Adding optional support for the /srv directory structure will give
39			sites increased flexibility on how to layout their machines.
40
41			Specification
42			=============
43
44			A new global USE flag - srvdir - will be added to Portage.
45
46			Ebuilds that choose to support the srvdir USE flag will configure the
47			package to install and use their data under the /srv directory.
48
49			Ebuilds that choose to support the srvdir USE flag - and which install
50			packages that need write access to the same directories that the
51			software is installed into - will configure the package to install
52			the software under the /srv directory.
53
54			All packages configured to support the srvdir USE flag will support
55			this breakdown of /srv:
56
57			/srv/<fqdn>/<service>/<service-specific tree>
58
59			where
60			<fqdn> is the fully-qualified domain name
61			<service> is the name of the service
62			<service-specific tree> is unique to the package
63
64			Ebuilds that install anything into /srv will install into /srv/localhost.
65			/srv/localhost - or any of the <service> directories underneath it - may be
66			symlinks created by the local administrator.
67
68			Examples
69			========
70
71			For example, backup packages which support the srvdir USE flag could
72			save backup data under the /srv/<hostname>/backups directory for each
73			host on the network that they perform backups for.
74
75			For example, web-based applications which support the srvdir USE flag
76			could install their software under the /srv/localhost/www/htdocs directory.
77			Ebuilds for web-based applications which also support the vhost USE flag
78			will allow the user to install software under other service domains
79			through the webapp-config package. See GLEP #11 and the vhost-config tool for
80			more information on how this works.
81
82			There are many other packages that could support the srvdir USE flag -
83			including Portage itself.
84
85			For packages that do not support the srvdir USE flag, there is currently no
86			recommended default location to use - although /var/localhost may prove a
87			useful alternative.
88
89			Rationale
90			=========
91
92			Introducing optional support for the /srv directory will benefit a number of
93			groups of Gentoo users.
94
95			* Users who wish to have /usr mounted read-only
96
97			/srv provides an optional alternative for packages that install writable
98			files into /usr.
99
100			* Users who wish to isoloate services from /home utilisation
101
102			Services stop working when real users fill /home. As many packages cannot
103			detect or robustly cope with this situation, services that write files
104			to disk normally end up corrupting those files.
105
106			* Users who do not wish to export /var or its sub-directories
107
108			Exporting /var - or its subdirectories - via NFS et al is something that
109			some system administrators simply do not wish to do. Providing these users
110			with the choice of installing into /srv fits with the published Gentoo
111			philosophy of allowing users as much choice as possible.
112
113			* Users who share resources via NFS, or who use Network-Attached Storage (NAS)
114
115			Allowing system administrators to choose to configure service-providing
116			software to use a single file hierarchy will greatly simply the management
117			and maintenance of NFS exports - and imports - in clustered environments.
118
119			* Service providers, who host more than one customer's services on a machine
120
121			Grouping all the storage (web, ftp, databases, IMAP, etc etc) under one
122			location greatly simplifies managing disk quotas on that host.
123
124			It is common practice for shared hosted systems to place web sites,
125			ftp sites and so on under a user's actual home directory. This practice
126			requires the user's home directory to be world-readable, which does not
127			promote strong security!
128
129			* Users who wish to store service-orientated files onto a single logical
130			volume to support future growth
131
132			The Gentoo Philosophy clearly states that Gentoo Linux will be a
133			highly-configurable meta-distribution. Adding optional support for /srv is
134			very much in keeping with our Philosophy.
135
136			Implementation
137			==============
138
139			A new USE flag - srvdir - will be added to Portage.
140
141			Ebuilds and eclasses will choose to support the srvdir USE flag or not on
142			an individual basis.
143
144			(Author's note: If this GLEP is approved, all web-based applications will
145			support the srvdir USE flag through the work being carried out under GLEP #11)
146
147			There has been some debate about whether the /srv directory should be provided
148			by the basesystem package or not. Because this support is optional, and
149			because different sites will have different storage requirements, we believe
150			that it should be left to the local Gentoo system administrator to manually
151			create the /srv directory.
152
153			If baselayout feels that it must install a /srv, then we propose that
154			baselayout installs /srv as a symlink to /var/srv. This approach will support
155			installations that mount the root filesystem read-only.
156
157			Backwards Compatibility
158			=======================
159
160			Users who choose not to use the new srvdir USE flag will see little to no
161			change. It is likely that some ebuilds will change their non-srvdir directory
162			layout to reduce the amount of effort required to support both options.
163
164			Copyright
165			=========
166
167			This document is licensed under the Creative Commons - Attribution / Share
168			Alike license. (http://creativecommons.org/licenses/by-sa/1.0)