Deploying large net boot networks. Large net boot networks. A couple of good things in here. My name is Joel Rennich, CE manager for Enterprise Sales. So we do nice enterprise things. So a couple things about net boot in here, I've got a favorite a personal favorite, I'm very proud of this, very excited. I've yet to get anybody to use it yet.

But I'm very excited about it, entry that we have that changes net boot, allows you to do more load balancing, get more stuff out of it. We then have Mike Bombich who's coming up here who's talking about.

- Where was that when I said who I was?

Click. So what you'll learn, how Pixar uses NetBoot automated system utility and how to make NetBoot systems more redundant and this would be the American definition of redundant. Not to make redundant as in fire people. Alright? So we're giving you more options not less. So we're getting old enough with net boot now that we can use words like traditional, old style. Alright so traditional net boot balancing, you've got a couple of net boot servers out there you've got a bunch of net boot clients, net boot clients boot up they ask who their net boot daddy is, they get that information.

The net boot server that handles them will cache their Mac address. In further boots that server will prefer that client. In a decent world with a lot of randomization all your machines over a period of time will kind of balance out across all the servers based upon load.

However, it is quite possible that at one time if you only boot half a lab or depending on just how the chips or the Mac addresses fall, you may end up with all of your clients on one system. Alright? So while it is randomized and while it is balanced, it is not necessarily randomly balanced. So that's traditional net boot balancing. Alright? Still in 10.4 still works nothing changed there. If you're using this and you have a set up and all that, nothing changes.

What we have now is the fancy new net boot load balancing. Alright? Ooooh. So if you go into your NB image info dot p list file, you'll find that you can put in a new key. Load balanced server. This is a string that can be either fully qualified DNS name or it can be an IP address.

Alright? Now your clients will boot up. They'll send out the boot strap discovery protocol packet. They will get a net boot server, the net boot server will respond. Net boot server responds with a couple of different pieces of information. One is where it's going to go for its TFTP image.

The other is where it's going to go for its NFS or HTTP system image. The address either the DNS name or the IP address that's given in both the TFTP or the NFS or HTTP URL is going to be the IP address or the fully qualified DNS name that you provide in that string under the load balanced server.

What does that mean? Let me show you. Alright. We've got some fun new iMacs on the right side, we've got some G5 Xserves, or Intel Xserves, oh I'm sorry, Intel Xserves on the other side. We've got some net boot servers that are also up there too. So this is kind of a common larger environment net boot set up where we have a DHCP helper running on the switch that's forwarding on the information.

Alright? Now my iMacs are going to begin net booting. Begin net booting, there we go. And they're going to go off and they're going to get a net boot response. That net boot response is going to come directly from those net boot servers. So far we are no different than any other set up that you may have where this is already working.

Now where the magic happens, we have a hardware load balancer, right? A variety of companies have Coyote Point, couple other places that do this. The load balancer will allow you to have a virtual IP address. The load balancer as a virtual IP address takes all the incoming connections on that IP address and distributes that traffic across the server farm behind it.

Ah! So now when my net boot servers respond back with who your TFTP and NFS share point is, they can actually provide that virtual IP on the load balancer. Now all of your traffic back to those net boot servers, will go through that load balancer and be truly distributed across the back end systems.

Alright? Load balancers can have a lot of logic in them. They can redirect clients to new machines if one machine goes down. They can maintain state, they can do all kinds of fun stuff. Alright? So this gives you a huge amount of options of how you can actually make your net boot system significantly more redundant.

What we're really excited about here is the possibility of hosting images on Xsan. Alright? Leopard, new Xsan, all kinds of good stuff, right, go in there, do this, put the net boot servers up there, alright? Post your image on that, I can have a server farm providing that net boot image and load balanced entirely across it.

Ah! Perception coming through here, okay? So some great ideas that you can use now for load balancing just with that one additional net boot setting and that NB image info P list. Now keep in mind experimental. Alright? We're very interested in what you think you can do with this, we're very interested in seeing some of the setups that you might have, we're very interested in helping you with this redundancy and this larger scale.

When I lie awake at night thinking about net boot, I don't think I do it as much as Mike, but I sometimes do. And I think about net boot and I think about what it can do for your set up, what it can do for your systems. I really get excited about this, I really, really do. Alright? So we're calling this the super kinky net boot.

