Archive for the ‘macosx’ Category

Using managed preferences in the local DS domain on Macs

Saturday, January 26th, 2008

Longer article up at AFP548.com, but basically I’ve been playing around a fair bit with MCX in DSLocal lately, and there are a lot of interesting applications….

It’s so nice to be able to just manage plists now…. NetInfo I miss you not at all.

Post Macworld 2008

Friday, January 25th, 2008

So my webhost managed to mess up all htacess files and thus lock me out of my blog for a couple of weeks. I considered briefly posting via MySQL, but then dragged myself back into the realm of the sane and just waited it out. Apologies to the comments that were awaiting moderation…. My resolution is to actually blog more this year, so I’ve started trying out MarsEdit to see if being able to work offline improves the situation….

Another Macworld is over. To be honest, this one was a bit too hectic to really enjoy as a pure punter, and besides, I missed what was a brilliant match where India broke Australia’s record equalling winning streak in Perth.

Schoun Regan and I did the two day PowerTools conference on Advanced OS X Server, then Jeff McCune and I did a shorter presentation and demo on Puppet that seems to have provoked some interest in the MacEnterprise crowd.

The few other talks I managed to make it to were quite good, even given the difficulty of catering to the very wide range of technical ability in a Macworld crowd… I thoroughly enjoyed Andrina Kelly’s Lucid System Administration presentation, some of our Google techs were inspired by Kevin White’s Neutered Admins talk, and I heard lots of good reports about Greg Neagle and Philip Rhinehart’s System Imaging and Deployment two day session.

The two highlights of the week for me were firstly that Joel managed to work the optical inch into his Directory Services talk. Nice work….

Secondly would have to have been seeing Devo in the flesh. Thanks to Dave Pugh (you need to get that blog going Dave…), I now have much better photos than my mediocre camera gave….

Devo were simply awesome. I was prepared to have all my illusions shattered… but they put on an awesome performance….

Wrapping ‘defaults’ to be more flexible…

Thursday, November 22nd, 2007

So I don’t know about any of you, gentle readers, but ‘defaults’ really gives me the shits sometimes.

Exhibit A:

/ $ defaults read /Library/Preferences/com.apple.loginwindow.plist
2007-11-21 13:12:04.288 defaults[97501:10b]
Domain com.apple.loginwindow.plist does not exist
/ $ defaults read /Library/Preferences/com.apple.loginwindow
(snip actual working output)

Exhibit B:

  / $ cd /Library/Preferences
/Library/Preferences $ defaults read ./com.apple.loginwindow.plist
2007-11-21 13:13:24.327 defaults[97540:10b]
Domain ./com.apple.loginwindow.plist does not exist
/Library/Preferences $ defaults read ./com.apple.loginwindow
2007-11-21 13:13:25.799 defaults[97546:10b]
Domain ./com.apple.loginwindow does not exist

This really annoys me, that ‘defaults’ firstly doesn’t accept the full path to the plist, when other tools like ‘launchctl’ do, and requires that you strip off the “.plist” from the end, and secondly, that you can’t use relative paths.

This annoyed me so much that I decided to finally do something about it. This function resolves both problems.

function defread { defaults read $(echo "$@" | sed "s|\./|`pwd`/|g" | sed "s|.plist||g"); }

And now we can do:

/ $ defread /Library/Preferences/com.apple.loginwindow.plist
/ $ cd /Library/Preferences
/Library/Preferences $ defread ./com.apple.loginwindow.plist

or even:

/Library/Preferences $ defread ./com.apple.loginwindow.plist SHOWFULLNAME
1

mmmm.

Making parts of the filesystem read/write from NetBoot

Monday, October 30th, 2006

So we use NetBoot (well NetInstall really) a lot here for diagnostics and as a platform for radminding machines from.

I’ve recently been refactoring our entire Radmind setup here, mainly because we’ve been using it for so long that we’re not actually taking advantage of any of the features Radmind has introduced in the last couple of years.

As part of this, I’ve been trying to avoid using our existing radmind wrapper script, and instead to try and do everything using the supplied ra.sh script, with appropriately configured preapply/postapply scripts, which is working rather nicely so far.

