I've been changing my mind and messing about with this for years and *still* haven't really come to a sensible final conclusion. It's not even that it matters all that much but I wish there was an obvious answer. Where do you put all your HTML stuff on a home Linux server? There are two basic alternatives, each with advantages and disadvantages:- 1 - In your home directory Permissions are easy to deal with, no need to become root to edit web pages. But it means that, if the outside world has access, you have to be *very* careful with apache set up if you want to be sure only the right bits are visible to the outside world. You either have to use the ~<user> in the URL or you have to add symbolic links from apache's DocumentRoot. If there's more than one user (not in my case) /home makes more sense. Backing up is easy as the HTML gets backed up with your home directory (though there might be bits in DocumentRoot you want to back up anyway). 2 - In apache's DocumentRoot (/var/www/html in my case) Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory. Easier to make sure that any outside access can only see what you want to be seen. Cleaner/easier URLs without the need for symbolic links. Not really practical for multi-user but this doesn't apply for me. Need to back up separately from /home (though I suppose you could make /var/html a link across to the /home partition) I keep a lot of quite dynamic (i.e. frequently changing) files as HTML, or at least their content is web browsable, so the above issues are important for me. Does anyone have any comments, ideas, solutions? -- Chris Green
On 28 Dec 2007, at 4:12 pm, Chris G wrote:
I've been changing my mind and messing about with this for years and *still* haven't really come to a sensible final conclusion. It's not even that it matters all that much but I wish there was an obvious answer.
Where do you put all your HTML stuff on a home Linux server?
There are two basic alternatives, each with advantages and disadvantages:-
1 - In your home directory
Permissions are easy to deal with, no need to become root to edit web pages.
But it means that, if the outside world has access, you have to be *very* careful with apache set up if you want to be sure only the right bits are visible to the outside world.
You either have to use the ~<user> in the URL or you have to add symbolic links from apache's DocumentRoot.
If there's more than one user (not in my case) /home makes more sense.
Backing up is easy as the HTML gets backed up with your home directory (though there might be bits in DocumentRoot you want to back up anyway).
2 - In apache's DocumentRoot (/var/www/html in my case)
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
Easier to make sure that any outside access can only see what you want to be seen.
Cleaner/easier URLs without the need for symbolic links.
Not really practical for multi-user but this doesn't apply for me.
Need to back up separately from /home (though I suppose you could make /var/html a link across to the /home partition)
I keep a lot of quite dynamic (i.e. frequently changing) files as HTML, or at least their content is web browsable, so the above issues are important for me.
Does anyone have any comments, ideas, solutions?
OK, I'll bite. I don't think most of the things you've described as issues aren't actually issues. For example, if you're the only user of the machine, you can set the permissions of /var/www/html to whatever you want and hence the need to be root or to have 'messy' permissions is alleviated. As for cleaner URLs, you can put the folder containing your HTML wherever the hell you want on the system and set the DocumentRoot in apache to match this and the URLs will be just as clean as putting them into /var/www/html/ currently. In conclusion, there is no official 'sensible' way of doing it, so just set it up whichever way you feel more comfortable with and the configure apache to fit with it. Thanks, -- David Reynolds david@reynoldsfamily.org.uk
On Fri, Dec 28, 2007 at 06:45:00PM +0000, David Reynolds wrote:
In conclusion, there is no official 'sensible' way of doing it, so just set it up whichever way you feel more comfortable with and the configure apache to fit with it.
I know that it's entirely up to me, but I can't work out what I like! :-) -- Chris Green
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
I've been changing my mind and messing about with this for years and *still* haven't really come to a sensible final conclusion. It's not even that it matters all that much but I wish there was an obvious answer.
Where do you put all your HTML stuff on a home Linux server? ... Does anyone have any comments, ideas, solutions?
Put it where you want, then configure the webserver to use the appropriate place. If you want it in your home directory then you can use DocumentRoot to point / of the webserver to a directory under ~ If you don't want to alter the webserver config you can symlink the default docroot into your home directory. Change the permissions on that directory so you can write to it as your normal user. Put yourself in the www-data group and then you can ensure the webserver can access files even if you want to prevent other users from doing so. Or use a rewrite/redirect rule if you want to put content under a ~user/ directory and then have the / of the webserver accessing that content. There are many other options too. I don't think there's a "right" answer. Use what works for you. I tend to take the approach of mostly putting things under ~user/ directories but then my main box is multiuser with the same domain shared by everyone. J. -- Revd. Jonathan McDowell, ULC | noodles is back group
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
This is what groups were invented for.
Not really practical for multi-user but this doesn't apply for me.
Why not? I have sysadmined machines with well over 100 seperate sites under /var I'd just setup each directory with the permissions for the correct owner and leave them to get one with it.
Need to back up separately from /home (though I suppose you could make /var/html a link across to the /home partition)
That won't matter as you are already backing /var up aren't you? Adam -- jabberid = quinophex@jabber.earth.li
On Fri, Dec 28, 2007 at 11:58:08PM +0000, Adam Bower wrote:
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
This is what groups were invented for.
Yes, and what group do you use? I couldn't come up with any sensible group to make things work as I wanted, apache/httpd runs as 'nobody' which makes things a little difficult.
Not really practical for multi-user but this doesn't apply for me.
Why not? I have sysadmined machines with well over 100 seperate sites under /var I'd just setup each directory with the permissions for the correct owner and leave them to get one with it.
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).
Need to back up separately from /home (though I suppose you could make /var/html a link across to the /home partition)
That won't matter as you are already backing /var up aren't you?
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). -- Chris Green
On Sat, Dec 29, 2007 at 10:39:44AM +0000, Chris G wrote:
On Fri, Dec 28, 2007 at 11:58:08PM +0000, Adam Bower wrote:
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
This is what groups were invented for.
Yes, and what group do you use? I couldn't come up with any sensible group to make things work as I wanted, apache/httpd runs as 'nobody' which makes things a little difficult.
I thought everything sane was using www-data/www-data for webservers these days and trying to limit the number of things running as user nobody. What distro are you using? J. -- Programmer, | Computers talk to each other | Tel/SMS: sysadmin & | worse than their designers do. | +423-663-212343 BHMF. | | Made by HuggieTag
On Sat, Dec 29, 2007 at 10:43:15AM +0000, Jonathan McDowell wrote:
On Sat, Dec 29, 2007 at 10:39:44AM +0000, Chris G wrote:
On Fri, Dec 28, 2007 at 11:58:08PM +0000, Adam Bower wrote:
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
This is what groups were invented for.
Yes, and what group do you use? I couldn't come up with any sensible group to make things work as I wanted, apache/httpd runs as 'nobody' which makes things a little difficult.
I thought everything sane was using www-data/www-data for webservers these days and trying to limit the number of things running as user nobody. What distro are you using?
I was using slackware (where httpd is nobody), it turns out that on Fedora 7 where I am now httpd is run as user apache. I see no www-data anywhere! :-) -- Chris Green
On Sat, 2007-12-29 at 10:39 +0000, Chris G wrote:
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).
Erm no Var is variable data (hence the name) there is nothing to suggest that the data there is worthless (logs at least might be very handy when recovering a failed system), just that it changes a lot. The whole point of var was twofold, 1. to make it possible to mount other dir's such as /usr read only and 2. by containing the busiest areas of the filesystem (in terms of writes) it is possible to contain the damage an unclean shutdown may cause and minimise the amount of time it will take to get the system back online. In the days of fsck operations that could take several hours this was very relevant because you could fsck var (which really needs to be RW for things to work) Then bring the system back online with most other stuff RO and then check the other filesystems whilst providing some degree of availability.
On Fri, Dec 28, 2007 at 11:58:08PM +0000, Adam Bower wrote:
On Fri, Dec 28, 2007 at 04:12:03PM +0000, Chris G wrote:
Messier with permissions if you want to edit HTML without becoming root all the time. Also not so convenient for editing even with permissions set up OK as it's not in your home directory.
This is what groups were invented for.
Yes, and what group do you use? I couldn't come up with any sensible group to make things work as I wanted, apache/httpd runs as 'nobody' which makes things a little difficult.
Not really practical for multi-user but this doesn't apply for me.
Why not? I have sysadmined machines with well over 100 seperate sites under /var I'd just setup each directory with the permissions for the correct owner and leave them to get one with it.
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).
Need to back up separately from /home (though I suppose you could make /var/html a link across to the /home partition)
That won't matter as you are already backing /var up aren't you?
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). [please don't reply to me *and* the list, very confusing] -- Chris Green
On Sat, Dec 29, 2007 at 03:23:19PM +0000, Adam Bower wrote:
On Sat, Dec 29, 2007 at 03:13:47PM +0000, Chris G wrote:
[please don't reply to me *and* the list, very confusing]
Err, I didn't. The only thing around here that appears to be causing confusion is you.
Well I certainly *received* two copies of your reply. I actually replied to the one I got on my personal E-Mail address and then, when I saw you had sent it to the list as well I copied my reply to the list. I'm not seeing this from anyone else. -- Chris Green
On Sat, Dec 29, 2007 at 03:29:15PM +0000, Chris G wrote:
Well I certainly *received* two copies of your reply. I actually replied to the one I got on my personal E-Mail address and then, when I saw you had sent it to the list as well I copied my reply to the list.
I'm not seeing this from anyone else.
They are only getting sent once. I'd suggest you take a look at your mail system but I fear it would only result in more questions. Adam -- jabberid = quinophex@jabber.earth.li
On Sat, Dec 29, 2007 at 03:50:13PM +0000, Adam Bower wrote:
On Sat, Dec 29, 2007 at 03:29:15PM +0000, Chris G wrote:
Well I certainly *received* two copies of your reply. I actually replied to the one I got on my personal E-Mail address and then, when I saw you had sent it to the list as well I copied my reply to the list.
I'm not seeing this from anyone else.
They are only getting sent once. I'd suggest you take a look at your mail system but I fear it would only result in more questions.
It's not worth the effort, it works fine for everyone else and every other mailing list. I'm not thus trying to get at you and I wasn't doing so to start with. I was just asking as it appeared to me that you were sending both to me and to the list (which quite a lot of people do without thinking), if you weren't then, fine, it's hardly a huge problem. .... and something was different about that message as it was the only one I got twice (and I haven't changed anything since). -- Chris Green
On Sat, 2007-12-29 at 15:13 +0000, Chris G wrote:
The whole point of /var according to the standards is that there is *nothing* there that needs backing up.
Ok in the interests of me learning something new. Please point me to the standard that says that you don't need to back up /var.
On Sat, Dec 29, 2007 at 03:39:31PM +0000, Wayne Stallwood wrote:
On Sat, 2007-12-29 at 15:13 +0000, Chris G wrote:
The whole point of /var according to the standards is that there is *nothing* there that needs backing up.
Ok in the interests of me learning something new. Please point me to the standard that says that you don't need to back up /var.
Reading http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY harder suggests to me that FHS is almost trying to avoid saying anything about backups. However the first line of the /var section there says:- /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. Now in my books "transient and temporary files" are definitely not candidates for backup. "administrative and logging data", it depends, you might want to back them up on a commercial system for auditing reasons but on a personal system it's debateable. "spool directories and files", more likely you want to back them up I suppose. However *none* of it is what I would call "important data" like the contents of databases, web pages, things like that. The database files and web pages should be in /srv. -- Chris Green
On Saturday 29 December 2007 15:59, Chris G wrote:
Ok in the interests of me learning something new. Please point me to the standard that says that you don't need to back up /var.
However *none* of it is what I would call "important data" like the contents of databases, web pages, things like that.
Suggestion: Install Debian, Red Hat, or any other deb/rpm based distro. Clean out /var of any/all files. Now try installing a new package and see what goes tits up. You may also want to look at /var/cache/man and/or a closer look at /var/lib. Regards, Paul.
On Saturday 29 December 2007 10:39, Chris G wrote:
That won't matter as you are already backing /var up aren't you?
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
Disagree - /var/mail, /var/lib, and possibly /var/cache should be backed up as much of the meta data related to installed packages reside there. Backing up /var/log is advisable should you ever need to do any forensics after a system has been hacked. [current spec can be found at http://www.pathname.com/fhs/pub/fhs-2.3.html ] As for web files (html, tarballs, general "stuff"), much of it goes in /var/www, some in /home/<usr>/stuff, and a great gob of files in /debian - Anything outside of /var/www gets symlinks.. Bottom line, your system, your choice ;-) Regards, Paul.
On Sat, Dec 29, 2007 at 11:58:54AM +0000, Paul wrote:
On Saturday 29 December 2007 10:39, Chris G wrote:
That won't matter as you are already backing /var up aren't you?
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
Disagree - /var/mail, /var/lib, and possibly /var/cache should be backed up as much of the meta data related to installed packages reside there. Backing up /var/log is advisable should you ever need to do any forensics after a system has been hacked.
Ah but /var/mail in particular is suggested may be a link to somewhere in the /home hierarchy isn't it?
[current spec can be found at http://www.pathname.com/fhs/pub/fhs-2.3.html ]
As for web files (html, tarballs, general "stuff"), much of it goes in /var/www, some in /home/<usr>/stuff, and a great gob of files in /debian - Anything outside of /var/www gets symlinks.. Bottom line, your system, your choice ;-)
Exactly, but I'm trying to come up with a strategy that isn't just a confused mess. -- Chris Green
On 29 Dec 15:15, Chris G wrote:
On Sat, Dec 29, 2007 at 11:58:54AM +0000, Paul wrote:
On Saturday 29 December 2007 10:39, Chris G wrote:
That won't matter as you are already backing /var up aren't you?
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
Disagree - /var/mail, /var/lib, and possibly /var/cache should be backed up as much of the meta data related to installed packages reside there. Backing up /var/log is advisable should you ever need to do any forensics after a system has been hacked.
No no no... backing up /var/log is less important if you have syslog configured to also log to a remote syslog daemon on a different machine. That way you should have logs right to the point that it was broken.
Ah but /var/mail in particular is suggested may be a link to somewhere in the /home hierarchy isn't it?
I've never seen a system configured that way. That way madness lies. /var/spool/mail is a symlink to /var/mail on a lot of the systems I use. Most people wanting to move mail over to home deliver to a maildir these days, ~/Maildir/ being the usual place, and certainly how I configure new machines these days.
[current spec can be found at http://www.pathname.com/fhs/pub/fhs-2.3.html ]
As for web files (html, tarballs, general "stuff"), much of it goes in /var/www, some in /home/<usr>/stuff, and a great gob of files in /debian - Anything outside of /var/www gets symlinks.. Bottom line, your system, your choice ;-)
Exactly, but I'm trying to come up with a strategy that isn't just a confused mess.
So, use: /srv/websites/tld/domain/subdomain eg: /srv/websites/uk/co/sommitrealweird/www or: /srv/websites/uk/co/www.sommitrealweird.co.uk Just decide on a layout and have done with it. (Personally, I have lots of sites all over the place, on this particular box I have a django server that is fronted by apache's mod_proxy, but the django instance is running using fastcgi fronted by lighttpd, the data is in /home/brettp/django/alug, which then has code in the alug subdirectory, images/other media in alug-media and templates for use in the code in alug-templates. My main website is hosted on another box, where it is sitting in my home directory as a directory called srw_html, I have symlinked public_html to that as I class it as the main site and where I'm most likely to want to put things on that box). Ho hum, -- Brett Parker
On Sunday 30 December 2007 19:57, Brett Parker wrote:
No no no... backing up /var/log is less important if you have syslog configured to also log to a remote syslog daemon on a different machine. That way you should have logs right to the point that it was broken.
You are indeed correct, but I was assuming a simple/minimal system that was not configured for remote logging.. Regards, Paul.
On Sun, Dec 30, 2007 at 07:57:08PM +0000, Brett Parker wrote:
No no no... backing up /var/log is less important if you have syslog configured to also log to a remote syslog daemon on a different machine. That way you should have logs right to the point that it was broken.
but.... your remote syslog machine could/probably would end up having the logs put into /var on the logging server.... I'd make sure that was backed up too ;) Adam -- jabberid = quinophex@jabber.earth.li
On Sun, Dec 30, 2007 at 07:57:08PM +0000, Brett Parker wrote:
Anything outside of /var/www gets symlinks.. Bottom line, your system, your choice ;-)
Exactly, but I'm trying to come up with a strategy that isn't just a confused mess.
So, use: /srv/websites/tld/domain/subdomain eg: /srv/websites/uk/co/sommitrealweird/www or: /srv/websites/uk/co/www.sommitrealweird.co.uk
Just decide on a layout and have done with it. (Personally, I have lots of sites all over the place, on this particular box I have a django server that is fronted by apache's mod_proxy, but the django instance is running using fastcgi fronted by lighttpd, the data is in /home/brettp/django/alug, which then has code in the alug subdirectory, images/other media in alug-media and templates for use in the code in alug-templates. My main website is hosted on another box, where it is sitting in my home directory as a directory called srw_html, I have symlinked public_html to that as I class it as the main site and where I'm most likely to want to put things on that box).
Yes, OK, I think it's just that most other things are rather better defined and you don't end up with such a mess of symlinks and such. I guess I'll just carry on muddling by (and backing up /var as I do already). -- Chris Green
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.
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. Adam -- jabberid = quinophex@jabber.earth.li
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?
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? -- Chris Green
On Sat, Dec 29, 2007 at 03:21:24PM +0000, Chris G wrote:
I just did read FHS, where do you get the /var should be backed up from there?
I'm sorry but the fhs doesn't tell you what to backup, if you can't see why you should backup /var despite having people already on the list tell you then don't. I'm still waiting for your reference to the standard that the point of it is that it shouldn't be backed up. Adam -- jabberid = quinophex@jabber.earth.li
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*, -- Brett Parker
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. -- Chris Green
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, -- Brett Parker
On Mon, Dec 31, 2007 at 01:55:28PM +0000, Brett Parker wrote:
On 31 Dec 12:30, Chris G wrote:
On Sun, Dec 30, 2007 at 08:08:53PM +0000, Brett Parker wrote:
[snip]
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.
Well if you want to pull that sort of seniority thing I've been developing software for 35 years or so. Length of experience doesn't necessarily equate with wisdom! ... and that applies to both of us :-)
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!
Well it's a bit difficult to move from Slackware to Fedora without doing a clean install. It also appears from the Fedora users list that upgrading from Fedora 7 to Fedora 8 isn't always straightforward. Doing a re-install also has the advantage of discarding the junk that slowly accumulates over upgrades. -- Chris Green
On 31 Dec 15:16, Chris G wrote:
On Mon, Dec 31, 2007 at 01:55:28PM +0000, Brett Parker wrote:
On 31 Dec 12:30, Chris G wrote:
On Sun, Dec 30, 2007 at 08:08:53PM +0000, Brett Parker wrote:
[snip]
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.
Well if you want to pull that sort of seniority thing I've been developing software for 35 years or so. Length of experience doesn't necessarily equate with wisdom! ... and that applies to both of us :-)
Software development isn't the same as web development, as many many people will be able to tell you, if we were just hitting software development then I started back in christmas of 1986 with a 48k spectrum, back when I was 5. Software development in and of itself doesn't tell you how to lay out a system for easy modification later, heck, my development environment for somethings is quite a lot different to my production environment - where the development environment is a single chroot running 3 tomcats and 2 different long term java processes on a single machine and the production environment being 4 seperate machines, a whole host of key sharing, and a fairly serious set of boxes (the main box doing the backend has 32G of ram and some seriously nice 2.5" disks using a fairly nice RAID controller, with LVM layered on top - at that point, layout is everything, and consistancy is very much a requirement - other people have to admin those machines when I'm on holiday - so making sure that it's documented and that people know where to find things is very very much a requirement).
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!
Well it's a bit difficult to move from Slackware to Fedora without doing a clean install. It also appears from the Fedora users list that upgrading from Fedora 7 to Fedora 8 isn't always straightforward.
Doing a re-install also has the advantage of discarding the junk that slowly accumulates over upgrades.
This is where using a system that has a decent package management structure is much more useful, though. (We run 99% of our software on debian systems, some of our customers run RHEL so we also test on CentOS 4 and 5 systems - both of which we have "laying about" and we try as far as possible to keep to packaged software or create our own packages in most cases. Being able to ask the package management system where xyz is installed is a god send for a lot of situations. -- Brett Parker
participants (7)
-
Adam Bower -
Brett Parker -
Chris G -
David Reynolds -
Jonathan McDowell -
Paul -
Wayne Stallwood