Recently in Unix Category

It's customary for Solaris admins to slag off the patch system, so I guess I'll have a go. For the sake of full disclosure: I used to be part of the 1st / 2nd line support team that does global support for smpatch / Sun Update Connection / Update Connection Enterprise. If you raised a Sun case on these products between November 2005 and April 2007, you very probably spoke to me at some point. That said, most of what I have to say is based on my experience working with Solaris, rather than supporting it...

smpatch is broken, but you already know that.
The dependency tree required for a working smpatch install is vast - so vast that Sun won't (didn't?) support anything less than a full end-user (SUNWCuser) install cluster for smpatch. Put together a minimal install for a boundary system and want to patch it? Get yo' Recommended Cluster on, dawg.
Any kind of slow-ish or intermittent Internet connection, and you'll have to supervise patch downloads, lest the 'Error: null' beast be awoken from its slumber (just re-run the 'smpatch download' - you'll usually get at least one more patch down before it errors out again). This is typical of the error messages from smpatch - largely useless, mostly misleading, occasionally deceitful.
Circular dependency in your smpatch database (recent kernel/zones patches, for example)? Ha ha haaaa, sucks to be you. smpatch can't figure it out, so you'll just get a load of patchadd failures during the smpatch run and subsequent shutdown. Re-running smpatch won't work, so don't bother. Time to hit SunSolve and work backwards down the dependency tree manually. You'd better hope SunSolve's feeling perky (gateway timeout anyone? Yeah, thought so), 'cause you're going to be there for a long time.

sconadm is as broken as smpatch, but with the added advantage of weird database issues at the Sun side which may stop you registering anything on your support contract. "Registration failed!" it will challenge. "What the fuck?" you will retort. Do not attempt to debug sconadm issues - your sanity is more valuable than your pride. Call Sun and get hold of SWUP_SUPPORT - they'll give you a script to run that will detail all the packages and patches missing from your system, including a Java update you can't install because your Oracle instance depends on a particular JDK version. But maybe that's just me.

Update Connection Proxy? Don't put yourself through the agony.

The enlightened (with similarly enlightened management) among us use PCA and avoid the smpatch/sconadm brain damage. I heartily recommend that you do too.
Giggle as your patches download without error. Rejoice in the HTML patch list output, with links to the READMEs for each patch. Bask in the glory of the caching PCA proxy.
Unfortunately though, the horror runs much deeper than just the automated patch tools...

The way patches are rolled is insane. Any one patch can update several packages, all-but-one of which may not be installed on your host at the time of patching. What happens if you install one of those not-installed packages after patching? That's right. The patch tools see all your applied patches, so won't recommend any of them again despite the just-installed, unpatched package on your system. Cue headaches trying to work out why you just got pwn3d by 1337 |-|4x0rz despite apparently being patched up to the eyeballs.