Combining the elements of the load balancing that we're talking about, combining all of this into to make a very redundant net boot solution. We want this to be redundant across network links, we want this to be redundant across net boot servers. The loss of any single thing will not slow you down. You'll be able to net boot regardless. Alright? As long as you don't lose all your clients.

If you only have one client, make two, then you can get that. So again, it will be using a combination of DNS, so bind named views, so you can actually do DNS resolution differently depending on where your clients are booting up from, we're also going to do this with some Cisco or some other networking IOS where you can go in there and do some interior routing protocols with OSPF or whatever you might want to use. So this is a very highly advanced, this isn't something you put in, in an afternoon, but it's something that you can really plan out to truly really increase your scale and increase your redundancy with a net boot solution.

So let's go over this. We have the WAN, we have Chicago, we have LA, net boot systems in both sides okay? We now have our net boot servers somewhere else. Now try to find a third place, maybe New York. But eh, it's kind of cliche. So somewhere else. A secret undisclosed location in your server room.

In there you have your net boot systems you have a couple of different IP addresses, your routing system sets up using OSPF, something else, you have these IP addresses show up here. Alright? My Chicago net boot systems are going to net boot. I'm using BSDP helpers, DHCP helpers so that BSDP query response goes back to my central location.

I change that NB image info p list key so that the net boot server that its responses are going to be NB.apple.com. Alright? So I have two net boot servers there in my server room. They're set up to respond with NB.apple.com. I have DNS view set up in Chicago. My systems in Chicago resolve NB.apple.com to that 10.0.10.10 address.

This means that my Chicago net boot systems will now be definitely net booting off of local net boot pare. That 10.0.10.10 address can actually be the virtual IP of a hardware load balancer that's actually balancing the traffic between two net boot servers behind it. So far so good. Essentially what I talked about a couple of slides ago. Now I'm going to LA and I boot a system in LA. Have a similar BSDP traffic, the response back is NB.apple.com. We have local DNS we have a view set up. This now turns into 192.168.10.10.

So the same configuration to net boot server somewhere off in the middle of nowhere are actually telling the clients to go net boot off different systems. And those net boot systems are different based upon your location based upon those DNS views. Not anything that's very complicated to set up whatsoever.

Alright? Now the other thing that I can do with this, not only can I resolve that to a local IP address using interior routing protocols OSPF like I said, getting probably not a six pack, but maybe a twelve or twenty four pack of beer to your Cisco or your Nortel or whoever guy that you have to do that for you. You can actually do redundant links. So now that 10.0.10.10 address has a very low path cost in at Chicago. But if it can't be reached in Chicago because the link is down, that load balancer went away, it can actually appear over in your central server room.

Ah! So now your Chicago clients net boot, they get NB.apple.com, they resolve that locally to 10.0.10.10 , they boot off the local systems if they're there. If the local systems aren't there, the network and the router will actually pass all that traffic across the WAN or the mantling that they have back to wherever else you want to go.

So you have instantaneous redundancy on your net boot service. If you're using HTTP to net boot your systems, stateless protocol right? You should be able to get away with having your live clients. Survive a server failure and be redirected by the network or the hardware load balancers to another server.

Ah! That's where this gets cool. Alright? Again experimental but we want to give you the tools so you can start testing around with this and see what you can do. And now you can end up with a server farm of net boot servers. Where you can pull them in and out without having to worry about all the clients being shut down or what interruption this is going to give them.

So again, redundant across net boot servers, redundant across networks. Very, very redundant, lots of stuff. So very interested anyone that wants to do this. Again, this is my dream. I wake up in cold sweats, aahhh we can do this. So hopefully it gives you some options and all of this is predicated off that one little entry in the P list. So now that I've bored you with networking, bring on Mike Bombich.

Talk about System Image Utility.

So we're going to change gears this year. I'm going to talk about one of the Apple applications that leverages net boot technology for mass deployment. We're going to talk about System Image Utility. It's been completely overhauled for Leopard. It still retains the core functionality of creating a net boot, net install and a restore based net boot set. But if you compare the interface to what we had in Tiger and Panther, you can see that it's completely different. They really don't bear much resemblance to each other at all.

