NetBoot Part 3
I've become quite the package whiz, if I do say so myself. Actually, I'm probably doing something ass-backwards, but still, I wanted to share some of my working methods as they seem to be, well... Um... Working...
One of the things I'm doing is using packages to run shell scripts that make computer settings (like network settings and user-creation) rather than actually installing files.
This can be done in PackageMaker by taking some creative liberties with preflight and/or postflight scripts. The only hitch is that PackageMaker insists that you install at least some files onto the target system.
So the majority of my packages contain only a single script. That script first gets installed to /tmp, thus fulfilling PackageMaker's "must install files" directive.
The script then runs as a posflight script, and the last line of the script deletes the instance of the script in /tmp, just for good measure.
It could be argued that there's no reason to create packages from scripts, that you could just as easily run the scripts directly in ASR, but packages offer a couple of advantages. For one, packages leave receipts, so it's easy to check and see if something's been set on a computer. For two, packages are easy to deal with; assistants and other SysAdmins know how they work and can easily understand how to use them. Need to change a machine's settings? Don't run a script. Hell, don't even bother opening System Preferences. Just open and run a package. What could be easier (and less error-prone, I might add)? From an ease-of-use perspective, packages have a huge advantage. And ease-of-use adds efficiency. Which is why I not-so-suddenly find myself in the envious position of being able to build systems in about half the time (or less!) it used to take. That's a huge improvement!
Using this method (and sound DNS) I've been able to write packages that configure network settings, create computer-specific users, set custom disk and file permissions, set up autofs, bind to our authentication server and set up SSH for password-less login.
Next on the list: File Sharing!
Should be fun.
One of the things I'm doing is using packages to run shell scripts that make computer settings (like network settings and user-creation) rather than actually installing files.
PackageMaker: I Prefer the 10.4 Version of Packages
(click image for larger view)
(click image for larger view)
This can be done in PackageMaker by taking some creative liberties with preflight and/or postflight scripts. The only hitch is that PackageMaker insists that you install at least some files onto the target system.
PackageMaker: Installing Scripts to /tmp
(click image for larger view)
(click image for larger view)
So the majority of my packages contain only a single script. That script first gets installed to /tmp, thus fulfilling PackageMaker's "must install files" directive.
PackageMaker: A Postflight Script
(click image for larger view)
(click image for larger view)
The script then runs as a posflight script, and the last line of the script deletes the instance of the script in /tmp, just for good measure.
Shell Script: Removing the Script from /tmp
(click image for larger view)
(click image for larger view)
It could be argued that there's no reason to create packages from scripts, that you could just as easily run the scripts directly in ASR, but packages offer a couple of advantages. For one, packages leave receipts, so it's easy to check and see if something's been set on a computer. For two, packages are easy to deal with; assistants and other SysAdmins know how they work and can easily understand how to use them. Need to change a machine's settings? Don't run a script. Hell, don't even bother opening System Preferences. Just open and run a package. What could be easier (and less error-prone, I might add)? From an ease-of-use perspective, packages have a huge advantage. And ease-of-use adds efficiency. Which is why I not-so-suddenly find myself in the envious position of being able to build systems in about half the time (or less!) it used to take. That's a huge improvement!
Using this method (and sound DNS) I've been able to write packages that configure network settings, create computer-specific users, set custom disk and file permissions, set up autofs, bind to our authentication server and set up SSH for password-less login.
Next on the list: File Sharing!
Should be fun.
Labels: Applications, Lab, Leopard, MacOSX, NetBoot, Server
This entry was posted
on Monday, March 31, 2008 at 5:00 PM.
You can skip to the end and leave a response.
6:03 AMSounds awesome. I think I should do this too. Now that I have assistants, I mean, peeps that help me odd times. We can't all be in the office 24/7.
We almost need a script, pkg repository for all the best ones. I always keep my fav one liners in ARD but now is the time for a pkg repository. Cool.
9:13 AM
Script-only packages are pretty cool and I've been using them for years in combination with Apple Remote Desktop 1.2 and later. I love them because, as you mentioned, they make it really simple to build once, then hand off to someone who may be less savvy with Unix or Mac administration tasks.
1:20 PM
Yeah, I basically am building a script/package repository. That's a good description of what I have.
And, yeah, I think they'll be super-useful. I probably won't even have to do most of the lab building this summer. Just get the assistants to do it. Much as I'd love to get them to learn the ins and outs of UNIX and Mac management, I only have them for two semesters. And I think they'll benefit more conceptually from seeing the idea of the layered build in action than what little command-line administration they can pick up in two semesters.
I only wish I'd had the resources to do this earlier. Now that I have the resources, I find myself lacking the time, which is part of why I'm forcing myself to do it now. It should save me huge amounts of time in the future. Actually, it already has.
Anyway, I'm rambling.
Thanks for the comments, folks.
-systemsboy
» Post a Comment