Archive for November, 2007

iPhone Subtleties

Update 2007/12/15: The iPod has two shuffle modes. I’d been going to the list of songs and hitting Shuffle, but this isn’t sticky. The trick is to 1) start playing a song, 2) tap on the cover area to get the track position slider, and 3) tap the shuffle icon on the right side. This is sticky, and I now have shuffle play by default! Still no shuffle by album, though…


The iPhone has a few very small features which show a surprising level of thought went into its design before launch.

The do not disturb switch. This has been a signature feature of Treos for years — completely disabling the speaker. Apple got smarter: the iPhone’s side switch mutes incoming calls, SMS notifcations, & calendar alerts. But the alarm clock and immediate actions on the phone, including speakerphone and iPod playback (with earphones disconnected) — still use the speaker. So Apple has evolved from “mute” to “do not disturb”, which is much more useful.

Keyboard key-up. Registering keys on finger lift allows correction without mistyping (if you’re paying attention) and provides some really handy tricks, like dragging from shift to I to get a capital I in one (long) tap instead of three — works for numbers & punctuation too.

iPod stop on earphone removal. When you unplug earphones, the iPhone stops music or video playback. I use this feature at least twice a day, when I get home or to work. If the iPhone is in a holster or bag, this saves the trouble of getting it out to stop playback. Apple could have opted to activate the speaker instead, but people unplug their earphones and stop using the iPod much more often than they switch from earphones to speakers.

Earphone remote behavior. When listening to music, it fades out if the phone rings; I thought this was silly, but it’s nice. When I hit the button on the remote, the phone answers; when I hit the button later to hang up, the music resumes. If I’m using the iPhone (in any app) and hit the earphone remote, music starts (or stops) playing; this saves me a few steps on switching into the iPod app and back to what I was doing. When watching video, it pauses and resumes. Between that, the double-click to skip to next track, and the volume controls on the side of the iPod (easily accessible in a belt holster), I don’t miss the 6-button iPod remote.

Unfortunately, it’s always alphabetical play of everything on the iPhone, so I have to switch to iPod and start Shuffle play the first time; then it stays in Shuffle mode until either a) the iPhone gets confused and stops playing, or b) I plug into a Mac; neither of these should switch me out of Shuffle mode, actually.

And that reminds me: What genius at Apple decided that iPhone users don’t want to shuffle by album? So much for “the best iPod ever”. Pfeh!

But overall, the iPhone is remarkably sophisticated. Perhaps Ive & Jobs and their 5 closest friends spent a year writing down all the things about cellphones that annoyed them, and brought that into the iPhone design discussions.

Comments (1)

Parallels Oddness: Network mis-configured

I use Parallels Desktop for Mac to run the Action Request System (Remedy) for trouble ticket tracking at work. They have a webapp, but it’s not really usable.

A couple weeks ago, about when I upgraded my work desktop to Leopard, Parallels broke. I couldn’t connect to the Remedy server, or our voicemail system. I don’t really think about Parallels networking, but it’s all virtual so normal troubleshooting is unavailable. Basically there’s a fake DHCP server (or two) inside Parallels for the VMs, and I had very little visibility into why it was doing the wrong thing. I reinstalled Parallels but hadn’t spent much time on it, since I don’t use Remedy heavily.

It turns out I needed to re-set Parallels from Bridged to Shared networking mode, whereby it uses the Mac as a NAT server. The NAT alleviates many of my concerns about running Windows. But how & why did that setting get changed in the first place??

Comments

Crackhead of the week: Phil Manchester @ The Register

With thanks to Daring Fireball’s JotW.

I like The Register because they cover the stuff I’m interested in, and their leanings correlate reasonably well with my own. But they don’t edit their stuff, and have no shame about being wrong or just lost in left field. Today’s example:

Android: developer dream or Google cash machine?

By Phil Manchester

Published Friday 16th November 2007 18:49 GMT

