[larkost]

You do need to have both updates in, but in the right order. The update 2 does not require update 1, but update 3 does require update 2.

[larkost]

As a little plug: InstaUp2Date does have this correctly in the vanilla.catalog file. Even if you are not using InstaUp2Date it might be worth watching the vanilla.catalog file for a known-good list of updates that is in a known-good order.

[larkost]

I have a couple of images with Java on them, and have not seen a problem.

[larkost]

1) The packages that you produce go into: InstaDMG->InstallerFiles->InstaUp2DatePackages. The ones that InstaUp2Date downloads for you (from the vanilla.catalog file for example) get put in InstaDMG->Caches->InstaUp2DateCache.

2) Ya, that is a little confusing. I just checked in a change the new lines are:
[code]# The <> can be one of the following:
# name of a .pkg file in the InstaUp2DatePackages folder in InstallerFiles
# http: reference to be downloaded (a flat-file .pkg, a .dmg or a .zip of a folder)[/code]

3) The easiest way is to wrap the installer and the InstallerChoices.xml file in a .dmg. At one point you could just put them in a folder, but that code dropped away (I think), and the major revision that is in my head does not have to worry about that.

[larkost]

Three reasons:

1) The code does not just generate the checksum, but also the whole line you need to use.

2) This way it uses the exact same code as is used inside InstaUp2Date, so there is never any doubt that both will get the same result for a given file/directory.

3) For directories (not used so much right now, but they might make a comeback) I was not entirely sure that I wanted to checksum everything, so this allowed me to exclude things (like documentation). This code never actually got written. And directories were primary on my mind for #2.

[larkost]

It sounds silly, but I don’t have access to the document that produces the PDF… I will have to talk to Josh and remind him that we need the original document in SVN again.

[larkost]

Ya, if you start it up it will pull down the updates and cache them locally for you.

[larkost]

Actually, I keep such a thing as part of InstaUp2Date, and you can find the latest version at:

http://code.google.com/p/instadmg/source/browse/trunk/AddOns/InstaUp2Date/CatalogFiles/vanilla.catalog

I try to keep pretty close to the latest, but right now I am missing the latest iTunes and FrontRow updates. If someone wants to validate them, I will be happy to commit the changes.

[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.

[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]

[larkost]

You just have to tell DirectoryServices to reload it’s configuration files:
[code]killall -HUP DirecotyService[/code]
This must be run with root permissions (so: with sudo), and you don’t want to forget the ‘-HUP’ as without that DirectoryService will sometimes erase your changes.

But since this is a InstaDMG conversation, you don’t have to do this, since DirectoryServices on the target volume is not running, and will pick up things when you boot it for the first time.

[larkost]

The Apple Developer tools go right in with no problem. I did have a little trouble when I was trying to use the “old” style of InstallerChoices file, but with a wide-open version it works fine.

[larkost]

Then you are stuck with #1: Accept that the users are admins on these computers, and deal with the fact that they can mess around with anything they want.

Make sure that your management understands this, and that the management over both you and the end-users understands this as well. Then you have done everything you can reasonably do.

[larkost]

If you let users run as full admins, then they can do this. Trying to go back and plug the leaks so they can’t enable the root user at that point is going to be an exercise in frustration. You are better off going on of two other directions:

1) Accept that the users are admins on these computers, and deal with the fact that they can mess around with anything they want.

2) Do not grant the users full admin access, but rather create a group that has specific rights to do things such as installing software, and then twiddle with the sudoers file and /etc/authorization to provide them with these rights. Note: granting them permissions to install things means they can get creative and create their own packages to get root permissions. So this can only be seen as a bump, not an iron wall.

[larkost]

If you take apart the createUser package you will find that it installs the password as a file into /private/var/db/shadow/hash/. The file name needs to be the GeneratedUID from above.

[Author]

Posts