[opensuse-packaging] PHP application packaging
Hi, (btw, I'm always confused if opensuse-packaging or opensuse-factory is the right list for that kind of questions. Do we really need both?) I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now. But I have quite some open questions and even searching on en.opensuse.org or looking at other similar packages didn't shed some light on them. Is there any kind of packaging guide for PHP apps and Apache configuration policies I haven't found yet? The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME. In addition it is patched to have its php config files in /etc instead of the application directory. Do we really want that? Do we want to fiddle with the Apache config in %post or similar to add required modules (a2enmod)? Should apps be enabled with their installation or via server flags? Anyone got a pointer to openSUSE specific packaging guidelines here? Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.02.2012 19:59, schrieb Wolfgang Rosenauer:
Hi,
(btw, I'm always confused if opensuse-packaging or opensuse-factory is the right list for that kind of questions. Do we really need both?)
Opensuse-Factory is mainly for systemd infights and KDE3 legacy maintainence questions nowadays. I guess you chose the right list ;-)
I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now.
Great. Which?
But I have quite some open questions and even searching on en.opensuse.org or looking at other similar packages didn't shed some light on them.
Is there any kind of packaging guide for PHP apps and Apache configuration policies I haven't found yet?
I've been searching and asking for some but didn't fine much of value. I ended up with following some unwritten conventions and making some decisions on my own. Is it a pear package or a traditional "unzip tarball" app?
The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME.
Legacy stuff like horde3 installs itself to /srv/www/htdocs. phpmyadmin adheres to this schema too. If your existing app lives there, stick with it. If the app is currently not shipped with openSUSE and sufficiently modern to separate config from readonly "program" stuff, /usr/share/php5 may be a valid place too. Debian does it this way.
In addition it is patched to have its php config files in /etc instead of the application directory. Do we really want that?
Debian does it this way. If the patches are working, I suggest putting the ro stuff in /usr/share/php5/app and the config stuff in etc.
Do we want to fiddle with the Apache config in %post or similar to add required modules (a2enmod)?
Cannot answer that without looking at it.
Should apps be enabled with their installation or via server flags?
If you ask me, they should only be accessible from localhost by default.
Anyone got a pointer to openSUSE specific packaging guidelines here?
Sorry, no. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk84EGcACgkQCs1dsHJ/X7C8PgCgu2xy6xG18tk3SH6Mp9yBovGU Hl4AoN2tw4deMn4B+OsVYB5zabf2NByj =eWcs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 12.02.2012 20:17, schrieb Ralf Lang:
Am 12.02.2012 19:59, schrieb Wolfgang Rosenauer:
I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now.
Great. Which?
Roundcube Mail.
Is it a pear package or a traditional "unzip tarball" app?
unzip tarball app basically.
The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME.
Legacy stuff like horde3 installs itself to /srv/www/htdocs. phpmyadmin adheres to this schema too. If your existing app lives there, stick with it. If the app is currently not shipped with openSUSE and sufficiently modern to separate config from readonly "program" stuff, /usr/share/php5 may be a valid place too. Debian does it this way.
As Roundcube is not part of Factory I could move it but it's probably also not worth the effort if /srv/www/roundcube is ok, too.
Cannot answer that without looking at it.
For example it uses mod_rewrite wich is AFAIK not part of the default Apache config in openSUSE. So by using "a2enmod rewrite" in %post I could make sure it's enabled but not sure if we want that automatism?
Should apps be enabled with their installation or via server flags?
If you ask me, they should only be accessible from localhost by default.
Good point. I'll consider this. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 12.02.2012 20:59, schrieb Wolfgang Rosenauer:
Am 12.02.2012 20:17, schrieb Ralf Lang:
Am 12.02.2012 19:59, schrieb Wolfgang Rosenauer:
I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now.
Great. Which?
Roundcube Mail.
Is it a pear package or a traditional "unzip tarball" app?
unzip tarball app basically.
The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME.
Legacy stuff like horde3 installs itself to /srv/www/htdocs. phpmyadmin adheres to this schema too. If your existing app lives there, stick with it. If the app is currently not shipped with openSUSE and sufficiently modern to separate config from readonly "program" stuff, /usr/share/php5 may be a valid place too. Debian does it this way.
As Roundcube is not part of Factory I could move it but it's probably also not worth the effort if /srv/www/roundcube is ok, too. Personally, I'd like to reduce the number of default locations to /srv/www/htdocs and /usr/share/php5 but I'd like to hear feedback from others like chris wittmer. Maybe for now you should just do the update and you or I adjust the install path later.
Cannot answer that without looking at it.
For example it uses mod_rewrite wich is AFAIK not part of the default Apache config in openSUSE. So by using "a2enmod rewrite" in %post I could make sure it's enabled but not sure if we want that automatism?
I'm unsure on this and open for community decision. Does openSUSE usually enable apache modules when they are installed? With the horde stuff, I don't explicitly activate any apache modules. I am not even sure we should assume that users use apache2 and not lighttpd.
Should apps be enabled with their installation or via server flags?
If you ask me, they should only be accessible from localhost by default.
Good point. I'll consider this.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Am 12.02.2012 21:12, schrieb Ralf Lang:
For example it uses mod_rewrite wich is AFAIK not part of the default Apache config in openSUSE. So by using "a2enmod rewrite" in %post I could make sure it's enabled but not sure if we want that automatism?
I'm unsure on this and open for community decision. Does openSUSE usually enable apache modules when they are installed? With the horde stuff, I don't explicitly activate any apache modules. I am not even sure we should assume that users use apache2 and not lighttpd.
Probably we shouldn't assume as in keeping the door open for alternative http daemons. But I guess fact is that most packages like these contain a preconfiguration for Apache explicitely. The %post scriptlet could be smart enough to only enable an apache module if it's actually installed. I have to admit that I never used an alternative http server yet so cannot bring in much input on that side. But it's one more reason to get something written up and agreed upon for these packages. Thanks for your input so far, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Am 12.02.2012 21:12, schrieb Ralf Lang:
As Roundcube is not part of Factory I could move it but it's probably also not worth the effort if /srv/www/roundcube is ok, too.
does Personally, I'd like to reduce the number of default locations to /srv/www/htdocs and /usr/share/php5 but I'd like to hear feedback from others like chris wittmer. Maybe for now you should just do the update and you or I adjust the install path later. I would prefer to have it under /srv/www/{name} and deliver a useful /etc/apache2/conf.d/{name}.conf. For me I'm also planning to move phpMyAdmin to /srv/www (apache_serverroot)
For example it uses mod_rewrite wich is AFAIK not part of the default Apache config in openSUSE. So by using "a2enmod rewrite" in %post I could make sure it's enabled but not sure if we want that automatism?
I'm unsure on this and open for community decision. Does openSUSE usually enable apache modules when they are installed? With the horde stuff, I don't explicitly activate any apache modules. I am not even sure we should assume that users use apache2 and not lighttpd.
I think you "should" add this to %post. Just have a look at some Apache_Modules. There it is done, too.
Should apps be enabled with their installation or via server flags?
If you ask me, they should only be accessible from localhost by default.
Good point. I'll consider this.
Hmm, why do you want to install a "webmailer" that is only accessible from localhost ? I can understand this for postfix but not for a webmailer. FMPOV, installing, (starting), accessing via web and configuring via web, happy :) Cheers -- Christian ---------------------------------------------------- - Please do not 'CC' me on list mails. Just reply to the list :) ---------------------------------------------------- Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de ---------------------------------------------------- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Am 12.02.2012 23:07, schrieb Christian:
Hi
Am 12.02.2012 21:12, schrieb Ralf Lang: I would prefer to have it under /srv/www/{name} and deliver a useful /etc/apache2/conf.d/{name}.conf.
That is how it's done now and I'm going to keep it until we have rules for consistency reasons.
For example it uses mod_rewrite wich is AFAIK not part of the default Apache config in openSUSE. So by using "a2enmod rewrite" in %post I could make sure it's enabled but not sure if we want that automatism?
I'm unsure on this and open for community decision. Does openSUSE usually enable apache modules when they are installed? With the horde stuff, I don't explicitly activate any apache modules. I am not even sure we should assume that users use apache2 and not lighttpd. I think you "should" add this to %post. Just have a look at some Apache_Modules. There it is done, too.
I'll look into it.
Should apps be enabled with their installation or via server flags?
If you ask me, they should only be accessible from localhost by default.
Good point. I'll consider this. Hmm, why do you want to install a "webmailer" that is only accessible from localhost ? I can understand this for postfix but not for a webmailer. FMPOV, installing, (starting), accessing via web and configuring via web, happy :)
The reason is that just because a package is installed it should probably not open up something. It's no service to be enabled so as soon as someone installs the package and has Apache running (and actually reloads the Apache config but this is a minor detail) the app would be accessible from outside if no further step to actually enable it would be needed. So either make it only accessible from localhost or make sure that some switch needs to be toggled to enable it (like server flags as used for mailman and ssl for example. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hmm, why do you want to install a "webmailer" that is only accessible from localhost ? I can understand this for postfix but not for a webmailer. FMPOV, installing, (starting), accessing via web and configuring via web, happy :) Cheers
Because we don't know if it is meant to listen on all interfaces. Especially as long as it hasn't completed initial setup steps. I haven't looked at roundcube but remembering things like egroupware, I wouldn't want to have the initial setup listen on all interfaces without me knowing. It's no dogma though. We should find a consensus and write it down somewhere. I'll adjust "my" packages to this later. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
[12.02.2012 20:59] [Wolfgang Rosenauer]:
Am 12.02.2012 20:17, schrieb Ralf Lang:
Am 12.02.2012 19:59, schrieb Wolfgang Rosenauer:
I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now.
Great. Which?
Roundcube Mail.
Maybe you can take some inspration from the home:pheinlein repo? Today, I got roundcubemail-0.7.1-2.1 from there. And please, remove the line php_admin_value open_basedir "/srv/www/roundcubemail:/etc/roundcubemail:/tmp" from /etc/apache2/conf.d/roundcube ;-). Every other package thinks it needs an open_basedir setting, and so no package works - since one package forbids the other package's workdir. gnaaa.... Me, I package DokuWiki to /srv/www/dokuwiki and link /srv/www/dokuwiki/conf to /etc/dokuwiki. Maybe this is not nice, but I do not want to rewrite the whole configuration reading and writing mechanism of DokuWiki. I take it as a compromise... Regards, Werner -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 13.02.2012 17:59, schrieb Werner Flamme:
[12.02.2012 20:59] [Wolfgang Rosenauer]:
Am 12.02.2012 20:17, schrieb Ralf Lang:
Am 12.02.2012 19:59, schrieb Wolfgang Rosenauer:
I'm not deep into PHP app packaging but I'm working on an update for an existing app in server:php:applications right now.
Great. Which?
Roundcube Mail.
Maybe you can take some inspration from the home:pheinlein repo? Today, I got roundcubemail-0.7.1-2.1 from there.
And please, remove the line
php_admin_value open_basedir "/srv/www/roundcubemail:/etc/roundcubemail:/tmp"
+1
from /etc/apache2/conf.d/roundcube ;-). Every other package thinks it needs an open_basedir setting, and so no package works - since one package forbids the other package's workdir. gnaaa....
Me, I package DokuWiki to /srv/www/dokuwiki and link /srv/www/dokuwiki/conf to /etc/dokuwiki. Maybe this is not nice, but I do not want to rewrite the whole configuration reading and writing mechanism of DokuWiki. I take it as a compromise...
Would it be technically possible to have the files in /etc/dokuwiki and link them to /srv/www/dokuwiki/conf ? - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85S40ACgkQCs1dsHJ/X7AQdQCdEI8octjImbi50JbhQXxZ4bMU 7HMAoMrjfnEFiWC2xxKiLovQnJL0OzaB =+9zN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 13.02.2012 18:42, schrieb Ralf Lang:
Me, I package DokuWiki to /srv/www/dokuwiki and link /srv/www/dokuwiki/conf to /etc/dokuwiki. Maybe this is not nice, but I do not want to rewrite the whole configuration reading and writing mechanism of DokuWiki. I take it as a compromise...
Would it be technically possible to have the files in /etc/dokuwiki and link them to /srv/www/dokuwiki/conf ?
I think so. There is no restriction of PHP directories inside DokuWiki, so I may change the location. At least I'll try ;-) Of course, /etc/dokuwiki has to belong to the Apache user then, because this user must be able to write there (currently, I provide Apache integration only, being lazy as I am. There are plans to support nginx and lighty, but I had to care about our new SAP servers first...). Does other software, like phpmyadmin, use a subdirectory of /etc too? I never noticed... Regards, Werner -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 13.02.2012 17:59, schrieb Werner Flamme:
Roundcube Mail.
Maybe you can take some inspration from the home:pheinlein repo? Today, I got roundcubemail-0.7.1-2.1 from there.
home:pheinlein/roundcubemail is a link to server:php:applications so you got "my" roundcubemail package today ;-) Looking forward to your feedback.
And please, remove the line
php_admin_value open_basedir "/srv/www/roundcubemail:/etc/roundcubemail:/tmp"
from /etc/apache2/conf.d/roundcube ;-). Every other package thinks it needs an open_basedir setting, and so no package works - since one package forbids the other package's workdir. gnaaa....
I removed this in this version already. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Wolfgang Rosenauer wrote:
The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME.
The latter is certainly wrong as the web server allows full access to those files by default then. IMO /srv/www/ is also the wrong location. Just put the files in /usr/share/NAME or /usr/lib/NAME like any other non-web application would do it.
In addition it is patched to have its php config files in /etc instead of the application directory. Do we really want that?
Proper packages have their program code in a read only location and config files in /etc/. I don't understand why web stuff should be any different there even though sloppy programming seems to be more common in that area.
Do we want to fiddle with the Apache config in %post or similar to add required modules (a2enmod)?
We have a policy to not enable daemons by default to avoid accidentally wide open systems. That's a good practice for any kind of service IMO. Unfortunately we lack infrastucture and tools to manage web apps properly. A tool like chkconfig that also understands virtualhosts etc would be nice, wouldn't it? :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 13.02.2012 09:52, schrieb Ludwig Nussel:
Wolfgang Rosenauer wrote:
The app I'm working on is installing itself into /srv/www/NAME. Others are using /srv/www/htdocs/NAME.
The latter is certainly wrong as the web server allows full access to those files by default then. IMO /srv/www/ is also the wrong location. Just put the files in /usr/share/NAME or /usr/lib/NAME like any other non-web application would do it.
Hm, also sounds reasonable. Actually that's what I prefer but apparently we have as many opinions as people within the discussion.
Proper packages have their program code in a read only location and config files in /etc/. I don't understand why web stuff should be any different there even though sloppy programming seems to be more common in that area.
Yes, for me the question is if it's worth the effort? When I first tried to use the package a few months ago it was simply broken because of the move of the config files and missing patches what I noticed and fixed it. If upstream does not handle that (as most upstream PHP apps do) I'm wondering if it's worth the risk to break something. From a packager perspective it's not always possible to foresee every possible workflow which might break it.
Do we want to fiddle with the Apache config in %post or similar to add required modules (a2enmod)?
We have a policy to not enable daemons by default to avoid accidentally wide open systems. That's a good practice for any kind of service IMO. Unfortunately we lack infrastucture and tools to manage web apps properly. A tool like chkconfig that also understands virtualhosts etc would be nice, wouldn't it? :-)
I agree with the "not enable daemons by default" and that's why I replied that the localhost option might be a solution. Another one would be the Apache server flags. I can do either but again it should be as consistent as possible. I'd probably like to hear an Apache maintainer what is preferred (if there is any). Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 13.02.2012 10:14, schrieb Wolfgang Rosenauer:
We have a policy to not enable daemons by default to avoid accidentally wide open systems. That's a good practice for any kind of service IMO. Unfortunately we lack infrastucture and tools to manage web apps properly. A tool like chkconfig that also understands virtualhosts etc would be nice, wouldn't it? :-)
I agree with the "not enable daemons by default" and that's why I replied that the localhost option might be a solution. Another one would be the Apache server flags. I can do either but again it should be as consistent as possible. I'd probably like to hear an Apache maintainer what is preferred (if there is any).
A lot of pear software adheres to separation of config and data, other things can be patched to work this way. Proposal: 1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages( 2) Config lives in /etc/{appname} 3) We find a dir in /srv/ for apps that cannot easily be patched to work this way or need a web-writable folder 4) rpm-installed web apps listen on localhost by default 5) We won't be all too strict and won't scare off maintainers of existing packages Candy: 6) If somebody mentors me on the best practices for /etc/sysconfig and yast development, I'll develop a nice little yast module which configures some aspects of the required vhost.d/ and conf.d/ stuff. Is there any skeleton/template for this? I am in no hurry with this though. If it's ready for 12.2 - fine, if not - then later. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85ABgACgkQCs1dsHJ/X7AsxgCgx5iovwZr6tP14/vC+HuuEFbp PeUAniDjwRbRpTK1Opx/k8lEcEQPCWZ9 =P9Kg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ralf Lang wrote:
[...] A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages( [...]
Fedora seems to have some basic policy that openSUSE's could be based on: https://fedoraproject.org/wiki/Packaging/PHP
Candy: 6)
If somebody mentors me on the best practices for /etc/sysconfig and yast development, I'll develop a nice little yast module which configures some aspects of the required vhost.d/ and conf.d/ stuff.
Is there any skeleton/template for this?
I'm not sure whether it makes sense to involve /etc/sysconfig mechanisms or even yast to do the hard work. AFAIK gentoo has a script called webapp-config. I don't know how it works though or whether it's actually good but maybe worth a look. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Montag, 13. Februar 2012 schrieb Ralf Lang:
A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages(
Define "Immutable parts", please ;-) What about - template files that a user might customize (even if only 1% actually does it) - smarty cache (templates_c directory) - a CMS that allows uploading pictures etc. - a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-) - webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp) Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course). If you want real-world examples which parts/directories need to be writeable, I can lookup the details in my apache AppArmor profile for (at least) Joomla, Typo3, S9Y and Mediawiki. Just ask if you are interested ;-)
2) Config lives in /etc/{appname} 3) We find a dir in /srv/ for apps that cannot easily be patched to work this way or need a web-writable folder
Sounds interesting. It will be even more interesting how your open_basedir setting will look like for such a setup *g*
4) rpm-installed web apps listen on localhost by default
I'm not sure if this is the best idea. Security-wise, well, maybe - but it will annoy lots of users... If you implement something like this, please make sure to find a solution that - won't cause lots of files in /etc/apache2/conf.d/ to be marked as "modified" by rpm (which makes updates more interesting - I don't like the idea to merge and cleanup 100 *.rpmnew or *.rpmorig files) - won't lock the webapp again after an update
5) We won't be all too strict and won't scare off maintainers of existing packages
;-) That said, http://blog.koehntopp.de/archives/860-Webanwendungen-und-der-FHS.html is still an interesting reading (german, use google translate if needed) and contains lots of interesting points (feel free to ignore the "don't package webapps as rpm" part) If you have a dejavu while reading this, don't be too surprised ;-) and have a look at http://lists.opensuse.org/opensuse-packaging/2011-04/msg00127.html (my comments from april are still valid) BTW: The fedora policy is "just" for PHP modules, PEAR and PECL packages (and it makes sense for them). It doesn't cover webapps (unless I overlooked something). Regards, Christian Boltz -- Natürlich kann man Bäume mit der Nagelschere fällen, und es ist bedeutend sicherer, als, sagenwirmal, eine Kettensäge. Trotzdem ist eine Säge das korrekte Werkzeug. [Ratti in suse-linux] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 14.02.2012 00:36, schrieb Christian Boltz:
Hello,
Am Montag, 13. Februar 2012 schrieb Ralf Lang:
A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages(
Define "Immutable parts", please ;-)
Parts which are not expected to be changed. You don't expect users to do weird hacks in an application's core files when installed via rpm. In an rpm-provisioned system, the correct deployment for a patched application is a patched rpm.
What about - template files that a user might customize (even if only 1% actually does it)
If the app is customizable, templates are either "data" (html with snippets of php)
- a CMS that allows uploading pictures etc.
Uploadable data should reside in DB or a data dir or any other data store. In fact most apps I have seen do it this way.
- a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-)
How should additional files in a plugin dir be affected by a proper rpm? They are not.
- webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp)
If you want your app from rpm / from distribution, you also want updates via rpm / from distribution. If you don't like the way the distribution handles stuff, you can always "download and unzip". For example, while it is technically working to upgrade an rpm-installed pear library or app via pear upgrade or by replacing files, it is not the best idea. You will bring yourself into trouble. If you want manual gui updates decoupled from the distribution, you better get a tarball.
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
So what? I never said distribution packaging was always easy.
If you implement something like this, please make sure to find a solution that - won't cause lots of files in /etc/apache2/conf.d/ to be marked as "modified" by rpm (which makes updates more interesting - I don't like the idea to merge and cleanup 100 *.rpmnew or *.rpmorig files) - won't lock the webapp again after an update
Agreed. Generally, I am not interested in discussions IF applications should be packaged. This is the packaging list after all and we are discussing because we currently have not yet found answers how to handle things. Any scheme we agree on should have sane migration paths and only migrate parts when they are working. Users will always have the option to generally not use a distribution-provided app but when they do, they should get an app that behaves like any program in the distribution. I certainly won't reject anything for s:p:a just because a packager does not try arcane tricks to make apps work this way which simply can't by design. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8594kACgkQCs1dsHJ/X7DE3gCgjvHbeMVUV2TJLL2ZgKOyyLeO vC4An1SDkmf/aAhsRgPXnn3k9jAGzF47 =bIBg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
I'm heavily symlinking all the sources from /usr/share/NAME to /var/lib/NAME/webroot ; in /var/lib/NAME/webroot configuration, extensions and templates can be configured and the application can have write-access, too. Additionally I add /var/lib/NAME/temp and /var/lib/NAME/sessions directories, which are configured for php to be used for uploads and session information. As PHP is per configuration (in /etc/apache2/conf.d/NAME ) not allowed to access files outside /var/lib/NAME and /usr/share/NAME, the applications are configured in a very safe way. An advantage is, that its quite simple to use the same package for different virtual hosts (which is a as requirement in LSB, when I remember right). It's not important for web-mail tools, but its nice to have eg. for packages like mediawiki... In this case the installation un /usr/share makes also sense, as the sources are used from different vhosts. The package structures are also compatible with other distributions. Disadvantage is, that for some applications you must sometimes add patches to work correctly with symlink-structures.. Johannes Am 14.02.12 06:56, schrieb Ralf Lang:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 14.02.2012 00:36, schrieb Christian Boltz:
Hello,
Am Montag, 13. Februar 2012 schrieb Ralf Lang:
A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages(
Define "Immutable parts", please ;-)
Parts which are not expected to be changed. You don't expect users to do weird hacks in an application's core files when installed via rpm. In an rpm-provisioned system, the correct deployment for a patched application is a patched rpm.
What about - template files that a user might customize (even if only 1% actually does it)
If the app is customizable, templates are either "data" (html with snippets of php)
- a CMS that allows uploading pictures etc.
Uploadable data should reside in DB or a data dir or any other data store. In fact most apps I have seen do it this way.
- a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-)
How should additional files in a plugin dir be affected by a proper rpm? They are not.
- webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp)
If you want your app from rpm / from distribution, you also want updates via rpm / from distribution. If you don't like the way the distribution handles stuff, you can always "download and unzip". For example, while it is technically working to upgrade an rpm-installed pear library or app via pear upgrade or by replacing files, it is not the best idea. You will bring yourself into trouble. If you want manual gui updates decoupled from the distribution, you better get a tarball.
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
So what? I never said distribution packaging was always easy.
If you implement something like this, please make sure to find a solution that - won't cause lots of files in /etc/apache2/conf.d/ to be marked as "modified" by rpm (which makes updates more interesting - I don't like the idea to merge and cleanup 100 *.rpmnew or *.rpmorig files) - won't lock the webapp again after an update
Agreed.
Generally, I am not interested in discussions IF applications should be packaged. This is the packaging list after all and we are discussing because we currently have not yet found answers how to handle things. Any scheme we agree on should have sane migration paths and only migrate parts when they are working. Users will always have the option to generally not use a distribution-provided app but when they do, they should get an app that behaves like any program in the distribution. I certainly won't reject anything for s:p:a just because a packager does not try arcane tricks to make apps work this way which simply can't by design.
- -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8594kACgkQCs1dsHJ/X7DE3gCgjvHbeMVUV2TJLL2ZgKOyyLeO vC4An1SDkmf/aAhsRgPXnn3k9jAGzF47 =bIBg -----END PGP SIGNATURE-----
-- 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
Hello, Am Dienstag, 14. Februar 2012 schrieb Ralf Lang:
Am 14.02.2012 00:36, schrieb Christian Boltz:
Am Montag, 13. Februar 2012 schrieb Ralf Lang:
A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages(
Define "Immutable parts", please ;-)
Parts which are not expected to be changed. You don't expect users to do weird hacks in an application's core files when installed via rpm. In an rpm-provisioned system, the correct deployment for a patched application is a patched rpm.
OK, agreed.
What about - template files that a user might customize (even if only 1% actually does it)
If the app is customizable, templates are either "data" (html with snippets of php)
(did you forget the "or" counterpart for the "either"?)
- a CMS that allows uploading pictures etc.
Uploadable data should reside in DB or a data dir or any other data store. In fact most apps I have seen do it this way.
Yes, and if you are lucky, they even have a data dir != the webroot ;-) (fortunately most webapps at least honor this basic rule)
- a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-)
How should additional files in a plugin dir be affected by a proper rpm? They are not.
They are not "affected" by the RPM, but they still open up an interesting question. Let's assume the webapp itsself lives in /usr/lib/mywebapp/, comes with some plugins in /usr/lib/mywebapp/plugins/ and now someone installs another plugin from an online repo (= no rpm). Where should this plugin be stored? - /usr/lib/mywebapp/plugins/ - that means backup fun and violates the FHS (a system should work with read-only /usr) - /var/something (or /srv/something, doesn't really matter) - will probably result in a symlink hell in the first place (because you'll need a symlink for every plugin shipped in the rpm instead of one symlink for the symlink directory) and it will become even more interesting if the next version of that webapp contains additional plugins (which means you'll have to create additional symlinks on upgrade) - always assuming the package uses symlinks to handle the FHS-compliant packaging I don't say it's impossible, but at least it makes the packaging very interesting[tm] and, main problem, possibly makes the package hard to understand for users. The perfect solution is that the webapp supports two plugin directories (one "global" for plugins contained in the upstream tarball and installed by the rpm, and a "local" one for additional plugins that the user added somehow). Typo3 does it this way[1], but many others only allow a single plugin directory.
- webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp)
If you want your app from rpm / from distribution, you also want updates via rpm / from distribution.
Yes ;-) I expected your answer, and I couldn't agree more. Nevertheless some webapps offer this option, and I'm quite sure if someone installs wordpress as rpm, we'll get a bugreport that the built-in online update fails because of missing write permissions ;-)
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
So what? I never said distribution packaging was always easy.
The question is how hard we (packagers) should make our live. Is it really worth the effort to split a webapp to 4 directories (config in /etc, "immutable" files in /usr, data in /var, everything symlinked together in /srv - did I forget something?)
Generally, I am not interested in discussions IF applications should be packaged. This is the packaging list after all and we are discussing because we currently have not yet found answers how to handle things.
Personally, I'd simply package everything in /srv and - restrict write permissions to the places that need to be writeable - set open_basedir restricted to the webapp's directory [2] - optionally session.save_path, upload_tmpdir etc. set to a specific directory - set a "deny from all" for directories that shouldn't be public (for example smarty's templates_c directory) - maybe even include an AppArmor hat? I know this is not strictly following the FHS ;-) but it has a big advantage: users/admins always have the same directory layout of the webapp - independent of the question if they use a rpm or install from a tarball. In other words: it's less confusing ;-) Symlinking the config file(s) to /etc/ would be OK, but everything else doesn't bring an advantage IMHO. (Note that I'm talking only about webapps - for PEAR packages etc. a location in /usr makes a lot of sense.)
Any scheme we agree on should have sane migration paths and only migrate parts when they are working.
Wise words. I'm sure we would have less annoyed users if everybody (not only webapp packagers) would follow this rule ;-) Regards, Christian Boltz [1] well, to be exact, it even has 3 plugin directories, but this detail doesn't matter here [2] I hope the good old "I'll mixup your vhosts' open_basedir" gremlin is finally gone from PHP - I have to admit I didn't test this since some time --
*gruebel* Beenden sich Zombie-Prozesse nicht irgendwann mal von selbst? Ne, die sind ja schon beendet. Umpf. Jetzt wird's schwierig. Wie zum Henker tötet man tote Untote, die schon gestorben sind? [Eilert Brinkmann und Martin Leidig in suse-talk]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just quoting the parts that need to be quoted ...
What about - template files that a user might customize (even if only 1% actually does it)
If the app is customizable, templates are either "data" (html with snippets of php)
(did you forget the "or" counterpart for the "either"?)
Yes. It was about configurable templates and that any app I remember Sometimes I read twice before sending to filter out lines with less rational motivation and then I forget to repair the sentences.
- a CMS that allows uploading pictures etc.
Uploadable data should reside in DB or a data dir or any other data store. In fact most apps I have seen do it this way.
Yes, and if you are lucky, they even have a data dir != the webroot ;-) (fortunately most webapps at least honor this basic rule)
I'll call this case "traditional web app". Obviously, I expect modern production ready web software to have a more suitable design. Apart from that, if something cannot be made work our way without too much trouble, we shouldn't. That's why my proposal includes a fallback location for this kind of stuff and for packagers which do not (now) have the time to convert. We can review what happens and react. If there is few stuff in /srv/{fallback} then fine. If there is most stuff in /srv/{fallback} and only select stuff installed system-style, we're not harmed at all - - but we still have stopped the confusion if it should be /srv/www/htdocs or /srv/www/something or /var/lib/stuff
- a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-)
How should additional files in a plugin dir be affected by a proper rpm? They are not. They are not "affected" by the RPM, but they still open up an interesting question.
Let's assume the webapp itsself lives in /usr/lib/mywebapp/, comes with some plugins in /usr/lib/mywebapp/plugins/ and now someone installs another plugin from an online repo (= no rpm). Where should this plugin be stored? - /usr/lib/mywebapp/plugins/ - that means backup fun and violates the FHS (a system should work with read-only /usr)
Obviously, it needs install time rw access. I don't want to split hairs now ;-) I understand your case is "webapp admin not aware of / not in charge of underlying system". Then he doesn't update the rpm-based base app, too.
- /var/something (or /srv/something, doesn't really matter) - will probably result in a symlink hell in the first place (because you'll need a symlink for every plugin shipped in the rpm instead of one symlink for the symlink directory) and it will become even more interesting if the next version of that webapp contains additional plugins (which means you'll have to create additional symlinks on upgrade) - always assuming the package uses symlinks to handle the FHS-compliant packaging
I don't say it's impossible, but at least it makes the packaging very interesting[tm] and, main problem, possibly makes the package hard to understand for users.
The perfect solution is that the webapp supports two plugin directories (one "global" for plugins contained in the upstream tarball and installed by the rpm, and a "local" one for additional plugins that the user added somehow). Typo3 does it this way[1], but many others only allow a single plugin directory.
See above: Where it won't work, it won't work.
Yes ;-) I expected your answer, and I couldn't agree more. Nevertheless some webapps offer this option, and I'm quite sure if someone installs wordpress as rpm, we'll get a bugreport that the built-in online update fails because of missing write permissions ;-)
Wordpress should be shipped with the disable core updates plugin ;-)
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
So what? I never said distribution packaging was always easy.
The question is how hard we (packagers) should make our live.
Is it really worth the effort to split a webapp to 4 directories (config in /etc, "immutable" files in /usr, data in /var, everything symlinked together in /srv - did I forget something?)
No need for the latter part. You can serve directly from /usr/share/php, having links to config and mutable parts from there.
Generally, I am not interested in discussions IF applications should be packaged. This is the packaging list after all and we are discussing because we currently have not yet found answers how to handle things.
Personally, I'd simply package everything in /srv and - restrict write permissions to the places that need to be writeable - set open_basedir restricted to the webapp's directory [2] - optionally session.save_path, upload_tmpdir etc. set to a specific directory - set a "deny from all" for directories that shouldn't be public (for example smarty's templates_c directory) - maybe even include an AppArmor hat?
I know this is not strictly following the FHS ;-) but it has a big advantage: users/admins always have the same directory layout of the webapp - independent of the question if they use a rpm or install from a tarball. In other words: it's less confusing ;-)
Symlinking the config file(s) to /etc/ would be OK, but everything else doesn't bring an advantage IMHO.
(Note that I'm talking only about webapps - for PEAR packages etc. a location in /usr makes a lot of sense.)
It's a fine line. Pear packaging isn't about libraries only. If we install our pear stuff more or less FHS-like, we should at least try and provide other apps in a similar style where this works. It's not so much about religious belief in FHS. People seem to like having configs in /etc/, all in one place. I've seen systems with /etc/ being a subversion repository or backupped daily. I think we begin repeating ourselves. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk87am8ACgkQCs1dsHJ/X7C3hwCgyjIkNJKbR/TEAli9PfYviyg3 PasAn01dX2fmVhu0hiSBe8MT3VGhRnQQ =tPiZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz wrote:
[...] - webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp)
Yeah, I always need to have a sick bag handy when thinking about web apps ;-) As Ralph already wrote the update mechanism for an rpm package is installing an updated rpm package. If you don't like that then don't install the app as rpm in the first place. We don't let e.g. Firefox update itself per user either.
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
I guess some webapps are better and some are worse, depending who wrote it and for what purpose. I'm sure a well designed application would work both in the shared hosting scenario as well as in the system package mode with least privilege thinking and separation of data and configuration. It's just the same as with 'native' programs. Fortunately DOS style programs that want world writeable /opt/something directories or only work in $HOME are almost extinct.
If you want real-world examples which parts/directories need to be writeable, I can lookup the details in my apache AppArmor profile for (at least) Joomla, Typo3, S9Y and Mediawiki.
I'm not sure what the number of hits in the CVE database for those candidates tells us about them :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Dienstag, 14. Februar 2012 schrieb Ludwig Nussel:
Christian Boltz wrote:
[...] - webapps that allow to update themself online (like wordpress - and> no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp) Yeah, I always need to have a sick bag handy when thinking about web apps ;-)
;-)
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
I guess some webapps are better and some are worse, depending who wrote it and for what purpose.
Yes, of course. Which leaves the question if we should invest lots of time to force the packaging-unfriendly webapps into the scheme we like for the packaging-friendly webapps, or if we accept the fact that they need everything in one directory. See my reply to Ralf's mail for more details.
for (at least) Joomla, Typo3, S9Y and Mediawiki.
I'm not sure what the number of hits in the CVE database for those candidates tells us about them :-)
That there are people who care about those webapps and check them for security issues? Hmm, I don't remember a CVE for /bin/true - does this mean nobody audited its code? ;-) Oh, and all that is still better than the way the Adobe security chief would like, see http://www.zdnet.com/blog/security/offensive-security-research-community-hel... (money quote: "Finding a bug is pretty straightforward" ;-)) The even more interesting reading is the comment about the article on http://blog.fefe.de/?ts=b1cba1ed (in german - google translate exists) Regards, Christian Boltz -- Aus technischen Grunden befindet sich die Signatur auf der Rückseite dieser Mail. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 15 Feb 2012 01:43:25 +0100, Christian Boltz
http://blog.fefe.de/?ts=b1cba1ed (in german - google translate exists)
I doubt google translate can get the style of this typical fefe post across though ;-) Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Ludwig,
The latter is certainly wrong as the web server allows full access to those files by default then. IMO /srv/www/ is also the wrong location. Just put the files in /usr/share/NAME or /usr/lib/NAME like any other non-web application would do it. Ever thought /usr/share/NAME is for files "shared" to other apps, isn't it. For me a "webapp" should have its files in /srv/www/NAME.
Proper packages have their program code in a read only location and config files in /etc/. I don't understand why web stuff should be any different there even though sloppy programming seems to be more common in that area. agreed.
We have a policy to not enable daemons by default to avoid accidentally wide open systems. That's a good practice for any kind of service IMO. Unfortunately we lack infrastucture and tools to manage web apps properly. A tool like chkconfig that also understands virtualhosts etc would be nice, wouldn't it? :-) Yes, I agree partly. as an example postfix is installed by default, but should not be open to the world. OK But when I "definitly" install a webapp (webmailer) I want to have it "work" when I start apache. I like "ready-to-run" installations. ;)
-- Christian ---------------------------------------------------- - Please do not 'CC' me on list mails. Just reply to the list :) ---------------------------------------------------- Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de ---------------------------------------------------- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 13.02.2012 14:55, schrieb Christian:
Hi Ludwig,
The latter is certainly wrong as the web server allows full access to those files by default then. IMO /srv/www/ is also the wrong location. Just put the files in /usr/share/NAME or /usr/lib/NAME like any other non-web application would do it. Ever thought /usr/share/NAME is for files "shared" to other apps, isn't it. For me a "webapp" should have its files in /srv/www/NAME.
Pear apps usually install themselves distributed over peardir, www_dir, bin_dir, data_dir etc whatever they are set to. If a php app includes cli parts, these should be where the distribution places "commands" (binaries to run from the shell). To me, /srv/ should be for user data (and apps that cannot be split into immutable parts and mutable parts are like mutable data)
Proper packages have their program code in a read only location and config files in /etc/. I don't understand why web stuff should be any different there even though sloppy programming seems to be more common in that area. agreed.
We have a policy to not enable daemons by default to avoid accidentally wide open systems. That's a good practice for any kind of service IMO. Unfortunately we lack infrastucture and tools to manage web apps properly. A tool like chkconfig that also understands virtualhosts etc would be nice, wouldn't it? :-) Yes, I agree partly. as an example postfix is installed by default, but should not be open to the world. OK But when I "definitly" install a webapp (webmailer) I want to have it "work" when I start apache. I like "ready-to-run" installations. ;)
I like them too. On local network. * But making an app run which requires a specific apache extension requires restarting (reloading?) apache and disturbing running operations. I do not want this triggered by rpm. * Some apps expose functionality which you don't want to over via web. Example: Horde comes with a system shell and a php shell for admins. The default config authenticates anyone as the administrator until another backend is configured. If you have a system with relaxed /home/ security this means anybody who can access your host can browse all user's data. I don't like that. Granted, most web apps don't provide such and it could be configured away. But still. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85K9EACgkQCs1dsHJ/X7AD9wCgl0J6N5M68JSf0eV6xLHIVnnv 8DMAnAodH+KpmOJNsHx7Srm+WFq4wPNF =AGjo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Montag, 13. Februar 2012 schrieb Ralf Lang:
Am 13.02.2012 14:55, schrieb Christian:
Yes, I agree partly. as an example postfix is installed by default, but should not be open to the world. OK But when I "definitly" install a webapp (webmailer) I want to have it "work" when I start apache. I like "ready-to-run" installations. ;)
I like them too. On local network.
* But making an app run which requires a specific apache extension requires restarting (reloading?) apache and disturbing running operations. I do not want this triggered by rpm.
Do you want a bugreport for phpMyAdmin? ;-) (it does /etc/init.d/apache2 try-restart in %post and %postun) Oh, and it should have the apache2 package in the Requires ;-) Ah, and I just found out why I always get a /etc/phpMyAdmin/config.inc.php.rpmnew - %post has a sed command that modifies config.inc.php. Now combine that with a %config %noreplace and you'll get your *.rpmnew. It would be a good idea to move blowfish_secret and the fqdn to a separate file (which is modified by sed) so that config.inc.php can stay unmodified (if the admin is happy with the defaults) and just include the sed'ed file. (I'lll open an enhancement request if you don't object ;-)
* Some apps expose functionality which you don't want to over via web. Example: Horde comes with a system shell and a php shell for admins. The default config authenticates anyone as the administrator until another backend is configured. If you have a system with relaxed /home/ security this means anybody who can access your host can browse all user's data.
That's a security bug (insecure default configuration), please open a bugreport (upstream) and/or fix it.
I don't like that.
I'm sure everybody agrees ;-)
Granted, most web apps don't provide such and it could be configured away. But still.
In other words: Most web apps are secure even without restricting access to it to localhost. The few remaining cases need to be fixed, and no, "allow from 127.0.0.1" is _not_ a fix. Regards, Christian Boltz -- Ein Killfile ist der natürliche Lebensraum von Trollen und Elchen. Wenn sich jemand zu ihnen gesellt, entstehen lustige Geräusche, wie PLONK. Manchmal machts auch PLATSCH, wenn der Lebensraum bereits überbevölkert ist. [David Dahlberg] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Christian -
Christian Boltz -
Johannes Weberhofer -
Ludwig Nussel -
Philipp Thomas -
Ralf Lang -
Werner Flamme -
Wolfgang Rosenauer