[Greg Neagle]

Did you check to see if your new MacBooks shipped with a later build of 10.5.7 than the one on your NetBoot startup disk? If so, you may need to build a new NetBoot/NetInstall disk from the DVDs that shipped with the new MacBooks.

-Greg

[Greg Neagle]

[QUOTE][u]Quote by: tlarkin[/u][p]By default all local accounts have a UID of 500 to 999 and all open directory accounts, be portable or network have a UID of 1000 or greater. You can maybe do it by UID I think[/p][/QUOTE]

While that’s the current behavior of OS X and Open Directory, I wouldn’t rely on it. And if you are using any directory service other than Apple’s Open Directory it’s unlikely to follow Apple’s conventions as far as UIDs.

-Greg

[Greg Neagle]

I don’t know if it’s fixed or not. I’m still managing Screen Saver the way I described in the blog article, and for me, the “require password” checkbox is still grayed out.

-Greg

[Greg Neagle]

scutil only operates on the currently booted volume, so you can’t use it to change things on the InstaDMG diskimage.

Once Karl gets the the whole chroot stuff working 100%, it _might_ work, but I wouldn’t count on it.

[Greg Neagle]

Do you really need to know if it’s a network account, or do you just need to know where the home directory is?

Here’s how I detect local accounts in a login hook:

#!/bin/sh
USERNAME=$1
LOCALACCT=`/usr/bin/dscl . read /Users/$USERNAME 2>/dev/null`
if [ “$LOCALACCT” != “” ]; then
# $USERNAME is a local account
else
# $USERNAME is a network account
fi

and here’s how I get the home dir (no matter the account type) in a login hook:

#!/bin/csh
set homedir=~$1

Note that I used /bin/csh in the second example. /bin/sh won’t do the same thing.

There are other ways to do these.

[Greg Neagle]

As of Leopard, you can’t launch just any random app at the loginwindow. Background apps are OK, but anything that has a GUI must be specially written. iHook was specifically updated so it could show a GUI at the loginwindow. Apple also states that any app that shows a window at the loginwindow must NOT show a menubar.

Therefore you are limited to those applications that have been properly written to display at the loginwindow.

Some of the issues are described here:
http://developer.apple.com/SampleCode/PreLoginAgents/listing3.html

-Greg

[Greg Neagle]

Any particular reason you can’t just combine both of these actions into a single script?

[Greg Neagle]

Once you create a mobile account, it is essentially a local account as far as most of the rest of the OS is concerned. This means augmented records will no longer apply, as the augments are used in combination with a specific directory service – in this case, AD. Since your mobile account information is not in AD, the augments don’t apply.

I’m guessing Apple did not take augmented records into account in their mobile account creation: what would have to happen is that the createmobileaccount process would have to create the local account as a synthesis of the primary directory service record + the applicable augment record from the secondary directory service, and then keep everything in sync. It sounds from your description that the mobile account is created using only information from the primary DS.

For your specific case, I’ll bet you can work around the HomeSync issue by using dscl to edit the OriginalHomeDirectory attribute to point to your desired smb: share, similar to this article: http://managingosx.wordpress.com/2009/02/19/leopard-mobileaccounts-and-nfs-homes/

Alternately, you may be able to use the createmobileaccount tool and pass the desired SMB URL via the -u option.

[Greg Neagle]

[quote][i]Since it uses the GeneratedUID, it looks like I will have to learn how to do some sort of post-restore script to make this work.[/i][/quote]

No, the GeneratedUID is in the username.plist. As long as it matches the name of the file in /var/db/shadow/hash, no scripting needed. Just install both files.

-Greg

[Greg Neagle]

To install a fully-functioning user, you need to install the user’s plist at /private/var/db/dslocal/nodes/Default/users/username.plist and also the shadow password hash, which is located in /private/var/db/shadow/hash/ and named after the GeneratedUID of the user:

dscl . read /Users/username GeneratedUID
GeneratedUID: B7CBD232-AA9C-4E57-A130-7AF46FD46F31

-Greg

[Greg Neagle]

I’m now seeing a similar issue – and this is a recent development as of 10.5.6 (and maybe 10.5.5). I have not yet figured out the trigger.

-Greg

[Greg Neagle]

Where are your user’s home directories according to the user accounts in LDAP?

You need to have NFS mounts at the same path(s).

Either fix your static mounts, implement appropriate automount maps (either as local flat files or in LDAP), or static map the NFSHomeDirectory attribute in the LDAP mappings to point to the right place….

But in any case:

dscl /LDAPv3/ldapserver.myorg.com read /Users/usershortname NFSHomeDirectory

must point to a valid path for each user, or they won’t get the right home dir.

-Greg

[Greg Neagle]

We’ll need to do some more experimenting to figure out this alternate syntax.

I tried feeding this xml file to installer against the iLife-08 installer:

[code]



attributeSetting

choiceAttribute
visible
choiceIdentifier
iWeb

[/code]

like so:

