The Guru College

gurufoto.net

My new photoblog, Gurufoto, is now live. I will be deprecating the old pixelpost photoblog soon, as I have already moved all the posts and photos over to the new server, and will shortly begin redirecting all traffic to the new photoblog.

It’s also a time to give a shout out to A Small Orange, my new hosting providers. Good prices, excellent features, and unparalleled customer support. Unlike my complaints about 1and1, the ASO crew seems to know what they are doing, and even have intelligent people manning the support queues at 11:00 PM, which is the only time I’m able to work on my side projects. So, for the ASO Team: YOU GUYS ROCK!

Anyway, please return to your regularly scheduled programming.

SMS responses for nagios commands

With the recent upgrade to the MultiModem GPRS SMS radios for the nagios boxes at work came a new, feature I wasn’t expecting: the ability to easily receive SMS messages sent to the phone line. Even better yet, the messages are automatically stored in a mysql table, allowing simple programatic access to them.

Here is the plan – if a message about a host has been sent to an administrator’s mobile phone via SMS, the admin is able to respond with an SMS for the next 10 minutes. They name the host and the actions they want taken: recheck, maint, unmaint. These commands are then sent to the nagios command buffer where they will be executed as if the web interface had been used. For security, the daemon only listens for messages from the numbers it has sent messages to, and further, it only allows action to be taken on hosts it has sent alerts about. If you can think of any glaring security concerns with this, let me know, but I’m pretty sure that by keeping it simple, it’s not going to be open to abuse.

Honestly the hardest part of this was writing the perl script to properly daemonize, listen for sigkill / sigterm, and make sure the database connections are dropped cleanly when exiting in a controlled manner. There was one other small gotcha, for people looking to write their own 90 line perl daemon: gnokii-smsd records the country code on messages in the inbox, but does not require it for messages being sent (+9195550199 in the inbox, but 9195550199 in the outbox), so there is a minor bit of trickiness to validate and then compare the two sets of messages.

Lion FTW

Despite my better judgement, I went ahead and upgraded to Mac OS X 10.7 Lion yesterday morning, about 30 minutes after it became available on the Mac App Store. While it was installing, I read John Siracusa’s amazingly in-depth review on ArsTechnica. While I agree with most of the criticisms, especially about the lack of retention of spatial information in the Finder, I have to say that Lion has hit the ball out of the park. I’m totally comfortable with almost everything they are doing – most of it will make OS X easier to use and support – and make the OS get the hell out of my way when I’m trying to do something. I’m particularly enamored with the running program/process management pieces, where Lion will silently quit unused applications (that support the state-saving magic) and relaunch them when they are requested again, as well as *not* quit applications when there is a glut of available resources. For most users, this will mean a better experience with the OS and with applications, and it will serve as a pretty good carrot to get developers to support the new APIs and move into the future.

I ran into four gotchas when I upgraded:

  1. Lion disables support for older Kerberos ticket types. This breaks my employer’s AFS tokens. Add allow_weak_crypto = true to the [libdefaults] section, and single-des tickets work again
  2. AFS 1.4.x, which I was running, doesn’t work well with Lion, even after Kerberos is fixed. Upgrade to the Lion build of OpenAFS 1.6pre7, and you’re golden.
  3. TimeMachine over SMB has broken for me, and I haven’t been able to get netatalk 2.1.5 to work with Lion yet.
  4. The globalSAN iSCSI Initiator has some issues – while it will let me mount Solaris 11 iSCSI volumes, I can’t reboot without kernel panics and it seems to destroy battery/sleep management. Uninstalled for now, as I don’t need it on my laptop.

That’s it so far. I’ll post more as I run across issues and gems.

iSCSI and non-cluster filesystems

I broke the number one rule of non-cluster-aware filesystems Thursday night, and accidentally mounted the iSCSI volume that hosts my Aperture library on two systems at the same time, both of which were in read/write mode. The volume was only mounted for 15 seconds or so, but the damage was done: pages of error messages in Disk Utility, ending in “invalid thread count” and an error that the volume could not be repaired. Disk Warrior was also unable to do anything with the disk, reporting it damaged beyond repair.

I also broke the number one rule of using iSCSI on a Mac: my last backup of the volume, which holds my Aperture library (but not the raw images themselves) was on Monday, after I had finished importing all the pictures from Dov and Nikki’s wedding last week.

