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