Apologies for the downtime – I took it upon myself to upgrade this server to RHEL5.
The upgrade went pretty smoothly, taking about 6 hours – although that includes a lot of time copying files around. Some sites on this server aren’t back up yet, as I’m taking the opportunity to modernise a few bits of infrastructure here and there. Also, the media folder is completely missing for now – that will take a long time to copy back from my pathetic DSL.
My main reason for upgrading was difficulties I’d had installing various pieces of software – mostly pretty new stuff. Anyone who’s glanced at the CouchDB mailing list in the last few months will likely remember (with a groan) my epic struggle to get the thing working reliably on RHEL4 – that was a lot of hours splashed to the winds there. I’m delighted to be able to report that installation on this clean, modern server went without a hitch. I consider the time it’s taken me to reinstall “paid for” with that development alone.
Other changes include moving to nginx for Rails hosting, decommissioning SVN once and for all, moving to a new and more logical folder structure, revamping users and permissions, a coming public git repository, and other things I’d been wanting to do for a while but didn’t get round to because of the previous mess.
I’ll be renewing my efforts to hew strictly to RPM-installed packages on this OS. Some source installations are inevitable – Ruby and Erlang, for example, are quite old on the default system/package repo so they have to be installed from source. But everything else I’ll be endeavouring to keep as clean as possible for as long as possible – I want absolutely no repeat of the fucking debacle the js/spidermonkey CouchDB prerequisite install turned into.
In-place upgrades are not my usual cup of tea – I’ve made an exception this time because the hardware is still pretty decent, there were no immediately obvious gains in value to be had upgrading that, and I literally couldn’t do what I wanted to with the previous OS. A hardware upgrade is on the cards, however, and in anticipation of that I’ve kept my most detailed install notes ever – literally every command. What took me 6 or so hours (and counting) should take 1 or 2 next time.
Onwards and upwards, then ..
June 11th, 2008 at 8:12 pm
Ruby’s not _that_ old on RHEL 5.1. What is the default Ruby installation lacking that you need? I haven’t touched mine.
June 11th, 2008 at 8:45 pm
It’s not *that* old, but it’s two versions behind now – August 2006. I hadn’t heard of too many problems, but I knew there were some – yours included – so saw no reason not to update. I actually feel RH is being too conservative with Ruby; there’s no reason for them to not have included 1.8.6 yet. If they had I wouldn’t have messed with it.
However, it was a bad idea to go to 1.8.7 so quickly, I’ve had problems with it (see above post). Despite knowing it was backporting some work from 1.9.0, I mistakenly believed ruby-lang’s promise that it is “stable” – it is not, obviously, and has problems waiting to be worked out in 1.8.7-2. I will, ironically, be waiting for that to all be ironed out before moving my dev environment to 1.8.7 – not exactly the usual order in which I do things.
I think my priorities are a little different from yours – I have no problem departing from RH’s guaranteed system where necessary. I try to use it as much as possible but that’s just for convenience, security and long-term maintainability. That said, I’ve kept my number of custom installs on this system down to four, which is an unprecedentedly low number for me, and a trend I’d like to maintain : )
As mentioned in the post, too, I’ve used this upgrade to meticulously document the entire build process for the RHEL5 environment I prefer, something I’ve been somewhat remiss in doing in the past. I am fairly confident I can rebuild clean from script in an hour or two now, which gives me a little more confidence in being more aggressive in installations. I might start testing my scripts for a “perfect” install in VMs soon : )
I don’t like feeling like I’m “moving into a house” when I change server – making critical decisions that will affect me for years. I’d like to quickly set up the stuff I need, in the versions and configuration I prefer, with the knowledge that I can change and redeploy whenever I like. I want to get that process down to something I can do when I need, without having to worry about upsetting my precarious house of cards. Probably using Vlad, which I now prefer to capistrano. Well, still working on that, but at least I have the raw material for RHEL5 now : )
June 12th, 2008 at 1:56 am
Ah, yeah, about Thin. Yeah, I did submit a patch to it. But as you know, I never ended up deploying it because it had random, erratic unit test failures on every single different platform I tried it on (and various Ruby versions). I have no idea whether those problems ever got fixed but they were such basic issues that I had to discard Thin as a contender — it was really a non-starter — and never looked at it again.
In any case, my “problem” with Ruby 1.8.5 wasn’t really a problem at all, but a problem with Thin. I’ve had no actual problems at all with 1.8.5.
But where’s the necessity? My question was, “What is the default Ruby installation lacking that you need?” and I don’t think you’ve answered that.
June 12th, 2008 at 2:09 am
One other comment I should add here is that I am anticipating that the upgrade-obsessed Rails community will no doubt be breaking 1.8.x compatibility as soon as 1.9/2.0 gets out the door. That might just force my hand. Not looking forward to that.
June 12th, 2008 at 2:10 am
Fair enough. It isn’t really lacking anything, except in my mind it was “old”. I’m used to seeing 1.8.6, and didn’t like seeing 1.8.5, but there wasn’t actually any specific failure – probably an unnecessary upgrade, as you point out. Ah well.
Speaking of thin, on a lark I just cloned it and ran the tests myself. Failed, lol. And the thing doesn’t work at all on 1.9.0, despite claiming compatibility – I don’t think I’ll be adopting that anytime soon.
Needless to say I’m still running Mongrel. I don’t have much love for it, but at least it works.
June 12th, 2008 at 2:32 am
Funny you mentioned that. The last bug blocking Rails from 1.9.0 was actually fixed about a week ago – a new snapshot of 1.9.0 is due out soon (1.9.0s2) and it will be the first tagged release capable of running Rails. The framework itself, anyway, precious little else works.
After that happens, I expect the rate of adoption to be roughly proportionate to the actual speed gain 1.9 will bring – something I’ve actually been attempting to test, with little success so far since no proper servers work yet.
You’re right, though, I do expect that once 1.9 catches on the community will move over quickly. There’s some major changes in 1.9 which could make supporting both inconvenient. Happily, though, Rails is pretty damn feature complete by now, so it’s not like everything will just suddenly stop working if they do decide to switch – you’d have plenty of time. The real problem would be gems, whose authors are (even) less concerned with appearing professional than the Rails team.
Can’t see them switching to 1.9 before the end of this year, but could definitely be on the cards in 12 months’ time. Let’s see what the actual performance gain is – that’s what will light a fire under any migration effort.
June 12th, 2008 at 6:32 am
While I fully expect them to make Rails compatible with 1.9/2.0, thus opening up the way for better performance to anyone who cares to make the switch, I am talking about them breaking compatibility with 1.8.x and requiring users to upgrade their Ruby installations.
For the latter I see no real justification. Ruby 1.8.x works, it’s basically bug-free, and there is no compelling feature in 1.9/2.0 that would force a framework to require it. Nevertheless, I am predicting that if there’s any community that will jump at the chance to force an upgrade on its users, it will be the Rails core team. Very irritating and not at all the attitude I would hope to see in a framework vendor, but sadly it is exactly what I am anticipating.
You yourself wrote about the phenomenon in your Maglev piece.
June 13th, 2008 at 10:29 am
RHEL5? RPMs… Ewww, gross.
June 14th, 2008 at 12:20 am
Jonny:
I actually thought seriously about going back to Debian in this move. I do feel a bit more comfortable in a debian environment.
But .. I like the stability and “standard-ness” of RH, and I’m interested in doing more with their VM system. Also, a constant worry of mine with debian-style is that I might be missing some urgent security issue, and I simply don’t have time to keep on top of that kind of stuff the way I should. RH is pretty damn trustworthy in this department so I get a lot of peace of mind by relying on them to worry about urgent updates.
I’m pretty glad to see the back of up2date, though, I must admit. Yum is way, way better.
I do sometimes get annoyed with the lack of range in RPMs and RH’s general conservatism but most of the time I like it. When they finally do include something you know that it’s just going to work and you won’t have any problems. Although repos like EPEL and Dag aren’t run by RH, that conservatism carries over a lot more than in the debian world, IMO.
Just a matter of taste I guess. I actually run some business stuff off this server, so that’s my main reason for using RH. If it was just my plaything I’d probably go with debian, which is what I ran prior to this server : )
They all have pluses and minuses. I’ve got experience with RH, debian, solaris, freebsd and even OSX Server .. I have difficulty even saying which one is “best” because they all have their good points, and how they’re delivered is just a matter of opinion really. These days I probably would choose linux over the BSDs for a server but I couldn’t argue passionately one way or the other. Except, of course, that Windows sucks : )
June 15th, 2008 at 10:01 am
Yeah, fair enough. My first ever experience of Linux was actually RH, so I do have some degree of nostalgia for them.
I’m sure I don’t have to sell you on the stability of Debian, so I won’t try. Security… Yeah there was that one issue recently with SSH keys… But that was fixed very quickly, like within hours I think. (and that’s been the only major issue for a long time). In the end, from the sound of it though, it seems like you’ve got your set up all how you like it on RH, and that counts for a lot I think. If it ‘aint broke, don’t fix it, and all that.
VMs aren’t something I have done much experimentation with.
For me though, after getting used to the Debian package management system, I just can’t go back.
June 15th, 2008 at 10:48 pm
I think it’s very much a case of “horses for courses”. I’d never use Red Hat on a desktop machine but I consider it ideal for a server. I basically want to set up a server once and then just have it work indefinitely, kind of like plugging in a fridge. But the desktop is more of a playground, much more volatile, and I would almost certainly go with a distro like Debian.
June 16th, 2008 at 4:12 pm
Wincent: You have a knack for saying exactly what I’m thinking, but in 1/5 the words it takes me…
Back on the topic of Ruby, I got fed up with problems I’d had and reverted to 1.8.6-p114. I am not very impressed that there are so many breaking changes between 1.8.6 and 1.8.7, and needless to say I don’t recommend moving until you are certain the software you need runs flawlessly.
I understand that Ruby 1.9/2.0 is going to have backwards compatible elements, and that is fine – most of the changes I’ve seen are indeed improvements and I’m happy to learn them. But why the hell are they bringing these backwards-incompatible changes into 1.8? If they’re going to make breaking changes, they should do it in 1.9 – else what’s the point of the 1.8 branch at all?
1.8.7 is the official recommended stable version of Ruby now – in fact, you’ll have to look fairly hard to even find a tarball of 1.8.6 (I had to look through the ftp server manually). Many common applications and gems have difficulties or won’t run at all on 1.8.7. Not at good situation at all.