So I wanted to keep my PowerBook from automatically mounting the backup drive if I happen to have it connected, and went trowelling through macosxhints.com to see what I could dig up. I can’t remember my search terms, unfortunately, but I did find a link in a comment to a MacGeekery.com article explaining how to hide partitions or volumes and keep them from automatically mounting. Bingo! Exactly what I was looking for.

In my searching, though, I found a very useful article detailing the voodoo necessary to install Mac OS X with multiple partitions for the OS, /Applications, /Users and a seperate swap volume. If I ever get myself that Mac Mini I’d love to have and a copy of OS X Server, I’ll have to give that a try.

Finally, as I’m getting ready to go to bed, I’m scanning through my RSS feeds inNetNewsWire and found this article on TUAW pointing to this article on TidBITS explaining how to stop your PowerBook, iBook, MacBook or MacBook Pro from waking up from sleep when you open the lid. Score.

Three helpful tips in less than five minutes.

Well, as it turns out it was indeed Little Snitch’s handy “automatically deny after 60 seconds” setting that was keeping me from seeing what was going on with dashboardadvisoryd. Here, for your viewing pleasure, is the window that popped up for me. As you can see, it’s parent PID is 1, which is launchd, so it really is a periodic service fired off by launchd.

I’ve now added a permanent Deny rule to Little Snitch for this, as I don’t really approve of this check-in procedure by Apple to verify the widgets I’ve installed. Of course, now I really want to get a license of Little Snitch for my wife’s iBook…

I’ve been reading with some interest all the discussion online regarding Apple’s secret thrice-daily checkup with the mothership to determine if your Dashboard widgets match what Apple has published on it’s own site. I think a good part of this was kicked off by the “Apple Phones Home, Too” article on Daniel Jalkut’s Red Sweater Blog. At least, I’ve only noticed the other blog posts swirling around the ‘Net after reading his.

I am, however, a little confused, as I run a number of widgets on my Dashboard, but I find no running “dashboardadvisoryd” process running. I, too, run Little Snitch to try to keep an eye on what my computer is doing on the network, and I have not yet been asked what to do about “dashboardadvisoryd”. I even went so far as to explicitly delete all the rules in Little Snitch for the Dock, in case this “phone home” thing was running under the Dock’s name, but still, nothing.

Feeling left out, I decided to see if I really had updated my system. Yup, Software Update says I’m up to date, and About This Mac tells me I’m at 10.4.7. Okay, so this mystical daemon must be on the system somewhere. Dropping to a terminal window (I tend to prefer iTerm over Terminal), I broke out the trusty find command, which told me that yes, indeed, the daemon exists on my system. The only two files with “dashboardadvisoryd” in their names were:

/private/etc/mach_init.d/dashboardadvisoryd.plist
/System/Library/CoreServices/Dock.app/Contents/Resources/dashboardadvisoryd

So, does that mean my system is not phoning home to the Apple Mothership, or does this thing only run periodically (say, from cron or launchd?) Nobody I’ve read yet has really specified how it runs. Anyone know? Or has Apple disabled this in something else I installed via Software Update? (Yes, unlikely, I know.) I suppose one final option is that Little Snitch has been asking me about it, but I’ve not been around to answer it, so it happily defaults to denying the connection. Couldn’t find anything in the system logs from Little Snitch, so I’m not sure about this last theory.

UPDATE: Yes, I had Little Snitch set to automatically deny any connection request after 60 seconds. I’ve disabled this for now to see if I can catch this little daemon in the act.

I’ve been wanting, for a while now, to set up a FreeNX server on my linux box at home, and another on my linux box at work. I’d like to get both my home and work linux systems to the point where it doesn’t matter if I’m at the console or coming in over the network from my PowerBook and I get the same environment. It’s a laudable goal, in my opinion.

This is actually part of another project I’m undertaking at home, of setting up the free VMWare Server on my linux box to create virtual hosts. I’d like to create a virtual image for two Windows XP images (one for my wife and one for me, and yes, I have two XP licenses for this purpose.) I’m thinking at least one or two other virtual images for linux and some other experimentation I’d like to be doing. At any rate, I was figuring, if I can work out how to get FreeNX working, I can have my virtual Linux system make itself public via FreeNX, and each of the windows hosts available via RDP.

In short, I’m swinging very heavily into the “virtualization and remote access are good” camp. Because, well, it’s good. Having ready access to a stable host over low-bandwidth links and being able to disconnect and resume a work session without much in the way of hassle at all is really handy. Ask any sysadmin.

