NetBoot Part 2
So here's the plan, as it stands right now. (Yes, I have a plan already! Yes, that was quick.) First, build an image that's good for all workstations (laptops, staff machines, standard workstations, etc.) throughout the lab with:
IMAGE THIS SYSTEM
This becomes the base system build, the Master Image — the replacement system if a machine ever needs rebuilding. It is the only full system image. There is only one.
Everything else that is machine-type specific — that is, users, applications, application components, crontabs, anything — gets turned into and installed via either a downloaded or hand-rolled package. So far I've been using Apple's PackageMaker, which has matured a great deal since last I tried it. It's pretty nice. I'm also taking a look at Iceberg, which also looks to be pretty full-featured and nifty.
Iceberg: by White Box
PackageMaker: by Apple
(click image for larger view)
These packages can be machine-type specific and stored in a simple folder hierarchy by machine type — laptop packages in the laptops folder, etc. — for organizational purposes. In addition to being machine-type specific, packages can also, I believe, be machine specific. That is, I think we can make settings like computer name and network settings using packages as well. So what we're talking about here is a system of computer building that happens completely over the network, and that can be directed almost entirely from one ARD-toting computer, that computer being mine, of course. (I've always said, the sign of a good SysAdmin is that he never leaves his chair.)
I've gotten pretty good at making application packages, at this point (not that it's terribly hard, mind you). My next step will be to learn how to make system settings with packages as well. My other next step is going to be, of course, creating the Master Build. None of this building happens 'til summer. But still, something tells me it's going to be smart to start this process now and see what crops up over the next couple of months.
As usual, I'll be reporting any new and/or interesting developments.
Oh, and thanks to everyone who commented on the last post. The comments were extremely useful!
- Base OS (Mac OS X Leopard 10.5)
- A DHCP network connection
- Apple applications
- Adobe applications
- Drag-and-drop applications
- Other third-party applications
- One admin user
- ARD active
IMAGE THIS SYSTEM
This becomes the base system build, the Master Image — the replacement system if a machine ever needs rebuilding. It is the only full system image. There is only one.
Everything else that is machine-type specific — that is, users, applications, application components, crontabs, anything — gets turned into and installed via either a downloaded or hand-rolled package. So far I've been using Apple's PackageMaker, which has matured a great deal since last I tried it. It's pretty nice. I'm also taking a look at Iceberg, which also looks to be pretty full-featured and nifty.
Iceberg: by White Box
(click image for larger view)
PackageMaker: by Apple
(click image for larger view)
These packages can be machine-type specific and stored in a simple folder hierarchy by machine type — laptop packages in the laptops folder, etc. — for organizational purposes. In addition to being machine-type specific, packages can also, I believe, be machine specific. That is, I think we can make settings like computer name and network settings using packages as well. So what we're talking about here is a system of computer building that happens completely over the network, and that can be directed almost entirely from one ARD-toting computer, that computer being mine, of course. (I've always said, the sign of a good SysAdmin is that he never leaves his chair.)
I've gotten pretty good at making application packages, at this point (not that it's terribly hard, mind you). My next step will be to learn how to make system settings with packages as well. My other next step is going to be, of course, creating the Master Build. None of this building happens 'til summer. But still, something tells me it's going to be smart to start this process now and see what crops up over the next couple of months.
As usual, I'll be reporting any new and/or interesting developments.
Oh, and thanks to everyone who commented on the last post. The comments were extremely useful!
Labels: Lab, Leopard, MacOSX, NetBoot, Server
This entry was posted
on Wednesday, February 13, 2008 at 1:31 PM.
You can skip to the end and leave a response.
5:03 PMLook up the "InstaDMG" on AFP548.com - not only is it a great way to build that universal OS installer you were talking about, it's also got a great example of how to pkg a system setting (in this case, a shell script setting up a user).
5:34 PM
Funny, that's exactly what I was working on when I received this comment: creating a user from a shell script and bundling it up in a package installer. I've actually almost got it.
But still, I've been meaning to look more closely at the InstaDMG stuff for clues. I'm certainly basing my approach on InstaDMG's creator's approach. I'll check it out in a bit.
Wow. With all the help I've gotten this project's way ahead of schedule. So cool! Thanks!
-systemsboy
1:07 AM
Not rebuilding until the summer, eh? I need to work for a school again. Wow. The luxury of all that testing time between now and then... sheesh. ;) I am rolling out everything as Leopard, client and server, and making it up as I go. Let's hope it all works. Now that's effective planning.
12:45 PM
I was just talking to a friend about our mutual preference for working in education. I'm always a little tempted to look elsewhere, as the money's not what it could be. But you just can't beat the freedom to learn and experiment that you have at an educational institution.
So, yeah, maybe you should work for a school again.
Actually, I'd be really curious to know how you've liked working in a non-educational setting versus an educational one. Better? Worse? Both?
Maybe someday I'll take the plunge.
-systemsboy
1:13 AM
I've worked in public and private secondary schools (one an Art School, and the other a technical training institute). It always depends on the management, and level of enlightenment found therein. But yes, we had more time to test and try solutions out before deploying. A lot more time. And there were more spare computers to test on. In a private company there might not be as many test computers or test networks to try things out. And waiting for downtime is tricky when you're 24/7. Just make sure you always have a good backup before you operate on the patient. It's high adrenaline. You might get tired of the students and the school semesters and long for more excitement, but maybe you'll come to your senses and stay put. Who knows?
4:50 PM
Hmmm... Yeah, that's pretty much what I thought. I have the problem with downtime whenever I do freelance for corporate clients. What a crazy way to do systems work. Drives me right up a wall.
When I get those jobs I feel like staying in edu. When I realize I'm pushing 40 and can't afford to buy property, I get the money itch.
It's a tough call.
-systemsboy
11:26 PM
On a note, related to your post... I tried a custom netinstall of a Leopard (Mac OS X 10.5) DVD + adding extra packages. Specifically, the 10.5.2 update + Leopard Graphics update + wacom tablet driver. The netinstall would fail if I chose to include the wacom driver, while the leopard gfx was deselected and could not be chosen. It worked great as a 10.5 + .5.2 update netinstall. But gave me a "preflight" error for the wacom. More testing needed.
2:07 PM
Ah, thanks! Good to know. That's weird, though. Can't really imagine why it'd behave that way.
-systemsboy
8:05 PM
I stumbled upon your site by accident (serrendipity). I'm currently amidst this very process. The following may help.
1. Creating a separate Adobe CS3 package gave me grief. Due to time restrictions, I ended up putting it into the base build (OsX 10.5.2.& Adobe CS3). I suspect that when building the Adobe CS3 package, that permissions were altered in some manner and this prevented the abode license manager from being able to authenticate apps.
2. A third party tool to help create packages is JAMF Composer. http://www.jamfsoftware.com/products/composer.php
It simplies much of the process of package creation. But there are some crevats.
- their customer support is terrible
- I am having problems using Composer to create packages over 8GB. It could be memory leak but it generates an error and quits out. (This also limits it usefulness for creating packages for the large apps, like... Adobe CS3, for example)
- It works inconjection with Xcode's Packagemaker. Hence Xcode must be installed before installing Composer.
- I'm not a fan of its interface, although it's workflow is direct and uncomplicated.
Good Luck with it all.
8:28 PM
Thanks for the Composer info. I'm aware of the software but have never used it. Good to know about its deficiencies. I was avoiding buying it because, well, I'm being cheap really. I'd love to find a way to do this for free, and PackageMaker's snapshotting should work well enough.
Glad to hear I'm not the only one who couldn't set Adobe stuff to snapshot. I too will be including it in my base OS build. Fortunately, a package can be created for the updaters.
Thanks again! I'll post more as it happens.
-systemsboy
» Post a Comment