The MacEnterprise steering committee has been talking about doing this
for way too long, but the recent lack of significant IT tracks at WWDC
has spurred us into action.

MacEnterprise is planning to partner with various other groups to get
a Mac IT focused conference started.

This is all very much up in the air, and at this stage we’re seeking
input as to how the community would like this conference to be
organized.

At this stage, we would like you to provide input on Google Moderator
as to ideas for the conference. You can submit ideas as well as vote
on other ideas here:

http://goo.gl/mod/4COQ

Additionally, there is some discussion going on on Twitter, under the
#MacITConference hashtag.

http://twitter.com/#search?q=%23MacITConference

Once we get a little bit better idea of the structure, we’ll be
calling for speakers and looking for sponsorship partners.

http://www.lavenderhell.com

The things that go on inside her head…

So even though we have reasonable packages out there for Puppet and Facter, some people prefer to install this sort of thing through MacPorts, the closest thing we have to a third-party packaging repository on OS X.

Anyway, Puppet and Facter are both out now.

nigelk@sillymidon [/Users/nigelk]
$ port search puppet
puppet @0.24.8 (sysutils)
Puppet is a configuration management solution.
nigelk@sillymidon [/Users/nigelk]
$ port search facter
facter @1.5.4 (sysutils)
A cross-platform library for describing OS attributes.


http://blogs.adobe.com/OOBE/

I’m really glad to see they’ve done this, but am still reserving judgment until we actually see some results from it…

I poked around a bit looking for something that did this, and couldn’t find anything, apart from some sample code using a private API to send the display to sleep, so I whacked that into a screeensaver.

https://sites.google.com/a/explanatorygap.net/misc-sw/files/SleepSaver.saver.zip

This does use a private API and thus could do anything. No warranties, may destroy your machine, etc etc etc, but works for me.

code:

//
//  SleepSaverView.m
//  SleepSaver
//
//  Created by Nigel Kersten on 1/29/09.
//  Copyright (c) 2009, Google Inc. All rights reserved.
//

#import "SleepSaverView.h"

@implementation SleepSaverView

- (id)initWithFrame:(NSRect)frame isPreview:(BOOL)isPreview
{
self = [super initWithFrame:frame isPreview:isPreview];
if (self) {
if (! isPreview) {
[self dimDisplayNow];
}
}
return self;
}

- (BOOL)hasConfigureSheet
{
return NO;
}

- (NSWindow*)configureSheet
{
return nil;
}

- (void) dimDisplayNow {
io_registry_entry_t r = IORegistryEntryFromPath(kIOMasterPortDefault, "IOService:/IOResources/IODisplayWrangler");
if (r) {
IORegistryEntrySetCFProperty(r, CFSTR("IORequestIdle"), kCFBooleanTrue);
IOObjectRelease(r);
}
}

@end

http://developer.apple.com/technotes/tn2005/tn2083.html

This is really just going here so I can find it again as I can never remember what keywords to search with to find it and I often need to refer to it.

AAAAA+++ Excellent TechNote Would Read Again kthxbye

Presentation here:

So as host, ping, nslookup, dig etc don’t use the same resolver path as the rest of the OS, we used to always use lookupd for this.

It’s not exactly the most obvious solution in the world, but since lookupd, netinfod and memberd were all rolled into DirectoryService in 10.5, we now use dscacheutil to do this.


$ dscacheutil -q host -a name www.google.com
name: www.l.google.com
alias: www.google.com
ip_address: 74.125.19.104
ip_address: 74.125.19.147
ip_address: 74.125.19.99
ip_address: 74.125.19.103


This is a much more appropriate way of debugging host problems if the *nix tools aren’t showing any problems but OS X components are.

This will fetch the result from the cache, and if it’s not there, fetch it and place it in the cache. If you want to make sure this is a fresh request, do:

dscacheutil -flushcache

and you can always do this:

dscacheutil -cachedump -entries host

to inspect the cache for hosts.

I was actually debugging a Mobile Account problem the other day where the user agreed to create a mobile account at the loginwindow, and yet it kept logging them in with the network account.

Inspecting the DirectoryService cache with:

dscacheutil -cachedump -entries user

showed that the /Local/Default entry for that user was never retrieved. Flushing the cache fixed it.

Turns out the user said no to creating a Mobile Account once, and then logged out without rebooting (and didn’t tell us they’d said no ;-) ). OS X kept the cached entry around and failed to update when creating the Mobile Account as it should have.

Need to get that one into radar….

And along similar lines to the afp548.com article on this, Greg Neagle written a similar piece describing how he’d use it in his environment (and it even has screenshots …).