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