On no other Unix (that I've ever worked on at least) does a kernel patch clobber your sendmail config. This is a result of the way the patches are rolled, as above. You were told during the patchadd operation that the sendmail config had been moved, but you weren't expecting what was allegedly a driver update to affect userland apps, and you don't have the time to review 1000 lines of smpatch output for each of 30 odd machines at the end of a 12 hour shift caused by smpatch failing. to. download. every. second. patch, so you missed it. Say goodbye to the free space in /var as the mail spool fills up over the next few days. Say goodbye to your email-based system monitoring.

Ah well, I suppose it's a living. Say hi to SWUP_SUPPORT for me next time you raise an smpatch case. There's also a pretty good blog by one of the PST team at Sun which goes some way to explaining the madness: Patch Corner. Not pretty, is it?

I've sorted out the account signups for this here blog, so you should be able to sign in / retrieve passwords etc. now. See below if you're really interested in what the problem was. The blog software has also been upgraded to the latest stable release, but it shouldn't make any difference from where you're sitting. Anyway, normal people can stop reading.... now.

(I'm posting this, because I've seen a number of people on forums who've had the same issue I did, and none of the threads were answered. Hopefully Google will pick this post up.)
The main problem with the signups was that the return address hadn't been specified in MT, so the emails weren't being sent out to external addresses. Unfortunately, MT doesn't appear to email errors to the admin, so I didn't know about this until Koof pointed out that he couldn't sign up. Once that was fixed I created a new account with my work address as the email address, but the email bounced off the Exchange server with a 500 error for an invalid Return-Path.

MT (on Linux at least) sends mail through the sendmail utility (Postfix in my case) as the webserver user, so it wasn't setting the envelope address sensibly. This meant that everything appeared to be coming from the (unresolvable) local-network hostname, which was correctly rejected as invalid by the remote side. To fix this you can set up Postfix to re-write the envelope headers by editing /etc/postfix/generic, and adding, e.g.:
webserveruser@localhostname.localdomain webmaster@example.com
Then add:
smtp_generic_maps = hash:/etc/postfix/generic
to /etc/postfix/main.cf if it's not already there, then run:
postmap /etc/postfix/generic
and
killall -HUP master
to make the changes stick. Once that's done, mail from the webserver user will appear to come from webmaster@example.com and all should be well.

So I was on Digg the other day, and I heard that Movable Type is going Open Source, so I downloaded it (and installed Apache and MySQL) and I'm playing about with it on my desktop machine. It's pretty impressive; both in how easy it is to set up, and what it can do.
I'm thinking, therefore, about using it in place of the venerable HTML hack-up you see before you.
All I need to do is find a style that's not yet another "Web2.0 - paster-colours - drop-shadow - gray-on-white-text - ground-reflections etc." look that I'm becoming really fucking sick of seeing all over the place. You know what I'm talking about.

Update: Sod it. The 'Minimalist Grey' style looks pretty good, so that's what I'm going to use. Gray on gray text or no.

Unfortunately I'm forced to use a Windows machine as my desktop box at work. This causes me pain. Things that would be a two minute job (like burning ISO images to DVD) take an age, and require the installation of third party software. I miss select-to-copy and middle-click-paste. Creating Word documents isn't scriptable. Applications put user data on the C: drive. It's a mess.
I have lessened the pain somewhat with the use of some choice apps:
- Dexpot (virtual desktops and hotkey desktop switching).
- WinKey (key bindings to launch apps).
- X-Win32 (X server).
- Cygwin (BASH and various Unix tools).
After installing all that crap, Windows is just about usable. I can Ctrl-Tab between a fullscreen CDE session and a Windows desktop, and I can operate in a relatively mouse-less way most of the time.

On the upside though, I've had a chance to test that Java web server I was working on a while back (it's still not finished, but I intend to get back into it soon). I'm surprised to report that it works just fine on Windows with Sun's Java installed. I was expecting all kinds of hassle with path seperators etc, but it's all handled very gracefully. Nice.

So I'm watching The Antiques Roadshow one Sunday, while stuffing my face with delicious chicken, and there's a bit on Thomas Chippendale. Bear with me.
Basically, according to the old-stuff boffins at the afore mentioned Roadshow, he's only really famous because of one thing.
He released a book of drawings of his furniture.
Apparently, that's it. Don't get me wrong, he was a choice chippy, but the thing that made him the legend that he is, is his book.
Could this be the first example of successful Open Source in a modern(ish) commercial market? At the time his peers though he was utterly mental for releasing publicly, to anyone who cared to pick up his book, what would normally be considered trade secrets.
Sounds pretty familiar...

Yay! Fedora have packaged version 2.10.4 of lm_sensors, so I can (with the aid of a 2.6.22 series kernel) now see the CPU temperatures on my Mac Mini. On to some testing...
Loading each core with cpuburn-in, the temp on core 0 gets up to 80°C (that's 176°F, for those still in the dark ages) after a minute or so.
That's pretty hot.
The system fan (the only fan in the box) goes from a very leisurely 1500rpm to an almost as leisurely 2000rpm during this time, and the temp on core 0 stabilises at pretty much exactly 80°C. Core 1 only ever gets up to 65°C (149°F), though. Removing the load causes the temps to drop very fast.
I've updated the kernel .config for 2.6.22(.1) in case anyone's interested.

Just bought a Mac Mini. And do you know what I did with it?
I put Linux on it.
Well, first I replaced its hard drive with something more reliable, then I put Linux on it. It's now my mail and FTP server.
Why a Mac Mini? It's quiet, really wee, fast (once you get a decent hard drive in it) and it runs normal i386 Linux after some minor tweaking.

What do you think the record is for dead GBICs in one 16 port switch?
I'll start the bidding at 10. Damn you Cisco.

Maybe someone found a use for multiburn?
And maybe they 'got the jail' too.

Just for kicks, and something to do while changing phase the hard way from last week's night shifts, I put together a wee script to fade my desktop between two colours throughout the day. Have a look on scripts for all you could ever hope to find out.