InstallerChoices Discussion.markdown

Our Initial Question:

Q. What is the equivalent of a "Kickstart" (or preseed) file in OS X? What file can you create with OS X that would customize an OS X Install AT, or before, Install-time?

• My initial thought was the InstallerChoices.xml file - but as far as I'm aware that file isn't 'read' by the OS X Installer during Installation - it has to be submitted as an argument.

Greg responded to me with the below:

"Yes, I suppose the ChoiceChangesXML file (of whatever name) is the closest analogue of the Kickstart file.

You could create a workflow that curled an InstallerChoices.xml file and used it to install; there's no way to get Apple's Installer to do that for you that I know of. But if you are using disk-free NetBooting, you can do almost anything at that point."

There are articles here, and here on Netbooting from Linux machines. Ohad Levy is the author of a tool called The Foreman http://theforeman.org and is possibly looking at rolling this solution into The Foreman. What might be the best way to do this?

Feel free to comment below:

I don't think InstallerChoices will TRULY act as a kickstart file - where it can modify what's installed AT install-time while you're booted FROM the installer disk...unless I'm missing something. But, you could create a custom netboot image, script it to curl down an InstallerChoices file, run the installer binary, and do an entirely CLI-based install - right? Not having to think about this for awhile (thanks DeployStudio and InstaDMG), I think I may be missing quite a bit, though.

and in order to generate that image, you would still need osx?
is it legal to distribute those images? (say that we create one per os or something?)

As I understand it glarizza is right but that is (maybe) not the only option. In OSX theres actually two ways of doing installations after netbooting, you could boot into a "reduced OS" like DeployStudio does, and then use tools within that context to restore images.

The other way is to use something called NetInstall. Instead of booting into a more or less full OS to RAM and work from there, you then could maybe boot directly to the Apple OS installer application. And THIS installer could possibly be customised by an ChoiceChangesXML-file. You would however need to apply a number of changes to the source image beforehand, and as far as I know you'd need to use OSX to do that. I'm not 100% on this though, or even if NetInstall could work this way, maybe someone else knows.

I'd be happy to do some more research into it though, unless someone pops up with a quick and definite answer. Greg? :-)

That's a good question. I don't think distributing them would be acceptable, but a means to generate them would be fine (which, yes, would still need OS X for the kernel and any System files to boot to a minimal UI).

Well, either way is going to require OS X Kernel files - which wouldn't be 'legal' for Ohad to distribute with Foreman. He can provide scripts that would generate the minimal booter image from an OS X machine, but that is still going to be susceptible to all the problems we currently have for booting new hardware (i.e. the booter image needs to be created from the NEWEST piece of hardware you own so that all of your machines will be able to boot from the custom booter image).

The images are not distributable. In a Foreman workflow I'd say the user could provide the OS installer media and then you'd twist that to work. To require the user do that from a Mac would possibly be the easiest route, then you could do the amount of twisting needed locally at "import time". I don't know Foreman well enough to see if something like that would fit.

Yup, you'd need to do it from the newest Mac in your pool, and sometimes forks are needed, like at the moment .. new models need a different installer source than the rest

Anyone with extensive InstaDMG experience? :-) http://code.google.com/p/instadmg/source/browse/#svn%2Ftrunk%2FDocumentation%2FInstallerChoices

I've used InstaDMG - but I've not had a need to crack open the code. InstaUp2Date is in Python, but instadmg.bash is definitely a huge shell script. I'm sure Ohad would be able to weed through and find the bits he needs from there - InstaDMG is a good starting point for utilizing the InstallerChoices.xml method.

As I understand it, all instaDMG does with a choicesChanges file is pass it to the installer binary to access the options allowed in the OSInstall metapackage. Karl Kuehn made a GUI utility to extract the options and make the process easier, still in the InstaDMG branch, called InstallerChoicesHelper. I'm not certain what the end goal state is though to dynamically alter the OS install, so I can't comment on what could satisfy that need.

The end goal would be to have an as pristine OS as possible installed, with just the Puppet client/framework added. And to reach that goal with as few dependencies as possible ..

Sure, so we all know the experts at stripping down to a minimal, apple-flavored bootable OS kernel are the DeployStudio guys, and they might not be allowed to share. We could conceivably reverse-engineer what made it in to their 2.1GB bootable image and just have installer put those packages in a DMG a la instadmg, and just keep an eye on kexts/display drivers so future hardware is supported. Not the smallest of tasks, but I stripped a bunch of unnecessary packages out of iLife when I just needed iPhoto - and for that I didn't need a choiceChanges file, just a list of packages to install in a specific order.
Sorry I'm still hazy on the intent, where would this be put into use?

Read at the top .. "Ohad Levy is the author of a tool called The Foreman http://theforeman.org and is possibly looking at rolling this solution into The Foreman." http://twitter.com/#!/ohadlevy

Reversing DeployStudio is possible yes. Right now (some of) their code is in bash, actually :-) And we have this http://support.apple.com/kb/TA21133?viewlocale=en_US

not to get too far off track here, but DS uses a shell script called sys_builder.sh to… build a netboot system. the contents are also located here: /Applications/Utilities/DeployStudio Admin.app/Contents/Resources/DeployStudio Assistant.app/Contents/Resources/sysBuilder

so creating a bare boot image doesn't have to be a mystery. there's no mention of licensing in their file, but it would be worth checking on terms for the whole project or just contacting the developers.

