The Intel Announcement

So Sun and Intel have announced a deeper relationship, partnership, call it what you will. Jonathan Schwartz’s blog posting (the URL curiously ends “but_we_did_not_hug”!) mentions a couple of positive aspects, such as the engineering collaboration to come on the server side, but doesn’t talk much about the lower-end stuff that ought to be interesting to lots of us.

We should be able to look forward to better power management, proper WiFi drivers, and hopefully better drivers for the integrated Intel video chips. Some of those graphics drivers are already around in Nevada, which is cool. This ought to make it easier to get Solaris booting on Macs too, maybe bringing the era of Acer Ferrari laptops at Sun to an end.

I see Ben Rockwood’s not too positive about it, which puzzles me. Are there really “fans” of one processor line over another (compatible) processor line? You could understand SPARC vs PA-RISC or something, but an x86 chip vs … another x86 chip? Wierd. It is clear that Intel are currently able to build faster CPUs than AMD, and I see no problem with going with Intel to get those.

But what’s with the odd statement that Intel’s agreed to OEM Solaris itself? Intel doesn’t OEM any OS, even ones from Redmond, so this seems a bit strange.

The associated slides are interesting. Apart from the mega disclaimer on the first slide (stylish – not) there’s a chart of the number of Solaris users (or downloads? it isn’t clear) on UltraSPARC vs x86.

Positive article at The Register

The Register has published a surprisingly positive article on Solaris and OpenSolaris, managing to debunk most of the “Slowaris”-style myths.

Well done the Reg.

Patching

Sun’s patching tool – smpatch – leaves a lot to be desired. It is written in Java, so is horribly clunky and slow. That would be just about forgivable if it was reliable, but it isn’t. Sun Studio patches simply don’t apply because they have to be added to the global zone via the -G flag, and smpatch can’t do that.

That’s when you grab a copy of Martin Paul’s wonderful Patch Check Advanced, aka PCA. It is a perl script that does the same job as smpatch except:

• it works
• it is nice and lightweight
• it handles Sun Studio patches nicely
• it works when smpatch doesn’t

The last point is a good one – I updated to Solaris 10 11/06 last year, and that caused showrev -p to start dumping core. That completely broke smpatch and PCA. There’s no sign of a fix from Sun, but Martin tweaked PCA and we’re back up and running again. Thanks Martin!

“Because you can…”

Sorry for not publishing anything for a bit! Let’s get active again…

Last week’s LOSUG meeting demonstrated a neat, albeit probably non-useful, trick.

They were showing the new iSCSI initiator (i.e. server) code in OpenSolaris, which works with the latest iSCSI target (i.e. client) code in Windows. So they created a 100MB disk for iSCSI from a backing file, connected to it from Windows, formatted it there as FAT, wrote to it, etc etc.

It all Just Worked. The new iSCSI admin tools look easy to use, and were modelled a bit on the ZFS tools.

Anyway then Frank, one of the filesystem guys, went and found the backing file on the Solaris laptop, took a quick look at it with mdb and then mounted it over loopback on Solaris! I think he tricked lofiadm into starting at some offset into the file, as there’s presumably some sort of header at the start of the backing file.

To prove it wasn’t a cheat, he edited a file on it using vi. Switched over to Windows, did the equivalent of disabling and reenabling the disk, and voila the edits were there on Windows.

It’d be fun to set up a ZFS pool from a backing file stored on an iSCSI-attached disk, and then mount a filesystem from that pool back on the iSCSI target. Fun, but sick!

Why no ZFS?

According to Andy Tucker, Sun are distributing pre-built Solaris appliances for VMware. Great! I was annoyed that there were hardly any Solaris ones at VMware.

But what’s this? Only Update 1? We’re nearly at Update 3 already, and by missing out Update 2 you’re missing out on ZFS, one of the crown jewels of Solaris 10. What were they thinking?

So at the moment what you should do is download another VMware appliance (any other OS) and use that to install Solaris from a DVD image.

SMF Intro

Ben Rockwood’s back and posting furiously! He’s written a good intro to SMF in his latest post which is well worth a read.

Step 1 Complete

Clearly I managed to fax the right side of the paper to Sun, because they’ve given me a “Sun Contributor Number”. That means I am now able to submit patches!

Contributing to OpenSolaris, Step 1

OK, so I previously wrote about contributing code/fixes to OpenSolaris.

I’m starting to put my money where my mouth is…

Step 1 is to sign over copyright to anything I do, by completing a Sun Contributor Agreement.

I’ve faxed it off. I’ll keep you posted when I get a response.

FMA

I managed to make it to last week’s LOSUG meeting about FMA, which I mentioned earlier.

The turn-out wasn’t so big as before, but hey, more free beer and nibbles for everyone else!

