For this, someone needs a punch in the nose.

Dear Drugstore.com,

Please inform your software devlopers that their reasoning behind what is and is not a “valid” name is severely flawed and is thus resulting in my refusal to mutilate my name to fit your web store’s idea of what is valid.

Yes, when I go to create an account for myself, and enter in my name:

  • First Name: Gregory
  • Last Name: Ruiz-Ade

And then I proceed to fill in my email address and create a password, and click continue, I get a dialog box that tells me I must enter a valid name.

This is absurdity.

Anyone who is old enough to be competent enough to design and implement an online storefront of the size and caliber of drugstore.com should surely know that there are hyphenated last names out there in the wilds of the internet (let alone the whole world.)

As such, I politely decline to make a purchase with drugstore.com today.

Thank you,

Gregory


Yes, I just emailed that to them.

For this, someone needs a punch in the nose.

Using SuperDuper! for FileVault2 System Volumes

Since my first Mac (an Aluminum PowerBook G4), I had relied upon SuperDuper! as my backup method for my Mac notebooks. It’s a wonderful tool, and faithfully replicates an entire volume, including making it bootable, for a worst-case drive failure scenario. I’ve used it for migrating my system to a new disk when doing disk upgrades, transferring an image to a new/replacement notebook, and just plain backups.

I’ve long since switched to using CrashPlan for my backups. CrashPlan has worked wonderfully, and saved my bacon a number of times. I use it on every computer I own. Crashplan isn’t, however, an ideal solution for migrating data to a new drive when upgrading your hard disk, simply because it’s rather slow to restore a lot of data over the network.

So, back to SuperDuper! I go, as I’m planning to add an SSD to my current MacBook Pro, and re-instate the “build a DR boot volume on an external drive” policy at home. The wrinkle is that since the upgrade to OS X Lion, both my wife’s and my notebooks are using FileVault2 for full-disk encryption. Given the sheer amount of personal information on these computers, it’s the only sane thing to do, especially when the notebooks are bound to iCloud, with Find My Mac enabled. (This gives you remote-wipe capability on your notebook, which is very useful if it’s lost/stolen.) Unfortunately, there’s no clear way to use SuperDuper! with a clean hard drive and end up with an encrypted volume that duplicates the original.

At least, not directly within SuperDuper.

All is not lost, though, as there is a way to do it, and get a fully encrypted, bootable duplicate of your FileVault2-encrypted OS volume!

In short, the procedure is:

  • Install OS X Lion to your destination hard drive
  • Activate FileVault2 on the new install
  • Reboot to your normal startup disk
  • Use SuperDuper! to “Smart Update” the destination
  • Boot from the destination (SuperDuper! target) disk again
  • Open System Preferences -> Security, and click on the FileVault tab.
  • Click the button to enable users to unlock the volume, and enable any additional accounts (if you have the users there to type in their passwords.)
  • Reboot to your normal startup disk again
  • Pat yourself on the back! You did it!

I’ve tested the procedure on my old MacBook Pro, from which I’m preparing to remove the SSD to transplant it into my new MacBook Pro. It works, it boots from either volume, and they’re both encrypted (granted, with different recovery keys, as one would expect). I’ll post a followup in about a week complete with screenshots of the whole process when I migrate my OS volume to the SSD in my new MacBook Pro.

Stay tuned!

Using SuperDuper! for FileVault2 System Volumes

Did you leave the parking brake on?

Just a reminder, when you’re migrating a lot of data and configuration information to a new machine, remember to make sure you pull all the relevant information.

I just spent the better part of my afternoon/evening chasing down a problem where a user could not log on via SSH. He had the right key. He were using the right passphrase. His account existed in /etc/passwd, and he was listed in the right groups in /etc/group. We did all sorts of debugging on his client, and then a clue popped out when we ran the server in debug mode:

Access denied for user dude man by PAM account configuration

Well, I thought it was a clue. Turns out there was nothing overtly obvious about what was going on. Nothing, that is, until I finally decided to check the contents of /etc/shadow, only to discover that the user in question had no entry there.

Remember to check the simple things first. For a Unix/Linux account to be happy these days, it needs an entry in both /etc/passwd and /etc/shadow! It’s a step that is only really missed when you’re copying the contents of these files from another machine, instead of using built-in utilities (useradd, groupadd) to create user accounts.

Did you leave the parking brake on?

LDAP, SSH and Access Control on Linux

I was recently asked for my opinion on options for adding access control, or, more specifically, host-level authorization for users connecting to Linux systems. All the systems in question are a variety of CentOS, and all of them are configured to use LDAP for authentication and authorization via the pam_ldap and nss_ldap modules.

The Problem