with that said, i don't think there's anything on the mac side akin to a kickstart file. kickstart files are much more powerful. we don't even have machines that will netboot out of the box without human intervention (one of my long-standing gripes).

i'd expect apple licensing terms to get in the way with most of this.

the best bet is probably to get to a point where it's easy/trivial to reliably produce bare bootable images with configuration management tools in place to do the rest. i don't know that installerchoices or the like will need to be involved.

talked to ohadlevy on irc today, this gist is getting long now but ohwell :-)

beddari: ohadlevy: did you get any more comments om Mac-support?
ohadlevy: beddari: did you see the gist?
beddari: ohadlevy: yea me and glarizza kind of startet that
ohadlevy: beddari: honestly I didnt have much time to go over the way of how the image is created
beddari: ohadlevy: been thinking about it last few days as I'm in a situation where I'm dependent on DeployStudio and I don't quite like it
marcellods: ohadlevy: I do it now, but I think it's unhandy and I can't trigger. Foreman UI would be better.
ohadlevy: beddari: but for me there are a few high level questions
ohadlevy: 1. can we provide users a script to generate an image (and not to that touch image too often)
ohadlevy: 2. can we generate some sort of a template, which implement JeOS (just enough OS) to run puppet
ohadlevy: 3. can it be done automatically, or does it require some actions from the user (like boot from network vs boot from local disk)
beddari: 1,2,3 can all be done automatically
beddari: you would need to start with either the OS source DVD or a pristine computer as the source
beddari: I would prefer the DVD
beddari: and then you need to generate both a netboot image and what you call JeOS
ohadlevy: beddari: cant we do it over the network instead?
ohadlevy: or you are talking about image creation?
beddari: im talking about the creation yes
beddari: you could save both of those directly over the network using nfs of course
beddari: but you need to be able to use the os specific utils to generate the images
beddari: and as I say, you need two items, the netboot image (a reduced os image) and the JeOS image to be put on clients
beddari: you could - most likely, I havent tried yet - put Puppet on the netboot image
beddari: thats of course totally out of wack compared to kickstart-like workflows :-)
beddari: and thats for the image generation ..
ohadlevy: beddari: if we can provide a script to generate the image I think it would be fine
beddari: yes
ohadlevy: then we would probably need to change some files on the tftp server?
ohadlevy: and then the only question is how to feed in some sort of a post script
beddari: yea documented already at that edu link you had
ohadlevy: for example, maybe the image could do something like
ohadlevy: curl /script_for_mac | sh
ohadlevy: beddari: we do something similar in solaris
beddari: yea that is comparable technically
ohadlevy: beddari: my overall goal is:
ohadlevy: 1. user login in foreman, to define his host
ohadlevy: 2. network boot his mac
ohadlevy: 3. os is installed + puppet running
beddari: yes
ohadlevy: without any manual steps in between
beddari: right now, 2 is a bit awkward, as you'd need a special keypress to network boot
beddari: you could skip that but then you'd need to run a local utility on the client first to tell it to netboot next
ohadlevy: beddari: ok, thats an option too
ohadlevy: beddari: we do that with grub
beddari: yup but first time around you'd need the keypress or something else
beddari: :-)
ohadlevy: wont it default to network if it cant?
ohadlevy: or there is always an os installed?
beddari: no defaulting to network no, and os is always installed from apple
beddari: so manual intervention is needed in any of those two forms, an util that you run or a keypress at startup
ohadlevy: beddari: ok, I think we can live with that fore the moment, we are talking about users machines, so its not like servers that you need to go to a remtoe datacenter or something
beddari: this is something a lot of people complain about :-)
beddari: so, for me, the ideal way of solving this as open source would be if there existed a separate project for generating the netboot-image
beddari: right now noone does this as open source
beddari: deploystudio does it free but closed
beddari: the code however is available to read, its bash :-P
ohadlevy: :-)
beddari: they have the most detailed knowledge of this AFAIK
beddari: so I guess someone could just ask them for permission
beddari: a project like this could possibly live as python, as that is what most mac sysadmins use
ohadlevy: beddari: not ruby? ;-)
beddari: hmm nah for some reason python is mostly used among sysadmins
beddari: i guess it is to keep distance from the rails guys
beddari: if you get the netboot image done, then you could curl a script into that that did the imaging and post-installed puppet as the last step .. the installer-binary actually lets you set another device/path as root for the install
beddari: as long as the package is created correctly, which it is, for Puppets case :-)

Yep - those were the thoughts I had (minimal OS, prebaked image, holding 'N' for netboot, etc). I object to your Python comment wholeheartedly :)

When the OS X installer is running, early on there are messages in the logs like:

Opening OSInstall automation file '/Volumes/xxx/Mac OS X Install Data/minstallconfig.xml
/Volumes/xxx/Mac OS X Install Data/MacOSXInstaller.choiceChanges file found.
Applied choice changes from /Volumes/xxx/Mac OS X Installer.choiceChanges

So there's definitely a file or two that the installer reads to determine exactly what to install.

Python vs ruby : my brain can hold only so many scripting languages at one time. Python has pushed out Perl in my brain for the most part. I worry what Ruby might push out that I'll still need...

I would argue that Pyton did you a favor :) Let's see if we can't get Ruby to kill a couple of Fortran brain cells...