However, it will take more than a $10 million “incentive” (http://www.sci-tech-today.com/story.xhtml?story_id=030002Y7BBKU) to truly galvanize people and generate a powerful and self-sustaining grassroots developer movement and ISV community. Some of the open source technologies changing today’s market, after all, built up critical mass because they were good, useful or employed a community friendly license - not because early developers got huge cash dongles.

Um, no. People write free and cheap Palm, Symbian, Windows Mobile, Google Maps, and (now) iPhone apps all the time. You don’t need to pay them $10,000,000 to do so.

Google’s Android agenda is far from clear, but it seems money is a driving factor, rather than a genuine desire to liberate developers and phone users from the nasty old telcos with an open platform. After all, Android’s backers include some of those very carriers that liked to lock you in (http://www.openhandsetalliance.com/oha_members.html) and have proved nothing more than an anchor on software and service innovation, but who just happen to be lagging the US market leaders.

See, the logical fallacy here is more subtle, but still big enough to throw a phone through. Google has never claimed that money wasn’t a driving factor. There are lots of people who are interested in Android for primarily non-commercial reasons. Nobody who’s awake ever thought Google (or the other Open Handset Alliance members) were among them. It’s “Don’t be evil.”, not “Liberate developers.” Whether or not you think Google is evil (I think they’re scary and cool, but not evil), they never pretended Android wasn’t supposed to make much money. Is there anyone, aside from Phil Manchester, who didn’t know that Google likes to make money and is quite good at it?

Enlightened capitalism maybe - but capitalism just the same.

Duh.

Comments

Securosis: ipfw ruleset

Update: After revising more than once, the permanent link to the latest ipfw ruleset is http://securosis.com/publications/ipfw.html.


Over at Securosis, Rich and I posted a piece on using ipfw to increase your security. Leopard’s new ‘firewall’ isn’t a network firewall at all. It restricts applications’ ability to listen on ports, rather than working at the level of the network stack, which means it cannot do things like allow ssh from home but not from the rest of the Internet. If you want classic packet filtering, it makes sense to use ipfw as well. We cooked up a starter ruleset for people to customize, with instructions on installing it using WaterRoof.

Comments

Oracle VM: Funniest thing I read all day

Update: It’s sillier and sadder than I thought. See below.

Today (2007/11/12), Oracle announced Oracle VM, their free competitor to VMware and (Citrix) Xen. A few months ago, Oracle announced “Unbreakable Linux”, which is their re-branding of Red Hat Enterprise Linux. There are already many free Red Hat flavors, including CentOS, but not too many companies have built business models on attempts to take Red Hat support business away from Red Hat.

Oracle has. They made many loud claims of being cheaper and better than RHEL, while claiming this wasn’t an attack on Red Hat. Red Hat was pretty quiet about Oracle Linux, but did point out that Oracle’s claims to be actively fixing bugs in RHEL (supposedly faster than Red Hat does) without forking RHEL were impossible — as soon as there’s a fix which isn’t available from Red Hat, that’s a fork.

There’s been a lot of ill feeling both ways over this, but of course neither company is willing to publicly and unambiguously badmouth the other.

Today we see another step in Oracle’s (Linux) plan: Oracle VM is free, but Oracle offers paid support. The best part is this, though:

What is the difference between Oracle VM and the virtualization that comes bundled with Oracle Enterprise Linux?

As part of the Unbreakable Linux Support program, Oracle supports virtualization that is included with Oracle Enterprise Linux 5. Please note that Oracle products are not supported to run in that environment. Any customer who wants to deploy Oracle products in a virtual environment should use Oracle VM, and subscribe to Oracle VM support. Oracle customers should refer to MetaLink note 466538.1

Translation: We sell RHEL5 (which includes Xen as part of the base price) but we don’t like it, because we want you to pay more for Oracle VM instead. We cannot realistically either break or drop support for Xen, even though we’d really like to, but we do get to chose what “platforms” we support Oracle on, so we’ll support Xen, and Oracle on Linux, but not Oracle on Xen. Please don’t think too hard about that one. It makes our heads hurt!


Update 2007/11/13: I missed the fact that Oracle VM is based on Xen. This means Oracle wants to sell you “Unbreakable Linux”, but wants to charge an extra $500 to virtualize its own software on “Oracle’s” Linux platform. I thought they were claiming Oracle VM was better than RHEL’s VM, but that can’t stand even cursory scrutiny, given that they’re basically the same code. Additionally, their

• Three times greater efficiency than current x86 based server virtualization products;

has to be in relation to VMware which is not paravirtualized, but there is no way Oracle’s brand-new Xen build is significantly faster than Red Hat’s Xen kernel, running on Red Hat’s Linux distribution.

Given that Oracle now recommends RHEL + Xen (from Oracle) as a platform for running Oracle Database & Applications products, Oracle’s lack of support for running on RHEL + Xen (when purchased from Red Hat) looks — I was going to say even more absurd, but this can’t be an oversight, so it’s just transparent corporate greed.

Comments

Leopard’s “socket firewall”

The new “firewall” in Leopard is called socketfilterfw, but as far as I can tell it doesn’t actually do any packet filtering, which is how ipfw and classic packet filtering firewalls work. Instead, it restricts the ability of programs to “bind” a port so they can receive all traffic for that port. This discrimination is not novel — UNIX systems (including Mac OS X) will not allow any program to bind ports 0-1023 unless they’re running as root (UID 0). Normal users get an error when they attempt to take over low ports like this.

In recent years, many operating systems have made adjustments to this restriction, in an attempt to make permissions more granular. Apple, however, has added an entirely different (and much more sophisticated) test to the process of binding a port: does socketfilterfw trust it? socketfilterfw can even cryptographically ’seal’ a binary (program), to make sure that if it is changed in the future, it automatically loses its authorization to listen on the network. Unfortunately, Apple seems to have gotten a bit carried away, and signed some tools that are as likely to be used by crackers who have just broken into a system as legitimate Mac users (netcat, I’m looking at you)

If socketfilterfw allows the request, the port is bound and the program receives traffic that reaches the port; if socketfilterfw denies the request, the port is not bound to the requesting program, and it doesn’t get any traffic. Ironically, this is very much more like a Windows firewall (e.g., ZoneAlarm), of restricting and allowing individual applications, rather than working at a network level that has little or nothing to do with individual programs.

Anyway, here’s the help message for socketfilterfw. Note the reference to firewallapp, which does not exist on my system. Presumably it is an unreleased CLI tool to manage the firewall, like the ipfw command manges the kernel firewall, or iptables on Linux. Note that the FreeBSD-derived ipfw is still available in Mac OS X Leopard (user), but not activated or used by the system — it just passes all traffic through unless manually configured. On the other hand, Mac OS X Leopard Server’s Server Admin (used in Advanced mode, but unavailable in favor of Server Preferences in Standard mode) still uses ipfw. Over at Securosis, I’m working on an example ipfw ruleset to get people dissatisfied with socketfilterfw started, but before we post any rules, we need to decide upon a suitable (easy) way for people to use them without delving into writing custom rc boot scripts.

$ sudo /usr/libexec/ApplicationFirewall/socketfilterfw -h
usage: /usr/libexec/ApplicationFirewall/socketfilterfw [-c] [-w] [-d] [-l] [-T] [-U] [-B] [-L] [-a listen or accept] [-s file to sign] [-v file to verify] [-p pid to write] 
firewallapp is used to control Application Firewall socket filter.
The command takes the following options that are evaluated in order, 
and several options may be combined:
 -h        display this help and exit
 -t app    set trusted app, e.g. -t app1 app2 app3
 -i        dump socket filter internal data info
 -d        turn on debugging
 -l        do logging and run in daemon mode
 -k        kill daemon
 -a        ask when listen or accept, ask "accept" or ask "listen"
 -s file   sign file
 -v file   verify file
 -c        check file

Note that sudo /usr/libexec/ApplicationFirewall/socketfilterfw -d dumps out a list of allowed programs; there’s some other junk in the output that looks like the signatures checked against the binaries, and a bunch of references to “ALF”, which could stand for “Application Level Firewall”.

Comments (1)

Time Machine: Exclude All System Files

Time Machine has a hidden feature, to “Exclude All System Files”. In Leopard Server’s Standard mode, Time Machine is a service, and in Server Preferences you can control whether clients back up their system files, or skip them. This is logical — for personal backups you want everything, but if you have enough users to justify a file server, you might well not want to back up the same Leopard system files for each user.

Today’s handy-dandy discovery was that Mac OS X Leopard “user” has this feature too, but there’s no visible knob to turn it on. Interestingly, I cannot find such a control in Server Admin either, which could be my oversight or could simply be a bug (I’ve reported it, anyway).

Instead, if on the client you add /System to Time Machine’s list of directories not to back up (I also skip /Developer, /sw, and my music files), Leopard pops up a handy dialog, asking if you really want to “Exclude All System Files”. I chose yes, although I’d like to know exactly what (directories) are excluded by this option.

"Exclude All System Files"

Server Admin’s Help has this to say:

Configuring Time Machine Backup Destination

Time Machine is a backup application that keeps an up-to-date copy of everything on your computer, which includes system files, applications, accounts, preferences, and documents. Time Machine can restore individual files, complete folders, or your entire computer by putting everything back the way it was and where it should be.

Selecting this option causes the share to be broadcast over Bonjour as a possible Time Machine destination, so it will show up as an option in System Preferences. On a standard or workgroup server, selecting this option also sets the POSIX permissions to 770 and sets the POSIX group to com.apple.access_backup.

A share point can be designated as a Time Machine backup in Server Admin.

Comments

Leopard Server Bug: Deleting an interface in Server Assistant is broken

10.5.0 Server: I have 3 interfaces. The onboard GE is broken, so I have GE cards in PCI 2 & PCI 3. When I delete Ethernet in Server Assistant (at installation time), it crashes and bounces me back to the Welcome screen at the beginning of the process. I can, however, just not leave it at DHCP (physically disconnected) and get through; I think I could also turn off TCP/IP for that port, but haven’t verified in 10.5.0 GM.

Comments

Leopard: Minor authorization bug

System Preferences has a security feature whereby you must “unlock” and authenticate as an admin to change sensitive settings, including Network settings. Ethernet & AirPort both have “Advanced…” buttons behind which Apple hides most of the actual controls — the non-Advanced settings are cut down and simplified (but definitely fine for normal use). Unfortunately, once you click Advanced… to change the settings, there’s no authenticate button. I’ve found myself in the Advanced sheet, unable to make a change, and had to back out of the sheet, unlock, and then click Advanced… again to make a change.

Apple declines to address this issue, so I’m documenting it here for others annoyed by this bug.

Comments

Screen Sharing replaces Apple Remote Desktop

Update 2008/2/3: Adam, thanks for the suggestion — I’d forgotten about the vnc:// scheme. But who’s Geoff?? I prefer aliases to functions because they’re simpler, and like to leave an ssh shell open, both for my own use and as a reminder to close the tunnel when done. Here’s a simpler alias — note that you must still supply the hostname on the command line after the alias, e.g.,stss salt“.

alias stss="(sleep 4; open vnc://127.0.0.1:5901) & \
ssh -C -4 -L 5901:127.0.0.1:5900"

Update 2007/12/14: I added a pbcopy command to put ‘127.0.0.1:5901′ on the Clipboard (pasteboard), so now I can just Paste and then delete (pbcopy appends an undesired Return to the Clipboard), which makes the whole thing easier. New alias (note that this is really properly one line, but it doesn’t wrap properly without help):

alias stss='echo 127.0.0.1:5901 | pbcopy; open \
/System/Library/CoreServices/Screen\ Sharing.app; \
ssh -C -4 -L 5901:127.0.0.1:5900'

I have a couple licenses for Apple Remote Desktop at work, for managing our 8+1 Mac cluster (”the orchard”) and for managing other Mac servers on campus. I find ARD very useful because although Remote Desktop uses VNC as the underlying protocol, Apple’s compatibility has been poor, so I had lots of trouble connecting from Chicken of the VNC and other clients. While I like ARD (particularly the automatic ssh tunneling in v3), I only use the remote control feature, never its other management capabilities.

With Mac OS X 10.5 Leopard, Apple has bundled /System/Library/CoreServices/Screen Sharing.app, which provides the VNC capabilities I use from ARD and skips the other features I don’t care about. It’s my favorite Leopard feature, accessible from the Finder Sidebar, iChat, Server Admin, and through Back to My Mac (which seems to have some problems with security).

The only thing I don’t like about Screen Sharing is that Apple apparently built encryption into the VNC protocol. Apple’s encryption is of course incompatible with all the other clients & servers, since it’s Apple proprietary (just like their proprietary compression encodings). It’s confusing because the Preferences options look identical to the ones in ARD3, which actually uses an ssh tunnel to provide encryption. It’s a firewall problem because there are lots of places we a) allow ssh, b) block unencrypted VNC, and c) would allow encrypted VNC. ARD3’s ssh tunneling is usable here but Screen Sharing’s port 5900 connection is blocked. Fortunately the workaround is simple — build the ssh tunnel manually, as is normal for non-ARD3 VNC users. I have this alias:

