[Anthony Reimer]

Only sightly OT, but the latest updater is 12.1.5 and it is a “combo” update. That should simplify the troubleshooting a bit.

[Anthony Reimer]

If you run Mac OS X Server on any of your machines, you could set up a software update server, which would, by default, collect all the updates. You can also have the server e-mail you when it has collected an update.

For each point update of the OS, I still do a clean install of that OS version and then find out what updates are still needed (mostly to exclude updaters that got rolled into the current update).

Anthony

[Anthony Reimer]

Pepijn, your reply was very helpful. I did indeed try to include that monster package in my InstaDMG workflow, but it failed. I was able to get around the need to enter the serial number on install by packaging the “Final Cut Studio System ID” file that the installer leaves at /Library/Application Support/ProApps/. However, the Final Cut Pro installer only allows installation on the boot volume. So while I could use some of the packages (virtually all of the other apps worked but not the support files), the key one (FCPro) cannot be used that way. Nevertheless, it does seem to work as a standalone installer (with the changes Pepijn suggested), so I could either repackage or leave it out of my InstaDMG workflow entirely and simply push it out after the fact.

Thanks for everyone’s help.

Anthony

[Anthony Reimer]

Is there any reason that the password needs to be changed on the image rather than after deployment? Thanks to the help of the people who frequent this board, I learned that a single UNIX command, optionally pushed out via ARD, changes the password instantly:

dscl . -passwd /Users/username newpassword

I changed the local admin password for an entire lab in a few seconds.

[Anthony Reimer]

[QUOTE][u]Quote by: gneagle[/u][p][i]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…
[/i][/p][/QUOTE]

Well that would explain why I couldn’t login to that account without resetting the password! Thanks for the tip.

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.

Anthony

[Anthony Reimer]

Just a follow-up. Installing the …/users/restricted.plist file within the InstaDMG build did [i]not[/i] work. Manually running a package that installs the file once the image has been deployed does seem to work (a couple glitches, but nothing major).

[Anthony Reimer]

The first signs of success! Thanks to the pathnames Greg’s method revealed to me (i.e. /private/var/db/…), I have been able to come up with a solution that worked on first testing. In brief:

1. Create an InstaDMG build train with two users (one admin, one restricted). Build an image from it.
2. Deploy the image on a tester machine and set MCX settings for the restricted user using Workgroup Manager.
3. Make a package out of the file /private/var/db/dslocal/nodes/Default/users/[i]restricted[/i].plist (where [i]restricted[/i] is the short name of the restricted user).
4. Install the package on any machine with the deployed image. (I did this when the target was not the boot disk. I have not tested it while booted from the disk, like might be done with ARD.)

I’m going to add the package to the InstaDMG build train and see how it goes. I don’t see any reason for it not to work, but I’ve been wrong before.

So thanks to Greg for the archaeology. Thanks also to Patrick for suggesting whitelisting /Applications and blacklisting exceptions — using this method means that I can dispense with a third user account that I had previously deployed.

Anthony

[Anthony Reimer]

OK, I have finally been able to find some time to get back at this and have found the primary error of my ways. Basically, I assumed (yes, I made an [i]ass[/i] out of [i]u[/i] and [i]me[/i]) that because my old method (using NetInfo database) succeeded when I cloned a machine with the right settings that this would also be the case if I got the settings right using MCX. Nope. I need to do a little more testing, but I believe I have fallen into the MAC address trap that Greg described in his Macworld slides.

Ironically, if I take a completed image, add Parental Controls, then make an image of that, it works just fine. The problem with that solution is that Parental Controls are not granular enough, particularly with System Prefs. I’ll try some variations on both and post back when I have either a solution or another query. Thanks for the replies to date.

[Anthony Reimer]

[QUOTE][u]Quote by: Patrick Fergus[/u][p][i]If possible, can you log in as an admin and hold down the “Option” key when clicking “OK” and ask to “Refresh Preferences”?[/i][/p][/QUOTE]
No change in behaviour, other than losing one nicety with the login screen. Was worth a shot.

[quote][i]Are you bound to any directory system (AD, OD) with MCX-aware schema?[/i][/quote]
No. That might happen down the road (and, from what everyone here says, should be my goal), but right now, all that our server does is serve files.

I’m going to go back to the InstaDMG part of the image and try to get that smaller image working (might as well eliminate some possible sources of failure).

Anthony

[Anthony Reimer]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p][i]What are you attempting to whitelist? Could you just whitelist the directories (/Applications) that contain the applications?[/i][/p][/QUOTE]
I could and have considered that. The reasons I didn’t are (1) I have had problems deleting some Apple-provided apps (e.g., Mail) that seem to resurface any time you push out an OS update, (2) It would provide access to all utilities (I have been known to place maintenance utils like CacheOutX in there that I don’t want general users to access). I could reconsider on that one.

[QUOTE][p][i]Are you attempting to disable access to Preference Panes, or just require an administrative L/P (your choice of words of “lock down” is unclear).[/i][/p][/QUOTE]
Disable access to specific panes. There are a number of panes that do not require authentication to which I would rather not provide access. Conversely, I want users to have access to panes that are important to quality of their work, such as settings for Wacom tablets and sound output.

Anthony

[Anthony Reimer]

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.

[Anthony Reimer]

[QUOTE][u]Quote by: melmaninga[/u][p]Right now, I think I have come up with a solution that I am testing, but thus far it seems to work.
…
I am testing the licensing packages and can keep the forum posted if anyone is interested in the results.[/p][/QUOTE]

I am definitely interested. I’ve had to use a hybrid approach (core with InstaDMG, then layer on manual installs of FCStudio, CS4 and package-resistant installs), so anything that moves that core image further ahead would be great! Thanks.

Anthony

[Anthony Reimer]

This new solution worked perfectly for me. I believe the reason the manual fix may have previously failed for me was a simple permissions issue — I made the patch on my personal machine, which has different accounts than my testing/master machine.

Thanks for all the effort!

[Anthony Reimer]

The manual fix that mosen has supplied is not working for me. My InstaDMG install for Office is:
• 12.1.1 packaged install
• 12.1.2 update (modified)

I looked in the logs and found the following error:

installer: Error verifying Office 2008 12.1.2 Update package contents: JavaScriptError

At least it logged the failure! 🙂 Perhaps I will try again with mosen’s AppleScript.

[Anthony Reimer]

[QUOTE][u]Quote by: knowmad[/u][p]There is a much simpler way of doing this…
[/p][/QUOTE]

Since I have no literacy in authoring login/preflight/postflight scripts, that way is [i]not[/i] easier. Regardless, I did do something similar to create a 12.1.1 Office package, but now that 12.1.2 is out, I would have to do all of that work over again — [i]certainly[/i] un-InstaDMG-like. Pushing out the 12.1.2 updater via ARD after the fact is my current plan unless mosen’s fine work creates a suitable patch.

[Author]

Posts