Category Archives: Technical Stuff

Disabling “secured” IPv6 addresses is macOS 10.12 Sierra

On older macOS versions, every network interface would have one IPv6 address autogenerated from its MAC address, easily identified by the characteristic “ff:fe” bytes in the middle of the host part:
$ ifconfig en0
ether 10:dd:b1:9f:6b:ba
inet6 fe80::12dd:b1ff:fe9f:6bba%en0 prefixlen 64 scopeid 0x4
inet6 2001:7c0:2012:4a:12dd:b1ff:fe9f:6bba prefixlen 64 autoconf

Since macOS 10.12 however, these were replaced with randomly-generated “secured” addresses:
$ ifconfig en0
ether 10:dd:b1:9b:d0:67
inet6 fe80::46:3b36:146:9857%en0 prefixlen 64 secured scopeid 0x4
inet6 2001:7c0:2012:4a:4e6:f1d1:dd90:c6b4 prefixlen 64 autoconf secured

Very little is known about these, besides a single mailing list post that discovered them. If you are running a server, you’ll want your IPv6 address to be deterministic so you can register it in DNS. Therefore, we need to revert to pre-10.12 behavior:

$ echo net.inet6.send.opmode=0 >> /etc/sysctl.conf
$ reboot

If you look at the source code of the XNU kernel (Search for the IN6_IFF_SECURED flag) and the IPConfiguration service in macOS 10.11 (the 10.12 source code hasn’t been released yet), you can see that the new behavior was already there, just not enabled by default like it is now. Also, we now know that the change wasn’t made to reflect RFC 7217 (Semantically Opaque Interface Identifiers) behavior, but rather implements RFC 3972 (Cryptographically Generated Addresses).

Fixing Microsoft Office 2011 SP2 Volume licensing

UPDATE 2012-11-15: The 14.2.5 installer no longer has this weird behavior (it does not include removables.txt files at all, however the postinstall script would still process them if they were there). Since it requires 14.2.3 as a prerequisite, you’ll still need to apply the fix mentioned below to 14.2.3 when chaining updates.

UPDATE 2012-11-30: I just obtained a copy of the 14.2.3 installer ISO from Microsoft VLSC. Copies of Office installed from it (or probably any 14.2.0+ installer ISO) do not exhibit the behavior explained here. The newer installer ships with flat-file Main.nib files that do not get removed by the removables.txt script.

UPDATE 2013-03-13: The 14.3.2 updater again contains a removables.txt which breaks Microsoft Office Setup If you didn’t replace your installer ISO with a newer version, you will again need to apply the fix mentioned below when installing this update.

When you run Word, Excel, PowerPoint or Outlook 2011, it checks /Library/Preferences/ . If that file is not valid (such as after doing a fresh install of Microsoft Office 2011), it launches /Applications/Microsoft Office 2011/Office/Microsoft Office Setup Microsoft Office Setup Assistant checks whether the DVD from which you installed is a volume licensed copy; if it is, it silently populates that plist and quits (allowing the app you initially started to start up); if it is not, it prompts you for a product key and activation.

If you install from the DVD, launch one of the Office apps to activate the license, quit it and then install all the available updates from Microsoft, everything is fine.

If you update to version 14.2.0, 14.2.1, 14.2.2, 14.2.3, 14.2.4 (or possibly future versions) right after installing from the DVD however, Microsoft Office Setup gets corrupted. This is due to ./Office 2011 14.2.X Update.mpkg/Contents/Packages/Office2011_all_core_14.2.X.combo.pkg/Contents/Resources/removables.txt, which gets run by ./Office 2011 14.2.X Update.mpkg/Contents/Packages/Office2011_all_core_14.2.X.combo.pkg/Contents/Resources/postflight. It deletes the contents of /Applications/Microsoft Office 2011/Office/Microsoft Office Setup (which is a bundle-style NIB), however (unlike probably everything else listed in removables.txt) the update does not contain updated versions of them.

If you’re running an individually-licensed copy of Office 2011, that is no big deal: the Office apps themselves are able to prompt for a license key and activation.

If you’re running a volume licensed copy of Office 2011, you’re in trouble: You now get prompted for a product key by every Office app, which you obviously don’t have.

To fix this situation, you have two options:

1. Copying /Library/Preferences/ from a working install. You can do this using your favorite software depolyment tool, such as Munki. Please note that importing it as a Managed Preference (MCX) into Workgroup Manager (and probably Profile Manager) does not help. The file needs to be physically present on the client machine.

2. Move Microsoft Office Setup out of the way before updating. You can do this if your software deployment tool supports adding custom pre- and post-install scripts (Munki allows you to do that).

Here’s my pre-install script:

cd "/Applications/Microsoft Office 2011/Office"
mv "Microsoft Office Setup" ""
exit 0

And my post-install script:

cd "/Applications/Microsoft Office 2011/Office"
mv "" "Microsoft Office Setup"
exit 0

To find out whether you still need to do this on future updates (such as 14.2.5), open the installer package in a tool like Pacifist and check the following: a) Did they remove the  Microsoft Office Setup lines from removables.txt (go to the Resources tab and enter removables.txt into the search box to locate the file)? b) Does the update contain a new version of Microsoft Office Setup (go to the Package Contents tab and enter setup assistant into the search box to check for its existence)? If either one is true, Microsoft decided to fix the problem and you no longer need to use my pre-/post-install scripts.

Extending Active Directory for Mac OS X clients

After I wrote about building your own OpenDirectory server on Linux a while back, I decided to do the same thing on Windows Server 2008 R2. The process of extending the AD schema to include Apple classes and attributes is documented by Apple (this is the Leopard version of the document – if you don’t plan on having exclusively Snow Leopard clients, you can follow the newer version of the document that skips a couple of things that Snow Leopard no longer needs).

