USSM tech request: Apache upgrade
DMZ · April 2, 2008 at 9:00 am · Filed Under Site information
We’re running Apache 1.3.x for our webserver. This is old. Capacity numbers I’ve seen show that Apache 2.2 would be way, way better for us. However, I’m worried (well, generally, about why 1.3 remains the most common Apache version used by FreeBSD servers), but also about hosing the site. If you’ve got the time and willingness to help work through the upgrade, well, by all means, hold your hand up now. The reward comes from not having a site outage.
Comments
10 Responses to “USSM tech request: Apache upgrade”
Leave a Reply
You must be logged in to post a comment.
Unfortunately, we don’t have a pre-production environment to run this stuff on.
Specifically, I’m worried about the pathing and config. What do you use for pathing when you run ./configure on an upgrade like this?
Right now it’s all standard: apache’s living in /usr/local/etc/apache, the binaries sit in /usr/local/sbin, and everything runs happily
Now if I read the 2.2 docs right, the default install path is /usr/local/apache2
Good times.
And, you know, I can’t turn root over to someone and have them pull this off for me.
It’s conventional to put the binaries under /usr/local/apache2/bin and /usr/local/apache2/sbin, so you can easily differentiate them from the apache 1.3 binaries — you can access them using full paths while you’re testing, and once you start to rely on 2.2, just list those two directories early in your $PATH environment variable.
Have you already been over config.layout, in the root of the apache 2 source directory? The bindir and sbindir settings there should help you avoid surprises.
I did:
prefix: /usr/local
exec_prefix: ${prefix}
bindir: ${exec_prefix}/bin
sbindir: ${exec_prefix}/sbin
I really think that if I just installed it it would work fine and I could test it and everything, but then I remember that the only time that thought ever pans out is when I’m upgrading WordPress.
That looks healthy. Run “make -n install” to get a listing of all the commands it will try to perform during a live installation. It’s a little opaque, but bring the output into a text editor and scan it for any paths to which it shouldn’t be writing. The main scenario you’re trying to avoid is one in which you didn’t configure with the layout that you thought you did.
“make -n install” doesn’t require root privileges, so it shouldn’t be run with sudo (or from the root account, if you’re the sort to live dangerously).
Apache 2 is in good shape; the rough edges in the installation process have been pretty well smoothed out. For maximum protection, if DF provides you with backup services, then coordinate the filesystem backup for a particular time, grab a database export before you begin, and you’ll have a safety net of last resort that will cost you no more than an hour or so to fully recover.
I don’t want to side-track the issue, but starting with FreeBSD 4, jails are provided, where you can setup virtual environments for, say, testing several Apache configurations/installations concurrently and safely. Both
ONLamp and
Wikipedia. It might be something to consider for the future, to ease these sorts of upgrades.
Sorry for the formatting/syntax issues in my last post. I meant to say that:
.
VMware is also a good tool for this kind of testing. I’m not a Windows guy, but I believe Virtual PC for Windows is free, and a quick googling suggests that it does allow installation of non-Windows OSs, which would amount to much the same thing.
If you’re looking to go virtual and use an MS product, both Virtual PC and Virtual Server are free as of last summer or so. Given a choice between the two products I’d suggest Virtual Server 2005 R2 SP1 (at least until Hyper-V on Longhorn is released). DMZ, send me email offline if you have any questions, I use VS daily for a variety of servers.
I don’t have any FreeBSD specific experience, but as long as you don’t accidentally smoosh any Apache1 files during the install, there shouldn’t be any reason you can’t have both running at the same time. Just configure Apache2 to “Listen” on an alternate port like 81 or 8080. Then you can install PHP into Apahce2 and test things out before making the switcharoo.
If you’re pressed for RAM you might want to limit the number of workers Apache2 can use while you’re testing things.