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.
Yes, but that *shouldn't* be necessary. The whole point of /var according to the standards is that there is *nothing* there that needs backing up. If something needs backing up it should be in /home or /srv (the 'right' place for web pages etc. is actually /srv).
According to which standards? The way I read the fhs is that it says the contents of /var should be backed up, or at least it would be prudent to do so given the data that it contains. If you disagree then I think you should read the fhs and a few books on basic sysadmin to see why.
I just did read FHS, where do you get the /var should be backed up from there?
The FHS is a set of guidelines for where things belong, it doesn't state what needs to be backed up. There's absolutely nothing that suggests /srv or /opt should be backed up. Heck, it doesn't actually state that /home needs backing up... Infact, it states that /home is *optional*.
In the section for /var/lib it says "application state data", now given that postgres is an application, and it's state is the databases that it's serving, surely that's a hint that you *might* want to backup /var (though - actually, you're always better off using pg_dump to backup databases).
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.
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.
*SIGH*,