Just a quick update, ruiz-ade.com has been migrated to WordPress.com.
Notes from China, Part 2
More TIL in China…
- There is nothing made here with High-Fructose Corn Syrup. Everything’s made with natural sugar, because China doesn’t subsidize corn like we do, insanely, in the US.
- Food is, by and large, fresher here. Meat was likely butchered within a day or so of being served or sold. Yogurt and diary products are not pasteurized. Eggs are not washed when collected, and can safely sit at room temperature for a few days.
- Xi’an cuisine is all about the noodle. ALL. ABOUT. THE. NOODLE. Shanghainese is apparently all about sweet, and dumplings. Tasty, tasty steamed dumplings. Now I’m hungry again.
- Food in China is ridiculously cheap.
- The Great Firewall of China really puts a serious damper on the Internet, especially anything that uses an encrypted protocol. E-mail doesn’t seem too dramatically affected, as my trusty Apple Mail app can still fetch and send to all of my accounts, but there seems to be a selection of services that do work, and everything else is just blocked. The things that do work are subject to deep packet inspection. This slows everything to a crawl. Unfortunately, this also means things like Evernote, DropBox, etc. are hit-or-miss, but mostly miss.
- Did I mention traffic here is a bit loony?
- Shanghai is definitely more upscale than Xi’an.
- I’ve seen more upscale cars in Xi’an and Shanghai than I do in La Jolla / San Diego. Jaguar, Land Rover, BMW, Mercedes, Porsche. I guess if food and housing is cheap, there’s only so many other places to throw your money, so a lot of people throw it at cars.
- With as crazy as traffic is here, I’m amazed that I’ve only seen two accidents on the roads, and one near-miss. I happened to be in the taxi for the near-miss. EXCITEMENT!
- Two weeks for a trip to China, especially if you’re going to central China (like, say, Xi’an), actually costs you about 5 days of travel, if you’re smart and plan on a one-night layover after/before you cross the Pacific.
I guess that’s about it. Looking forward to going home. Not looking forward to the extra 20 hours of travel being inserted into my day, but I’ll be in my own bed tonight after a 40-hour Friday.
Notes from China, Part 1
TIL, so far in China…
- KFC is the largest chain restaurant in China.
- “Parking” means stuffing your car wherever you can find enough space for it to fit. Whether that’s on the sidewalk, the side of the street, or blocking in three other (illegally) parked cars, it’s all good.
- Right of way is ruled by mass, and there’s no obligation to stop for a right turn on red. Left turns do not need to yield to oncoming traffic. Pedestrians cross at their own risk. I’ve always wondered what it would feel like to be the frog. Now I have an idea.
- It’s apparently better to be here when it’s warm than when it’s cold. Nobody burns their coal heaters when it’s warm, so the air is actually breathable. The constant rain for the last four days has helped, too.
- Sometimes the air conditioning works.
- The hotels try very hard to feel very European, but they’re very definitely Made In China. It’s a source of cognitive dissonance.
- If it has wheels, you’ll see it on the roads. And next to the roads. And sometimes on the sidewalks.
- Electric scooters are very popular here. And absolutely freaking silent. Keep your head on a swivel.
- There is a very complicated pattern drivers observe of when to use high-beams, hazard flashers, turn signals, horns, or even any lights at all, regardless of day or night. I have not yet figured it out, content to let driving be done by local professionals.
- Taxi drivers here are insane. And belligerent. If they don’t like where you want to go, they’ll drive off without you. Be prepared to argue. On the bright side, the taxis at the airport don’t have a choice if they want to get in the taxi line.
- Speaking of taxis, every single car service representative will chase you down to offer you a ride as you walk out of Customs. These people are dressed very nicely and professionally, speak passable English, and are quite insistent. Politely decline them all, and follow the signs for TAXI, which will lead you outside to the standard taxis queued up in a designated area, with what I can only assume are “taxi marshals”. You’ll pay about 1/6th to 1/5th the price of those driver services that feed outside Customs, and the cabbies cannot turn you down.
Yet Another Mac OS X Location Changer
I was going about my business, as you do, having used the LocationChanger script and launchd agent to automatically switch my Mac between my home and non-home network locations. Of course, I decided I could do it a little better, and got to work.
Here is the result: AutoLocation.
I learned a few new things while cooking this up, including how to actually deal with arrays in bash, a nifty thing called process substitution (which resulted in my favorite line in the whole script), and a great way to return arbitrary values into variables from functions.
I really like it when I learn new things on the way to solving a problem for myself. It’s the best way to learn something.
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.
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!
Balance (Security vs. Usability)
I suppose this should be filed under “Get More Pageviews”, but nonetheless, I took the click-bait to Sophos’ calling Apple out on making the iPhone 4S safer to use while driving easy to access by bypassing your passcode. My main issue is that they take what is a legitimate concern regarding the tradeoffs between security and ease of use (and even safety of use while driving) and instead paint it as a deliberately cavalier attitude towards data security.
What’s disappointing to me though is that Apple had a clear choice here.
They could have chosen to implement Siri securely, but instead they decided to default to a mode which is more about impressing your buddies than securing your calendar and email system. →
You see what he did there?
Ever notice how an expert in a certain field will only ever see choices from the perspective of that field? Interesting how there is the assumption that the only options were secure and insecure. It’s like he just assumes that nobody will ever try to use a phone while driving, something that seems like it would gain a huge safety improvement by reducing phone interaction.
On my lowly iPhone 4, if I want to call my wife while I’m on the freeway to see if I need to stop at the store, I’d have to:
- Pick up the phone
- Press the home button or the power button
- Swipe across the bottom of the screen
- Tap in my passcode, or, as suggested in the Sophos article, my complex alphanumeric-with-symbols password
- Tap the Phone icon
- Tap the Favorites button if it’s not already on the Favorites page
- Tap my wife’s entry
With an iPhone 4S and Siri, I’d presumably need only to:
- Pick up the phone
- Tap the button that activates Siri
- Speak: “Siri, call my wife.”
- Acknowledge Siri’s confirmation of my request by saying, “Yes.”
I wouldn’t ever have to look at the phone. The only touch target I’d need is a physical button on the phone, which is easy to locate without looking. It’s only marginally more complicated than asking a real person sitting in the car with you to dial the phone for you, because you have to push a button two times. I’m reasonably certain it’s this use case which Apple designers and engineers had in mind when setting the default options on the iPhone 4S, with the assumption that the security-conscious people could find and disable the “enable Siri while iPhone is locked” option themselves.
After all, while the iPhone is a popular device for businesses, it’s not the only market Apple sells to. Apple is going to make the choice, every time, to make it’s products easy and delightful to use for its primary customer base.
You know, ordinary people.
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.
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!
I really need to meet this Systems Boy…
… Or at least add him to my daily reading.
My last source of confusion (on this matter, at least) is that people are going after Apple on this at all. Until the iPhone there was never an expectation that phones should either run Flash or be open. A phone is not a personal computer. It’s a phone. All smartphones are just phones. They play by a whole different set of rules. And that set of rules is much longer and stricter than that of a personal computer. No one ever complained that Nokia’s phones weren’t open. Or Motorola’s. Or Samsung’s. Why now is it completely offensive that Apple’s phones should be? Moreover, there are no phones in existence today that can display Flash content because of all the reasons cited by Jobs in his letter. Google’s phones don’t. Neither do Palm’s. So why is everyone going after Apple? It’s just crazy. →
Quick update: About the only thing that has changed since he posted this, I think, is that Google has announced with Adobe that they’re going to get Flash on the Android platform. We’ll have to see how that turns out, but I honestly don’t have high hopes, primarily because touch is not the same as keyboard, monitor and mouse, and I’m not sure Flash content designed for web-on-PC will translate well.
Ruiz-Ade.com 