OAS. It’s not great.

April 16th, 2008 by jang

And by default it’s worse than that. Lesson is, if you want it configuring, do it yourself.

Personally, I don’t want it configuring, so it can sit and rot. Fuggit.

Deployment work, up and coming.

April 10th, 2008 by jang

I’ve just physically plumbed in to the deployment & management network two new boxes, spam3 & spam4. These will be targeted by an MBS instance for deploying SpamAssassin (& co) configurations onto.

There’s finally a light at the end of the tunnel with the filestore work. Once the HBAs turn up I’ll be putting a new NFS server in place. This impacts on the appinf work in two major ways:
Read the rest of this entry »

Post-Easter catch up.

March 26th, 2008 by jang

Well, that’s been a busy day. New SataBeasts arrived, they’ll be installed not a moment too soon.

I’ve rebuilt the first NFS node (munter) and captured the rest of the configuration alterations. Getting it all down in a series of Makefiles has certainly paid off.

There’s news on alternative machine rooms; so now at least we have something to aim at.

python expect, pexpect, from inside solaris cron

March 19th, 2008 by jang

Small issue: solaris cron doesn’t set up much of an environment, and /dev/tty won’t show up.
Read the rest of this entry »

Why Solaris isn’t always my favourite operating system.

March 18th, 2008 by jang

So, we’re on day two now and I’m about at the point where I have a working software stack that’ll let me start to build heartbeat.

This is not productivity.

Productivity is typing apt-get install heartbeat and, 20 seconds later, worrying about the configuration.

OpenSolaris is promising better things with package management. 15 years too late, perhaps, but thank Christ.

Plans for the coming month or two

March 13th, 2008 by jang

Having been off for most of the week with a stinking head-cold has let me take a step back and figure out what I need to be doing over the next six weeks:
Read the rest of this entry »

Update: NFS multilevel service progress via trusted extensions. Or rather, lack of it.

March 7th, 2008 by jang

I can’t even tell from the docs if I should expect TSOL NFS to do what I’m after - irritating when reading the source is actually looking like a faster way to find out the answers. Certainly I’m unimpressed thus far with the multilievel stuff. Bah.

Solved: should read the SB docs more closely

March 5th, 2008 by jang

OK, now I know why this isn’t working. Basically any array (Nexsan speak for Raid Group) is owned by only one controller at once - and its LUNs are only delivered via a single controller.

If we’d used QLE2462s and dual-attached the X4100 then we’d see multiple paths to LUN20, but they’d all go via SB c0. If the array is failed over to SB c1 then they’d show up there instead.

What I now need to do is to set up MPxIO, configure the first paths to the LUN, then try administratively failing its owning array over to the other controller. It remains to be seen whether this will “just work” or whether I need to further configure MPxIO to know that both results are basically one and the same thing (or even if that’s actually possible).

In any regard, this is looking very good.

At the other end of the problem, we installed the trusted extensions to Solaris which appear to permit multiple NFS views. We’ll confirm or deny this shortly. TSOL is a bit of a pain to configure - hopefully we can keep the setup requirement to a minimum - if Solaris 10 grows zonable NFS service (or I build a userland NFS server which I can configure myself) this might become more straightforward.

More SATABeast multipathing…

March 4th, 2008 by jang

Zoning changes get picked up properly…
Read the rest of this entry »

Bugger, it “Just Works”

March 3rd, 2008 by jang

Due to the unfortunate ability of the SATABeast to receive and process requests on all four controllers, failing the NFS array over to the second controller makes no discernible difference to the host: it can still talk to c0, alas.

So the only way we’re going to test this is with some brutal combination of FC zone modification and/or controller shutdown.