After a number of restarts of both the Mac and the Solaris box, and repeated runs with Disk Utility and fiddling with the globalSAN iSCSI initiator, I was able to mount the volume, even though I got a pile of error messages about “THIS VOLUME IS DAMAGED. BACK UP WHAT YOU CAN AND REFORMAT IT.” Rsync ran for a long time, and thankfully, pulled a working copy of my 103GB Aperture library back out of the burning wreckage. All 125,000 images files verified, and I was able to do an “Update metadata from master” for everything.

Yes, I’m making an extra set of regular backups now.

Google+

I don’t have a lot of time to write this post, as we’re leaving town in a little while for a week in Portland, OR and the wilderness around it. However, I’ve now used Google+, and I have to say: they got it right. It seems like Google has finally hit on a social media platform that people aren’t going to ignore. Only time will tell, of course, as every other social media platform they have tried has failed: notably Orkut and Buzz.

Google’s Product

Writing for earthweb.com in 2009, Mike Elgan made a very astute comment:

Who’s Google’s customer? You? Really? When’s the last time you paid Google for anything?

Not that it’s always a bad thing, but Google’s entire business model is based on selling information about you (what you like, what you search for, who you email, where you are, etc) to advertisers. Google makes some of the best internet-based products the world has ever seen, and they give most of them away for free. In reality, they are an advertising company that happens to have the world’s best internet company to sell their wares. Not a bad way to do it, really.

However, keep in mind that Google doesn’t make products for you to use. The information they harvest about you and 900 million of your closest friends is their product. Be careful what you willingly tell them, just as you are careful about everything that you post online ever, right?

Full disclaimer: My email domain lives on a Google Apps For My Domain account, as does my calendar and a bunch of other tools I use every day to get by in this digital life. And because of this, I can’t use the New Hotness, Google+, which has made me slightly bitter, as I’d like to see what they have to offer.

UPDATE: I’m in, and it’s actually pretty good.

Cheap Speedlights and Nikon Creative Lighting System

I have a pair of Nikon speedlights that use Nikon’s Creative Lighting System (CLS). Cannon shooters call this AWL, but it’s the same idea, which is remote control of a speed light via optical signals sent from another flash. This can be from another flash in the hot shoe on the camera, or from the built-in flash on the SLR body itself. It allows you to alter power settings on remote flashes without walking over to them, and it’s very handy for doing strobist work.

The trouble is the cheapest CLS-enabled speedlight Nikon sells is the SB-700, at $329.00 USD. The older, less powerful, less feature-rich and discontinued SB-600 still sells for $250 when you find a deal on one at KEH. Private party sales (forums, ebay, craigslist) can run as low as $200 or so. This is still a lot of money for a flash Nikon stopped making years ago. If you are willing to step down, however, out of the realm of CLS control and rely on flashes that have decent optical slaves built in, you can get a new-in-box Yongnuo 560 (YN-560) for $65 if you look a little. The trouble with these is they are engineered down to a price. Some of the cost savings come from having a cheaper display on the back and lower power output from the name brand flashes, but some of the savings also come from the fact that they don’t really offer end-user support, the manuals aren’t… useful… and quality control has been reported by David Hobby (and many others) to be an issue.

However, at $65 each, you could get four of YN-560’s and still be just at the level of a single SB-600 from KEH. Statically speaking, you’re going to get a number of speedlights that work properly. My question, before ordering some, is “Will they work side-by-side with CLS flashes?”. We know the built in optical slaves should be able to suppress the TTL pre-flash, but how will it handle the CLS commander flashes? Most reviewers online are triggering them with RF transceivers, not optical slaves, and none of the ones I’ve seen triggering via optical are trying to also use CLS at the same time.

The answer is simple: if you use your CLS flashes in TTL mode and zero out the pop-up flash, so it’s not contributing to the exposure, you can run the YN-560 in “S2” all day long, and it works. Up and down the aperture and shutter speed range, every test I tried worked. However, trying to use “M” on the CLS channels never got the YN-560 to fire at the right time. Sadness.

The good news is there is an announced but unreleased flash that solves all these problems – the YN-565 supposedly does Canon and Nikon AWL/CLS in the same unit (even though the hot-shoe mounts are slightly different). No word on the price, however.

Newer Posts | Home | Older Posts