Netbooting MacBook Air

I had assumed that the driver for the USB Ethernet adapter was loaded at boot time, and not available to EFI. This would mean that you would not be able to NetBoot using the USB Ethernet adapter.

I assumed wrong.

While I don’t yet have a MacBook Air-compatible NetBoot (or NetInstall) image, the MacBook Air does attempt to NetBoot over its USB Ethernet interface:


Feb 15 09:53:10 xserve06 bootpd[1411]: BSDP DISCOVER [en2] 1,0:1e:c2:fb:b0:26 arch=i386 sysid=MacBookAir1,1
Feb 15 09:53:12 xserve06 bootpd[1411]: BSDP INFORM [en2] 1,0:1e:c2:fb:b0:26 arch=i386 sysid=MacBookAir1,1
Feb 15 09:53:12 xserve06 bootpd[1411]: NetBoot: [1,0:1e:c2:fb:b0:26] BSDP ACK[LIST] sent 172.30.160.46 pktsize 339
Feb 15 09:53:20 xserve06 bootpd[1411]: BSDP INFORM [en2] 1,0:1e:c2:fb:b0:26 NetBoot195 arch=i386 sysid=MacBookAir1,1
Feb 15 09:53:20 xserve06 bootpd[1411]: NetBoot: [1,0:1e:c2:fb:b0:26] BSDP ACK[SELECT] sent 172.30.160.46 pktsize 396


This is good news for our deployment – eventually we should be able to image MacBook Airs just like any other Mac.

MCX, dslocal, and the Guest account

MacOSXHints has a hint on customizing the Dock for Leopard’s guest account.

This turns out to be yet another application of MCX records in the local directory service. The idea can be expanded to customize lots more things the Guest account can and cannot do – just use Workgroup Manager to manage preferences for the Guest account!

Managing Office 2008

If you are thinking about deploying Microsoft Office 2008 in your environment, there are some preferences you should consider managing.

Microsoft has provided a high-level overview here. But it’s short on details. Here’s a few…

Time Machine MenuExtra management

10.5.2 places a Time Machine menuextra in the menu bar for all users.

We’re not encouraging the use of Time Machine in our organization. I’ve removed it from the default dock, and am managing the preference to prevent Time Machine from asking if you want to use each new external disk for backups. Users can still use Time Machine, we’re just de-emphasizing it. Therefore, I want to remove the Time Machine menu extra from the menu bar by default.

If you import the Preference Manifests in /System/Library/CoreServices/ManagedClient.app, you gain the ability to easily manage MenuExtras. But the Time Machine menu extra has not yet been added to the list of menu extras. No matter – you can edit it like so:

Just select Edit… from the popup menu and enter TimeMachine.menu instead of one of the pre-populated choices. You’ll see the little badge warning you that your entry does not match the manifest. That’s OK, it will still work. Setting the value to “false” will cause the TimeMachine menu to be removed from the menu bar at the next login.

I’m managing it once, so it’s off by default, but users can turn it back on if they want.

MCX, dslocal, and radmind

In an earlier article about putting MCX data into the local DS store, I mentioned that I’m using radmind to deliver the pieces to each client machine. Here’s a little more detail on that.

Enforcing FileVault on local accounts

New in Leopard is the ability to protect an account with FileVault as it is being created. When creating a mobile account, you can check the box to use FileVault, and this setting is easy to enforce with Workgroup Manager’s preference management as part of the Mobility settings.

If you use the Accounts preference pane to create a local account, you’ll see a new checkbox labeled “Turn on FileVault protection”, but it’s unchecked by default. What if your organization wants to ensure that all accounts — even purely local accounts — on laptops are protected with FileVault? With Workgroup Manager’s preference management, there does not seem to be a way to manage this setting in the Accounts preference pane. But you can manage it if you dig a little deeper…

MCX, dslocal, and Leopard

Recently on the MacEnterprise mailing list, several of us were discussing putting MCX records into the local directory service. This is an appealing idea to me, because we don’t use Open Directory, and I’ve never wanted to spend the political capital to get our LDAP schema extended to support MCX, especially since I didn’t really know if ManagedClient/MCX would actually do what we wanted.

MCX in the local directory service seemed to me a way to experiment without having to convince our LDAP admins to make schema changes.

Leopard homeSync changes

I haven’t seen this discussed or documented anywhere, so I thought I’d better write this down so I don’t forget:

It appears that Apple has made an interesting change to the homeSync behavior in Leopard. Top-level directories in the home dir that begin with a dot (like “.netscape”) are synced at login and logout, but not in the background. More accurately, they are treated like ~/Library.

Even more on autofs and Leopard

If you’re not yet sick of learning about Leopard’s new autofs implementation, Rajeev Karamchedu has written several excellent articles, which I just stumbled across today:

Autofs Goodness in Apple’s Leopard – Part I
Autofs Goodness in Apple’s Leopard – Part II
Integrating Leopard Autofs with LDAP

More on autofs

Adam’s comment on my previous post on autofs in Leopard reminded me of some other improvements over the legacy automount program I hadn’t mentioned:

Wildcards:
The legacy automount doesn’t support these at all. autofs supports these, so you can have map entries like this:


* -rw,hard,intr host:/export/apps/&


If this entry was in the map associated with the /apps mountpoint, then a `cd /apps/foo` would attempt to mount host:/export/apps/foo on /apps/foo.

-hosts map

A special /net map is defined in /etc/auto_master that automatically mounts all exports from a given host:

/net -hosts -nobrowse,nosuid

This option existed under Tiger on PowerPC, but was broken on Intel. To use it, you’d cd to /net/hostname. An `ls` then shows all the available exports from hostname.


aquaman:~ root# cd /net/french
aquaman:french root# ls
rel sw vol


Variable Substitution

autofs supports variables in automount maps. ARCH, CPU, HOST, OSNAME, OSREL, OSVERS, and NATISA are directly supported. Most are defined by uname:

ARCH = `uname -m`
CPU = `uname -p`
HOST = `uname -n`
OSNAME = `uname -s`
OSREL = `uname -r`
OSVERS = `uname -v`
(If you look at the output of `uname -v` on OS X, you’ll see this isn’t terribly useful in an automount map… )
NATISA (NATive Instruction Set Architecture) = currently the same as CPU. No distinction between ppc and ppc64 or i386 and x86-64.

You can define additional variables in /etc/autofs.conf – see `man autofs.conf` for details.
These variables can then appear in automount maps, and their values will be substituted. To get similar functionality with the legacy automount program, you needed to use a script that did text substitutions – substituting the correct values for variable references.

You can find more info in the man pages for autofsd, automount, automountd, autofs.conf, and auto_master.
Most of the info here for Linux autofs.5 is also relevant.