[Bartron]

Update:

changing my apple class to the folowing appears to have worked:

class “Applei386” {
match if substring (option vendor-class-identifier, 0, 14) = “AAPLBSDPC/i386”;
if (substring(option vendor-class-identifier, 0, 14) = “AAPLBSDPC/i386”){
option dhcp-parameter-request-list 1,3,17,43,60;
filename “mac107-test/booter”;
if (option dhcp-message-type = 1) {
option vendor-class-identifier “AAPLBSDPC/i386”;
option vendor-encapsulated-options 08:04:81:00:00:67;
}
option root-path “http://foo.com/Resources/Images/stdimages/mac/NetRestoreTest.nbi/NetInstall.dmg”;
}
if (option dhcp-message-type = 8) {
option vendor-class-identifier “AAPLBSDPC”;
if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) {
option dhcp-parameter-request-list 1,3,17,43,60;
filename “mac107-test/booter”;
option vendor-encapsulated-options
01:01:01:
09:0c:81:00:00:01:07:6e:65:74:62:6f:6f:74;
option root-path “http://foo.com/Resources/Images/stdimages/mac/NetRestoreTest.nbi/NetInstall.dmg”;
} else {
option dhcp-parameter-request-list 1,3,17,43,60;
filename “mac107-test/booter”;
option vendor-encapsulated-options
01:01:02:
08:04:81:00:00:01;
option root-path “http://foo.com/Resources/Images/stdimages/mac/NetRestoreTest.nbi/NetInstall.dmg”;
}
}
}

I get a kernel panic but at least it’s a panic from a kernel it’s downloaded. I haven’t updated the nbi for quite a while so I’m going to create a current netboot set and see how that goes.

Our process has moved on to not include netbooting but getting it working is always a bonus.

[Bartron]

Been away for a while and theres some new posts here 🙂

ok, here’s what I have going right now and it seems to work pretty well. Works as a network based install or can be made to be standalone.

Firstly go and get Packages from WhiteBox (free – http://s.sudre.free.fr/Software/Packages/about.html). I’ve fount it to be really easy to use, much more than package maker.

Next you want to write a script for the application you want to install. Some apps are just drag and drop from a DMG, some will be a .pkg or .mpkg.

For the drag and drop style apps I get the dmg into /tmp (one of two ways, will expand on later), mount it and copy the .app to /Applications
For example, for Firefox I script the folowing:

hdiutil attach -nobrowse /tmp/Firefox_16.0.1.dmg
cp -Rf /Volumes/Firefox/Firefox.app/ /Applications/Firefox.app
hdiutil eject /Volumes/Firefox
rm /tmp/Firefox_16.0.1.dmg


Then in Packages I create a payload for firefox and either include the DMG to deposit into /tmp or create a pre-flight script to download from a server via http. This lets me create either a small, lightweight installer that downloads everything else or create a big fat installer that includes all the files I need. The other cool thing about this way is I can create payloads that always get installed and payloads that are optional.

The script for a .pkg (or .mpkg) is similar. e.g. for installing Flash (required for my workplace)
hdiutil attach -nobrowse /tmp/install_flash_player_osx.dmg
installer -pkg /Volumes/Flash\ Player/Install\ Adobe\ Flash\ Player.app/Contents/Resources/Adobe\ Flash\ Player.pkg -target / -verboseR
hdiutil eject /Volumes/Flash\ Player/
rm /tmp/install_flash_player_osx.dmg

(for flass I also do the following
# ensure flash is set to auto update
mkdir /Library/Application\ Support/Macromedia
flashCfgFile="/Library/Application Support/Macromedia/mms.cfg"
echo "AutoUpdateDisable=0" > "$flashCfgFile"
echo "SilentAutoUpdateEnable=1" >> "$flashCfgFile"

# run flash auto update in the background
/Library/Application\ Support/Adobe/Flash\ Player\ Install\ Manager/fpsaud &

)

I code an individual install script for each app and setting and get installer to run them.

The I build to a flat .pkg which can either be downloaded from a server or put on a USB key. (pro tip, get yourself a developer certificate and you can tell Packages to sign the .pkg when you build it. Then you can leave gatekeeper setting alone)

One important thing to remember is the order in which Installer executes a .pkg. There is the payload, pre-install and post install scripts. Installer will first execute all the pre-install scripts. It will then copy the payloads and then execute the post-install scripts. So, if you have 10 payloads it will execute the pre-install scripts for all the payloads before copying the payloads to wherever you want them. Also the “time remaining” is calculated from running the pre-install scripts and copying the payloads. Once installer reaches the post-install scripts the time remaining skips to “about 1 minute” and will stay there until it finishes, regardless how long it actually takes.

so my setup is this:
pre-install – either download the app to install or otherwise prepare any necessary folders
payload – if present, dump to /tmp or in the case of things like default user profiles and company wallpapers to wherever they need to go
post-install – install the app and cleanup.

This is all probably way out of scope for what installer was designed to do but I don’t really care. It works for us and lets me provide a professional looking installer that takes a vanilla OS X install and turns it into a system ready to roll out.

I also do other stuff as part of the install like download and run a small app I wrote that re-names the computer and joins it to the domain (among other things). All up it takes about 15 minutes to complete about 1.8GB of installs (10 minutes of that is just Office 2011).

I’m not sure how much more detail I can go in to without getting into stuff specific to my organisation but that’s the basic gist of it. Takes be about half a day to go through all my payloads (about 23) and make sure all apps and settings are up to date and repositories have the latest versions, then I can forget about it for another month or two.

[Bartron]

[QUOTE][u]Quote by: csumb[/u]
ewww, going to scrounge up a box and try testing as well. If it does work thats not remotely scaleable for us but would be good to know that somehow when our core is handing off the DHCP traffic its dropping something that mac is expecting[/p][/QUOTE]

yeah. How’s limiting to a class C useful in any environment (outside a classroom). doesn’t make sense.

I have a mini so I’m going to run up a copy of OS X server as well and stick that on various subnets, run up wireshark and see what happens. I’m only in it for my own curiosity at this stage though.

Anyone would think Apple didn’t give a flying F about the enterprise market 😉

[Bartron]

[QUOTE][u]Quote by: airlocksniffer[/u][p]We actually got this to work. What we found is that the newer firmware cannot get an IP address while netbooting when the DHCP server is on another subnet and falls back to the internal drive. We fired up an old HP server for DHCP and put it, the lion server and client on the same subnet and it works fine. I need to test whether or not I can netboot when the client is on one subnet and the dhcp/lion server are on another. [/p][/QUOTE]

On a class b or class c?

Either way that would mean we would need something like an extra 10 tftp servers to service all locations not on the same subnet as the dhcp server.

Gives me something to test though, thanks for the info.

[Bartron]

Other than a request to “try with the new firmware”? No.

I closed my bug ticket though so I don’t expect to hear anything further (still haven’t heard from them about an older bug I found using ARD to unlock your desktop without your password but that’s another story).

Anyway, I implemented an in-house developed scripted install method around 3 weeks ago and so far everyone is impressed. Takes about 10 minutes and the end result is a fully managed, branded, configured, adjusted install with domain authentication and all corporate apps installed and for the most part it’s hands-off (there’s about a 1 minute QnA at the end to name the computer and join the right OU). Bash scripts do the heavy lifting with an AppleScriptObjC app to make it look pretty (progress bar and other feedback). Longest part is installing Office 2011 @ 7 minutes including downloading. Speaking of which, updating the SOE to include SP2 will be as simple as copying the combo installer to the download location and changing the Office install script to point to the updated version..done. Only one component to test and it’s available straight away.

*Bonus Round*
With a slight adjustment to the scripts I already support 10.8 DP2 and should be able to support it on day 1 when it’s released 🙂

[Bartron]

Ditto.

on with my scripted install plan 🙂

[Bartron]

Depends on your setup I guess.

I support roughly 500 macs (a growing number admittedly) that get upgraded on a rolling 3-4 year cycle so the number of macs that need to be imaged is only going to be a handful every week and even then, distributed across the country. Unless something drastic happens I’ll never be in the position where I have to multicast to 50 macs at once. if that were ever to happen on a regular basis I’d invest in the proper hardware to do it. For now though we have something like 6 or 7 distribution servers around the country and each one can easily do 5-10 macs simultaneously. More if you stagger them by a minute or two (the biggest download is office at 900ish Mb but at 30Mb per second it’s only 30 seconds to download. Most of the time spent is installing, not downloading)

So, [b]for me[/b], getting net booting sorted on our mainly windows/Linux network is no longer an issue.

[Bartron]

After trying and looking at several solutions from custom USB boot drives, mucking about with the DHCP server, arcane terminal commands etc I had the bright idea of just forgetting about the whole “master image” concept.

So I did. B)

