[MacTUG] Using deploystudio on built macs

Tue Apr 9 11:46:24 EDT 2013

I am starting to manage Macs, beyond just our lab macs. That means getting them on AD and enrolling them in Profile Manager on the 10.8 server. It is a pain to do manually (mainly the typing in the fully qualified object name), especially as a few people are doing it here,  so I decided to set up deploystudio workflow to do this to existing (i.e. Built) Macs.

I thought I would share the process so far as it seems to be working. There are three components to the workflow, a script and two meta-workflows:

The first part of the workflow is a script that just sets the startup disk. I wish deploystudio had a built in task that controls the startup disk, but it does not. If you are initialling an OS from a disk image (the usual use of deploystudio) usually you have the checkbox turned on to have that installed OS be the default start-up volume. However if you are not using that task in your workflow, after the workflow is complete, the computer will continue to reboot onto the deploystudio netboot image. The script is simple, and likely could be more elegant, but does the trick…

#!/bin/sh
echo "set_startup_disk.sh - v0.1 ("`date`")"
# Get Volume
VOLUME=`mount | grep hfs | grep disk0 | cut -c 17- | cut -d " " -f1 | head -1`

echo " Setting Startup Disk to ${VOLUME}"
bless -mount "${VOLUME}" -setBoot

echo "set_startup_disk.sh - end"
exit 0

I started to write it up and then googling about I realized that someone else had done one that was simpler than mine. http://deploystudio.wikispaces.com/set-startup-disk.sh It is important that the execution of this script is not postponed to reboot (obviously, or the thing will never be run, haha). The cut portion is not that elegant. If you had more than ten partitions on a disk it likely would not cut the correct portion of the info from mount, but that is not something I am going to worry about ;-) I added the "head –1" part to deal with more than one partition on one disk

The second part is a  meta-workflow for binding to AD. There are a couple of differences from how I have this configured versus the meta-workflow I use in my lab build:

  1.  since it is the first action to happen, I have the target volume set to 'user selection' versus 'previous task target'.
  2.  Computer ID is set to hostname
  3.  Automate is not turned on – I want to give people the option of editing the 'computers node' to the correct path for the computer. Otherwise I have the computers node set to a folder in our OU for macs that have not been presaged. If the mac was prestaged if goes where the placeholder is

Last part is a metaworkflow that enrols it in profile manager. I have am  using a different enrolment profile than my lab enrolment profile. I have my lab enrolment profile to only enrol computers with placeholders, but in this case I want it to enrol a computer that does not have a placeholder

While the above all works, there is the issue of using deploystudio in this manner in a safe way. Most of the workflows on my deploystudio server are pretty destructive (e.g. Reformatting and rebuilding a lab computer). The thought of my coworkers using deploystudio on someones existing (and already built and in use) computer was a bit scary! So I have used Deploystudio's 'access group' feature to ensure that my coworkers can not access these destructive workflows when they are merely trying to bind the mac to AD, etc.

  1.  On the Mac OS X Server,  I created 2 groups. One called deploystudio-admins had the pre-existing user that deploystudio uses for automated installs. The second one had all the MAD staff accounts in it (their bang accounts actually). I want these users to be able to use this deploystudio workflow (but not the dangerous ones). For both of them I ensured that they could access file sharing on the server.
  2.  Using Deploystudio Assistant I went and reconfigured my server install of deploystudio and I created 'DS runtime' group for the deploystudio-admins group that I created
  3.  I Then started deploystudio Admin and went to the workflows section. For all the 'dangerous' workflows (and ones I just did not want other people to use) I set the access group to be 'deploystudio-admins'. For the safer workflows I left them alone (thereby ensuring any user of the server that had file sharing access could use them.
  4.  Back in deploystudio assistant, I created a USB boot disk. When I created it I did not include a default login nor password, wanting MADstaff to enter their bang account. When the disk image on the USB drive boots, the users enter their bang account and credentials. They only see the safe deploystudio tasks.

I have tried this on a few machines, that are not in my deploystudio computer list nor in AD and it seems to work. I have not released this for general consumption in my group but u can play with it if u want ;-)

I am also making other deploystudio workflows for use on modifying existing computers (such as adding common packages), I will likely be able to reuse lots of workflow parts to do so.

One last note: To do this, I have to have deploystudio set to allow unknown computers to connect. Often we have Deploystudio set so that only known computers in the Deploystudio database can connect. It would be more trouble than it is worth to add computers to the DS database just to bind them to the database or add the occasional package. Given that I mentioned that some of the workflows on Deploystudio are fairly 'destructive' I have minimized the risk of them being accidentally used (for example some staff person net booting on and rebuilding their computer as a lab machine) by a few methods: 1) I have firewall running on that computer and net boot services are only accessible on a subnet that ONLY contains lab computers, 2) I usually only turn those net boot images on during lab rebuild times, 3) In Netinstall I have set it to only allow certain types of Macs to net boot, and I will (when I figure out how to import in a CSV file) only allow a list of hardware addresses to net boot from those images.

If anyone has any questions, just ask.

------------------------------------
Donald Duff-McCracken
Technical Services Manager
Mapping, Analysis & Design
Faculty of Environment
University of Waterloo
(519) 888-4567 x32151
https://uwaterloo.ca/environment-computing/about/people/donald-duff-mccracken

------------
To request help from MAD please use Request Tracker. For info see:
https://rt.uwaterloo.ca/~wwwrt/cgi-bin/rtuser.pl

------------
This email communication is intended as a private communication for the sole use of the primary addressee and those individuals listed for copies in the original message. The information contained in this email is private and confidential and If you are not an intended recipient you are hereby notified that copying, forwarding or other dissemination or distribution of this communication by any means is prohibited.  If you are not specifically authorized to receive this email and if you believe that you received it in error please notify the original sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uwaterloo.ca/pipermail/mactug/attachments/20130409/9f923759/attachment.html>