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