REALLY Weird Create User Pkg Issue

[Kevin]

I have been using Create User Pkg for a while to create admin user accounts on our Macs through policy. It has worked well.

I use this to activate the root account on our Macs at imaging. I set a user id of "0", set the home directory to /var/root/, set the account type to Administrator and assign a password. It has never been problem, until now.

We have a couple of systems that have Apple fiber channel cards to connect to our StorNext SAN. Running this install package (no payload, just a post-install script) kills the ability of the machine to copy files over fiber. Copper connections are unaffected.

I installed a base 10.8.5 OS and setup the Xsan client. Copying files on the SAN worked fine. I ran Composer to get a snapshot of the box, then ran the installer. I captured the difference file with Composer.
Here is s list of the files affected:
/Library/Preferences/com.apple.TimeMachine.plist
/Library/Preferences/OpenDirectory/DynamicData/Active Directory/MYDOMAIN.plist
/private/etc/krb5.keytab
/private/var/audit/20141105212456.not_terminated

The Time Machine file is essentially irrelevant, and there are also some files in ~/Preferences that are modified, but this issue is not user-specific, so I have not included those files in the list.

I unbound the Mac from AD and deleted these files. I restarted the unit and re-bound it. The files were re-created. No joy. NOTHING I have been able to do short of wiping the drive and re-installing the OS seems to restore the ability to copy files over fiber. ALL other functionality seems fine. This has been verified several times now with wipe/re-install/ re-test/ verify. With a clean system and NOTHING done except running this script, it will reliably fail.

Does anyone have any idea what could be happening?

Here is the script that runs in the payload-free package:

#!/bin/bash
#
# postinstall for local account install

PlistArrayAdd() { # Add $value to $array_name in $plist_path, creating if necessary local plist_path="$1" local array_name="$2" local value="$3" local old_values local item

old_values=$(/usr/libexec/PlistBuddy -c "Print :$array_name" "$plist_path" 2>/dev/null) if [[ $? == 1 ]]; then # Array doesn't exist, create it /usr/libexec/PlistBuddy -c "Add :$array_name array" "$plist_path" else # Array already exists, check if array already contains value IFS=$'�12' for item in $old_values; do unset IFS if [[ "$item" =~ ^ *$value$ ]]; then # Array already contains value return 0 fi done unset IFS fi # Add item to array /usr/libexec/PlistBuddy -c "Add :$array_name: string "$value"" "$plist_path"
}

ACCOUNT_TYPE=ADMIN # Used by read_package.py.
PlistArrayAdd "$3/private/var/db/dslocal/nodes/Default/groups/admin.plist" users "root" && PlistArrayAdd "$3/private/var/db/dslocal/nodes/Default/groups/admin.plist" groupmembers "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

if [ "$3" == "/" ]; then # we're operating on the boot volume

# kill local directory service so it will see our local # file changes -- it will automatically restart /usr/bin/killall DirectoryService 2>/dev/null || /usr/bin/killall opendirectoryd 2>/dev/null

fi

exit 0

[davidacland]

It sounds like you may be overwriting the system root user account with the create user package. If you are looking to add an admin account to the Mac I would use an id other than 0 and specify a different home folder. Not sure if that is the cause but it might be a contributing factor.

[Kevin]

I was using this as a method to enable the root account.

[bentoms]

Why not use:

dsenableroot

[Kevin]

…and set the root password by running the script in the package so the password was not sent in the clear.

[mm2270]

@bentoms beat me to it, but why not use dsenableroot for this? Trying to create a new account that overwrites root does not seem like a good idea to me. I'm frankly surprised it ever really worked without creating issues before.

[Kevin]

The problem is it is already done. It has not presented any issues on any systems EXCEPT these, and ONLY copying files on the SAN.

I need to figure out how to fix it. There are really only three files that get edited. But replacing those files have no impact.

[Kevin]

OK, take root out of the equation.

I used the Create User Pkg app to create a new user, named admin.

I get the same result. BTW, the user ID is NOT 0 on this one…

New OS install. nothing else on the box.

[Kevin]

Update.

The issue seems to be confined to 10.8. Running the same process on a 10.9.5 box works fine.

[davidacland]

Not sure if this is still relevant as it will go away of its own accord, but anyway...

Did you do a new & modified snapshot with Composer? None of the files listed would be relevant to Xsan or fibre connections AFAIK. Looking at the list I would say it must be missing some files. /var/db/dslocal/nodes/Default/users is missing which would be modified if a new user was added.

If there was something in /Library/Filesystems that would make sense

[Kevin]

@davidacland

Yes, that is what I did. I agree. Replacing these files with the previous versions that were known good did not resolve it. Mavericks is immune. Even to the point of simply running the Mavericks upgrade over the top of a broken system fixes it.