[Greg Neagle]

MCX settings described here: http://support.apple.com/kb/HT2653

But after looking at this, I also verified this works:

defaults write com.apple.iTunes disableCheckForUpdates -bool YES

And interestingly, this turns off the check and disables the checkbox in the preferences dialog. Works on iTunes 8, at least…

[Greg Neagle]

This is probably best done with MCX. The iTunes plists are weird – probably a hold-over from its Carbon heritage.

[Greg Neagle]

Using Portable Home Directories doesn’t actually help much, unless you sync _everything_ in the user’s home to the network. And even then, what happens if the user puts something in /Users/Shared?

In most environments, the network home quota is less than the available local space, so certain directories are not synchronized. If your users are OK with not having this data on new/replacement machines, then they are more forgiving than mine.

-Greg

[QUOTE][u]Quote by: pteeter[/u][p]I’m liking this topic as it applies to my current machine deployment scenario – mobile accounts with local home dirs.

But doesn’t the whole discussion beg this question…

Why the heck not just use Portable Home Directories?

I’m not using them yet either but…PHD’s almost eliminate the need for the whole discussion depending on how one might deploy filters on the PHD.

Nonetheless, I’m looking forward to testing those backup & restore scripts at some point.

[/p][/QUOTE]

[Greg Neagle]

Why do this as a loginhook? That requires someone to login! Are you using the logging-in username in the script?

It seems to me this is better suited as a script that runs at startup – either triggered by launchd, or as a StartupItem. This way it runs automatically after imaging and restart.

-Greg

[QUOTE][u]Quote by: amsterdam[/u][p]I’m not sure about the edu.mit.kerberos file, becuase that is usually created automatically. But, all the files under the /Library/Preferences/DirectoryServices folder will do.

BTW, I’m using a loginHook when the computer is first image to do the binding, and not using the file-copy method.

[/p][/QUOTE]

[Greg Neagle]

Looking through those scripts – they backup and restore the user DATA only. No attempt is made to preserve account information. This _is_ entirely possible, but the Bombich scripts make no attempt to do so.

-Greg

[Greg Neagle]

Maybe a little late for a reply (I’ve been on vacation!), but:

Firefox default settings

might get you started…

[Greg Neagle]

“Universal Access
-“Enable Access for Assistive Devices”

This one is easy:

sudo touch /private/var/db/.AccessibilityAPIEnabled

Though if you do it this way it only takes effect after a reboot.

-Greg

[Greg Neagle]

This is a perfect example of why mobile accounts should be managed at the computer/computer group level: there a machines where it makes no sense to have mobile accounts, and the AFP server itself is at the top of the list.

What are you trying to accomplish with a mobile account on the fileserver itself?

[Greg Neagle]

With Leopard, I’m of the opinion that there is no excuse now to NOT use Apple’s client management tools, AKA MCX, or policy, or whatever. Even if you don’t have a directory server, you can use the local DS to store policy settings.

There may be configuration changes that still require running systemsetup or networksetup, or other tools, but just about anything that you’re currently using the defaults tool to manage can be managed with MCX records.

This is a huge win for Mac OS X admins, as now ALL admins can take advantage of MCX, no matter what your infrastructure is.

For some ideas on how to use MCX in the local DS, see

https://www.afp548.com/article.php?story=using-mcx-in-the-dslocal-domain
and

MCX, dslocal, and Leopard

Since these settings are now stored as plist files in /private/var/dslocal/nodes/Default, you can capture them into a package (or packages) and make them part of an InstaDMG workflow.

[Greg Neagle]

If the account is actually on the LDAP server and not the OD master, just change or disable their password.

[Greg Neagle]

I’d recommend using the networksetup utility:

networksetup -setappletalk “Built-in Ethernet” on

Note that you’ll actually want to query the available network interfaces — Mac Pros have two Built-in Ethernet ports, “Built-in Ethernet 1” and “Built-in Ethernet 2”

-Greg

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]How would I enable AppleTalk on the Ethernet port in InstaDMG? Currently I have a script being kicked off by a StartupItem that tries the following upon first boot of a freshly imaged machine:

[code]appletalk -q -u en0[/code]

Which does work when run after the machine starts up. However, trying to make AppleTalk join to en0 before OS X is completely booted is likely a problem.[/p][/QUOTE]

[Greg Neagle]

I’d go for the dscl method, as that doesn’t lock you into your own version of he admin.plist file. In other words, if Apple changes that file in a future update, you won’t have to notice that and deal with it.

It just seems more in the InstaDMG spirit of things to remove dependancies and make things modular.

-Greg

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]Adding the user to the admin group can be handled by dscl inside the instauser script:

[code]/usr/bin/dscl . -append Groups/admin GroupMembership localadmin[/code]

or by replacing the admin group plist with an already-set-up admin.plist:

[code]/private/var/db/dslocal/nodes/Default/groups/admin.plist[/code]

– Patrick[/p][/QUOTE]

[Greg Neagle]

While you can create a new user by adding files to the local DS store in /private/var/db/dslocal/nodes/Default and the password hash file in /private/var/shadow, you’ll still need a post-install script to add the user to the admin group unless you set the GID of the new user to group 80, the admin group.

[Greg Neagle]

This edit should work in 10.4 as well.

[Author]

Posts