NetBoot Part 1
My big, fat, self-assigned new project — or, as I like to call it, the bug up my butt — is system roll-outs. That is, I realized at some point two things. One, I am managing way more computers than ever before, and way more than I realized; and two, the scope and variety of these various systems has become increasingly wide. These realizations inevitably brought me crashing, headlong (yes, headlong) into a third and final revelation: I need to come up with a better system for managing machine builds and systems roll-outs.
Enter: NetBoot.
Actually, let me first explain how we've handled this in the past. When I began this job we had maybe 15-20 Macs running OS 9 briefly, and then OS X since about its inception. Mac OS 9 was notoriously easy to build. Just copy that shit and be done with it. But Mac OS X was a different beast entirely. Mac OS X was complicated. Moody. A tougher nut to crack. Mac OS X required me to delve into the dark arts of system cloning.
Cue thunder clap, scary music.
The process that eventually evolved was cloning over firewire. We'd build our master machine — a basic Mac OS install with all the latest updates and our requisite software — and then clone that to the other machines over firewire, with clients booted into our Master via firewire target disk mode. This was a quick and dirty way to build a bunch of systems. Once the group was built we could customize machines or groups of machines as we saw fit. For a lab of 15-20 Macs this has worked swimmingly. But our lab has grown slowly and steadily, and completely without my realizing it.
My latest count shows our lab at more like 50 Macs now. We've added a bunch of stuff: laptops, servers, more A/Vmachines of various configurations, a render farm, and of course more workstations. Using our old system of firewire cloning is becoming increasingly clumsy, slow and error-prone. We need a better way of doing things.
Okay, now. Enter: NetBoot!
Leopard's NetBoot Interface
(click image for larger view)
NetBoot is Mac OS X Server technology that allows for centralized storage of and access to system images for installation over the network. The way it works is this: You build a system, trick it out, make it perfect — this is your Master System. Put it on a firewire drive or something transportable, because you can't be booted from your Master System for the next series of steps — imaging. Run the application called System Image Utility, that comes with Mac OS X Server's server tools, and create a NetInstall image from your Master System. Load that image onto your server and enable it in the NetBoot settings in Server Admin. And what happens next is something akin to magic (unless you use Linux, and then it's pretty par for the course, I guess.)
The Network Boot Volume: So That's What It's For!
(click image for larger view)
With your NetInstall image enabled on your server, go to any client system and open the Startup Disk Preferences. Where you'd normally see the "Network Startup" icon (I'll bet you always wondered what that was for), you'll now get something a bit more descriptive. You should now be given the opportunity to boot from your master image. Choosing to do so will incur further magical results. Your system will now boot... Over the network! What's even cooler is that you'll be booted into the same basic installer environment you'd see if you were booted off a Mac OS X install disc, and you'll be walked through the steps required to install your Master System onto your computer. Um... OVER THE NETWORK!
There are some immediate advantages to a system such as this. First off, you can have a bunch of different Master System images for various build configurations in your lab. For instance, we can have a separate build for laptops and desktop machines. Cool! Also, this can all be automated (thanks to Automator integration) to make the process run almost entirely unattended. Sweet! And since the whole thing sits on the server and is available at all times, if a machines needs a rebuild, you just set it and forget it. Awesome!
But NetBoot has its drawbacks as well. Images — particularly large images — take for-freaking-ever to build. To give you an idea of how long, my near-36GB boot drive took an hour or so to clone to firewire, then 3-4 hours to be imaged by System Image Utility. So each build will take several hours to create. And God help you if you make a mistake on one of your images: the NetInstall images are read-only and can't (to my knowledge) be modified once they're built. NetInstall technology can't be used for non-package installers or updates either (again, to my knowledge), so you'll have to run all your Adobe and Microsoft updates by hand as usual. Also, one minor caveat that threw me at the outset: Mac OS X 10.5 server can only serve Mac OS X 10.5 builds. So you'll either be needing to update everything to Leopard or wait until your server and client OSes match.
I think I'm right on the crux of really needing this. I could probably live without it. Keep doing what I'm doing. But I do think I'm at a point where the benefits of using NetBoot outweigh its limitations. And I have enough resources now (like the required massive drive space and robust stable servers) that it's not impractical on the physical level. So, this summer I plan to use NetBoot to build my lab.
I mean, imagine this: you get your new systems over the summer, you unbox them, plug them into your network, set them to NetBoot (everybody say "command-n"! Good!) and go home for the night. You come in the next day and everything's basically done. You've just built your lab. Overnight. In your sleep. I don't know. Sounds pretty cool to me.
I'll let you know how it goes.
Oh, and by the way, in case you can't tell, I'm just now learning all this. It's still very new to me and there is a lot about it I don't know. So if anyone has any experiences or insights into using NetBoot (or if I get any of the facts wrong), I would absolutely love to hear about it. Please feel free to share your experiences in the comments.
Enter: NetBoot.
Actually, let me first explain how we've handled this in the past. When I began this job we had maybe 15-20 Macs running OS 9 briefly, and then OS X since about its inception. Mac OS 9 was notoriously easy to build. Just copy that shit and be done with it. But Mac OS X was a different beast entirely. Mac OS X was complicated. Moody. A tougher nut to crack. Mac OS X required me to delve into the dark arts of system cloning.
Cue thunder clap, scary music.
The process that eventually evolved was cloning over firewire. We'd build our master machine — a basic Mac OS install with all the latest updates and our requisite software — and then clone that to the other machines over firewire, with clients booted into our Master via firewire target disk mode. This was a quick and dirty way to build a bunch of systems. Once the group was built we could customize machines or groups of machines as we saw fit. For a lab of 15-20 Macs this has worked swimmingly. But our lab has grown slowly and steadily, and completely without my realizing it.
My latest count shows our lab at more like 50 Macs now. We've added a bunch of stuff: laptops, servers, more A/Vmachines of various configurations, a render farm, and of course more workstations. Using our old system of firewire cloning is becoming increasingly clumsy, slow and error-prone. We need a better way of doing things.
Okay, now. Enter: NetBoot!
Leopard's NetBoot Interface
(click image for larger view)
NetBoot is Mac OS X Server technology that allows for centralized storage of and access to system images for installation over the network. The way it works is this: You build a system, trick it out, make it perfect — this is your Master System. Put it on a firewire drive or something transportable, because you can't be booted from your Master System for the next series of steps — imaging. Run the application called System Image Utility, that comes with Mac OS X Server's server tools, and create a NetInstall image from your Master System. Load that image onto your server and enable it in the NetBoot settings in Server Admin. And what happens next is something akin to magic (unless you use Linux, and then it's pretty par for the course, I guess.)
The Network Boot Volume: So That's What It's For!
(click image for larger view)
With your NetInstall image enabled on your server, go to any client system and open the Startup Disk Preferences. Where you'd normally see the "Network Startup" icon (I'll bet you always wondered what that was for), you'll now get something a bit more descriptive. You should now be given the opportunity to boot from your master image. Choosing to do so will incur further magical results. Your system will now boot... Over the network! What's even cooler is that you'll be booted into the same basic installer environment you'd see if you were booted off a Mac OS X install disc, and you'll be walked through the steps required to install your Master System onto your computer. Um... OVER THE NETWORK!
There are some immediate advantages to a system such as this. First off, you can have a bunch of different Master System images for various build configurations in your lab. For instance, we can have a separate build for laptops and desktop machines. Cool! Also, this can all be automated (thanks to Automator integration) to make the process run almost entirely unattended. Sweet! And since the whole thing sits on the server and is available at all times, if a machines needs a rebuild, you just set it and forget it. Awesome!
But NetBoot has its drawbacks as well. Images — particularly large images — take for-freaking-ever to build. To give you an idea of how long, my near-36GB boot drive took an hour or so to clone to firewire, then 3-4 hours to be imaged by System Image Utility. So each build will take several hours to create. And God help you if you make a mistake on one of your images: the NetInstall images are read-only and can't (to my knowledge) be modified once they're built. NetInstall technology can't be used for non-package installers or updates either (again, to my knowledge), so you'll have to run all your Adobe and Microsoft updates by hand as usual. Also, one minor caveat that threw me at the outset: Mac OS X 10.5 server can only serve Mac OS X 10.5 builds. So you'll either be needing to update everything to Leopard or wait until your server and client OSes match.
I think I'm right on the crux of really needing this. I could probably live without it. Keep doing what I'm doing. But I do think I'm at a point where the benefits of using NetBoot outweigh its limitations. And I have enough resources now (like the required massive drive space and robust stable servers) that it's not impractical on the physical level. So, this summer I plan to use NetBoot to build my lab.
I mean, imagine this: you get your new systems over the summer, you unbox them, plug them into your network, set them to NetBoot (everybody say "command-n"! Good!) and go home for the night. You come in the next day and everything's basically done. You've just built your lab. Overnight. In your sleep. I don't know. Sounds pretty cool to me.
I'll let you know how it goes.
Oh, and by the way, in case you can't tell, I'm just now learning all this. It's still very new to me and there is a lot about it I don't know. So if anyone has any experiences or insights into using NetBoot (or if I get any of the facts wrong), I would absolutely love to hear about it. Please feel free to share your experiences in the comments.
Labels: Lab, Leopard, MacOSX, NetBoot, Server
This entry was posted
on Friday, February 08, 2008 at 5:02 PM.
You can skip to the end and leave a response.
3:25 PMYou need to check out NetRestore from http://www.bombich.com/. It makes the process even easier than Apple's NetInstall. It allows pre/post install actions (scripts) and you can have it automatically choose the right image based upon the machine. We use it to image over 1,200 Macs in our district. We NetBoot about 15 at a time and it automatically images and reboots the machine. We even have a script to run a boot to bind to Active Directory and Open Directory. You use NetRestore Helper to build both a NetBoot image with NetRestore on it and the actual master images.
5:42 PM
Tim,
Thanks! I'm aware of Bombich and NetRestore. I'll check it out for sure, though the latest NetBoot (in Leopard) seems to do a lot of what you're talking about (with Automator). Still, I'm betting there will be something compelling about NetRestore. It's obviously a popular product, and Bombich rocks.
Thanks again for the tip.
-systemsboy
12:18 AM
Ah, the first time I saw a spinning globe... netboot was a beautiful thing to behold. Of course, Mike Bombich and NetRestore was the only game in town, until Mac OS X Server got its act together (Panther?). Either way it is a big improvement over the firewire target-disk mode, when you got a lot of Mac labs to image.
Leopard changes a lot, and this includes their venerable netboot/netinstall imaging tool. I'm not sure the Automator-like functionality is better (it sure confused me a lot the first couple times I tried it!). With everything so new with each OS evolution, we all need to re-examine our methods and tools.
Monolithic builds may no longer be the answer. Especially with 30GB FCP6 installs... Layered buids, with a base OS, apps, and system tweaks make more sense and can adapt much more quickly to change. You can add new apps as needed, and roll back changes as desired. I'm thinking of course of Radmind, or the new kids on the block PKGImage and InstaDMG, as mentioned on afp548.com.
Something to think about anyway... You're making me all teary eyed for the days when I send one command with ARD v.1 to reboot all our Mac labs at once to all netboot and reimage themselves. Good times.
4:16 PM
MatX,
Yeah, the layered build approach is definitely appealing. Unfortunately, I've never been able to get Radmind working. And, of course, testing it is such a pain, and I'm never quite sure what I'm doing wrong. But the idea of it is brilliant.
I also really like the approach taken by the InstaDMG guy, which is basically that you do everything with packages. I've not been able to get this to work with proprietary installers like Adobe's (even using snapshots, I get build errors). But so far it works with everything else. (For those interested, read the theory here.)
I can't get past PKGImage's first screen.
So at this point I'm looking at doing initial, primary builds with NetBoot/NetInstall, and then any and all updates beyond our initial build with packages (either from Apple, or hand made with PackageMaker).
BTW, PackageMaker's come a long way since the last time I fired it up. It now has some pretty nifty and useful snapshot abilities. I'll be writing about it in my next post in this series.
Thanks for all the feedback. Really useful!
-systemsboy
12:32 PM
I use a combination of NetRestore and Radmind to manage our 300+ machines and it works quite well though I have been looking at package based solutions, which can give you more flexibility than Radmind and it's a lot easier to train people how to make a package versus a loadset in Radmind. Radmind's great for setting up labs but the learning curve is a bit...daunting.
I've heard that you can get around recreating NetInstall images by converting them back to read-only, running the installer against the image, then converting it back to read-only - though that might take as long as recreating the image.
Btw, I enjoy your blog!
Patrick
1:48 PM
Patrick,
I'm glad I'm not the only one who has found Radmind difficult. I really wish someone — ideally Apple themselves — would build something like Radmind that's intuitive and fairly simple to use. Conceptually what we want to do here is not hard. It's maybe just a bit tricky from a programming perspective.
I just took another look at Radmind today, and I'm astounded at how user-hostile it is. The language is terrible. The GUI makes absolutely no sense. Most of the time it's not clear what's going on or what's going to happen next. So if there's any kind of hangup — which in my experience there always has been — troubleshooting is a nightmare. I guess if I had 300+ machines I'd bite the bullet and learn it. But since I have only 50, I think I can get away with NetInstall/PackageMaker until something better comes along.
It's weird: we all have a perfect picture in our heads of what we want here. We all know what it should look like. I dearly wish someone would build an application around that picture. Adding a ".T" suffix to a loadset (which just sounds kinda gross, if you think about it) is just not a clear user interface.
As far as converting images to read/write and then back again, I'd considered it, but, yeah, I'm not sure that would be much of a timesaver.
Thanks for the comments and the kind words. It's been really great to hear more about what people are doing out there.
-systemsboy
5:12 PM
Thanks for the info everyone. We are replacing our classroom PCs (4 in each room) in two of our seven schools with 3 iMacs and 1 MacBook. We are a totally Win2k3 R2 AD network and am looking forward to all the milestones and roadblocks we are going to hit this summer with the deployment.
Do any of you have any good advise for me?
Thanks.
Anthony
11:17 AM
Mmm... Now that sounds like a blast...
We pretty much did the reverse of that — fit Windows and Linux into our Open Directory network. You can read all about it here.
I have no AD experience whatsoever, but it's far more common to do what you're doing than what we did. Search around on the internets and you should find plenty of info.
-systemsboy
» Post a Comment