> [cgi-bin in /var/www/cgi-bin?] > > > The more I think about it, the more I disagree. The /var hierarchy > > seems to be for variable data. Logs, databases, and intermediate data > > belong because the files are variable as are your examples. HTML and > > its brethren are static in the same sense as config files are. They may > > be modified, but it's not automatic. A person does it, not the machine. I also disagree with putting critical data in /var. This is a "how do you want to design it" issue. Different people will look at the problem differently and design it differently. There are many ways and most will be preference based upon a grander scheme. Here is mine. For me /var is machine generated. If it dies I don't care about restoring it. I don't back up /var. But if you put your web data there then suddenly you care about the content there and will need to back that up. In my methodology that is bad. I never put anything under /var that I care about enough to need to backup. I can regenerate /var by reflashing a new system. /var is therefore a bad place for critical data such as a web server root. > /var/www is ok for the html, as the purpose of the separation between > /var and /usr is (as far as I understand it) to allow /usr to be mounted > read only. html is static, but I think modified frequently enough that > you don't want to have to remount /usr every time. Close to the point. /usr/lib should be read only. But /usr/ in general does not need to be. You can mount /usr/share and /usr/lib readonly while having a locally writable /usr/local. And if you were for some reason mounting your html data in /usr/lib/htdocs on a bunch of clients then it is okay to change it daily. You would be changing it from designated master and not from the clients. From the clients it should be a read only copy of the master data. But you can change the master data centrally. That is the hole point of sharing that. > cgi scripts? I'm not sure myself. /usr/lib is the right place for > pre-packaged stuff, so /usr/local/cgi-bin would be ok for self-added > stuff. > > Personally (for ease of backup, mainly) I've always created a 'web' user > and put everything in /home/web/htdocs and /home/web/cgi-bin. This makes I agree totally. I always back up /usr/local and /home. So either of those two places are great places for generated content that you want to retrieve in the case of catastrophe. Disks will die at the most inopportune moment. Prepare for it. In a total collapse reflash the system and restore /home and /usr/local and you are probably mostly done with your recovery. But if you have to pick and choose files out of the system directories it will be much harder. Now if I had a series of web servers all identical in a load balanced configuration where I was recreating them with systemimager then I don't care about retrieving the content individually. I would just re-image them. In that case I would probably say that the copies of the data could live just fine under /var since the entire system is a commodit. But the master side of the data would be in systemimager instead which means that /var still is disposable. This is more of an industrial grade solution, obviously, but it points out another grand scheme of methodology to meet the needs. I would also recommend that all of your data get checked into CVS or some such. It is a good idea to use a configuration management system like CVS regardless of your backup scheme. It can save you from your own errors as well as from the wily cracker. Just my 2 cents. Bob
Attachment:
pgpjaVS4xtj7f.pgp
Description: PGP signature