[opensuse-packaging] RFC: packaging guidelines change: Web Applications
Hi, https://en.opensuse.org/openSUSE:Packaging_guidelines#Web_Applications suggest to package "web applications" to /srv/www/%name. I see two major problems with that 1. /srv is considered admin space so packages should not mess with it. Citing FHS¹: "... no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv ... Distributions must take care not to remove locally placed files in these directories without administrator permission" 2. For the reason that admins are expected to put files in /srv that are not tracked by package management, /srv is a default btrfs subvolume. That means anything installed in /srv is excluded from the default system snapshots. Ie rollbacks of packages that install code in /srv won't have any effect and the rpm database would not reflect what's actually running anymore. Therefore I'd like to propose to change the section to the following: Web applications packaged in openSUSE should place their their files in /etc, /usr, /var etc depending on type just like any other application would do. A package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. It's ok to allow the admin to configure the software to use /srv of course. cu Ludwig [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS... -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 21.03.2016 um 15:03 schrieb Ludwig Nussel:
Hi,
https://en.opensuse.org/openSUSE:Packaging_guidelines#Web_Applications suggest to package "web applications" to /srv/www/%name. I see two major problems with that
1. /srv is considered admin space so packages should not mess with it. Citing FHS¹: "... no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv ... Distributions must take care not to remove locally placed files in these directories without administrator permission" 2. For the reason that admins are expected to put files in /srv that are not tracked by package management, /srv is a default btrfs subvolume. That means anything installed in /srv is excluded from the default system snapshots. Ie rollbacks of packages that install code in /srv won't have any effect and the rpm database would not reflect what's actually running anymore.
Therefore I'd like to propose to change the section to the following:
Web applications packaged in openSUSE should place their their files in /etc, /usr, /var etc depending on type just like any other application would do. A package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. It's ok to allow the admin to configure the software to use /srv of course.
cu Ludwig
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
I fully agree to the suggested change. This simplifies cross-distro-packaging, too. Johannes Weberhofer -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On lundi, 21 mars 2016 15.21:11 h CET Johannes Weberhofer wrote:
Am 21.03.2016 um 15:03 schrieb Ludwig Nussel:
Hi,
https://en.opensuse.org/openSUSE:Packaging_guidelines#Web_Applications suggest to package "web applications" to /srv/www/%name. I see two major problems with that
1. /srv is considered admin space so packages should not mess with it. Citing FHS¹: "... no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv ... Distributions must take care not to remove locally placed files in these directories without administrator permission" 2. For the reason that admins are expected to put files in /srv that are not tracked by package management, /srv is a default btrfs subvolume. That means anything installed in /srv is excluded from the default system snapshots. Ie rollbacks of packages that install code in /srv won't have any effect and the rpm database would not reflect what's actually running anymore.
Therefore I'd like to propose to change the section to the following:
Web applications packaged in openSUSE should place their their files in /etc, /usr, /var etc depending on type just like any other application would do. A package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. It's ok to allow the admin to configure the software to use /srv of course.
cu Ludwig
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYS...
I fully agree to the suggested change. This simplifies cross-distro-packaging, too.
Johannes Weberhofer
Get one +1 from here too. Is there ary deep search that can be run against the content (at least factory, and perhaps devel repo) to grab a list of impacted package to open a series of bug against them ? Ludwig, any idea about the calendar for the RFC ( like a state of this should be fixed, higher warning, badness 10000000 :-) you would like to see ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2016-03-21 at 21:18 +0100, Bruno Friedmann wrote:
Is there ary deep search that can be run against the content (at least factory, and perhaps devel repo) to grab a list of impacted package to open a series of bug against them ?
I think zypper se --files /srv Should give a very good starting point Cheers Dominqiue -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2016-03-21 20:41, Dominique Leuenberger / DimStar wrote:
On Mon, 2016-03-21 at 21:18 +0100, Bruno Friedmann wrote:
Is there ary deep search that can be run against the content (at least factory, and perhaps devel repo) to grab a list of impacted package to open a series of bug against them ? I think zypper se --files /srv
Should give a very good starting point
Cheers Dominqiue zypper se --file-list /srv/ returned just 59 packages
On mardi, 22 mars 2016 12.15:21 h CET Bernhard M. Wiedemann wrote:
On 2016-03-21 20:41, Dominique Leuenberger / DimStar wrote:
On Mon, 2016-03-21 at 21:18 +0100, Bruno Friedmann wrote:
Is there ary deep search that can be run against the content (at least factory, and perhaps devel repo) to grab a list of impacted package to open a series of bug against them ? I think zypper se --files /srv
Should give a very good starting point
Cheers Dominqiue zypper se --file-list /srv/ returned just 59 packages
There's a bit more on devel project (stangely you don't have tomcat) and in the list there's some false positive too rpm -ql xkeyboard-config | grep srv /usr/share/X11/xkb/symbols/srvr_ctrl There's a bunch of cgi-bin and by default on SUSE/openSUSE we have /srv/www/cgi-bin We need to find a new location for cgi-bin /usr/lib/cgi-bin come first at mind, but there's not only perl/python/php script sometimes there's also binary, which then on 64bits should goes somewhere else ... -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Bruno Friedmann wrote:
[...] Ludwig, any idea about the calendar for the RFC ( like a state of this should be fixed, higher warning, badness 10000000 :-) you would like to see ?
Yes, warning about that via rpmlint would be a good next step once the change is accepted. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Mar 21, 2016 at 03:03:08PM +0100, Ludwig Nussel wrote:
Hi,
https://en.opensuse.org/openSUSE:Packaging_guidelines#Web_Applications suggest to package "web applications" to /srv/www/%name. I see two major problems with that
1. /srv is considered admin space so packages should not mess with it. Citing FHS¹: "... no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv ... Distributions must take care not to remove locally placed files in these directories without administrator permission" 2. For the reason that admins are expected to put files in /srv that are not tracked by package management, /srv is a default btrfs subvolume. That means anything installed in /srv is excluded from the default system snapshots. Ie rollbacks of packages that install code in /srv won't have any effect and the rpm database would not reflect what's actually running anymore.
Therefore I'd like to propose to change the section to the following:
Web applications packaged in openSUSE should place their their files in /etc, /usr, /var etc depending on type just like any other application would do. A package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. It's ok to allow the admin to configure the software to use /srv of course.
Well, I strongly disagree. What you propose goes far beyond the quote from FHS you tried to use to support your proposal. Currently, the common practice for servers like FTP servers, TFTP servers, HTTP servers etc. is to create a logically named subdirectory under /srv, set its permissions as needed and point the default configuration of the daemon to it. Important observation: this common practice does not contradict the FHS quote at all. However, your proposal strictly forbids it. Therefore such rule has no support in the FHS quote. If the proposal was accepted, packages would have to do one of (a) not create a subdirectory under /srv and not set default configuration to use it; all they could do would be to tell users to create such directory themselves, set their permissions, setup the configuration accordingly and then they could finally put their files there (b) not create a subdirectory but at least prepare the configuration; it would still require users to do the job packages could (and IMHO should) do for them; moreover, there are daemons which handle configuration refering to non-existing paths as an error or warn about them Sure, if someone installs a big public production server, this extra work is negligible (let's forget for a moment such admin is unlikely to use openSUSE but whatever is imposed on openSUSE is going to affect SLES one day). But there are other use cases. Today, if I want to setup a TFTP server in my home LAN to start an installation using PXE boot, I just put the files into the right directory and enable the service in xinetd.d. If your change gets through, I'll have to find out I have to create the directory, set its permissions, edit the service config and then enable the service. All the time I'd keep asking two questions (if I didn't read this e-mail which most users would not). First, why the ____ didn't the package prepare a ready to use configuration if it would be so trivial. Second, who is this obstruction going to help? And as a distribution user, I wouldn't be happy about the answer "Sorry, not my call, it's just because of one guy who misinterpreted one sentence in FHS." So please rethink your idea. Packaged web application installing a full directory structure with all files under /srv/www is one thing, completely forbidding any package to install even one empty directory under /srv is an overkill which would only make the packages less user friendly without any benefit. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 22 Mar 2016, Michal Kubecek wrote:
Well, I strongly disagree. What you propose goes far beyond the quote from FHS you tried to use to support your proposal.
Currently, the common practice for servers like FTP servers, TFTP servers, HTTP servers etc. is to create a logically named subdirectory under /srv, set its permissions as needed and point the default configuration of the daemon to it.
Important observation: this common practice does not contradict the FHS quote at all. However, your proposal strictly forbids it. Therefore such rule has no support in the FHS quote.
I don't think Ludwigs proposal was meant to forbid this practice. As you say, it makes sense to create empty directories under /srv and let the config point to them. But a set of files coming from a package that's supposed to be a web app (i.e. not just server software with a pre-configured but empty directory, but rather a collection of data and code files) should not be placed under /srv/ for the reason Ludwig stated. So, if the proposal would be amended to be explicit about allowing empty dirs in /srv/, would you still see issues? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz wrote:
On Tue, 22 Mar 2016, Michal Kubecek wrote:
Well, I strongly disagree. What you propose goes far beyond the quote from FHS you tried to use to support your proposal.
Currently, the common practice for servers like FTP servers, TFTP servers, HTTP servers etc. is to create a logically named subdirectory under /srv, set its permissions as needed and point the default configuration of the daemon to it.
Important observation: this common practice does not contradict the FHS quote at all. However, your proposal strictly forbids it. Therefore such rule has no support in the FHS quote.
I don't think Ludwigs proposal was meant to forbid this practice. As you say, it makes sense to create empty directories under /srv and let the config point to them. But a set of files coming from a package that's supposed to be a web app (i.e. not just server software with a pre-configured but empty directory, but rather a collection of data and code files) should not be placed under /srv/ for the reason Ludwig stated.
The intended scope was certainly restricted to "web applications". The statements about /srv are indeed generic though. I agree that pre-creating empty directories in /srv makes sense and it should be safe enough as rpm won't remove them on uninstall if they are not empty. It's probably worth mentioning that Fedora nevertheless disallows anything in /srv, even default configs pointing there. So we'd follow a more pragmatic approach. Unfortunately we don't have a generic section about file system layout. So until someone wants to come up with a proposal for that how about the following? Web applications packaged in openSUSE should place their files in /etc, /usr, /var etc depending on type just like any other application would do. In general a package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. In openSUSE it's ok to have a package pre-create an empty directory in /srv if the default configuration of the software points there. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ludwig Nussel wrote:
[...] Web applications packaged in openSUSE should place their files in /etc, /usr, /var etc depending on type just like any other application would do. In general a package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. In openSUSE it's ok to have a package pre-create an empty directory in /srv if the default configuration of the software points there.
Since two weeks have passed without further objections I've changed the guidelines accordingly. Thanks everyone for your feedback! cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 07.04.2016 um 13:10 schrieb Ludwig Nussel:
Ludwig Nussel wrote:
[...] Web applications packaged in openSUSE should place their files in /etc, /usr, /var etc depending on type just like any other application would do. In general a package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. In openSUSE it's ok to have a package pre-create an empty directory in /srv if the default configuration of the software points there.
Since two weeks have passed without further objections I've changed the guidelines accordingly. Thanks everyone for your feedback!
So what's the plan for existing packages? OBS violates that guideline by installing to /srv/www/obs/api and /srv/obs, doesn't it? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andreas Färber wrote:
Am 07.04.2016 um 13:10 schrieb Ludwig Nussel:
Ludwig Nussel wrote:
[...] Web applications packaged in openSUSE should place their files in /etc, /usr, /var etc depending on type just like any other application would do. In general a package must not install, remove or otherwise modify /srv content as it's use is reserved to the admin according to FHS¹. In openSUSE it's ok to have a package pre-create an empty directory in /srv if the default configuration of the software points there.
Since two weeks have passed without further objections I've changed the guidelines accordingly. Thanks everyone for your feedback!
So what's the plan for existing packages?
IMO existing packages should adopt the policy for the simple reason that they break when btrfs rollback is used. So far there is no enforcement yet though.
OBS violates that guideline by installing to /srv/www/obs/api and /srv/obs, doesn't it?
I'm not sure OBS ever tried to enter any official repo and comply to the policies there. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On pondělí 11. dubna 2016 8:28 Ludwig Nussel wrote:
Andreas Färber wrote:
Am 07.04.2016 um 13:10 schrieb Ludwig Nussel:
Since two weeks have passed without further objections I've changed the guidelines accordingly. Thanks everyone for your feedback!
So what's the plan for existing packages?
IMO existing packages should adopt the policy for the simple reason that they break when btrfs rollback is used. So far there is no enforcement yet though.
Adding a low severity OBS build warning might have better chance to get noticed than the change in guidelines, I suppose. Later, the badness can be raised. It would be very nice if it could be done in a way that would only affect Factory and its devel projects and not updates to already released distributions (13.2 and 42.1) - changing the directories there would do more harm than good, IMHO. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On středa 23. března 2016 11:29 Michael Matz wrote:
So, if the proposal would be amended to be explicit about allowing empty dirs in /srv/, would you still see issues?
I would have no problem with that. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Andreas Färber -
Bernhard M. Wiedemann -
Bruno Friedmann -
Dominique Leuenberger / DimStar -
Johannes Weberhofer -
Ludwig Nussel -
Michael Matz -
Michal Kubecek