That's because in Tiger System Image Utility had that horizontally aligned tabbed interface. And if we ever wanted to add functionality to System Image Utility, we had to add another tab. So there's only so many tabs that you can add to an application before it starts looking like one of those applications developed by another vendor. And obviously we don't want to go there. We don't want to keep adding tabs. So Apple addressed these limitations by implementing Automator technology in System Image Utility. This is great. System imaging, whenever you break down something into discrete tasks, excuse me.

So we're going to break things down into discrete tasks and then we're going to have an Automator action for each one of them. Whenever we break things down into discrete tasks like this it's easier to provide support for things, for lots of new features like volume partitioning. I'm not going to go into tons and tons of detail on System Image Utility. The folks that actually develop it are going to talk more about that on Friday at I think it's 5ive pm in Nob Hill.

So please go ahead and check out that session. With the arrival of Intel Macs, system administrators have a lot of new opportunities for deploying Macs for doing Mac OS X deployment. At the same time we also face some new deployment challenges. I think that building blocks specifically Automator actions is exactly the technology that we need to meet the diverse needs of Macintosh system administrators.

In the next few minutes I'm going to give a brief overview of system image utility just so that we're all on the same page with what's new in Leopard. Then I'll talk about how we can extend the functionality of System Image Utility and finally I will talk about how we can create our own Automator actions that will plug in to System Image Utility.

So let's take a look at the interfaces of the Tiger and the Leopard System Image Utility. In Tiger you've got that horizontally aligned tabbed interface and in Leopard when you first launch system image utility, you get two options. I can create a net install set or I can create a net boot set.

If I click on net install set, I can click on continue and get a super easy deployment solution or I can click on customize for more advanced options. As soon as you click on customize you can see that Automator is now part of the DNA of System Image Utility.

When you first start customizing your net install image you get an interface that's very much like that of Automator. You get a palette of Automator actions that are specific to System Image Utility and then on the right you get a canvas for assembling your deployment work flow. So you can see a lot of the actions up here.

Basically they took the tab, each tab from the interface in Tiger and they turned it into an Automator action. So the main actions, the most important ones of course, are define image source and create image and then the rest of them up there are just extras to give us some more customization.

So let's take a look at a basic work flow. The first thing that we're going to do is we're going to define our image source. So we're going to pick either a net boot or a net install set. If I choose a net install set, which is my favorite because I like mass deployment, we have two options. We're going to get either a package based deployment or we're going to get a restore based deployment.

Which one we get depends on the type of source that we chose. So if I chose a Mac OS X installer DVD as my source, I'm going to get a package based deployment. If I picked a volume that's already got Mac OS X installed on it, I'm going to get a restore based deployment.

So next let's say I want to partition my target disk on my client machines. That's great. I can't really do anything with that second partition just yet, but we're going to get there. That's kind of the point of this presentation. So next let's say I want to apply some system configuration settings.

I want to bind my client systems to the same directory service that my master machine is bound to. Let's say I want to change the file name of the bi-host preferences to match the Mac address of the current machine and say I want to set the computer name. I'll go ahead and do that here.

Obviously we want automation, go head and drop that in here. In this case, I'm going to go ahead and say there's a volume on my client machine's named Macintosh and that's what I wanted to use. I could say that some user sitting in front of the machine could pick the volume. That's a nice safety step. But kind of anti-automation. I also want to erase before installing to make sure I get my block level deployment.

Finally and this one must come last, we're going to create our image. So the first five Automator actions didn't actually do anything. They just kind of modified some preferences and then there's a dictionary that's passed down to each Automator action. It's this last Automator action create image that actually takes those preferences specified earlier and it will create a net install image, create my master image and then do anything else extra to configure that net install set.

So at this point I think we could say that System Image Utility covers the basics. We can create a master image, we can create our deployment set, we can do some basic pre and post restore actions. And we can do all of this with automation. For a lot of system administrators, this is fantastic, this is a great base deployment.

For a lot of other people though and I think probably a lot of people in this room, we do want a little bit more. We want to customize our deployment. We've got a hundred or ten thousand or a million machines that we need to deploy and we want to add some more customization to this.