sudo installer -showChoicesAfterApplyingChangesXML /tmp/choices.xml -pkg /Volumes/iLife\ \’08\ Install\ DVD/iLife\ \’08.mpkg -target /

And as might be guessed, iWeb stayed selected for install, but the choice was made invisible (like that’s useful at the command-line…):

[code]

childItems

choiceDescription
This package installs iWeb ’08.
choiceIdentifier
iWeb
choiceIsEnabled
choiceIsSelected
1
choiceIsVisible

choiceSizeInKilobytes
293520
choiceTitle
iWeb
pathsOfActivePackagesInChoice

file://localhost/Volumes/iLife ’08 Install DVD/iLife ’08.mpkg/Contents/Installers/iWeb.pkg


[/code]

So I edited /tmp/choices.xml like this:

[code]



attributeSetting

choiceAttribute
selected
choiceIdentifier
iWeb

[/code]

and tried again. Looks better:

[code]

childItems

choiceDescription
This package installs iWeb ’08.
choiceIdentifier
iWeb
choiceIsEnabled
choiceIsSelected
0
choiceIsVisible
choiceSizeInKilobytes
293520
choiceTitle
iWeb
pathsOfActivePackagesInChoice

file://localhost/Volumes/iLife ’08 Install DVD/iLife ’08.mpkg/Contents/Installers/iWeb.pkg


[/code]

It seems like it’s far most useful to control the “selected” attribute, rather than “enabled” or “visible”, which seem to be relevant only in the GUI…

It also looks like you must provide a separate dict for each choiceIdentifier+choiceAttribute combination:

[code]



attributeSetting

choiceAttribute
selected
choiceIdentifier
iWeb


attributeSetting

choiceAttribute
enabled
choiceIdentifier
iWeb


attributeSetting

choiceAttribute
visible
choiceIdentifier
iWeb

[/code]

results in:

[code]

childItems

choiceDescription
This package installs iWeb ’08.
choiceIdentifier
iWeb
choiceIsEnabled

choiceIsSelected
0
choiceIsVisible

choiceSizeInKilobytes
293520
choiceTitle
iWeb
pathsOfActivePackagesInChoice

file://localhost/Volumes/iLife ’08 Install DVD/iLife ’08.mpkg/Contents/Installers/iWeb.pkg


[/code]

Note that “choiceIsEnabled” is set to false; “choiceIsSelected” is set to 0, and “choiceIsVisible” is set to false, though I’m still not certain why’d you want to control anything other than “choiceIsSelected”.

I wonder if there is an undocumented place one could insert a choices.xml file into a package bundle that would then be used by Installer.app to provide different default choices in the GUI?

-Greg

[Greg Neagle]

More details on your process are definitely needed. LocalMCX is easiest to understand and deploy when you are managing settings for all users of a given machine – in that case, the settings are stored in computer records or computergroup records. When you manage computers or computergroups, it can be as simple as copying few files into the right places.

It’s certainly possible to add local MCX data to locally-defined users, but you’ll have to either modify createUser to inject the MCX data as it’s creating the users, or write some script that can find your local users and merge the MCX data into them.

Personally, I think it would be far easier to create the users on another machine, use Workgroup Manager to apply MCX settings, then capture the relevant files (/private/var/db/dslocal/nodes/Default/users/myadminsuser, /private/var/db/shadow/hash/$GeneratedUID, etc) and install them with a package or packages. This way you don’t have to use dscl to regenerate the MCX settings.

With your current image, use mcxquery and system_profiler SPManagedClientDataType to see what the MCX settings are for each user. You can also launch Workgroup Manager and look at the appropriate local records.

-Greg

[QUOTE][u]Quote by: jazzace[/u][p]Local MCX settings were a showstopper for me this month. I went over everything I could find on this board and did go over Greg’s MW2009 slides. Let me go through my process in case someone can see the point of failure:

Goal:
Leopard Image with three local user accounts: general user (whitelist apps and system prefs), instructor (standard account), and admin. Payload is 66 GB (!!), as it includes Final Cut Studio and Adobe Creative Suite. Deployed to 30 stations in labs (often use FW800 drives hooked up locally due to image size). Only ARD is available for systems management.

Process:
(1) Get as much packaged and installed as possible using InstaDMG workflow. Create at least the admin and general user account in that workflow using createUser.
(2) Place InstaDMG-generated image on a test machine and do the rest the old fashioned way (i.e. image a “golden” machine and deploy from that). Right now, “the rest” is Final Cut, CS4 and some customizations that are outside of my skill set right now (e.g., I don’t have any shell scripts that run at first launch after deployment).

Result:
Some MCX settings do not stick upon deployment. In the worst case, it ignores the application whitelist and blocks everything.

In desperation, I also tried using Parental Controls, but could not lock down the System Preference panes individually. Am willing to hear any thoughts and expertise.[/p][/QUOTE]

[Greg Neagle]

They work fine; sync happens at login, in the background while logged in, and at logout. The user’s home directory is mounted and available, and syncs happen normally.

-Greg

[Author]

Posts