All that said, back to FreeNX. FreeNX is to Unix systems what Citrix MetaFrame is to Windows systems. Snappy, fast remote access to a full GUI desktop. NoMachine sells the Server in a variety of licensing packages, and the clients are available for free. I figured I’d play with FreeNX, since it’s a free re-implementation based on the GPL code that NoMachine released for their products. Basically, if I liked what I saw with FreeNX, I’d strongly consider paying for the commercial version if it’ll get me better support.

I’ve only just now found the proper links for good documentation on FreeNX, so it looks like I’ll have to make a report in the future about how it goes. In the meantime, I’m going to work on installing VMWare Server and cursing my current system install, which is never optimal.

Apple’s Boot Camp has been creating quite a flurry of online activity. Honestly, far more than it is probably worth, but since, hey, this is Apple allowing you to run Windows on a Macintosh, it’s easy to understand why everyone’s panties are in a twist.

In between dealing with the multitudinous wildfires we have at work, which I’m still not really wanting to talk about, I manage to surface for a few minutes each day to try, in vain, to catch up on my email and RSS subscriptions. With so much buzz about Boot Camp, I was waiting to hear from John Gruber, given his very well-formed thoughts, reasoning and opinions on matters. I didn’t have to wait long, as he’s just posted an article with his thoughts on Boot Camp.

Reading through, I found something I simply had to quote here:

Right now, it’s a dual-boot situation, which is obviously less than ideal. It’s not hard to imagine, though, that the version of Boot Camp Apple is building into the upcoming Mac OS X 10.5 (a.k.a. Leopard) will be a concurrent virtualization tool — i.e. that Windows (and perhaps any other PC OS) could be hosted within a running Mac OS X session, obviating the rather annoying need to reboot to switch between OSes.

Mac OS X as a host to multiple guest virtualized systems leveraging the hardware virtualization capabilities of the Intel Core CPUs, running guest operating systems at near to full hardware speeds. All running without having to sacrifice a working, productive session in Mac OS X just to run an app or session in another OS. From the very day of the announcement of the Intel switch by Apple last year, I have been fervently hoping for this as a capability, and if I tune my Reality Distortion Field Detector just so, I think I can hear Jobs saying that it’ll be true.

As someone that lives in several OS environments for a living (Mac OS X, Linux, Windows XP), such an announcement would pretty much seal the fact that I’m buying Apple for my personal systems pretty much forever. I drool in anticipation.

What do you think?

Yesterday, my boss and I were beating our heads against the wall trying to figure out just why cfengine was refusing to run properly on one system. We googled and googled some more, scanned through mailing lists, usenet posts, and all manner of debugging information, because the error message we got was so… Opaque.

# cfagent
cfengine:: Received signal 13 (SIGPIPE) while doing [lock.cfagent_conf.myhost.link._var_cfengine_bin_cfenvd__usr_sbin_cfenvd_136]
cfengine:: Logical start time Mon Mar 27 17:11:55 2006
cfengine:: This sub-task started really at Mon Mar 27 17:11:55 2006

As it turns out, after a couple hours of heading in the wrong direction, I came in to work this morning with a clear head (and a very helpful email from my boss regarding something he found in a mailing list archive), and managed to get it all working. Damn skippy.

The actual problem was that the client was not on the server’s “allowed IP address” list for client connections. So the server was rejecting the connection. A 30-second fix (edit file, commit to repository, update server’s copy) and it’s all working. Now, wouldn’t it have been nicer if the client could have said something like “Hey, I got disconnected from the server unexpectedly, please check it out, kthx!” But no, popping the raw error condition from the OS, or, rather, simply making the extent of your handling of the error be some cleanup and then DYING is apparently the way to go.

Frustrating, to say the least.

It seems the people over at University of Washington have a silly side.

The Ten Commandments of implementing IMAP clients.

Home. Office. Random spots on campus. Random spots in the world. Enough people go enough places and have enough programs that seem to need twiddling whenever they change where they work that several solutions have been developed.

This is really an issue that’s been bugging me for a while. Not bugging me enough to learn how to write my own application to solve it yet (though I did hack up someone else’s idea.) Bugging me just enough to, well, you know, whine about it.

Location-based configuration settings is something I never really gave much heed to until I got myself a PowerBook last year. This is the first machine I’ve had that’s been portable enough, powerful enough, and just plain good enough to really become my single do-everything computer. In the year since I first aquired the ‘Book, I’ve decommissioned most of the other computers I had been using at home.

Many machines, minor mobility

Computers, you ask? It’s now to the point that the only computers you can expect to be running full-time at my house are the TiVo and the “home server”. The home server is a drastically overpowered little PC that serves DNS, DHCP, some file shares on a FireWire external drive, and serves as a local mail sending server. I’ve been using that machine primarily to archive all our CDs to MP3 for our iPods. Before the ‘Book, I had a monsterous Linux server, an ancient Sun workstation, a Windows PC, another Linux PC I used for experimentation and my Wife’s Windows PC. Then I added a pair of Apple PowerMac G3s (remember the first of the “New World” Macs, with the bondi-blue and white cases) for more experimentation, which eventually sold me on the idea of a Mac as my main computer. All of this was partly because I am a computer geek and like exploring new systems, partly because a lot of it was easy to aquire and partly because I was restless… I hadn’t really been happy with any one computer system, so I had one of everything.