alias stss='open /System/Library/CoreServices/Screen\ Sharing.app/; ssh -C -4 -L 5901:127.0.0.1:5900'

I use it with a hostname, as in: stss www

That makes an ssh connection to the specified host (www in this case), sets up a tunnel from 5901 on my admin workstation to 5900 on the server (since the admin workstation is likely to be running the Remote Management/Screen Sharing agent on 5900 already), and gives me a shell on www. As a convenience, it also launches Screen Sharing for me. In the Screen Sharing Connect window, I type 127.0.0.1:5901, and connect to the local end of the tunnel on port 5901; it goes through ssh and I get secure remote control via the ssh port (so it works across any firewalls that allow ssh). It’s actually doubly encrypted if I’m going across the Internet, since I always leave Screen Sharing’s encryption on too — if I forget to start the tunnel or connect to a machine that’s not firewalled on port 5900, I want to be sure I’m not transmitting passwords in plaintext.

Comments (4)

Mac OS X: Authentication Timers

I have been reading about Mac OS X 10.5 Leopard Server and non-Server lately, and I was surprised to realize how many different authentication & authorization systems are running each with its own timer.

  1. Access to the “console” (keyboard/video/mouse): Ends when you log out or the locking screen saver kicks in.
  2. Authentication for administrative actions in Carbon/Cocoa programs (such as modifying system directories in the Finder): 5 minutes (I believe).
  3. Apple Keychain: Doesn’t lock automatically unless you configure it in Keychain Access.
  4. ssh-agent (now linked to the Apple keychain): Clears when you reboot or when the Apple keychain locks.
  5. Kerberos V (both client-server and client-client): Apparently TGTs expire after 10 hours by default.
  6. sudo: 5 minutes by default.

