Tuesday, August 30, 2005

The great thing about standards...

You know the old chestnut: The great thing about standards is that there are so many to choose from.

Now SCSI is a great standard. The truth is that SCSI devices do interoperate
incredibly well. At that level, it's been a phenomenal success.

But SCSI really covers a lot of things. The thing that hit me recently was connectors and cables.

I remember old SCSI cables with DB50 and centronics connectors on. I don't remember using them much - they were being phased out when I started playing this game. Then came the small 50-pin connector. Then the HD68, and more recently the VHDCI connector. Did I forget anything?

And then of course there was original SCSI, fast SCSI, fast wide SCSI, FWD, ultraSCSI, and ultra320 SCSI. And single ended plus two variants of differential.

So it's not actually that easy, given a system and a device, to say whether they will in fact interoperate. And then you need to find the right cable. (And then is the cable rated for ultraSCSI speeds?)

Which has bothered me for a while, but recently came to the fore after a bad incident caused a system to fail. So I decide to move the disks from a Netra T1 to a V240 and run the services in a zone. Easy, right? Well, not quite. The T1 has a HD68 orifice as I recall, and I think the V240 has a VHDCI outlet on the back!

So I go for a rummage in the loft and find the right cable. I'll send that across to the machines, and hopefully will be able to set the zone up and have the service back operational later this week.

Monday, August 29, 2005

The good, the bad, and the ugly

Let's start with the good:

We've now got SMBIOS integrated into OpenSolaris. I think it's the systems administrator in me showing, but I find this really exciting!

Now the bad:

I know I don't work for a living at the moment, but still keep an eye on some systems for former colleagues. And one of them suffered a power cut recently. Not just any power cut either, by the sounds of it. I've already alluded to one of the problems, and I had to roll back the SMF repository on another machine, but worse was to come.

Basically, it fried a Netra T1. I managed to persuade it to power on from the lom prompt, but it immediately starts vomiting errors. No system, no ok prompt, just errors. Looks like it can't even run POST. This looks like a dead system to me, beyond hope of repair. That's bad.

And the ugly:

SJVN has been emitting more mindless drivel. I see two choices here - either he's genuinely incapable of understanding licensing, or he's got an axe to grind and is using his journalistic position as a veneer of respect.

The article - at least the snide part about Sun - is simply plain wrong. Using CDDL as the license for OpenSolaris doesn't give Sun control. Exactly the opposite: with CDDL as the license Sun have less control of what people can do with OpenSolaris than they would have had if they had used the GPL.

And as for failing to build a significant programming community, well for one thing they already have gotten a major community, and for another thing getting a handful of part-timers to build Solaris on the cheap was never the driving force - Sun spent a huge amount of cash on building Solaris, and open-sourcing it, and it was done for sound business reasons - such as to open up new markets - not to outsource development. (Or kill the penguin, or introduce submarine patents into Linux, or any of the other stupid reasons naysayers put forward.) Of course, once the open source plan became known, a huge bunch of use started clamouring to get involved so we can modify and improve Solaris in the ways that we want.

Saturday, August 27, 2005

Should I program to Tiger?

Simple question - when writing Java code, should I use the new features in Java 5.0, and thus not allow my code to work with older versions of Java?

There are, after all, some compelling reasons to do so.

In particular, I love Generics - I use Collections a lot, and being able to tell Java that the collection contains objects of a given (often fixed) type makes code so much cleaner. And again working with collections a lot, the enhanced for loop is a big win.

The question still remains - is backwards compatibility more important?

(I never found anything compelling in Java 1.4 to make breaking compatibility with 1.3 worthwhile, but the changes in 5.0 are a different matter.)

Thursday, August 25, 2005

NISminus

I'm a great fan of NIS+. Not only is it very easy to set up and use, it scales well and it's dead easy to manage the data stored in it.

(Much easier than old NIS or LDAP. Sun could be suicidal and ditch it, as they've been threatening too, but replacing it with dramatically inferior solutions like NIS or LDAP is going to make a lot of people miserable.)

Of course, it doesn't always work perfectly. I just had this one case where it stopped working. The server partially booted - the NISplus server was running and serving clients. It's just that the NISplus client on the server wasn't working. So lots of other things wouldn't work. Amongst others, the NFS server. So while I could log in to a client, I couldn't access any files. Bad!

(Some testing indicates an RPC authentication problem. But basically everything goes into the RPC black box and never comes back.)

The only thing I had done was to change the IP address of the server. And yes, I had run nisupdkeys -a to update the server's addresses. So my theory is that somewhere buried deep in the bowels of NISplus is some memory of the machine's old IP address, and I can't spot it right now.

(I managed to get it working again, but I'm not sure which of the half a dozen random kludges was the one that mattered.)

Back to JNI

While still thinking about how to make progress with jkstat - basically, how closely to align it with the existing libjkstat implementation - I started another quick project to use JNI to get at Solaris system information from Java.

And, again, programming in JNI is hard going. The real problem is that it's astonishingly easy to make a mistake. And then it falls over with SIGSEGV and cores on me. Even the stack trace isn't too informative - it tells me that it's gone wrong in the native code (usually when calling back to java). As if I didn't know that! Even knowing where it blew up isn't that much help - it never tells you why. So you have to fix by inspection, and it's not the most obvious syntax.

(For example, it was blowing up at one point. Eventually I realized that I had a typo in the class name, but there was no indication in the failure that that might be the case.)

So what's the application this time? It's a java interface to PICL (the Solaris Platform Information and Control Library). The first aim is to produce a graphical picl browser (like my kstat browser). The prtpicl command is useful, and you get the information with -v, but it's not at all easy to browse through the many pages of output that can result. The picl data is tree structured, so the arrangement used in kstatbrowser works quite well - a Java JTree in the left panel to display the tree structure, and the actual data in a panel on the right.


Give me a day or two to work through the JNI errors I keep making and some code might be ready to release.

Wednesday, August 03, 2005

Keeping Busy

Having finished the last job, I'm at home for a while.

Not entirely idle, though. We've been to a theme park, I've started to sign on, and I've been looking at an odd little NFS problem for some former colleagues.

I've also been going through my CD collection. No, not the musical one! The pile of Sun CDs for Solaris, Java, and all the other bits of software that Sun have made that I've got the media for. After all, how many copies of the StarOffice 5.2 CD do you need? I brought my whole stock home, and have managed to prune it quite considerably.

My next project is to skim through all the sysadmin books I've got, reminding myself of what it used to be like, and what obscure things I'm supposed to know all about but nobody in the 21st century actually uses any more.

(On the first page of the first book, it tells me the key responsibilities of a Systems Administrator. High up on the list is formatting floppy diskettes. Say what?)