On 31 Dec 12:30, Chris G wrote:
On Sun, Dec 30, 2007 at 08:08:53PM +0000, Brett Parker wrote:
As root, in to a shared location, not in anyones web tree, making sure that the users have not got write access to the code, or read access to any passwords for, e.g., the database backend that it's using. Then you only maintain *one* copy of the code, rather than having it scattered all over the place like a moron making maintainence much much easier.
Exactly! ... and then you go and try and do web maintenance type things and find lots of files owned by root.
Applications like phpmyadmin and Twiki fall between two stools in a way, there seems no well defined way of managing their permissions etc.
Weird, I just install the nice shiny debian packages and have done. The scripts are then (generally) around the /usr/share/<packagename> directory, with state stored in /var/lib/<packagename>. Of course, phpmyadmin being a pile of evil PHP doesn't go anywhere near a machine that I care about, but that's beside the point.
The reason that there's no "defined" way of doing it is because they are just web applications, and they can live anywhere - couple that with the fun of running more than one instance of your webserver, or even using the outside facing webserver to proxy to a completely different webserver (I do that quite a lot, apache proxying to tomcat, for example, which we do "quite a lot of" at work, including mangling a header on the way through). As long as the configuration is in a sensible place (/etc/apache2, for instance), then you should be able to quickly tell where the data is stored anyways.
As for managing permissions, that should be a one off hit - that's why you don't install the same application multiple times for different users. It's just common sense.
There is nearly always quite a lot of stuff about permissions and such in their installation documentation. Maybe it's just a fact of life with web/www software. The rest of Linux seems to have got its act together so well that one very rarely has to wonder about permissions etc., installing RPMs is usually trivial, even doing a ./configure, make, make install rarely needs any mucking about with permissions afterwards (and you can choose where you want to put it with --prefix= with the permissions sorted correctly for most cases).
*YAWN* - web applications usually have some configuration, wether it's done at the module level of the webserver, or a config file in the directory that it's working from doesn't matter. It very rarely needs much thought to get it in to a sensible location that can be reused.
Installing web applications rarely seems so easy and you always end up wondering whether you've put it in the right place.
Nope, I really don't. On the other hand, I've been doing this for probably the best part of 9 years.
Apparently you have to use "common sense" to work out what to backup... weird, that. Apparently you've decided that /home is vital data that needs to be backed up, but /var isn't.
Nothing of the sort, I back up /home, /var and some other things, it's just that a *lot* of /var doesn't need backing up and the mix in /var seems not to make a lot of sense. It appears that /srv is actually intended (though rarely used) for quite a lot of the stuff that currently gets put in /var and needs backing up.
/srv is fairly recent, it'll get used more when people start getting used to it - but then it's not going to be "completely obvious" as the structure for /srv is not defined, and so from one machine to another the /srv directory could be wildly different.
Maybe you need to spend some time actually recovering a machine that's had a disk failure, that's when you really learn that your backups are insufficient and that you've now got 6 months worth of configuration tweaks missing and a set of scripts in /usr/local/bin that you left out of the backups.
Yes, it's those "configuration tweaks" are the real killers! :-)
I back up /home, /var and /etc at the moment, I *think* that covers most stuff. I generally upgrade by doing a re-install and copying across the "configuration tweaks" and such which does indicate most of what I need backed up.
Given that yum will actually let you run through an upgrade these days, why are you doing a reinstall? Sounds like a lot of work for not a lot of gain to me - and occasionally - just occasionally - it even warns you of configuration file format changes!
Of course, Debian still wins on this one, with configuration files being treated "specially" and not overriden by a new package without asking, with the option of diffs between the distribution supplied config file and your local one during upgrades, etc, etc.
My current installation has *very* little in /usr/local, nothing customised, just a few bits of software that don't come as RPMs for Fedora.
Some of ours have "quite a bit", including scripts that build packages in chroots - these are, however, all also in svn and our svn repository is backed up (as these things should be - version control isn't a backup in itself, after all... well... I suppose except with distributed version control, when you can just push a copy to another machine simply).
Thanks,