[dmueller]

I had just recently set up something similar to this for some kiosk systems we use.
You can make an installer with a little design effort and you can use dscl to export out the managed setting you want to use (Example from 10.6.8, may differ some with Lion).

Create the user (testuser in this case) and enable parental controls
Open parental controls and make any desired modifications.
Open Terminal, cd to you location you want the export you parental control settings to and:
[code]sudo dscl . -mcxexport /Users/testuser -o parental_controls.plist[/code]
You can now use it as part of an installer/script to create and set the user as managed. An example script I used for an installer:
[code]#!/bin/bash
if [[ $UID -ne 0 ]]; then echo “Please run $0 as root.” && exit 1; fi

dscl . -create /Users/kiosk
dscl . -create /Users/kiosk UserShell /bin/bash
dscl . -create /Users/kiosk RealName “Kiosk”
dscl . -create /Users/kiosk UniqueID “1010”
dscl . -create /Users/kiosk PrimaryGroupID 20
dscl . -create /Users/kiosk NFSHomeDirectory /Users/kiosk
dscl . -passwd /Users/kiosk kiosk
dscl . -mcximport /tmp/parental_controls.plist
srm /tmp/parental_controls.plist
defaults write /Library/Preferences/com.apple.loginwindow “autoLoginUser” ‘kiosk'[/code]
In the above example, I had the kcpassword file used by autologin (dropped into /private/etc) and the parental_controls.plist dropped by the installer. Just substitute your user and password. The kcpassword file would be captured from you creating this previously with the desired account info.

It took a little sifting through Google, but with the information I found, I was able to get this to work well (for a local account).

As mentioned, this will essentially be a local MCX policy for the Managed User.

Best of luck.

[dmueller]

This should give you a rough idea:

[code]#!/bin/bash

# Check to make sure we are root
check_root() {
if [ `whoami` != “root” ]
then
/bin/echo “You need to be root to do this. Run the script using sudo.”
exit 0;
fi
}

AutoUpdate() {
# Make sure the system is updated with any current software updates.
sudo softwareupdate -i -a
}

OfficeUpdate2011() {
# Update Office 2011 to 14.1.2 – temporary workaround
echo “Updating Office 2011 manually to 14.1.2”
if [ -e “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg” ]; then
installer -package “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg”
if [ -e “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg” ]; then
installer -package “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg”
fi
fi

echo “Updating Communicator for Office 2011 manually to 13.1.1”
if [ -e “/usr/local/scripts/Communicator Installer.mpkg” ]; then
installer -package “/usr/local/scripts/Communicator Installer.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Communicator Installer.mpkg”
fi
}

Cleanup() {
srm “$0”
}

# Call the functions in the following order
check_root
AutoUpdate
#OfficeUpdate2011
Cleanup[/code]

[dmueller]

Sure thing.

I use a manual script to affect configuration changes after the image has been dropped to disk. I do this because we will, depending on the system, add the Application DVD utilities (iLife, CPU tools, etc) before delivery to the end-user. The post setup will name the machine, add it to Active Directory, modify the networks services, etc. I also will have it run softwareupdate to patch the system and iLife. I would place it in the same location (/usr/local/scripts/postsetup.sh for example).

As for the Microsoft patches; The SP1 (14.1.0) and update 14.1.2 are available at mactopia.com
Communicator is a bit more difficult to find. I had to trace it with Wireshark while downloading the 13.1.1 update through Microsoft’s Autoupdate utility.

Why do I have it set as a function? So it is easy to remark out of the script without having to comment out all of the lines. It helps keep the script modular too.

The piece I posted is just a function within the larger script.

I would post an example if I could get it past the spam block 🙁

Regards,

Edit: How I add them to the disk image: I created and installer through Iceberg that drops the files in that location from a custom catalog file through Instadmg

[dmueller]

One other alternative you can use is through a post setup script (needs to be run with sudo). Here is an example function I have used to solve the patching problem for now without having to modify the mpkg files:

[code]
OfficeUpdate2011() {
# Update Office 2011 to 14.1.2 – temporary workaround
echo “Updating Office 2011 manually to 14.1.2”
if [ -e “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg” ]; then
installer -package “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Office 2011 14.1.0 Update.mpkg”
if [ -e “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg” ]; then
installer -package “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Office 2011 14.1.2 Update.mpkg”
fi
fi

echo “Updating Communicator for Office 2011 manually to 13.1.1”
if [ -e “/usr/local/scripts/Communicator Installer.mpkg” ]; then
installer -package “/usr/local/scripts/Communicator Installer.mpkg” -target / > /dev/null
rm -R “/usr/local/scripts/Communicator Installer.mpkg”
fi
}
[/code]

14.0.2 was already incorporated through Instadmg on my base image. This piece is part of a postsetup script that makes some additional setting adjustments, as well as applying softwareupdates.

Kind regards,

[dmueller]

I have tried a few different things with distribution.dist and one or two of the scripts (office_updatable) in Resources to no avail (short of generating cool errors in the debug logs). Microsoft Update seems to go, but none of the package updates apply. The patch works great in munki and ARD but not through DeployStudio (even as a firstboot install) nor Instadmg. I wish I was a little more fluent with the installer scripts, but at least they added notes to in the scripts 😉

[dmueller]

Try a full path and be sure to run checksum.py on it. Here is a consistent working example that I use:

[code]Installer Disc Builds: 10J3210

ISO Language Code = en

Output Volume Name: Macintosh HD
Output File Name: QC_Mac_1067_10J3250_TB_test.dmg

Base OS Disk:
# the first one should be disk 1 of an installer disk
# this is not yet implemented

Installer Choices File: /Users/[profile]/Dev/instadmg/InstallerFiles/BaseOS/InstallerChoices.xml sha1:390db880591bec5ff37d92aa2bcb4d21b5639d46[/code]

Best of luck.

[dmueller]

It looks like some changes took place in the office_update script that may explain why this installer is not cooperating.

[code]# Get install location
#install_location=os.path.dirname(mso_folder)
# 2011-02-25 – The updater now uses the full path in the updatables, so used installer volume (“/”) instead of mso_folder (“/Applications/”)]
# This also allows us to use updatables in /Library
install_location=os.path.dirname(install_volume)[/code]

This distributes fine through ARD, but not through DeployStudio, nor Instadmg. I’m kind of surprised as nary a search engine pulls anything much up on people trying to distribute this update.

[dmueller]

Thanks Nate.

[dmueller]

I just tried this with the new update (14.1.0) and it fails to apply through Instadmg.

Nate, Is there a list of things you modify through your patcher that I could use as a reference?

Regards,

-Dennis

[Author]

Posts