Added to all that mess was my trusty Dell Inspiron 3500. It wasn’t the greatest machine around. In fact, it was kind of crappy, when you got right down to it. It was, however, mine, mobile and running Linux well enough to serve me on the road. Being a true unix geek having fun, whenever I needed to change my settings based on where I was computing from, I happily hacked the system configuration to suit my needs. If I got the system into a non-functioning state because of it, I was annoyed, but all the important stuff was elsewhere, so I didn’t care that much.

I want it all, and I want to take it with me.

Well, after a time, I decided that of all the systems I used, Mac OS X was the one I liked best for daily dealings. I also decided that if I was going to get a new computer, then damnit it was going to be a notebook. Hence, the PowerBook 15″. As I got comfortable with the new system, and migrated nearly all of my digital life to it, it started to matter a whole lot whether or not things “just worked” whenever I sat down somewhere to work.

At first I was pleased simply with OS X’s “Locations” menu in the Apple menu. This simply selects from one of the defined “Locations” in the Network Preferences panel, and then changes all the network settings to match the defined location. In itself, this feature really is useful, as it allows you to quickly switch between your DHCP settings you’d use at home, or your hard-coded IP address you need to use at work, or any number of hard-coded network settings if you work in multiple places. The only problem with this feature, though, is that it only works on settings in the Network Preferences panel.

“So?” you may now be asking. “What else do you need?” It’s really handy that you asked that, because I’ll tell you what else I need. I need to be able to connect to my mail servers for reading my email. I need to be able to send email, reliably, which often times requires changing what server I send mail through. I need to ensure, that if I’m not home, my screen saver requires a password, and kicks on a little sooner. I’d like to change my default printer to one physically near me. I’d like to have my audio muted in some places, and turned up in others.

The first thing I came across was an Automator workflow called Location Switch. All in all, it is pretty good, as it hits the major things, such as changing settings in Mail, default printer, volumes… Okay, they’re not major, but life is easier when you can change all those things at once. I found it had some limitations, though. I had to create a copy of the workflow for each location I wanted to deal with. I couldn’t have the workflow change the Network Location. This means to become operational in another locaion, I needed to do two things: change the system’s Network Location via the Apple menu, and run the appropriate Location Switch workflow.

See, I’m lazy…

I looked at what Location Switch could do for me, and I asked myself how I could make it better. So I read up a bit on Automator and AppleScript, and came up with a single workflow that leveraged what I read of AppleScript and added a “shell script” task to manage the changing of the Network Location. The resulting Automator workflow takes a lot from Location Switch, wraps it up in some more AppleScript, and yields a single workflow that asks you which location to use when you run it. Now, I have a single icon to click on, and then I answer a single question in a dialog box. Still two actions, but they’re easier than the last way of doing it. Also, I’m still not entirely happy with it.

Imagine my pleasure at finding that someone had already worked on an idea brewing in my head, and created an application that did all this in a much cleaner way. Reading through TUAW, I came across this article, which talked about Location X. Here was an application that seemed to work in much the way I had been thinking of writing my own app (hey, I needed an excuse to start programming in OS X!) I check it out, and download it, and install it, and start getting to know it. Honestly, it doesn’t do anything my Automator workflow didn’t already do, but it’s much cleaner, and goes straight to the plist settings files instead of having to work through the individual applications via AppleScripts. Much, much cleaner.

To top it all off, Location X even has a nifty feature called “AutoLocation”, which you can use to have Location X auto-configure your settings based on a wireless network ID. For example, if I were to turn on my notebook at home, and Airport found my home wireless router, Location X would use the name of my wireless network to trigger settings changes to my home preferences. Likewise, the same would happen at work, or any other location that I frequent and uses a wireless network, even if I’d be using the wired network instead.

So what don’t you like about this one, slacker?

Location X is shareware. That, in and of itself, is not what I don’t like about it. I never bothered with shareware until I started being a power user on my OS X systems. I’ve registered Delicious Library (it’s more than worth every penny.) I’ve registered Little Snitch (outbound firewall, per-application, leveraging OS X’s built-in pf firewall system from FreeBSD.) I’m planning on registering PCalc, given how much more useful it is compared to OS X’s Calculator. I’ve paid for NetNewsWire to keep tab on all the RSS feeds I care about.