Anyway, to get to the point of this post, I worked out that if I wanted to use ra.sh while booted from a NetInstall image, I really needed /var/radmind to be read/write, which it isn’t.

After poking around through the /etc/rc.cdrom script, I noticed that Apple do things this way:

echo "Creating RAM Disk for /private/tmp"
dev=`hdik -drivekey system-image=yes -nomount ram://2048 `  # 1MB
if [ $? -eq 0 ] ; then
  newfs $dev
  mount -o union $dev /private/tmp
fi

which is all rather dandy when you think about it. hdik is creating a 1Mb RAM disk, and then it is mounted as a union mount at /private/tmp, effectively making that directory read/write.

The only problem is that our Radmind transcripts take up about 40-50Mb, and you can’t use hdik to make a RAM disk of that size, which I imagine is a limitation of the fact that hdik is intended for rather lightweight disk images, being an in-kernel tool and all.

So I started poking around trying to work out how to use hdiutil to accomplish the same thing, but it turns out that hdid is actually far simpler. Rather than being an in-kernel tool, it will actually use the DiskImages.framework, which means the disk image limitations don’t hold.

So here’s what I add to /etc/rc.cdrom.postWS to create 96Mb of r/w space in /var/radmind

# Create r/w mount for /var/radmind and populate it with the file structure
echo "Creating RAM disk for /var/radmind"
dev=`hdid -nomount ram://196608` # 96Mb
if [ $? -eq 0 ]; then
  newfs $dev
  mount -o union $dev /var/radmind
  mkdir /var/radmind/cert
  mkdir /var/radmind/client
  mkdir /var/radmind/postapply
  mkdir /var/radmind/preapply
fi

and now everything is peachy.

wtfdtfd ? : A wiki-like system for the Mac OS X file system…

Thursday, September 28th, 2006

So I’m rather close to deploying a closed beta test of something that I’ve been working on in my spare time for a while now.

The basic idea is that you can browse a copy of the Mac OS X filesystem, and any registered user can attach “annotations” to a file or directory explaining what that file does. This is done with a wiki-like system, so any user can edit the annotations, or roll back to previous versions.

The main impetus behind this was me trying to train up someone at work to take over the radmind setup we have. It really doesn’t take long to learn how something like radmind works, but what does take time is working out exactly what files do, and whether you should include a particular file in any given transcript or not.

Thus the name “wtfdtfd” == “wtf does this file do?” …

It’s also been a way for me to finally start a proper project in Ruby on Rails, which I’ve been meaning to do for a while now.

I’ll be opening up the source to interested people after I deploy it, so if you’re interested in taking part in either coding or a private beta, send me an email by clicking on the “About” tab at the top.

Edit:
If you want to take part, the easiest way is to subscribe to the dev-list, which you can do by clicking on this link.

Subscribe to wtfdtfd dev-list

Thanks for the input people, it’s looking good…. :)

PlistBuddy is the shiznit..

Friday, July 14th, 2006

So I’ve been meaning to start using PlistBuddy for a while, and this morning I ran into a real need for it.

Unbeknownst to me, we had a problem with our imaging system where a machine would be freshly imaged, and it would retain the LocalHostName and ComputerName of the imaged machine until the next reboot.

(We normally set these values to “hostname -s” as part of a StartupItem)

Anyway, I wanted to set these values when machines are booted from our custom NetInstall image, and quite frankly, using “defaults” with nested dictionaries can sometimes either be an absolute pain in the ass, or impossible.

Obviously someone at Apple realised this a while ago, which is why they invented PlistBuddy. If you do “locate PlistBuddy” from a shell, you’re likely to see it in all sorts of Apple packages, and I feel perfectly comfortable simply stealing one of them…

PlistBuddy lets you easily write nested values and merge dictionaries into each other.

Here’s the two liner that lets you set the relevant values (as root/sudo etc)

$ PlistBuddy -c "Set :System:Network:HostNames:LocalHostName $(hostname -s)"  \
/Library/Preferences/SystemConfiguration/preferences.plist
$ /PlistBuddy -c "Set :System:System:ComputerName $(hostname -s)" \
/Library/Preferences/SystemConfiguration/preferences.plist