Currently it seems that FMA isn’t entirely integrated with SMF, so I was half-right and half-wrong before. The real disappointment for me is that it barely supports AMD boxes and it has zero support for Intel boxes. That mostly seems to be due to deficiencies in AMD and Intel.

But on recent SPARC boxes – wow, it can do some incredibly neat things! Gavin Maltby, the presenter, gave a demo of injecting a particular kind of memory fault. He then used (I think) fmdump to see exactly what the system thought had gone wrong. And the system had accurately identified the problem and narrowed it down to happening with one particular CPU, and offlined it for safety. That’s the self-healing bit, I guess.

The “predictive” bit is that they can monitor bits of hardware over time and by watching the voltage load (say) for a given part someone can tell that part’s going to fail in a week’s time (or whatever). Very cool.

Some of this code isn’t in OpenSolaris. Most of it is, but apparently Sun is cautious about revealing fixes for processor errata that haven’t themselves been made public. Allegedly these fixes are in OpenSolaris, but obfuscated in some way.

Solaris’s LDAP is Hard Work

A while ago we switched from using YPNIS to LDAP to handle all the authentication and name service lookups on our company LAN. It was fairly easy to set up a Linux network client, but quite hard to set up a Solaris network client. The server’s obviously Isode’s M-Vault running with its standard schema.

Here’s what I had to do to get a Solaris client working.

We allow general name service queries (what group is xxx in, what’s the username for uid 123) over plain LDAP. But we only allow authentication using LDAP over TLS. This gives us better security than NIS.

Sun’s LDAP libraries look for certificates and keys in two database files called cert7.db and key3.db. We need to make sure the LDAP server’s SSL certificate (actually the CA’s certificate) is in cert7.db. Start by downloading and installing Sun’s Directory Server Resource Kit because (sigh) the certutil tool you need to build these files isn’t part of Solaris. I installed it into /opt/dsrk52. Now run certutil:

# LD_LIBRARY_PATH=/opt/dsrk52/lib:/opt/dsrk52/lib/nss/lib
# export LD_LIBRARY_PATH
# /opt/dsrk52/lib/nss/bin/certutil –A –n "Isode CA" -t "TCu,Cu,Tuw" \\
  -d /tmp –i ~/ca.crt

That magic means create the two files in /tmp, and trust the issuer of that certificate. Now test those files:

# /usr/bin/ldapsearch –h ldap.isode.com –Z –b "" -s base –P /tmp \\
  "(objectclass=*)"

The -Z flag means use LDAPS, that is, LDAP over SSL/TLS on port 636.

Now that works, we’re ready to start configuring the machine as an LDAP client. For your first attempt, do this in a Solaris zone, as errors could otherwise lock you out of your machine…

In your zone, set up /etc/nsswitch.ldap to use “files ldap” for most things, and “files dns” for hosts. Copy those two database files into /var/ldap and chmod them to 0444.

Now set up a script in the zone’s root called /initldap as follows:

ldapclient -v manual \\
  -a defaultServerList=ldap.isode.com \\
  -a defaultSearchBase=ou=System,o=Isode \\
  -a serviceSearchDescriptor=passwd:ou=Staff,o=Isode \\
  -a serviceSearchDescriptor=group:ou=Group, \\
  -a authenticationMethod=simple \\
  -a serviceAuthenticationMethod=pam_ldap:tls:simple \\
  -a proxyDN=cn=Dummy,ou=System,o=Isode \\
  -a proxyPassword=dummy

Yikes! Let’s take it apart and see what it is doing.

First, it is initializing the client manually. Automatic initializations rely on some proprietary Sun schema, so won’t work.

Next, we set the address of the LDAP server. Note as we’re going to use SSL the name here has to match the name in the server’s certificate. Note also that this means we can’t use LDAP to look up host names…

Third, we generally start our searches at <ou=System,o=Isode>, except (the next line) for passwd-type searches we search our white page entries in <ou=Staff,o=Isode> instead, and (the next line) for group-type searches we search <ou=Group,ou=System,o=Isode>. Sun has its own idea of where to look for passwd and group information that don’t match the way our directory’s set up, so this overrides things.

Next, we generally authenticate with simple authentication. Except (the next line) the pam_ldap service uses simple authentication over TLS.

The last two lines are to get around some bugs in the ldapclient command. The name and password don’t get used.

Now just run the script.

If all goes well you can use id(1m) to query the name service.

Now get PAM configured up. Edit /etc/pam.conf so that everywhere you seen a line like:

service auth    required        pam_unix_auth.so.1

Replace it with the following 2 lines:

service auth    binding         pam_unix_auth.so.1 server_policy
service auth    required        pam_ldap.so.1 use_first_pass

Now you should be able to authenticate!