beatworm.co.uk

Please allow me to introduce memberd!

Mac OS X is a funny kind of Unix as was its father NEXTSTEP. And it’s a still a family trend. Maybe it’s the final glimmering remnants of its once-trendy microkernel heritage, maybe it’s an attitude influenced by all the ‘networks of directory services are better than forests of flat files’ thinking behind NetInfo and Open Directory, it doesn’t really matter why. There’s a host of system daemons running away on the Macintosh of today, some quite unfamiliar to users more used to the more traditional Unixes (or Unix-alike) operating systems. Collections of daemons managing system services aren’t anything new of course, but many of these have unfamiliar names. They replicate entire UNIX subsystems with unfamiliar, perhaps unexpected solutions. It’s just like Unix yet still unlike Unix.

Some of them date all the way back to antique NeXT releases. Like lookupd , which looks things up in directories. You might be more familiar with it in it’s guise as ‘every now and then my computer stops resolving certain addresses’ , necessitating a quick ‘ sudo lookupd -flushcache ‘ (one word, single dash, minimally intuitive). Others like configd are newer, (introduced in the transition to Mac OS, responsible for maintaing different ’states’ of machine configurations such as the network ‘locations’ feature), or the excitingly named, but ultimately rather prosaic blued (responsible for the rather wonderful mac bluetooth implementation, but on first encountering it running I wondered if it was providing all the blue in the Aqua GUI). And then there’s the bang-up-to-the-minute, hipper than hip new Tiger-only ones. Chief amongst them the slicing, dicing, init/cron/xinetd replacement and more that is launchd .

All of these have man pages to investigate, some of them are quite configurable, and can be fun to experiment with - especially launchd. I’m not sure how long memberd has been around for, but it was new to me today, when I stumbled across it.

As I keep a loosely organised collection of jumble-sale-quality Unix boxes, I place value in keeping my login account numeric uids synchronised across various systems I use. It obeys the principle of least surprise and is useful when network file sharing, especially via NFS. I also appreciate the access control features UNIX groups can offer to multiple users. I don’t care enough about either to actually invest in some enterprise-class networked directory service, nor am I enough of a wannabe systems administrator to aspire to wrestling such a monster into seving my will. So I generally shell in ad-hoc and adjust such things on a host by host, account by account sort of basis, as the situation demands. On OS X this can mean interacting with NetInfo, but that’s okay, I’m weird enough to quite like NetInfo, I’ve known it a while.

So today I was fiddling with some group permissions, and I actually ended up making a couple of groups entirely redundant. So I removed them from NI completely. After I was done I noticed from running id , that I was still a member of a couple of them. More oddly, the system could still identify them by name. So I panicked, assuming I’d deleted a set of NetInfo keys that were in entirely the wrong dictionary. On inspecting the damage it all looked fine. Then I realised that group membership changes were one of those things that are fixed in your environment, cached by the login shell. So I logged in and out. Still no good, the phantom groups persisted. Mental alarm bells were ringing at this point, so I started doing some digging. Walking through the list of running processes and poking at man pages led me to find memberd.

It starts up at system boot and keeps running. It has a fine man page. It seems to be how OS X 10.4 resolves user group membership. More pertinently, it maintains a cache of such information. This cache can be flushed when stale by running

memberd -r

from a root shell. And that fixed my all my troubles. Well, it got rid of the sticky invalid groups anyway.