So how else can we do that? Well the first thing that we can do is we can install additional software. There is an Automator action that's built in the system image utility that allows us to specify additional packages of software and scripts that we want to install after our restore.

Now this may seem to make more sense with a package based deployment. So remember the package based deployment started with our Mac OS X installer DVD and if we just install Mac OS X, obviously there's a lot of other things that we want to add on there, say Microsoft Office, Parallels, lots of other things.

It does have some merit in a restore based deployment too though. Anytime you factor out the software that's going to go out to your machines, it gives you a lot more flexibility in what software gets installed onto each one of your end machines. I'm not going to go into a lot of detail on this either.

There's a lot of different ways to create packages, there's tons of resources on the internet, Mac enterprise is a great site for this. There was also a session yesterday, Session 304, that went into a lot of detail on the why and the how of package based deployment. I encourage you to review those slides and check out that podcast when that becomes available.

So there's this thing, system image utility really leverages installer. That's just the technology that's built into Mac OS X and installer's great but it's an installer. It just kind of installs things. So the only way that we can legitimately customize or extend the functionality of System Image Utility is by adding package installers.

That's kind of what installers is built to handle, so that's what System Image Utility can do. With that condition in mind, maybe we should sharpen our pencils and figure out what else we can do with package installers. So a lot of you probably already know package installers can also run shell scripts. And there's this thing that we like to call payload free package installers that won't install anything at all it will just run a shell script.

So this is great. I've got a shell script that I've used for deployment before, I can take my shell script, drop it into a package installer, I can drop my package installer into System Image Utility, System Image Utility will create my net install set and copy my package installer into the net install set. I'm going to net boot my clients, they'll restore and then they'll install my package which doesn't install anything but it does run my post lite script. This is great.

Whew. Let me ask you something though. When I said Automator's now part of the DNA of system image utility, did you think I'd stand up here and say we're going to customize our Mac OS X mass deployment with a whole bunch of shell scripts? I hope not. I really hope not.

If I were to stop here, we wouldn't be anywhere closer to the idea of deployment solution than we ever have been before. We'd still be longing for additional functionality and we'd be turning to command line tools and shell scripts to customize our Mac OS X deployment. To customize the deployment of hundreds of thousands of machines.

Who wakes up in the morning and says gee I can't wait to get to work to tweak some shell scripts to manage my thousands of machines?

Yes I know I hear some, I know I hear you and I am not knocking shell scripts, I'm not. A lot of us here are plenty comfortable with shell scripts. Heck you know I am. I love them they're great. But there's a lot of system administrators that do want a graphical user interface for specifying the post restore customizations.

In particular, I mean we're a bunch of Mac heads here for the most part. Ninety nine percent maybe? If we want to woo system administrators from say the Windows platform to our platform, deployment is one of the first things that gets in the way. How do I deploy? And if we're going to shove shell scripts in their face, maybe that's not the best way to get them to our platform.

So there has to be a better way. And again, I'm not knocking shell scripts. They're great. They give us unattended automation and the number of command line utilities that are built into Mac OS X, it's just incredible. You can do anything with Unix that's what I always say.

It's the interface where things break down though. You set some newbie system administrator in front of a terminal window and it's got the blinking cursor and they're supposed to type text into it to make it do things? That's where things fall down. Fortunately Automator is here to bridge the gap. So deployment already consists of a series of discrete tasks. You can line up a list of tasks and that would be your deployment.

We've also recognized that having modularity in our deployment tools gives us a lot of flexibility into how much customization we add into our deployment solution. So all that we need to do now, as developers and system administrators is create an Automator action for each task that we want to achieve in our deployment. These Automator actions will provide a very friendly interface for the case specific options, just the information that they need to provide to customize it to their own situation while it's gearing all of the back end details, everything that's driven by command line tools and shell scripts.

So Apple can provide all of this functionality there is definitely no lack of talent at Apple for creating very innovative solutions. But I think that the developer community, the deployment community can play a large role in not only defining what functionality should exist, raise your hand if you've ever submitted a bug report, but also in developing that functionality.

Automator actions of course can be written using Objective-C, obviously we would assume that. But they can also be written using AppleScript Studio and a lot of system administrators are familiar with AppleScript, even coming from the Windows world, they're familiar with, what's it called? Visual basic or something like that.

