[opensuse-packaging] RPMLINT warning: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/*
Hi folks, while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ?
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways? /srv is a mess. It mixes vendor files with user files, config files with static data, binaries with state databases etc. This is not specific to horde of course but let's use it as example. Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 21. April 2011, 14:39:13 schrieb Ludwig Nussel:
Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ?
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways?
Because the default suse apache server does not like access to arbitrary locations, I know of no policy on installing vhosts via rpm (or even assuming that apache is used and not another httpd). The Horde3 debian package used symlinking a lot to move configs to /etc/ but it actually lead the majority of users to NOT using the packages but installing pristine sources. I've been taking part in the upstream project's support channels, irc, mailing list and have experienced that a lot of users If we develop some common process for web app deployment (including a default running environment) I have no objections against /etc/. I am pretty sure that what happened to the debian packages would happen to the suse packages again otherwise.
/srv is a mess. It mixes vendor files with user files, config files with static data, binaries with state databases etc.
This is not specific to horde of course but let's use it as example. Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4?
See above. Without actually providing a sane, fast-to-run solution we alienate users. -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 21. April 2011, 14:39:13 schrieb Ludwig Nussel:
Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ?
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways? /srv is a mess. It mixes vendor files with user files, config files with static data, binaries with state databases etc. This is not specific to horde of course but let's use it as example. Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4?
From my POV web-apps aren't stand-alone applications but script files for an interpreter used by apache2. Therefore I see no problem having all files under DocumentRoot. It also makes it easier to confine web-apps without giving an attacker access to /etc. Bye Thomas -- Thomas Biege <thomas@suse.de>, SUSE LINUX, Security Support & Auditing SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- Wer aufhoert besser werden zu wollen, hoert auf gut zu sein. -- Marie von Ebner-Eschenbach -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Thomas Biege wrote:
Am Donnerstag, 21. April 2011, 14:39:13 schrieb Ludwig Nussel:
Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ?
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways? /srv is a mess. It mixes vendor files with user files, config files with static data, binaries with state databases etc. This is not specific to horde of course but let's use it as example. Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4?
From my POV web-apps aren't stand-alone applications but script files for an interpreter used by apache2. Therefore I see no problem having all files under DocumentRoot.
The document root mixes user provided content with distro content which makes it hard to create useful backups.
It also makes it easier to confine web-apps without giving an attacker access to /etc.
Isn't that an argument pro using /etc? So an attacker that gained access to the document root can't read or even modify the config file? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Donnerstag, 21. April 2011, Ludwig Nussel wrote:
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways? [...] Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4?
Short answer: Try to setup some web apps with the file structure you proposed, and you'll find out that it's somewhere between difficult and insane ;-) I could write a long answer, but Kris Köhntopp already wrote a great text about "webapps and the FHS" some years ago, and there's nothing I could add. Please read his article at http://blog.koehntopp.de/archives/860-Webanwendungen-und-der-FHS.html (german, use google translate if needed) BTW: I know both sides of the problem - I'm admin on several webservers and also one of the main programmers (and RPM packager) of PostfixAdmin. Regards, Christian Boltz --
[AOL] Normalerweise brauchen die doch ihren eigenen Krempel.... ... [bei DSL] geht das jetzt auch über Standardprotokolle. Für ISDN und Modem wird nach wie vor der Krempel auf den kostenlos verschickten Untersetztern benötigt. [> Axel Lindlau und Manfred Tremmel in suse-linux] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 21. April 2011, 23:25:39 schrieb Christian Boltz:
I could write a long answer, but Kris Köhntopp already wrote a great text about "webapps and the FHS" some years ago, and there's nothing I could add. Please read his article at http://blog.koehntopp.de/archives/860-Webanwendungen-und-der-FHS.html (german, use google translate if needed)
BTW: I know both sides of the problem - I'm admin on several webservers and also one of the main programmers (and RPM packager) of PostfixAdmin.
The article is interesting reading but it itsn't totally accurate for 2011. Release cycles PEAR can adhere to FHS. It is merely a distribution system just like RPM and doesn't mandate non-FHS locations. PEAR roles implement both the rule and the exception: PEAR provides roles for documents, commandline-run binaries, variable data (..) and modern pear-packaged applications do ship their own roles like a "web" role - stuff that has to live in a browser-accessible location. The article mandates against distribution packaging at all - but I package because I intend to use and make available. Actually the Horde project doesn't provide Horde 4 as "Download Bundles" or tarball releases and won't do so soon. While web apps may be commonly developed for shared hosting services, there is no reason not to distribution-package them for other use cases like intranets, local networks with low or no bandwidth to the outside, kiwi appliances (..) In these cases you don't want several competing distribution and update mechanisms. You also don't want to depend on the used version still being available from the upstream vendor. That's why - against the article's claims - rpm packaged web apps are handy. Now let's see how we can deploy them more easily. Maybe -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Freitag, 22. April 2011, Ralf Lang wrote:
Am Donnerstag, 21. April 2011, 23:25:39 schrieb Christian Boltz:
I could write a long answer, but Kris Köhntopp already wrote a great text about "webapps and the FHS" some years ago, and there's nothing I could add. Please read his article at http://blog.koehntopp.de/archives/860-Webanwendungen-und-der-FHS.html (german, use google translate if needed) [...] The article mandates against distribution packaging at all - but I package because I intend to use and make available. [...] While web apps may be commonly developed for shared hosting services, there is no reason not to distribution-package them for other use cases like intranets, local networks with low or no bandwidth to the outside, kiwi appliances (..)
Packaging in general is an interesting point, and I don't object to provide webapps as RPM packages. In some cases (apps that can be used server-wide, for example phpMyAdmin or PostfixAdmin), I'm even using RPM packages myself. (I admit that Kris' article is somewhat provocative in this point.) OTOH, things that are deployed to vHosts are the natural enemy of RPM packaging ;-)
[...] You also don't want to depend on the used version still being available from the upstream vendor.
In most cases I'm not too interested in ancient versions - I prefer the most recent one that include all security fixes.
That's why - against the article's claims - rpm packaged web apps are handy.
As I said: in some cases I agree ;-) but there are also several cases where RPM packages of webapps are quite useless. The most important case is installing a webapp into a (or multiple) vHosts [1]. That said: For me, the most interesting part of the article is how webapps should be split according to the FHS, and I still think that this part of the FHS is insane. For example, - customers can't edit or backup config files (over FTP, which (unfortunately) is still the most popular method to access the webspace) if they are in /etc - or, to speak more general: customers are usually chroot'ed to their homedir, which means they can't access anything outside it - being it config in /etc/, documentation in /usr/share/doc/, data in /var/lib/, ... - using PHP's open_basedir (which is a good idea) is hard(er) with config files in /etc. Well, you can include multiple directories in open_basedir, but that makes the config quite complex. Additionally, my experience is that you already get funny behaviour with one open_basedir per vHost sometimes (switching to the "correct" open_basedir did not always work, which means I ended up with setting /srv/www/htdocs as open_basedir to avoid a self-DOS - not sure if that gremlin still exists in the latest PHP version) There are more issues with following the FHS, but already those mentioned above are showstoppers for me.
Now let's see how we can deploy them more easily. Maybe
Hmm, the "Maybe" looks like the beginning of a new sentence. Did you send the mail too early and miss the second half of the sentence? Regards, Christian Boltz [1] At the moment, I'm basically using two strategies for the webapps I have to maintain for customers: - MediaWiki, S9Y: use a direct SVN checkout of the release branch (not trunk), and just run "svn up" for bugfix updates and "svn switch" to switch to a new major release. Same method for extensions. Pro: SVN can handle local modifications easily (which I sometimes need in MediaWiki and its extensions) and keeps them across updates. Con: no central bugfix updates (not a real problem for now because the number of MediaWiki installs I maintain is quite low) - Typo3: put the code in a shared directory, and symlink it into the vHosts. The symlink always points to the major x.y release, which then symlinks to the latest x.y.z release. This results in central bugfix updates, but (more or less) manual updates to switch to a newer major release. That way makes sense because switching to a new major release needs database updates etc., not only replacing the code. -- Yes, basil troll, the opensuse release manager, long time kde developer, and member of the opensuse board is not a linux person, he doesnt understand linux like you, oh, great linux overlord you are, he is just a newbie who doesnt know what he is doing. You are so cute you must poop rainbows. [Druid in opensuse-factory] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi Christian, Am Freitag, 22. April 2011, 20:45:14 schrieb Christian Boltz:
While web apps may be commonly developed for shared hosting services, there is no reason not to distribution-package them for other use cases like intranets, local networks with low or no bandwidth to the outside, kiwi appliances (..)
Packaging in general is an interesting point, and I don't object to provide webapps as RPM packages. In some cases (apps that can be used server-wide, for example phpMyAdmin or PostfixAdmin), I'm even using RPM packages myself. (I admit that Kris' article is somewhat provocative in this point.)
In most cases I'm not too interested in ancient versions - I prefer the most recent one that include all security fixes.
That changes if you need to maintain a production setup for years. BC-breaking API changes on upgrades are particularly tricky. But it depends on use case, of course.
As I said: in some cases I agree ;-) but there are also several cases where RPM packages of webapps are quite useless. The most important case is installing a webapp into a (or multiple) vHosts [1].
Let's see below. I make some assumption on the business model though: Either you provide just the webspace + environment - then you don't want to care what the customer runs. You just want to make sure he has no way of putting other users in danger. Or you provide services like database, imap/smtp, web gui for database, webmail - then you usually want to maintain a certain standard and decide carefully on what the customer has access to. At least I would not make the application code ftp-accessible nor the config if it's hosted.
That said: For me, the most interesting part of the article is how webapps should be split according to the FHS, and I still think that this part of the FHS is insane. For example, - customers can't edit or backup config files (over FTP, which (unfortunately) is still the most popular method to access the webspace) if they are in /etc
Why should they? The app should sport a web interface for manipulation and your deployment process should either forbid them tinkering with the config or provide the app in a state where the web gui can be used.
- or, to speak more general: customers are usually chroot'ed to their homedir, which means they can't access anything outside it - being it config in /etc/, documentation in /usr/share/doc/, data in /var/lib/,
And do they need this?
... - using PHP's open_basedir (which is a good idea) is hard(er) with config files in /etc. Well, you can include multiple directories in open_basedir, but that makes the config quite complex.
If the app must run in the vhost, you can grant permissions per-vhost. This needs a deployment model though which supports this - maybe some template configs for packaged web apps.
There are more issues with following the FHS, but already those mentioned above are showstoppers for me.
Again, these are interesting problems and I had them myself in the past, but they are solveable.
Now let's see how we can deploy them more easily. Maybe
Hmm, the "Maybe" looks like the beginning of a new sentence. Did you send the mail too early and miss the second half of the sentence?
It just means doubt ;-) -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Christian Boltz wrote:
That said: For me, the most interesting part of the article is how webapps should be split according to the FHS, and I still think that this part of the FHS is insane. For example, - customers can't edit or backup config files (over FTP, which (unfortunately) is still the most popular method to access the webspace) if they are in /etc - or, to speak more general: customers are usually chroot'ed to their homedir, which means they can't access anything outside it - being it config in /etc/, documentation in /usr/share/doc/, data in /var/lib/, ...
So the current method of dumping everything in /srv/www is equally useless as files there are owned by root or wwwrun but not by the customer. The shared web hosting case the way you want it can't be coved by distro packages. We don't install packages in /home/* either after all. The correct way would be to have web apps look into /etc if run in "global mode" and in "$HOME" when run in shared/per user mode. IOW just like any other sane Linux program does too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Ludwig Nussel wrote:
Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ?
Good topic. Why do web apps not adhere to the traditional layout we are used to anyways? /srv is a mess. It mixes vendor files with user files, config files with static data, binaries with state databases etc. This is not specific to horde of course but let's use it as example. Why not keep the default document root /srv/www/htdocs clean and put horde to e.g. /usr/share/horde4, it's config files to /etc/horde4 and it's database or whatever variable data it has to /var/lib/horde4?
Looking at Fedora they do exactly that. Taking phpMyAdmin as random sample their package does not contain excessive patches or symlink tricks to make it work. So getting a clean /srv isn't that hard at all. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Apr 21, 2011 at 02:09:41PM +0200, Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
This isn't even a config file (you're supposed to copy conf.php.dist to conf.php and edit that one.) -- Joerg Reuter, Technical Support Engineer Novell Technical Services, Worldwide Support Services Linux SUSE LINUX GmbH, Maxfeldstr. 5, D-90409 Nürnberg; Phone: +49-911-74053-488 GF: Felix Imendörffer, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 21. April 2011, 14:43:06 schrieben Sie:
On Thu, Apr 21, 2011 at 02:09:41PM +0200, Ralf Lang wrote:
while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist
This isn't even a config file (you're supposed to copy conf.php.dist to conf.php and edit that one.)
Thank you for the hint (it's correct) but: That's not the answer to the question. Prefs.php, Nls.php, motd.php ... they all live in config dir and are not supposed to be overwritten by an RPM upgrade. This isn't horde3 anymore where everything was provided as .dist -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Christian Boltz -
Joerg Reuter -
Ludwig Nussel -
Ralf Lang -
Thomas Biege