Carl Fürstenberg schrieb:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debia
This one time, at band camp, Joey Hess said:
> The idea that you shoot off a list saying "eh, Debian would like to violate
> the
> FHS now" and get back a "oh, fine we put in a footnote, so you're still FHS
> compliant" does not match anything I've observed re the FHS.
That was sort of the point
]] Gunnar Wolf
| What could be a course of action is that all webservers ship (as I
| described I am doing earlier on) their default sites in
| /usr/share//default-site, and instead of an "It works!" or
| similar page, information on what steps should the user take to turn
| it into something use
On Sun, Jul 20, 2008, Joey Hess wrote:
> I think that there's room for Debian to establish distro-wide policies
> for the *default* directories in /srv, as a suppliment to the FHS.
I don't see the need for taking the risk of FHS non-compliance.
Why not use a new package for such policies?
e.g
Joey Hess dijo [Wed, Jul 23, 2008 at 11:59:05AM -0400]:
> Gunnar Wolf wrote:
> > Moving from /var/www to /srv/www gains nothing - We would still have
> > all webservers throwing files where they are not supposed to, to a
> > user-managed directory.
>
> There's a large difference between Debian as
FHS:
| Applications must generally not add directories to the top level of /var. Such
| directories should only be added if they have some system-wide implication,
and
| in consultation with the FHS mailing list.
Stephen Gran wrote:
> /var/www is not actually explicitly forbidden, just implicitly
Gunnar Wolf wrote:
> Moving from /var/www to /srv/www gains nothing - We would still have
> all webservers throwing files where they are not supposed to, to a
> user-managed directory.
There's a large difference between Debian as a whole violating the FHS
by using a nonstandard top-level director
On Wed, Jul 23, 2008 at 3:48 AM, sean finney <[EMAIL PROTECTED]> wrote:
>sean (with his dusty debian webapps team hat on)
Exactly.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
On Monday 21 July 2008 06:16:16 pm Steve Langasek wrote:
> The process for deploying content under apache with the current settings is
> "copy it to /var/www". If we used /srv/www as a default, the process would
> be "mkdir -p /srv/www && ..." I don't think that's a hugely significant
> differen
Hi,
On Monday 21 July 2008 05:17, Joey Hess wrote:
> Hmm, my reading of this has been that programs should default to using a
> directory in /srv (it says "should be used as the default location for
> such data"), but have to allow being configured to use any other
> directory in or out of /srv fo
On Mon, Jul 21, 2008 at 01:26:09PM +0200, Gabor Gombas wrote:
> "This main purpose of specifying this is so that _users_ may
> find the location of the data files for particular service, ..."
>
> Note how it only talks about users, not the operating
> system/distribution.
Also note that it says "
Brian May wrote:
>
> Packages should not fill [the default webroot] directory with any
> files. Period. No exceptions. Not even .htaccess files (which normally
> shouldn't be used anyway because enabling these slows down web
>this accesses - at least according to official Apache documentation).
N
On Monday 21 July 2008, Steve Langasek wrote:
> Would the suggested /srv/www/localhost/htdocs as a default work for you?
> Apparently this is widely deployed on other distros, and seems to be
"Apparently" and "widely" lead me to think something is fishy with this
suggestion.
Centos/RedHat/Mandri
Franklin PIAT wrote:
In a few years from now, many packages will have migrated their stuffs
from /var/lib/* to /srv/$1/localhost/.
At that time, the whole benefit of /srv being a clean location would be
voided.
Personally I am happy with what ever location Debian decides to be the
default. H
On Mon, 2008-07-21 at 14:04 -0700, Don Armstrong wrote:
> On Mon, 21 Jul 2008, Franklin PIAT wrote:
> > Can Debian satisfy them both ? Well... why not !
>
> We already do. Someone who was concerned about such things could write
> a policy-rc.d which checked to see whether a particular daemon was
>
Ben Finney dijo [Sun, Jul 20, 2008 at 10:39:43AM +1000]:
> > Should we force all httpd:s to use /srv/www instead of /var/www, or
> > should an exception to the policy be added?
>
> I think there's no hardship if we support the FHS location, so an
> exception shouldn't be made.
>
> What do you mea
On Mon, 21 Jul 2008, Franklin PIAT wrote:
> Can Debian satisfy them both ? Well... why not !
We already do. Someone who was concerned about such things could write
a policy-rc.d which checked to see whether a particular daemon was
allowed to start based on any number of critera, including whether
On Mon, 2008-07-21 at 18:32 +0100, Stephen Gran wrote:
> This one time, at band camp, Steve Langasek said:
> > On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> > > > > So you think it's a good idea to ignore the the sentence above?
> >
> > > > No, I don't think that using it as a de
On Mon, 2008-07-21 at 07:46 -0500, William Pitcock wrote:
> On Mon, 2008-07-21 at 13:26 +0200, Gabor Gombas wrote:
> > On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> >
> > > Yes. My webservers tend to use something like
> > > /srv/www//{config,cgi-bin,htdocs,lib,logs,blah,blah}/
This one time, at band camp, Steve Langasek said:
> On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> > > > So you think it's a good idea to ignore the the sentence above?
>
> > > No, I don't think that using it as a default webroot is "rely[ing] on a
> > > specific subdirectory stru
On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> > > So you think it's a good idea to ignore the the sentence above?
> > No, I don't think that using it as a default webroot is "rely[ing] on a
> > specific subdirectory structure of /srv existing or data necessarily being
> > stored
Stefano Zacchiroli wrote:
> ... but I've a lighter interpretation of the text you quoted: a package
> can for example have a configuration dialog upon removal (or maybe only
> upon purging) that ask whether or not to remove stuff placed under /srv.
You are correct.
I don't think that we should ad
On Sun, Jul 20, 2008 at 11:35:09PM -0400, Joey Hess wrote:
> The FHS is pretty amusing on this topic:
Agreed ...
> Distributions must take care not to remove locally placed files in these
> directories (/srv/*) without administrator permission. [20]
>
> [20] This is particularly important
Stephen Gran wrote:
> Please no. The layout of /srv/ is specifically said to be undetermined,
> so we can't actually rely on any paths in /srv/. I think the current
> setup is fairly good, actually - by default simple site layouts work out
> of the box, and don't interfere with more complicated s
Ben Finney wrote:
> I'm now in favour of '/srv' being out of bounds for the package
> manager, like '/usr/local'.
The FHS is pretty amusing on this topic:
Distributions must take care not to remove locally placed files in these
directories (/srv/*) without administrator permission. [20]
[2
Tollef Fog Heen wrote:
> You can't know the structure of /srv, see the FHS rationale:
>
> The methodology used to name subdirectories of /srv is unspecified
> as there is currently no consensus on how this should be done. One
> method for structuring data under /srv is by protocol, eg. ftp,
Hi,
On Mon, 2008-07-21 at 13:26 +0200, Gabor Gombas wrote:
> On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
>
> > Yes. My webservers tend to use something like
> > /srv/www//{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
> > normal layout. Exposing /srv/www as a document root
On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> Yes. My webservers tend to use something like
> /srv/www//{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
> normal layout. Exposing /srv/www as a document root would give access to
> lots of things that are not public in many cas
This one time, at band camp, Steve Langasek said:
> On Mon, Jul 21, 2008 at 01:14:05AM +0100, Stephen Gran wrote:
> > This one time, at band camp, Steve Langasek said:
> > > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > > > So you "vote" for an exemption from FSH in this case,
On Mon, Jul 21, 2008 at 01:14:05AM +0100, Stephen Gran wrote:
> This one time, at band camp, Steve Langasek said:
> > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > > So you "vote" for an exemption from FSH in this case, as per
> > > > 9.1.1?
> > > http://www.debian.org/doc/pa
This one time, at band camp, Steve Langasek said:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > So you "vote" for an exemption from FSH in this case, as per
> > > 9.1.1?
>
> > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>
On Sunday 20 July 2008, Steve Langasek wrote:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> I think it's perfectly in keeping with other parts of policy to ship our
> webservers with /srv/www as the default webroot, and leave it up to the
I think that this is a terrible idea.
Edward Allcutt <[EMAIL PROTECTED]> writes:
>
> Purpose
>
> /srv contains site-specific data which is served by this system.
>
>
> To me "site-specific" implies "not installed by the package manager".
> I believe it's quite reasonable for apache, CVS, etc. to set up a
> default location under
On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > So you "vote" for an exemption from FSH in this case, as per 9.1.1?
> http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> "Therefore, no program should rely on a specific subdirectory s
On Sun, Jul 20, 2008 at 07:36:33PM +0100, Stephen Gran wrote:
> > I was refering to the use of /var/www, which isn't FHS valid, and no
> > excemption is made in the policy about that.
> The FHS is not an exhaustive list of every directory on the system, so
> I'm not convinced that introducing a n
This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 19:58, Stephen Gran <[EMAIL PROTECTED]> wrote:
> >
> > I don't think there's any excemption needed. The FHS already makes it
> > essentially impossible for distributors to place anything under /srv.
> > Not putting anyth
On Sun, Jul 20, 2008 at 19:58, Stephen Gran <[EMAIL PROTECTED]> wrote:
> http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>
> "Therefore, no program should rely on a specific subdirectory structure
> of /srv existing or data necessarily being stored in
On Sun, Jul 20, 2008 at 07:32:33PM +0200, Carl Fürstenberg wrote:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBY
This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> >> to
On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> This one time, at band camp, Carl Fürstenberg said:
>> FHS 2.3 specifies in
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>> to use /srv for "Data for services provided by this system", for
This one time, at band camp, Carl Fürstenberg said:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http:
Le Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg a écrit :
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the sect
On Sun, Jul 20, 2008 at 08:58, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> ]] Ben Finney
>
> | We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
> | that is, make '/srv/www/foo' the canonical location but allow a long
> | transition period where '/var/www/foo' is permitted as a
]] Ben Finney
| We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
| that is, make '/srv/www/foo' the canonical location but allow a long
| transition period where '/var/www/foo' is permitted as a symlink to
| '/srv/www/foo'.
You can't know the structure of /srv, see the FHS r
"Carl Fürstenberg" <[EMAIL PROTECTED]> writes:
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added?
I think there's no hardship if we support the FHS location, so an
exception shouldn't be made.
What do you mean by "force all [HTTP s
On Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg wrote:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
46 matches
Mail list logo