So we, deployers, we know what we need. We can develop this functionality and when I say we, I mean you.

So here's my hit list, this is the list of functionality that I would like to see in addition to the core functionality that is provided by Apple and System Image Utility.

You probably recognize a lot of items up here on this list. This is a list of the shell scripts that I've included with net restore over the last several years. I think that we can do some really cool things with these shell scripts using Automator. So what I'd like to do next is take a look at what we can do with one of these items, with Automator.

Before I get into that though, as you probably imagined, there are some implementation details. There's some things to keep in mind. So before we get into the example, I want to lay some ground rules. First of all, remember that the product of our Automator action has to be a package installer. That's what we're going to be able to put into our net install image is a package installer. So whatever we do in our action, we have to put a package somewhere.

And what we're going to do with that package is, it's going to be a payload free package installer, it's going to have a postflight script and whatever we provide in the interface, we're going to take the options that the user specified and we're going to use that to populate variables in our post lite script. If there are any additional utilities that we need to, need in addition to our shell script, maybe a custom command line application, we're going to have to include that as a resource in our packages installer.

If our custom utility requires any frameworks that aren't part of the base net install set, so that net boot image that we net boot from for deployment, things get a little bit hairy. You would actually have to crack open that net boot image and install your own frameworks. Try to avoid that.

And I'm speaking to you as developers. What I would like to see is a deployment community where we contribute Automator actions to a collective whole. So if you're going to develop Automator actions for that community try to avoid the type of situation that has lots of external dependencies.

Finally System Image Utility acting as a work flow administrator, it passes a dictionary of information from each action down to the next. So we're actually going to take that dictionary of information and use one of the arrays within it to let System Image Utility know where we're putting functionality into this process. So those are the ground rules.

Set firmware password. I love this one. It's really super simple, the firmware password post action script is probably nine lines of code, is really easy and there's only one variable. So I think it's going to be a really good example for demonstrating how to create an Automator action that plugs in to System Image Utility. So to do this, here's what we would do, and again, you can create Automator actions in Objective-C, it's probably what I would prefer but for the interest of system administrators who don't have lots of time to learn Objective-C we're doing it in AppleScript Studio.

So step one: create a new apple script Automator action. You do that in Xcode. Next go ahead and set up a really simple interface in interface builder. In this case it's really simple, there's just a couple secure text fields. I had another little field with a checkmark just so people know if their passwords match.

Next, we need to create our payload free package installer. Now we could leverage the package maker command line utility to do this for us programmatically when our action runs. But this payload free package installer is really pretty simple. So I think that would add just a lot of extra code. So step one for me is to just go into package maker and create my payload free package installer. It's going to have an empty folder for the contents and then we have just two things that we're going to include as scripts.

We're going to include that OFPW utility that's hosted by Mac enterprise dot org. That's the thing that actually sets the firmware password, and then we're going to include our template post lite script. So in the script you can see its pretty boiler plate. The one thing of interest is the password variable. We're going to have to change that password variable during the runtime of our action so I like to set this to some easily parseable string in this case percent password percent. I've got a nice one liner in Perl that's going to replace that really easily for us.

So once we've created our payload free package installer we're going to drop that package into our Automator action project in Xcode. It will pop up a little dialogue asking if we want to copy it into our Xcode project, click yes, that's what we want to do because when our action runs, I'm sorry when we build our action in Xcode, it's actually going to copy that package installer into our actions bundle.

So wherever our action goes, be it distributed on the internet or just around our network, that payload free package installer the template, is going to be right there within our action. So the next thing that we need to do is configure our Automator action to accept input from System Image Utility.

And last Friday I discovered a very interesting thing. It only affects AppleScript Automator actions and I'm hesitant to even describe this little caveat because it's a one time thing and hopefully it's going to be so transparent to you all that you'll never have to deal with it. But here it is.

AppleScript Automator actions will spit out an NS Apple event descriptor instead of an NS mutable array. And that's kind of icky. So we actually need a converter action that will convert the output from our AppleScript Automator action to the next System Image Utility action. Again, I've already done this for you. In the sample code that I'll show you at the end of this, I've included a converter action that does this for you.

