Deploying MCX with InstaDMG

[kennyj]

Hello, please forgive me if this has been answered elsewhere… I’m a bit new and haven’t been able to figure out the answer to this yet.

I have MCX files created and am dropping them into my InstaDMG images with a package. This part works perfectly; but I still need to edit the entries when the machine boots. I took a script I found in these forums that works perfectly, however I’m not sure how to get it to run on first boot only one time. I tried using launchd by placing the script and the plist in the correct spots with a package. However this did not seem to work. Is there a better or easier way of doing this?

Oh yeah, I also have another script I need to run once upon first boot to set ARD, VNC, and SSH settings.

Thank you,
Ken

[larkost]

(going in roughly reverse order)

If you are having trouble getting launchd to work, my best guess is that you have a permissions problem. launchd items must be owned by root, and be group ‘wheel’. Anything else and it won’t run.

But for ARD, VNC, and SSH settings you should not need startup scripts to set those. Instead use PackageMaker to record file changes for you while you set the settings, and then look at the files that changed during the process. With a little weeding, and some looking at the plists that actually changed, you should be able to create a package with only the files you need changed to make the settings.

I have gone away from run-once scripts completely on my images. Instead a collection of scripts runs at every startup and each checks if it needs to run (where possible that check is in the launchd plist). If a full run is not needed then I have only lost a fraction of a second. This has the nice effect that if something gets messed up it is easy to have to the script automatically fix it.

Specifically with local MCX I would strongly recommend . Here is the script I use for that:
[code]
#!/bin/bash

# this script adjusts the MAC address that is stored in the localhost computer item
# this should be run at every boot

/usr/sbin/networksetup -detectnewhardware # just to make sure that it is done

DSLOCAL_COMPUTER_NAME=’localhost’
DSLOCAL_COMPUTER_UID=’AAAABBBB-CCCC-DDDD-EEEE-FFFFGGGGHHHH’

PRIMARY_MAC_ADDRESS=`/sbin/ifconfig en0 | /usr/bin/awk ‘/ether/ { print $2 }’`

if [ `/usr/bin/dscl . -list /Computers | grep -c “$DSLOCAL_COMPUTER_NAME”` -lt 1 ]; then

/usr/bin/dscl . -create “/Computers/${DSLOCAL_COMPUTER_NAME}” generateduid “$DSLOCAL_COMPUTER_UID”
/usr/bin/dscl . -append “/Computers/${DSLOCAL_COMPUTER_NAME}” comment “This is the local computer. This is used to manage it into local groups.”
/usr/bin/dscl . -append “/Computers/${DSLOCAL_COMPUTER_NAME}” name “localhost”
/usr/bin/dscl . -append “/Computers/${DSLOCAL_COMPUTER_NAME}” realname “This Computer”
/usr/bin/dscl . -append “/Computers/${DSLOCAL_COMPUTER_NAME}” ip_address “127.0.0.1”

fi

if [ `/usr/bin/dscl . -read “/Computers/${DSLOCAL_COMPUTER_NAME}” en_address | grep -c “$PRIMARY_MAC_ADDRESS”` -ne 1 ]; then

/usr/bin/dscl . -delete “/Computers/${DSLOCAL_COMPUTER_NAME}” en_address
/usr/bin/dscl . -append “/Computers/${DSLOCAL_COMPUTER_NAME}” en_address “$PRIMARY_MAC_ADDRESS”

/usr/bin/killall loginwindow
fi

exit 0
[/code]

[kennyj]

Thanks larkost… I think part my problem may be the permissions on the launchd plist files… I’ll check those out. The other part to the problem I think is that I was deleting the script as well when it was finished… obviously that wouldn’t work from itself, and it doesn’t need to be removed anyways. I’ll take another poke at it and see what I get. I built the plist files with lingon… do you suggest writing them manually instead, or is this ok to do? I’ve been using the Users Daemons (/Library/LaunchDaemons/)… is this also correct?

As for the suggestion on the ARD settings… I’ll give your suggestion a try.

Thank you again for your help!

[larkost]

I usually use Lingon myself, and then switch to the “advanced” view and copy out the results into another file (just easier for my methods).

And I keep forgetting the people have worked out that the ARD setting tool can target non-booted volumes, so you could also do it that way. Some people are creating payload-less packages with a script that sets up ARD this way. If you go that route, then it will be more likely to still be what you want when Apple makes any changes to ARD.

And you should be able to delete a script from within itself, I have done that in the past myself. But I am coming around to the idea that this is not the best practice for most reasons.

[kennyj]

Building a new image right now… we’ll see what happens.

[kennyj]

Ah, it’s working just fine… i was just impatient and didn’t restart it… settings are visable after a reboot.

Thank you for your help… now to figure out how to push security settings

[Author]

Posts