Re: FHS: Where to store user specific plugins / code

Hi Jonas, On 18-03-09 19:18:50, Jonas Meurer wrote: > Am 09.03.2018 um 14:23 schrieb Georg Faerber: > >> Ian's comments are good for admin-installed plugins that the users can > >> use. In fact there is good precedent for an app checking > >> /usr/lib/pkg/... for plugins installed from Debian pac

Re: FHS: Where to store user specific plugins / code

On 09.03.2018 14:23, Georg Faerber wrote: Hi, > I guess we'll go with /usr/local/lib/schleuder then? Does this sound> like a reasonable choice? That would be my choice. OTOH, it might be nice to have a helper that automatically creates deb packages. (would also be nice for other applications,

Re: FHS: Where to store user specific plugins / code

Am 09.03.2018 um 14:23 schrieb Georg Faerber: >> Ian's comments are good for admin-installed plugins that the users can >> use. In fact there is good precedent for an app checking >> /usr/lib/pkg/... for plugins installed from Debian packages, >> /usr/local/lib/pkg/... for plugins installed by the

Re: FHS: Where to store user specific plugins / code

Hi, On 18-02-28 18:14:17, Marvin Renich wrote: > If a user get to install his/her own plugins, they should go in the > user's home directory, e.g. /home/user/.config/scheduler/plugins/. > Non-root users should not generally be given write permission to > /usr/local, and definitely not to /usr/lib.

Re: FHS: Where to store user specific plugins / code

Hi, On 18-03-01 07:55:08, Peter Silva wrote: > -- it is best practice for daemons/services not to run as root. They > should have an application specific user. Schleuder does use a dedicated user, called schleuder. $HOME is set to /var/lib/schleuder. Inside there mailing list specific data is st

Re: FHS: Where to store user specific plugins / code

Hi all, Thanks for your replies, and sorry for the delay in answering. (Note to myself: Don't write such mails while traveling..) That said, I think I wasn't clear regarding "user specific": On 18-02-28 18:54:14, Georg Faerber wrote: > Currently, we allow users to run / execute their own plugins

Re: FHS: Where to store user specific plugins / code

On Wed, 2018-02-28 at 18:14:17 -0500, Marvin Renich wrote: > * Ian Jackson [180228 17:45]: > > Georg Faerber writes ("FHS: Where to store user specific plugins / code"): > > > Currently, we allow users to run / execute their own plugins, stored in > > > /etc/schleuder/plugins. Obviously, that's no

Re: FHS: Where to store user specific plugins / code

er flag to let users manage their own daemons. On Thu, Mar 1, 2018 at 7:26 AM, Ian Jackson wrote: > Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"): >> [stuff] > > I agree completely with Marvin's message. > > Ian. >

Re: FHS: Where to store user specific plugins / code

Marvin Renich writes ("Re: FHS: Where to store user specific plugins / code"): > [stuff] I agree completely with Marvin's message. Ian.

Re: FHS: Where to store user specific plugins / code

On Wed, 28 Feb 2018 09:54:14 -0800 Georg Faerber wrote Therefore, I'm wondering what's the correct place: Would /usr/local/lib/schleuder/plugins be sensible? If not, any other place which is more suitable? If they're binaries, the FHS answer is that

Re: FHS: Where to store user specific plugins / code

* Ian Jackson [180228 17:45]: > Georg Faerber writes ("FHS: Where to store user specific plugins / code"): > > I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list > > manager with resending-capabilities". > > > > Currently, we allow users to run / execute their own plugins, store

Re: FHS: Where to store user specific plugins / code

Georg Faerber writes ("FHS: Where to store user specific plugins / code"): > I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list > manager with resending-capabilities". > > Currently, we allow users to run / execute their own plugins, stored in > /etc/schleuder/plugins. Obviously,

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

]] 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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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 "

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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 >

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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}/

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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,

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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,

Re: FHS and /var/www

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

Re: FHS and /var/www

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 >

Re: FHS and /var/www

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.

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

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:

Re: FHS and /var/www

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

Re: FHS and /var/www

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

Re: FHS and /var/www

]] 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

Re: FHS and /var/www

"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

Re: FHS and /var/www

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

Re: fhs

[EMAIL PROTECTED] writes: >>> echo $HOME/Mailbox >$HOME/.forward > >Richard Kettlewell: >>This is a bad idea if the home directory is NFS-mounted from a remote >>system; IME file locking under NFS is very easy to get wrong. (Not >>that all mailers get locking right even on local file systems.

Re: fhs

Raul Miller writes: >I think you should look at this issue a bit differently. In one >sense, both policies are broken -- delivering mail to a spool >directory requires sgid programs for the user to read mail (in the >usual sense). A more secure and more robust solution would be to >deliver mail

Re: fhs

> Raul Miller writes: [quotation removed] > I think you should look at this issue a bit differently. In one > sense, both policies are broken -- delivering mail to a spool > directory requires sgid programs for the user to read mail (in the > usual sense). A more secure and more robust solu

Re: fhs

Raul <[EMAIL PROTECTED]> writes: > I don't understand why, for example, /var/spool/mail needs to be > changed to /var/mail -- this seems like a candidate for a symlink. This is under discussion right now. There are several reasons to use /var/mail and several reasons to stick with /var/spool/mai