As long as you include that in your project, or you include it in your Automator actions folder, you're going to be all set and you're never even going to notice. Anyway so for reference, here it is. This is what your info.plist has to look like for your Automator action. I feel like I missed something.

I did miss something, I missed a slide. No I didn't, I guess its next. That or it mysteriously disappeared and I wanted to see if I could act on my feet. So the next thing that we need to do during runtime is we need to take the input that we received and we need to, it did miss a slide, I swear.

I'm sorry, there was a slide here that was supposed to say what we're supposed to do during the action of our script. It's pretty important because we need to do two things when our action runs, we need to copy our package installer to some temporary location. We're going to do that with a really simple do shell script ditto my package to temp location, one line.

And we need another line that's going to take the input from the user, the password, and plug that into our template post lite script. Another one liner. Do shell script, Perl, blah, blah, blah, blah, blah, path my shell script. You'll see that, I'm sorry it's not up here.

So once we're done with that we need to take that dictionary of information that was passed from the previous Automator action and modify it to let it know where our package is located. So within that dictionary of input from the previous action, there is an array keyed by package list.

That package list just contains an array of paths to various packages that we want to add to our net install set. So we're going to plug in the path to our package which is temp FW dot package, and then as our Automator work flow runs, it eventually is going to get down to the create image action and that create image action is going to create our net install set, it's going to create our master image, it's then going to iterate through this package list array and copy each package into our net install set.

So that's all there is to it. All that we had to do is take input from the user, plug that into a template post lite script, pop out a package and let System Image Utility know where it is because then System Image Utility is going to do the rest of it for us. Piece of cake right? There's like four months between now and Leopard, you guys should crank out like a dozen of these at least.

So the sample code project that I developed to describe this procedure is available up on the ADC website at least if it isn't right now it should be available within the next couple days. I encourage you guys to take a look at that. Download it, check it out and please go ahead and try to create your own. Automators are very empowering technology, or the deployers, we always rely on somebody else to give us the tools to customize our deployment. Now it's in our hands. We can do it. And again, I say we, I mean you.

And we can do this now with the tools that are in Leopard. So of course I use the word now very liberally. Leopard's not going to be available just yet. Up next is Chris LaSalle, he's going to show us what Pixar is doing with the current set of tools for their Mac OS X mass deployment.

Hi, hi.

I'm Chris and I am the lead infrastructure admin for the Mac group at Pixar. And I'm going to talk about how we use net boot in something we call Metro which is our Macintosh deployment system that we built back in the Jaguar days and it's constantly being modified and we're really looking forward to Leopard.

First a little bit about our environment. At Pixar we have four buildings on one campus, we have about nine hundred Macs spread across those buildings, and nine hundred Linux machines and about two hundred Windows machines as workstations. Our network infrastructure is pretty diverse it's grown up over the last twenty years from a very Linux based background. We have an LDAP database that's our authoritative source of information for users and machines and everything else, it's all in LDAP and our NFS data and NIS data and DHCP data and DNS data all comes to out of our LDAP database.

Most of the Mac accounts, even though the Macs are all on this network and all have access to this stuff, our Macs are all pretty standalone, they don't net boot for normal use. They are local, they have local accounts, they have access to the network but everything's all local.

We've done that for various reasons especially historical. We're looking forward to getting away from that but for now that's how it is and Metro is built around that. But we still use net boot as an administrative tool for deploying all of these Macs in this really complex environment.

So Metro is a collection of shell scripts of course, and PHP scripts and Perl scripts that all work together to do four basic tasks that we use as administrators. The users never really see net boot. But as administrators we use it primarily to deploy new Macs, that's the most thing, the thing we do every day. We pull a Mac out of the box and we net boot it and we use Metro.

We also use it to troubleshoot and diagnose Macs that are out there on a user's desk. And say we need to run a disk utility on it or something to do some repair, the admin will net boot it and then have all the tools they expect to have and they're not booted off a hard drive so they can start doing things to the hard drive.

We use it to redeploy existing Macs. We've got one in inventory, we need to send it back out to another user, we'll net boot it and use Metro to completely reconfigure it for the new user. And we use it for major OS upgrades say from Tiger to Leopard.