In a default configuration, pam_ldap and nss_ldap will make user and group accounts in LDAP act just like user and group accounts in /etc/passwd, /etc/shadow and /etc/group. If it is present, it’s a valid account for the system. In the general case, this is a good thing, and simplifies the configuration of your systems. Things get complicated, however, when you only want a subset of users to be allowed to log in to specific machines. Traditionally, the method for doing this has been to force pam_ldap to examine the LDAP entry for the user trying to authenticate, and only allow the authentication to succeed if some attribute of the user’s object matches a configured value. The host attribute of the account objectclass is a great one to use, but if your user objects are based on person or inetOrgPerson, and you’re doing the right thing and have strict schema checking, you can’t use it. You’d either have to violate your schema and disable checking, or violate your schema and add the extensibleObject objectclass, which is basically a schema-valid end-around to schema checking.

There are similar tradeoffs for other object attributes you might choose for utilizing for access control, especially considering that you can only use attributes that exist in your users’ LDAP objects, and not outside them. While it certainly can be done, and I have done it in LDAP implementations before, there’s never a truly clean way to implement the policy, and changes to the policy induces the risk of breaking the host’s LDAP configuration entirely.

A Good Solution

In the case I was most recently asked about, the only way to gain access to the system is via SSH. The application stack which the hosts run either doesn’t do any user authentication, or handles it itself. Taking a step back from LDAP, then, there is an easier way to do access restrictions: the OpenSSH daemon’s AllowUsers and AllowGroups configuration directives.

Utilizing the capabilities of OpenSSH takes one piece of complexity out of the already complex LDAP client configuration, and moves it into a service that is a lot easier to repair should something go wrong. This is especially true if you are utilizing a configuration management (CM) system like CFEngine, Puppet or Chef, where the ability of the CM to do anything might completely hinge upon the system user and group databases being intact. A configuration error that causes people to not be able to log in via SSH is less serious than all of your systems user and group records disappearing, which can completely unhinge your system.

Finally, utilizing OpenSSH’s AllowUsers and AllowGroups let’s you manage access to hosts simply by modifying group memberships of users, which can be easily done in LDAP with tools such as my personal favorite, the LDAP Account Manager. This nicely avoids the possibility of having to write your own management tool for access control to add/delete/modify attributes that aren’t easily handled by existing tools, or may not even be visible to those tools. Saving time and effort is key to sanity as a systems administrator, and this will save you a lot.

The best part, though, is that this method works regardless of whether you use LDAP, NIS/NIS+, rdist /etc/passwd and friends from a master copy, or any other method of pushing user and group account data out to your hosts. On top of that, there’s nothing saying you can’t layer this on top of LDAP ACLs, too, for that extra bit of paranoia.

Loose Ends

There are, however, some downsides to doing access control via OpenSSH. The first is that it only applies to OpenSSH. This may seem like a statement of the obvious, but it’s important to point out. Other services you may be running, which also rely on LDAP for authentication and authorization, will not be beholden do your policies configured for OpenSSH. Again, it may seem like I’m simply re-stating the obvious, but consider:

  • Do you run an FTP server with user accounts?
  • Do you run an IMAP or POP service?,
  • Do you run SMTP AUTH?

Those are just three examples, but any service you provide that performs user auth and does so via PAM, SASL (backed by PAM) or directly with LDAP would need to have it’s own ACLs in place if you don’t want all your LDAP users to have access.

With that in mind, however, if your needs are simple, use a simple tool, and get the job done with less stress.

Happy hacking!

LDAP, SSH and Access Control on Linux

Dear Adobe Reader Safari Plugin: Die.

If you’re anything like me, you have a strong dislike for all the stupidity that surrounds the Adobe Reader (formerly known as Acrobat Reader.)

I won’t go into the details here (though this guy can explain it in great detail), but because I very occasionally need features of Adobe Reader, I still keep it installed on my Mac, while I use Preview for all my other PDF needs. I’ve gone so far as to install the Firefox PDF Plugin for Mac for when I use Firefox, just to avoid Adobe Reader. And, really, there’s no point in Adobe Reader for most cases where you just want to be able to view or print PDF files. Doubly so, since Mac OS X lets you print any document to a PDF file as a default feature of the OS.

There are, though, edge cases where having Adobe Reader installed and available are useful. So I have it installed, but I refuse to use their web plugin. Adobe doesn’t care, though, and will periodically, sometimes randomly, and sometimes even without my consent, re-install the plugin. Even though I’ve told it not to. Adobe Updater, I’m looking at you, here.

Sadly, my solution is heavy-handed. I created a launchd task that will forcibly remove the Adobe Reader plugin from /Library/Internet Plugins whenever it’s created. It’s fast, efficient, and works.

And, as soon as I can figure out the new wordpress theme, I’ll post it here in a legible form

UPDATE: Thanks to Lynne and Chad on Twitter for suggesting the Preserve Code Formatting plugin!

And now, the Launchd config. Save this as:
"/Library/LaunchDaemons/org.unnerving.RemoveAdobeReaderPlugin.plist"