Comments

Leopard Server’s Server Admin is NOT backwards compatible

Page 155 of Server_Administration_v10.5.pdf says “Mac OS X Server v10.4 servers can be administered using v10.5 server administration tools.”

Alas, they cannot; this means there’s no way to manage a Leopard and a Tiger system from the same box without screen sharing — something I and every other Tiger admin would like to do for the upgrade process! More generally, people who have upgraded to Leopard must use screen sharing to manage our Tiger Servers. Let’s hope Apple fixes this quickly — rather than after most of us have slogged through our own upgrades.

This version of Server Admin is not compatible with this server.

Comments (2)

As a system admin, excitement is generally bad: HVAC Oops!

machine room pictures

So today they cut the wires to our main machine room’s A/C. This occurred as part of the general campus work, which is why we were expecting to be out of our old machine room by now. Alas, the new machine room is not quite ready yet, so our primary systems were in a very warm room. It was a bit uncomfortable working there, although not too bad.

So around 3:30, my bosses (2) came over to ask me what could be shut down; in a perfect world, this would be just stringing a bunch of hostnames together, between “dsh -w” and “shutdown -h now” (for Linux) and “shutdown -y -g0 -i5” (for Solaris), from my desk. Instead I tromped over and started reading labels on servers (many of which were out of date — now updated!), and deciding what we could do without, calling users to ask them which machines could be turned off for a while. We had my boss, boss^2, and boss^3, as well as a bunch of the Plant Ops guys and their boss.

After I’d shut down a dozen or so, they told us the A/C might be back within 15 minutes (hooray!). The first repair didn’t hold (fuse immediately blew), but within 25 minutes we had (partial but insufficient) A/C, and I turned most things back on.

For a while we opened the door to the FDR drive, which cooled the room a bit. I got a few pictures of the drive and of blinkenlights.

Comments

Leopard: Turn “Allow guests to connect to shared folders” off

Setting up new Leopard (user) and Leopard Server systems, I was shocked to discover that, in System Preferences:Accounts:Guest, “Allow guests to connect to shared folders” is enabled by default. This is lousy security. Fortunately file sharing is off by default, but I turned file sharing on a day or two before I noticed guest access was enabled. I don’t want guest access enabled, and it shouldn’t be on without a conscious decision.

"Allow guests to connect to shared folders" is enabled by default

Comments