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