But since schema extensions are generally frowned upon in the Windows world because they’re irreversible (why the heck, Microsoft…?), I initially tried a dual-directory (golden triangle, magic triangle) type approach where I’d be augmenting my AD with Apple records coming from an AD LDS (Active Directory Lightweight Directory Services, previously called ADAM, Active Directory User Mode, which is basically a plain LDAP server from Microsoft). While this may sound like a great idea, I just couldn’t get it to work. After dozens of manual schema extensions to AD LDS (Microsoft doesn’t include many standard LDAP attributes, so I had to dig through the dependencies of apple.schema and even tried importing a complete OD schema), I gave up because I could not get Workgroup Manager to authenticate against it to allow me to make changes.

So the next thing to do was follow Apple’s AD schema extension guide (linked above) and do what everybody else did. This was rather straight-forward (managed preferences for users, groups and computers worked right away), but when I tried to create a computer list (which is not possible using Snow Leopard’s Server Admin Tools, but requires Tiger’s (which throw loads of errors on Snow Leopard but still get the job done) since Leopard introduced computer groups which however are not supported by the AD plugin), it just said I didn’t have permission to do that. After enabling DirectoryService debug logging (killall -USR1 DirectoryService && killall -USR2 DirectoryService), I traced it down to Active Directory: Add record CN=Untitled_1,CN=Mac OS X,DC=xxx,DC=zz with FAILED – LDAP Error 19 in /Library/Logs/DirectoryService/*. Apparently, that’s caused by some versions of ADSchemaAnalyzer setting objectClassCategory to 0 instead of 1 on all exported classes. Too bad AD schema extensions are irreversible and that’s one of the attributes you can’t change later on… 🙁 Well, with AD Schema Management MMC snap-in, I was able to rename the botched apple-computer-list class, defunct it and add a new one using ldifde. With some really wild hacking in the AD Schema using ADSI Editor, I was then able to  eventually get OS X to no longer look at the renamed attribute, but instead at the new one. To see whether you have been successful, killall DirectoryService, wait a few seconds and grep -H computer-list /Library/Preferences/DirectoryService/ActiveDirectory* will show a line indicating which class in the schema it’s using.

Once you’re there, everything should work as expected. If you don’t want to use Tiger’s Workgroup Manager to create old-style computer lists, you can do that in ADSI Editor and create apple-computer-list objects in the CN=Mac OS X branch by hand.

So, attached is the schema ldif that’s exactly the way it should be. I really wonder why Apple doesn’t provide it themselves – it’s going to turn out exactly like that every time you follow their guide on any Windows server… Apple Schema for Active Directory

I guess that the overall conclusion of this should be that AD schema extensions in general and specifically Mac OS X managed clients in AD environments are a nasty hack. I suppose the dual directory/magic triangle/golden triangle approach with a Microsoft AD and an Apple OD would work, but it requires maintaining two separate directories, which may not be that great in a larger environment either.

If Apple discontinues Mac OS X Server at some point in the near future (which the demise of the Xserve and the lack of announcements regarding Mac OS X 10.7 Server alongside Mac OS X Lion suggest), this is definitely something they need to improve. There are some third-party solutions that store MCX settings outside of AD (similar to Windows GPOs, which are stored on the SYSVOL share) such Thursby ADmitMac – however that’s a rather expensive solution (a dozen client licenses costs about as much as two Mac mini servers) and might break after OS updates (though from what I’ve heard, they’re rather quick at providing updates). If Apple does discontinue Mac OS X Server, they should definitely improve Lion’s AD integration to replicate ADmitMac’s features.

Slim down Final Cut Studio’s Media Content using HFS Compression

A full installation of Final Cut Studio 3 with all media content (for Motion, DVD Studio Pro, and Soundtrack Pro Loops) takes up around 40-50 GB of hard drive space.
How about regaining 5-10 GB of precious by enabling HFS compression for these folders? Since HFS compression is completely transparent, there are no adverse effects to expect (other than browsing the content libraries being almost unnoticeably slower).

To start, you’ll need a command-line tool called afsctool which can compress (and, amongst other features, decompress) folders using HFS compression. The command you’ll need to run is e.g. sudo afsctool -c -l -k -v -i -9 /Library/Application\ Support/Final\ Cut\ Studio. This compresses all files the given folder using the highest possible compression, verifies its results, prints out the names of files it is unable to compress, and outputs statistics once it’s done.

Some of the folders I compressed:
/Library/Application Support/Final Cut Studio/ (contains Motion and DVD Studio Pro templates): 22.5% compression savings
/Library/Application Support/LiveType/ (contains Motion’s LiveType fonts): 11.4% compression savings
/Library/Application Support/GarageBand/ (contains GarageBand’s  instruments and learning-to-play stuff): 14.3% compression savings
/Library/Application Support/iDVD/ (contains iDVD’s themes): 19.5% compression savings
/Library/Audio/Apple Loops/ (contains GarageBand’s and Soundtrack Pro’s loops): 4.1%
/Library/Audio/Impulse Responses/ (contains  Soundtrack Pro’s impulse response data): 41.3% compression savings

Looking at the compression savings: everything that contains high-quality video can be compressed by around 20%, while audio which is already heavily compressed only yields around 5%. The most amazing result though are the 40% by which the Impulse Responsed were compressed – apparently, these are uncompressed AIFF audio files and thus ideal for compression.

Obviously, your mileage may vary and I’m not responsible if you compress too much and break your system (I’m sure there is a reason why Apple didn’t compress all system files). However, compressing the iLife and Final Cut Studio media content appears safe, I haven’t noticed any unwanted side-effects and it seems well worth trying if you’d like to regain a few gigabytes.