We plan to be using Metro, we also used it, we've used it since the days of Jaguar. That was our first, Jaguar to Panther was our very first time really pushing Metro to its limits. And of course it's all based upon net boot. We couldn't do it without net boot so let's talk about how we use net boot.

We start with a net boot image, using the traditional Tiger net boot image tools, we build one with system image utility, but we really strip it down. We customize it as much as possible and we take everything out of it that we don't need. And then when it's made our image, that's not stripped down enough, so we will mount the image and we used to do this manually, we would go through and tweak the image and remove things and add things and do what we wanted with it, but we finally said, no we do this too much lets make a shell script.

So we made a shell script to do all that stuff. So that script will mount the image after we've made it and apply all these modifications to it and it will strip it down even farther. And then we'll put it on our net boot server and use server admin to set it up and make it live.

Here's an example of some of the things that, that shell script does. We do more than this, but we will resize the image as appropriate depending upon what we want to do with it. First off we'll remove most of the applications from it like since every net booted machine at Pixar is being used by an administrator for administrative purposes, we don't need iTunes on there.

So we'll take iTunes off. We'll take Chess off, we'll take almost everything in the applications folder off of there, because we just don't need it. We'll also set the root password because most of the administrators will log in as root to do various high level things with it, we will create a single admin account which gets used for other purposes. And this is all happening on the image as it's mounted just on our work station.

We'll create the SSH keys because most of our administrators are used to using the command line, they'll want to net boot a machine and SSH into it to start running some tools that we have on there. So if we don't generate these keys on the disk image itself then every time a client net boots, it's net booting fresh and it's going to generate those keys the first time you SSH in and that takes about thirty seconds on a slow machine. So you sit there and wait, and wait and wait. So in order just to avoid that way, we generate them once and then we've got the SSH keys.

We also, and this is important, we create a little RC dot local script that we put onto the net boot image. This little shell script will run during the boot process and it will look at the environment it's booting in and kick off a cascade of other scripts that will allow us to do those four different functions that we want to do.

And we also just touch a little file on the image itself so that some of these scripts which run both in the net booted and the locally booted environments, they need to know whether or not they're net booted very quickly, so we just touch a little file on the image and if that file is there and knows it's net booted, and the scripts connect appropriately.

So when a machine net boots at Pixar, the little RC dot local script starts running. And it will basically branch into one of two different modes of net booting. It will do a normal net boot in which case the administrator can log in to the GUI, or can log into the terminal, and we use that mainly for a new machine deployment and for diagnostics and troubleshooting when there's a problem with the machine.

But we also have kind of like a net install process we have an auto install process where the RC dot local strip will see certain things happening on the disk drive and on the net boot image and it will say, okay I need to start immediately installing a system and it will go do that. And in that case it won't give anyone an option to log in to the GUI.

So let's look at the normal net boot process. In this process RC dot local will take a look at things and say oh I need to boot normally, this is what happens if you just boot a machine with the N key down. During the boot process, RC dot local will, through other scripts, it will install various GUI admin tools like Carbon Copy Cloner or Disk Utility or, well Disk Utility is already there, but it will do Disk Warrior or any number of other admin tools that we might want to do troubleshooting work on the machine.

It will also install all of the command line tools that we use at Pixar that we've home grown over the years that we're all used to having on every machine. It will just install them so that when an admin logs in through terminal, they'll have the tools they're used to having.

It also configures the environment both in the GUI and the shell. For example it modifies roots dock during the boot process so that when it finally boots up and administrator can log in to the GUI, and the dock with all the tools is right there, and it does this on the fly so that when there's a new version of something or when we want to add another tool, we just change a script and it suddenly appears the next time someone net boots. It also modifies the shell environment it will create new path environments it will create everything that the admin needs so that when they log into the machine, start working on it, they have the tools that they expect on any Pixar configured machine.

Most importantly it will activate a web front end. It downloads from our central server a bunch of PHP pages that it puts into library web server documents it turns on Apache after activating PHP, and then once the machine comes up, the admin goes back to their desk. Actually they just, the admin will take a machine out of the box, plug it into the network, plug it into a keyboard, hold down the M key and boot it, once they wait a few seconds they go back to their desk, they open up a web page to the net boot server which shows a log of all the net booting machines.