Shareware on OS X is, I’ve found, much better than the sea of crap you’d find on Windows, and often worth the few bucks, even if you don’t lose any features for not paying.

What I don’t like is that the “demo” for Location X limits you to eight location changes before telling you to get lost. The other thing I don’t like is that it’s $20. I may be lazy, but I’m also stingy when it comes to certain things, especially when I already have a mostly functional way of doing what the $20 would buy me. Maybe it’s just a price point, though. I asked myself, if this were $5, would I buy it? Unquestionably, yes, I’d buy it. What about $10? Still, yes, I’d pay for it and move on with my life. I found myself wavering a bit at $15… I’d have to think about it, because that feels like it’s about the limit of how useful I’d call Location X to me. It’s really not more than $15 useful, you see, especially since I have something that already does the job.

Being mobile and not having to think about it

I may yet pay for Location X, and abandon my Automator workflow, simply because it is a much cleaner way of managing the concept of locations. I may pay for it primarily for the AutoLocation feature. I may pay for it because changing my location won’t involve waiting for Mail and the Printer Setup Utility to fire up so they can accept scripting commands. It has the potential of letting me not worry about how my system is currently configured to play on the network, and simply move on to getting my work done, rather than playing sysadmin for the first five minutes of each boot or wake-up.

You’d think, though, that something like this would have come as a standard part of the OS. Or, at least, as something available in the OS and all of Apple’s applications with an interface for other app vendors to use. With today’s emphasis on mobile computing and laptops and notebooks out-selling desktops, we wouldn’t have to find add-ons (or write them) to handle these situations. Maybe someone at Apple is having these same thoughts.

Maybe I should just pony up the $20 and quit bitching.

When your Users Group has its own Library, and the Librarian is sick of lugging around all the books to every meeting, it’s time to make technology do the work.

For several months now, at our Kernel Panic Linux Users’ Group meetings, our Librarian has been absent due to scheduling conflicts, and before that, both he and his predecessor have complained about the troubles involved in lugging around three cases of books to and from the meetings.

After giving this some degree of thought, and knowing that the new web site is based on Plone, I’ve decided that my first active project in some time now is going to be a web-based library system, complete with a borrowing request mechanism and lending tracking. Why? To prevent the Librarian from having to carry all those books, of course. Also, it will then be possible to browse the library’s collection online for the whole month between meetings, and, if I provide a suitable machine for use at the meetings themselves, we can even browse the library there, if we have Internet access.

This is an intriguing project to me, mainly because it’s not really a simple problem, but one that, if solved elegantly, will appear simple to the site users.

Stay tuned…

Sometimes you wonder why a vendor might include a tool which seems so useful but ends up being more of a waste of your time than anything else.

So it was, today, when I found that I needed to install a complete development environment on a Red Hat Enterprise Linux 3 Workstation system. “Ah,” I said to myself, “this should be quite simple! After all, Red Hat includes this wonderful utility that lets you select and install software packages after the initial install.”

Hah.

The utility in question is redhat-config-packages via the command line (I have no recollection of what the GUI menu item for it is.) It’s a GUI application for the X windowing system, so I fired it up, pointed back at my Linux workstation’s X display, and set to work. I scrolled down the lists of package groups, exactly as they are presented to you during the system installation, and selected the “Development” and “Kernel Development” groups. I then clicked on the “Update” button, and was presented with a wonderful error dialog, alerting me to the fact that the application couldn’t find a package that it needed.

For those that don’t know, when you purchase a license for RHEL, you get a year’s worth subscription to Red Hat Network, which gives you the wonderful ability to install updates and new packages via the ‘Net. At least in my mind, then, it wasn’t a great leap to assume that the “install new software” tool would utilize this facility. Well, not only is that not the case, but if you’ve applied any updates at all to your system after the initial install, redhat-config-packages simply doesn’t know how to deal with the resulting dependancy issues, apparently because it knows nothing about the up2date tools.

In fact, this was an issue right at the initial release of RHEL 3, and at least one bug was filed with Red Hat over this issue over a year ago. Search for “krb5-libs unlocatable” on Google and you’ll come up with a number of people complaining about this very problem.

Why bother including a utility that is likely going to fail under expected use profiles? Back before it was so easy to update a system, sure, including a utility that based all it’s package installation and dependency tracking on the CD’s used to install the OS made sense. However, when you expect your end-users to update their systems as you release fixes and patches, shouldn’t your users expect your tools to take that into account? And why let the bug linger for over a year without so much as a comment?

Really, how hard would it be for redhat-config-packages to check with up2date to see if what it needs can be fetched via Red Hat Network? Why should I have to figure out all the individual packages on my own, just because the tool that would otherwise do it for me doesn’t know how to handle anything other than what was on the install CDs?

This was quite maddening.