Claus wrote:

I have the same setup running. Each apache instance runs chrooted under their own user id and home directory.


I realized after I sent that message that I left out a couple of details, like each instance also having its own user (www0-4). I leave the default www user and /var/www stuff pretty much untouched in case I need to look at something 'untainted' by my fingers. The normal install of the modules modifies those bits of course, which are later copied to the individual httpd homedirs as needed. I don't recall exactly what does and doesn't need copying, I have it all _very_ throughly documented kinda script-like so I can reproduce it quickly if need be, with my notes and copy/paste-able mass link / copy / etc commands.

The setup I had before that was more interesting as it only needed one IP. A main httpd instance was setup to do proxy for the individual httpd instances of each site. The main instance ran on port 80 with the real IP. The site instances ran on localhost with each their own port number and weren't accessible from outside of the machine. Logging, SSL and maintenance is a pain though.

I never tried the proxy method simply because I wanted all daemons to be autonomous. If something died, so be it (I should note it's never happened yet). Not to mention, I use a couple of the sites for development, so sometimes I have to kill an individual httpd{x} instance when I monkey with the config.

I have briefly considering moving from Apache to nginx, but haven't for a few reasons:

1) ATM, I don't need the performance of nginx vs. Apache, not by a long shot
2) I love the track record of OpenBSD's Apache. It's been fine for me for years. 3) just when I was peeking into nginx (stable) a security vuln popped up. I'm sure it's excellent, but *to me* it could mature, security-wise. (no flames please)
4) time to play with it all and get everything nicely together
5) simple philosophy: if it ain't broke, don't fix it.

When I have time, I need to figure out some automated solution to deal with the logs. I use cronolog for rotation with custom log file formats, and have plans to do some things with webalizer-type apps, but that's still on the back burner.

My interest is in using relayd to filter bad requests (again, back burner for now.) I have *not* done my homework on this yet, but when I farted around with it briefly a few days back, I ran into problems with the relayd config for SSL acceleration. Again, when I have time I'll look into it, but I was stumped and figured I'll make sure my RTFM-fu is strong before I post here about it. (Besides, isn't it somehow more satisfying to finally go *aha I fixed my mistake* without asking for help?)

I knew I wasn't the only one that realized (for many circumstances, I'm not saying _all_) that VM'ing a lot of services is just silly, but it's nice to hear from others also doing the multiple httpd thing with OpenBSD.

For Matthew Weigel:

Yes, there are a lot of httpd instances. I'm not entirely sure of how shared memory applies in this case (probably not), but on my web server my memory use is 129M/316M, and that includes a bunch of other daemons (eg. databases), when pretty much idle. It has plenty of room to grow, but if memory becomes an issue, I'll look harder into nginx. (I'd like to do it just for the knowledge, but again, time constraints.)

For the installation of everything into the chroot, I can't comment on non-Apache setups, but with Apache it loads that stuff before chrooting so only one installed version needs to be done, which makes life easier. The links (etc) still have to be done. It could easily be scripted, but I prefer to have my notes (with my big "don't forget" warnings) where I can just paste the commands. If your documentation (notes) are solid, you'll be fine, and I just played musical tables with the servers (new drives for both) using carp and another box a few months back with no probs. As long as your notes are thorough enough that a blind drunk moron could do it.. :)

Hope this isn't noise on the list.

--

-RSM

http://www.erratic.ca

Reply via email to