And for us we just point it to /Volumes/System/Library/… etc as that’s where the SOE partition is while NetBooting.

Much nicer than using defaults…

Moving the hibernate image file on a MacBookPro…

Thursday, June 8th, 2006

So I like to partition my Macs so that my user directory is on a different partition to the system drive.
I got kind of frustrated when I got my MacBook Pro and realised that due to having 2Gb of RAM, the hibernate settings by default were taking up an extra 2Gb on my system partition with the sleep image file at /var/vm/sleepimage.

After poking around with pmset for a while, I realised that you can move the image file…

sudo pmset -a hibernatefile /Volumes/OtherVolume/sleepimage

Then trash /var/vm/sleepimage, and all seems hunky-dory…

There are some other useful settings I’ve seen people mention on the web, like setting:

sudo pmset -a  hibernatemode x

Where x is an integer meaning:

  • 0 – disable hibernate mode.
  • 1 – hibernate when shutting the lid instead of sleeping.
  • 3 – normal hibernate settings.
  • 5 – hibernate when shutting the lid instead of sleeping (with secure virtual memory turned on)
  • 7 – normal hibernate settings (with secure virtual memory turned on)

I wonder what the even numbers do…

How OS X launches Applications…

Monday, April 3rd, 2006

Quickie: A very nice article on how OS X launches applications and a follow-up Q & A.

Greg Neagle's Managing OS X blog…

Thursday, March 30th, 2006

I’ve just added a link to it in the side column, but it’s well worthwhile checking out Greg Neagle’s Managing OS X blog.

There are getting the screensaver to work over the loginwindow, several, really, good posts on using Portable Home Directories without Open Directory.

Forcing Mobile Home Directories to another partition.

Thursday, February 9th, 2006

So we never keep our user’s local home directories at /Users, primarily so that we can always blow away the boot partition with our imaging system without worrying about user data.

We’ve started using Mobile Accounts for some of our desktop users due to some limitations in the OS X Server AFP server, and it was kind of bugging me that new Mobile Accounts would always get created at /Users/username, and we’d have to faff around with niutil in order to change this after the account had been created.

So I’ve managed to work out a LoginHook that will force Mobile Accounts to another location, even on the first login… I’m just showing part of it here, the bit that deals with such users, so some bits might strike you as the long way round…

#!/bin/bash
#

homes_disk="/Volumes/Storage"
local_homes="/Volumes/Storage/Users"

lookup_local=$(niutil -read . /users/$1 2> /dev/null)
if [ "$lookup_local" != "" ]; then
        is_local=1;
else
        is_local=0;
fi

# If they are a local user.
if [ $is_local -eq 1 ]; then
auth_prop=$(niutil -readprop . /users/$1 authentication_authority 2> /dev/null \
				   | grep LocalCachedUser)

# If they are a mobile user.
if [ "$auth_prop" != "" ]; then
  logger "LoginHook: Started for Mobile Account - $1"
  home_location=$(niutil -readprop . /users/$1 home)
  # If their home directory hasn't been moved to $local_homes yet.
  if [ "$home_location" != "$local_homes/$1" ]; then
      logger "LoginHook: Moving home from /Users/$1 to $local_homes/$1"
      if [ -e $homes_disk ]; then
        mkdir -p $local_homes
        chmod 1755 $local_homes
        chown root:admin $local_homes
        /System/Library/CoreServices/mcxd.app/Contents/Resources/MCXCacher \
        -U $1 -h $local_homes/$1
        ditto /Users/$1 $local_homes/$1
        rm -Rf /Users/$1
        sleep 2
        lookupd -flushcache
        sleep 2
      else
        logger "LoginHook: ERROR! Could not find $homes_disk"
      fi
  fi
    logger "LoginHook: Finished for Mobile Account - $1"
else
		logger "LoginHook: Not running for Local non-Mobile Account - $1"
fi

# If they are not local, they must be a network user.
else
	logger "LoginHook: Started for Network Account - $1"
	# Do your stuff for network users here.
	logger "LoginHook: Finished for Network Account - $1"
fi