Label
org.unnering.RemoveAdobeReaderPlugin
ProgramArguments

rm
-rf
/Library/Internet Plug-Ins/AdobePDFViewer.plugin

QueueDirectories

/Library/Internet Plug-Ins/AdobePDFViewer.plugin

WatchPaths

Dear Adobe Reader Safari Plugin: Die.

Digital Photo Archiving

Dear LazyWeb:

My wife and I have something like 4000+ photos that we need to scan (at high resolution) and archive, and be able to logically manage.

My platform choice is Mac. I will likely be purchasing a Mac Mini to dedicate to this task (2GHz model). I do not want to afford a Mac Pro, as awesome as it would be to have such a powerhouse in my home. I already have an Epson 2400 scanner, and would prefer to not have to replace it.

I have no idea what software to use for the resulting photo collection. I’d like something better than simple files on the disk, and am considering either Lightroom or Aperture, even both of those seem aimed more directly at digital photography.

I would like a simple workflow, if possible, that doesn’t rely on me naming the images. Tagging and notes/comments would be required.

Can I get away with Lightroom or Aperture, and whatever scanner software I can install for my scanner? Do I need something different?

Can Lightroom or Aperture store images on an external disk (which may not always be connected?) I’ve got plenty of storage already on my home network.

UPDATE:

Hardware will likely end up being a new 13″ MacBook, instead of a Mac Mini, as my wife needs a replacement for her iBook anyway, and the new MacBook has way more power than the mini. This definitely necessitates the ability to store all the images on external storage, ideally via a network (SMB/CIFS) share.

Digital Photo Archiving

Oh… Safari was already awesome.

So, yeah, this is probably old news to everyone else, but I’m late to the party, as usual. I finally tripped over two menu options in the History menu of Safari that I had not previously noticed.

The first is “Reopen Last Closed Window.” This is very useful.

The second is “Reopen All Windows From Last Session.” This takes care of my biggest concern regarding session restore.

So I guess maybe a “Reopen Last Closed Tab” option might be about all I could add to that to be truly complete.

I do still look with great envy at Firefox’s extensions system, particularly for Adblock Plus, FlashBlock and NoScript.

Oh… Safari was already awesome.

Safari: You’re Awesome, But You Could Be More Awesome

It’s been about a week and a half since Apple release the last batch of updates for OS X, including the latest version of Safari. In the interests of keeping up to date with security updates, I went ahead and updated. I did my research first, though, and uninstalled Saft before the attempt (there were some who had problems with InputManagers installed during the upgrade.)

I was happy to discover, this evening, that Saft had been updated to support the latest version of Safari. Despite my general revulsion for running InputManager-based hacks (let alone other system behavior modification software, like Haxies, that hook in even deeper to the system), Saft offers a subset of functionality that I simply don’t like doing without. A couple of the features, I feel, really should be integrated into Safari proper.

Continue reading “Safari: You’re Awesome, But You Could Be More Awesome”

Safari: You’re Awesome, But You Could Be More Awesome

.Mac syncing for iPhone

A few weeks ago, when Apple announced all the new features coming to the iPhone, and specifically mentioned ActiveSync, I was reminded of a thought I had a couple months back:

There really is no good reason why the iPhone should not be able to synchronize its data to a .Mac account instead of being restricted solely to syncing via iTunes on a computer. This would actually make the iPhone even stronger for people who need reliable access to the latest version of their data without having to remember to plug the phone in all the time.

And then, this evening, as I’m going through the various RSS feeds I didn’t look at all day in NetNewsWire, If find this post on TUAW mentioning .Mac syncing on iPhones. Okay, that means the feature is most likely going to come some time this year.

Amusingly, even though I have my personal Mac at home (a 1.5GHz G4 PowerBook 15″) and a Mac at work (2GHz Core2 Mini), I still haven’t gotten myself a .Mac account. As much as I would like to synchronize my data between the two machines, I can’t seem to justify $100 a year just to be able to keep my Safari bookmarks and Address Book contacts synchronized. I already keep all my calendar information on Google Calendar, which my wife and I both use, and sync it to my Mac with Spanning Sync. (Spanning Sync will eventually have Contact syncing between Address Book and Google Calendar/Gmail too, now that Google has finally announced a Contacts API.)

The iPhone being able to sync to .Mac, however, changes the game. .Mac syncing means that, for $100 a year, I can basically never have to remember to plug the iPhone into my computer just to make sure my calendar, contacts, bookmarks and notes (well, hopefully notes) are all current. I don’t have to worry that when I add a contact in my iPhone, I need to plug in to sync it back to my Mac. For someone like me, who simply prefers for the technology to Just Work and do so on a consistent and transparent basis, .Mac syncing would sell itself.

Heck, it’s hard enough for me to remember to sync my music to my current iPod, because it means I have to dig out my cable. It’ll be interesting to see what really does come of this rumor.

.Mac syncing for iPhone