On Sun, Dec 30, 2007 at 08:08:53PM +0000, Brett Parker wrote:
On 29 Dec 15:21, Chris G wrote:
On Sat, Dec 29, 2007 at 12:19:07PM +0000, Adam Bower wrote:
On Sat, Dec 29, 2007 at 10:39:44AM +0000, Chris G wrote:
That's OK until, as I said, you install something that wants to be root when installed and you get some stuff with root permissions again and you have to carefully set the permissions back to what you want (without opening them up too much).
What on earth are you installing into website directories that needs to be root? If you are using things that need root permissions in your web directories then you have more serious problems than worrying about some simple permissions on your html.
What user do you install things like phpmyadmin as, or Twiki?
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. 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).
Installing web applications rarely seems so easy and you always end up wondering whether you've put it in the right place.
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.
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.
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.