And here’s what Ive come up with instead:

I originally had a set of shell scripts that would set up a master image of OS X. Nothing flash, but they did the job of automating my workflow. I have now extended those and wrapped them up in a nice piece of applescript that launches them all. Now my roll-out process involves pulling the Mac out of the box, going through the new user wizard (what the user is called is irrelevant) browsing to a simple web site hosting a DMG with the applescript application within. After authenticating the scripts go ahead and one after the other configure everything that needs to be configured and install all the apps that need installing, downloading packages from our distributed file system without further interaction (the whole ‘back end’ runs on Windows Server 2008 R2). The last thing it does is call an application I wrote to automate joining to our domain. Once re-booted the system is a fully configured and AD authenticated OS X workstation. The whole process takes about 9 minutes 51 seconds (I timed it) not including unboxing and creating the first user account.

To many, this may seem a lot like what Puppet can do and it’s actually something we’ll look at in the future. Overall though the scripts I wrote only took a couple of days of the framework. The rest is just modifying individual scripts as new settings/applications are needed.

So that was after about 2 weeks tying everything together. The great thing is that apart from my printer config, everything works on OS X 10.8 without changing anything. This will be handy now that Apple are moving to a yearly release cycle.

So in the end, Apple breaking our net boot environment has actually resulted in my organisation being in a much better position in regards to new versions of OS X as they come out. 🙂

[Bartron]

Yup, I’m essentially going through the process of working out alternate solution.

I don’t use deploy studio (I use a modified version of the recovery hd) but I’m in the process of sorting out a dozen or so USB sticks to distribute around to the various sites. As our image is hosted on a http server so I can use the default recovery hd to do a restore but this is hardly ideal (especially since I went to the effort of hacking the recovery hd, made it net bootable and installed some custom apps…works well on older hardware at least).

I have reported the issue to apple via bug track but I’m sorely tempted to write an email and sent it to Tim Cook directly (and CC in half a dozen other SVP’s) as communicating with Apple via normal channels is about as productive to talking to a wall.

[Author]

Posts