And they can see the machine that they just net booted, they click a button, and they will see this webpage. This webpage gathers information from the machine itself and gives them some fields to fill out and once they fill this all out they will create the L app entry in our central LDAP server for this machine from which all of the other stuff about this machine will get created.

So they can fill out this form, click the create or update button, and the record is either created or updated as appropriate. And they do this from their desk after they've booted the machine and so they can boot their machine in another room and do all this from their webpage. Then they go back after they've created the LDAP page, they get a similar page but this page let's them decide how and what they're going to actually install onto the machine. They can select which of the hard drives that's connected to the machine.

They can choose whether or not they're going to erase it or repair it before they run an installer. They can choose which installer they're going to run or they can let the system just choose the default and solar for an Intel machine or PPC machine or whatever. Or if they've got a machine that's going to be used for certain activities that needs an older version of the system, it will know that automatically.

And if they just let it by default, it will install the right system. They can choose to install some of the network installed packages that we have available that we build our own little packages for and they come down through the network after the installation. All they do is click that button when they fill out the form that says build out and the machine immediately starts installing. And they can just kind of watch the progress on a couple of different web pages. In about twenty to thirty minutes, it's done, they can unplug it, take it to the user, it's completely configured.

So that's how we build out a new machine.

For existing machines that are already out there, we say we want to go from Tiger to Leopard. We will, and this is how we move from ten three to 10.4 and actually even from ten two to ten three, we started with this. On every Pixar configured machine there's a little shell script that we will use to initiate an auto install.

So we can just SSH into a machine and will run this command that will tell it to auto install. It will net boot but this time instead of doing all this on the fly configuration during the boot process, it will say oh I'm just immediately going to start installing.

So first it does a couple of preinstall tasks because it doesn't bother installing all the admin tools and all that stuff because it doesn't need to. All it needs to do is start installing. So it first checks like, if on a laptop okay, is there a battery or are we plugged in.

If it's just running on battery power it will stop and give an error. Is there enough hard drive space for what I want to do? It runs a bunch of checks to make sure things are good. Assuming they're all good, it immediately starts running the installer program using the installer package that we specified.

And after the install it will run all of the configuration for Pixar. So that all happens while the machine is at the users desk. We can SSH in, type a command, the machine net boots, off it goes. Twenty minutes later the user can log back in, it's got the new OS.

So how do we initiate that process? Here's the shell script that we use or a little bit of it anyway. Basically the admin makes an SSH connection to the user's machine, runs the script, it asks a bunch of questions. The script is kind of like a mix of the start of the preference pane, and the build out webpage that you just saw where it asks like which disk do you want to install on.

It will ask the admin a bunch of questions, if they want they can erase the drive, they can run a repair on the drive, they choose which drive and this little script will just write a bunch of little files onto the machine in a little hidden directory and then the RC'd out local file during the net boot process, will see those and say okay I need to start installing using these parameters. And off it goes.

So that's how the auto install process works and we'll probably be using something very similar when we move to Leopard. We're hoping actually to write a GUI wrapper with AppleScript Studio or something around this, so that when we make the move to Leopard, we can actually have the users do it themselves. We'll just say run this program, fill out the form, type your password, and go away.

- And come back in a half an hour, go have lunch.

And then after that they'll come back and they'll have Leopard.

So where are we going with Metro from here? Well Metro's been around for awhile now so we're trying to, we're always rewriting it and trying to make it better. Right now I'm working on it to make it a little more modular so that we can make changes on the fly.

I'm also implementing a live environment versus a development environment on the same server so that my co-workers can connect in to use it while I'm continuing to work on it. And then as I make small improvements I can move them over easily and quickly and my co-workers will get the benefits of that work.

Especially with Leopard now we're constantly reevaluating what we have to do. There's so much new stuff and there's a lot of better ways we could implement the stuff we've done. So we're really looking forward to Leopard and as Mike was just talking about, we're looking forward to how we might be able to use the new System Image Utility, it has a lot more flexibility and we can probably get rid of some of our shell scripts and use that. So that is Pixar's Metro and hopefully it will be inspiring to some folks. And now I'm going to hand it back to Joel, thanks.