We'll get to them in a little bit. But what we want to talk about is the preparation that you need when moving from one to the other. We did this two years ago with Panther to Tiger and we're doing it again. But we want to focus on certain critical areas. And those areas are the service configurations. DNS, AFP, the file sharing services. Firewall, really critical, some other stuff.

We're going to talk about the password server, KDC, and we want to talk about all the accounts. The user accounts, group accounts, computers, computer lists, computer groups, all that kind of fun stuff. If you haven't downloaded the upgrading and migration guide from Apple, the URL is at the end. I urge you to go out there. So go to Apple.com. The wireless is up here. Download it and you can play along with your home version of the games. So what we want to talk about is some terminology.

We want to talk about backing up your server right away, just a quick and dirty method. So if things go bad, you can get back. Talk about some rules of engagement. And we have two different things we want to talk about, upgrades and migration. So first off, the terminology. We have three terms and sometimes these terms get misused, so we want to define them. So we have an update. So recently Apple updated from 10.5.2 to 10.5.3.

And then we have an upgrade. An upgrade is Tiger to Leopard, major OS, .rev. You learned from Bertrand that Snow Leopard will be coming out and that'll be an upgrade. And then we have migration. So we want to separate these. We want to talk about these. We're not really going to talk about an update.

We're going to talk about an upgrade. Then we're going to talk about a migration. So what's supported? Well, 10.4.10. So if you have Tiger, you need at least 10.4.10. It updates the schema extensions for Leopard, anything less not supported. Panther 10.3.9. How many people are still running Panther Server? Two? All right. OK.

If it's running DNS, DHCP, if it's running firewall, it's going to work good for you. It's not a problem. Also, anybody out here Windows NT? No, yeah, no. All right, what's in the migration guide? So if you want to do it, it's in there. We're not really going to cover that. But we can also upgrade from Jaguar as well. 10.2.8, 10.3.9, 10.4.10. We can migrate over. Easiest method, probably already been there. If you have a small deployment, small office, home office, clean install. You have five, 10 users.

Migrate the data, back it up, do a wipe. Easily recreate the passwords, recreate the users. There's no access control list, no file ACLs, service ACLs, or directory service ACLs. You don't have that problem. That's easy. So think about your deployment. How many people are running Open Directory Masters replicas? Show of hands? OK.

So if you have that, it's going to be a little bit easier. We're going to talk about that a little bit later. But what we want to focus on are the tools necessary to do a successful migration. How to do this? How to do an upgrade in place? What do we really need to focus on? So let's talk about a quick and dirty backup procedure. And this works great no matter what you're doing. If you have an XServe, you have three drives, you can do this at home.

First off, you have an XServe, chances are if you're running the OS, you may have a mirrored software RAID on the first two drives, you have the third drive. You can install Mac OS X or Mac OS X Server on that third drive. When you set up that third drive, make sure the username, password, make sure all your SSH keys if you're doing that, make sure the IP address is the same, use ARD, set it up. Basically set it up exactly like you would the server. Copy over library preferences, preferences.plist with the IP address information, all that kind of good stuff.

When you do that, if the XServe software fails for some reason or you reboot the XServe, you're still going to be able to remote access into it. It's going to have the same IP information, same administrator password, same username, same SSH keys, all that kind of stuff. When you boot into it, you can actually use Apple Software Restore, you can use disk image, do whatever you need. You can make a sparse disk image, make a clone of your server.

Don't get the user data because you want all the really good stuff, right? When you do it that way, you have a live backup that you can just push back over any time you need. And you can actually use rsync if you want to to synchronize the two. Use hdiutil, mount the disk image, use rsync to synchronize the data, unmount the disk image, works really well.

So where are we right now? Right now you should be thinking about, okay, I did a backup. Am I going to do an upgrade? Am I going to do a migration? Which am I going to do? And before we go any further, we have some rules. We need to play by these rules. We don't play, things don't go well. Rule number one.

and Andrew F. Hans. Thank you. So, show of hands of people that have lost their jobs.

What do you really want to back up? Well, hopefully the user created data, all the iLife files and iWork files and Office files and all that kind of stuff, hopefully that's all backed up.

What we're talking about is the data based on the services, The account data, KDC, password server, all the critical stuff, all the configuration stuff, all the stuff that at 3:00 AM you changed because it didn't work and then you went back to sleep because you didn't remember what you changed. You need to remember what you changed. DNS.

We say this all the time, if you bend any of the other, just the DNS house needs to be in order, period. If you have homegrown configuration files in certain services, and we're going to talk about that later, these files may be fixed or cleaned. A good example of that we're going to talk about is DNS. If you've customized your DNS configuration files and you do an upgrade, Apple may try and clean those up. So you may want to have a backup of those.

We need the server admin tools. Right? Need to download them, need to make them there. You can have the Tiger and the Leopard Server admin tools on the same thing. It's not going to cause a problem. So if you need to administer both, you can do both, but you can't go back.

and what about netboot images? You have your greatest hits netboot images. You're still running Panther. If you have 10.3 netboot images, they're still gonna work, they're fine. Anything retro, you're gonna have to update a little bit. and what about some caveats? Well, hardware mon D, Any startup items? Anything like that that you've customized? No. LaunchD rules the roost. It's process number one. So Watchdog? No. HardwareMondee? No. Startup items? You've customized them. You may want to copy them over.

Everything you have should be moved to LaunchD. Everything. Watch a process, watch a file, watch a packet, watch the network, then trigger a script to do it. Macintosh Manager people! Yeah, okay. So no Mac manager support anymore. John Detroit is just shedding a tear right now, but there's no Mac manager support.

QuickTime Publisher, it's gone. If you were a fan of QuickTime Publisher, that's all right. You may need to redo the path to your MP3s and your playlists. Update the paths, you're going to be fine. Right? And PHP is into life. PHP 4 is done. It's over. There's not going to be any more updates after August. So if you're running PHP, upgrade to 5. If you're still running 4, just make sure you have the patches in place. Those of you that write the code, understand that. Just be aware of that.

And what about the XML files? We have a couple slides just to talk about the XML files. Almost all the XML files now are stored as binary. which means you can use property list editor to open them, you can use PLU till to convert them, right? You can have automated scripts that actually convert them, make some changes that you want, convert them back. And I'd like to invite Andre LaBranche up, do a little demo.

of an upgrade. - Andre. - Thank you. So I have no less than five demos for you today. This one's gonna be very short, sort of kind of an intro demo. Basically, we're gonna start with the upgrade in place path. And so what I'm gonna show you here is just a Tiger Server 10.4.11 briefly showcase some of the services that are set up. And I don't really expect you to see all the details here.

The point is I'm just showing you that we have a bunch of stuff going on here. And so I'm going to launch a few things and just quickly show you that, hey, this is a Tiger Server. It's got stuff running on it. And then I'm going to kick off and upgrade to Leopard.

So we have mail server. We have Kerberized mail. Got a couple of mail accounts here. Here's a server admin. And I'm just showing you this not to demonstrate mail, just to show you that a mail server is running. There is actual data here. You can see a list of services we have configured.

If I click back over here, I'll just show you a couple of quick shell script outputs that I've got. We've got a DNS zone file here. That's a little dig command that shows a zone transfer. So you can see I've got some DNS records. We've got some IPFW rules, including one custom rule that I've placed in etsy/ipfilter/ipfw.conf. In addition to rules configured through the GUI, we've got a Jabber server set up. We've got an Open Directory master set up.

And I can do things like, since I just logged in using Kerberos with the mail client, see that I've got Kerberos ticket-graining tickets and service tickets. If I go into Workgroup Manager, You can see that I've got some, I've got an LDAP container here, got some users, got some groups, got some computer lists, and I have one computer list that is slightly populated.

And that's pretty much all I want to show you there. So we've got our Tiger Server. It's working. Hooray. So now we're going to upgrade. So basically-- oh, and the web as well. I've got two websites, one that's pretty cool, and another one that's just unspeakably cool, SSL. I don't know if you can tell, the URL there is an SSL-enabled URL. So I'm using a self-signed certificate for that.

And oh, you get a print queue as well. So there's my print queue, which is just a standard LPR queue, or IPP queue, I should say. So then we will boot into the Leopard Server installer. So I go to my startup disk. Now I've went ahead and imaged this to a hard drive partition, so it's a little faster for the demo. But same idea.

As it's restarting here, I'll just sort of describe what's going to be coming with the rest of the demo. So this is sort of almost an intro demo, not really showing you too much here. I'm going to click through the basic in-place upgrade steps that you would take if you were going to do an in-place upgrade. And then the rest of the demos are going to focus on what happens afterwards.

So you've got a server that was upgraded in place, what happens to the services. So through each of the subsequent demos, I'll be sort of picking a couple of services and just showing you the results of the in-place upgrade. And then the last demo is a bit longer.

That's sort of the migration example where we have a fresh Leopard Server installation and I've got a bunch of data that was exported from my Tiger Server. So things like service configurations, open directory archives, that sort of stuff. Things we'll be talking about. And oh yes, the installer DVD does not do mirroring. So... I'm clicking Next.

Clicking Continue. And there's no way to set mirroring from here. Totally forgot about that. Clicking Agree, License Agreement, Select a Disk. I will select my-- you know, I'm telling you what's happening here. I select Tiger Server. I click Continue. I could customize it if I want to by selecting or deselecting other packages. And I click Install. And away we go with the in-place upgrade. And so now I'll turn it back over to Schoun.

Thanks Andre. Just to confirm, yeah, it's really doing that. So the upgrade that Andre is doing, right, the most important one, and that's the one we want to focus on, is the Tiger Master to Leopard Master, right? So we have an OD Master, we have an LDAP database, we have a KDC, we have a password server, all the really, really crucial stuff that we need. And so we've done the in-place upgrade. So we've upgraded it.

Most importantly, serial number. Obviously, you have the serial number. Have it there. Boot from the DVD. Make sure you have the hardware requirements. Right, it's not going to work if it has less RAM or a smaller hard drive. You can image it over, but let's meet Apple's requirements to make sure we're happy. Have it ready to go back up, maybe a replica. If things go awry, reboot the server.

Then upgrade each replica. Test with your clients. Leopard clients, Tiger clients. Make sure everything testing is done. Then you can get your groove on. Then you can go. It doesn't work. Things go wrong. You don't have, maybe you have some custom configuration files, maybe the power went out, whatever happened.

You still have that Tiger replica that you can promote to a Tiger master, right? You can change that LDAP database from read-only to read-write. So, that's the path that Apple supports, that's the path they want you to take, that's the path that we're suggesting. What about Nuke and Pave? Archive using server admin utility 10.4.10 or later. Get the disk image. Open the disk image.

Make sure the files are there. Make sure that you can see the files and read the files. When you do an archive, what does it save? It pipes out the LDAP database. Does dump of the password server. Pipes out the KDC database. It pipes out the directory service folder in the library preferences. It pipes out the IP address information. It pipes out Tiger NetInfo. It pipes out the SMB.configuration file. It gets this. What doesn't it get? SSH keys if you're doing key pairs. Custom configuration files. Service preferences.

So you got to make sure you get those. Just make sure you get those. Archive it, back up the other ones, especially if you have not service hackles, not file system hackles, but directory service hackles. So in Tiger you could do directory service hackles to make sure you knew who read the database, who could write to the database, that kind of thing. And a little interesting way to do that, you had to use the inspector and write the commands or import them. and perform a clean install of Leopard Server. Promote it to an open directory master. Use server admin to pull the stuff in. Joy.

You want to be careful because when you promote to an open directory master, Make sure you use the same administrator name and password and Because when you do a restore, you want to make sure that the username and the password that you had in the LDAP database that's going to be restored for your Open Directory master is exactly the same as the one that you have now. Because password server doesn't merge, doesn't really do an overwrite, so you want to make sure that they're the same.

Upgrade server service changes. Each service has a config file. In Tiger we have the really cool tear off, right? You go to the services, do the tear off thing and you show that to Windows people and they'd be really cool. So you could do that and you save those files and you want to import those files one at a time and test all the services that you're running on your Leopard server. What about directory services and then upgrade? Well, we want to talk about four things, NetInfo, LDAP, Kerberos and binding. Net info doesn't live here anymore. You heard it last year, you're gonna hear it again. It's gone.

Apparently there's applause for NetInfo being gone. Okay, fair enough. The next people are shutting it here, but that's okay. Private VARDB, DSLocal, nodes default. That's where everything is stored. We'll talk more about that. And I urge you to go to the directory services troubleshooting session and the directory services lab if you're interested in finding out more about the local data store. There's some really cool things you can do with a local data store.

LDAP. The schema was updated in 10.4.10 to add the Leopard schema additions. You can actually use slap test. to talk about these changes. So if any of you have actually updated your schema, and configure your schema in a custom sort of way, you can actually use slap test to do this.

And what you're going to find out is if you did the schema changes, you actually have a new container. And so I don't want to spend a lot of time on this because we're going to talk about directory services. But the bottom line is if you have an LDAP container, you have main server.printedincode.com. And inside there you have a container for users, container for groups, container for configurations, all that kind of stuff. If you have custom schema, it actually goes into a separate container. Which is the config container which is local. And it actually overlays on top.

So the directory service team has done a wonderful job of handling the overlays in that fashion. You can do it without a restart. It actually works really, really nicely. What about group accounts? Group records should include the GUIDs, right? For all the members and computer lists to computer groups. So we have this migration.

from Tiger to Leopard because we have certain attributes that the groups need to have. So you can actually do an export because groups don't have passwords. So you can use Workgroup Manager to do an export and do an import. And Andre is going to speak to that in just a little bit. And we have Kerberos.

If you still have users with crypt passwords, it can be brought into the 21st century, right? And if you have a service that's not Kerberized, you can use slap config with the Kerberos flag and crank up the The KVC part and make sure the principles are going. And what about binding? What about the magic triangle? Unbind.

Unbind first, do the upgrade, rebind. Keep in mind that with Leopard Server, if you're going to do a magic triangle, and again, I'm going to talk about this, make sure you bind active directory first, then promote to an open directory master. The KDC is smart enough now not to start up, not to overwrite the edu.mnt.gobros file.

Sensors applause about that. You may want to also look inside your local config container because when you do a bind, not only is it in the edu.mit.curberos file, but inside your local config container, you also have a config record for all the KDC information, just like you would on an open directory master. It's pretty cool.

At this time, I'm going to turn it back over to Andre. Hopefully the machine is restarted and things are going to work. Thank you, Schoun. So as you may have guessed, I have cheated. I have pre-baked states here on Firewire partitions, just like on the cooking shows. So I have one in the oven here I'm going to show you.

And in this short demo, I'm going to basically show you a couple of changes between Tiger and Leopard. Going to show you some changes with the way the group records need to be managed, a couple of gotchas or one gotcha there. Going to take a quick look at the DSLocal replacement for NetInfo and also quickly talk about the local KDC as well.

So if I pull up Workgroup Manager, this is the upgrade, by the way. So we could see in Server Admin that, hey, look, most of our services are there. Most of them, but not all of them. We'll get to those later. So let's start back here in Workgroup Manager.

Got a couple of groups here. I've got one called Dev and one called Legacy. Now this is a slightly contrived example, but it's still kind of important to know about. So normally, a group will have lots of different attributes, but two of the key ones are group members and group membership. The basic idea is that a group is more than just a list of usernames.

It's also a list of GUIDs that correspond to each username. And the GUID is important because it helps the system identify a user, even if the same username might exist in another directory somewhere else. So Mac OS X Server really wants each user to have a GUID in this group record.

So my Legacy group here doesn't have any GUIDs. That's why it's called Legacy. So if you had a really old GUID, you'd have a really old group record, like a BSD standard record or such, you might not have these extra attributes. So there used to be actually a button that said upgrade legacy group.

So that was a feature of Tiger Server. We're in Leopard now. So if you happen to have one of these legacy groups, the easiest way to get it into the new format to add those extra attributes is simply delete it. Well, first you would back it up. I've already done that. Just export it using Workgroup Manager. And then import it again. And when you do that, you will be able to import your legacy group. And you will basically get your group record, your group configs legacy group.

What I will see is that if I go into the inspector, which you can turn on in the Workgroup Manager preferences, that now I have both the group member and the group membership attributes. So I have the corresponding GUIDs for each user in the group list, which is very important. So make sure that your groups are correct. And there's actually another gotcha that we'll see in the last demo where if you don't have a proper group record, some of the things that should automatically work don't. So make sure that your group records are good.

So next we'll take a quick brief look at the DS local database. So if I open my utilities folder and I type in, what's missing here? Well, the network, excuse me, the net info utility is missing. So you don't have that utility anymore. Instead, we rely on directory services tools.

So Tiger has a bunch of tools, command line tools that start with DS. A very easy way to find your DS tools is to open a terminal, type DS, and then hit tab a couple times. The shell will show you all the commands that start. So if you want to use the command line tools, you can do that with DS. Read the man pages for all of these. They're good. So we could use, for example, DSCL, the directory services command line. And it's sort of got an interactive interface. So I could browse into local and list.

And we have an instance of a local database type called default. There could be others, but usually there's not. I'll go into default. And we see all of our record types here, like users and groups. And I could browse into this. And oops, got to type it right. Does tab completion. And this is just the same as it would be on Tiger. That's kind of the point. Totally new database.

Database underneath. But because the directory services tools provide an abstraction layer, you shouldn't even need to care that it's a different database format. So if you use your DS tools, the point of that is when you need to operate on this data, use DS tools. And that will sort of future-proof you.

So, for example, if you were doing things like operating on raw NetInfo database files, you would have to update those procedures for Leopard because there is no NetInfo. So use the abstractions provided to you through the DS tools. I do want to show you one quick thing here.

Grab a root shell. And I'm going to go into var db dslocal default. Or excuse me, nodes default. And this is actually the back-end data storage for the dslocal node. And we see record directories here that correspond to record types. I can go into one of these directories. Each record now is stored as a property list, an XML property list that you can actually read. So you could look at it through a pager such as less.

This is basically a group record, but now it's in sort of an XML format. Resist the urge to operate on this data directly. Again, for the reason I just mentioned, this totally bypasses the directory services abstraction layer, which means that if you make changes here, the running directory services demon, A, doesn't know about it, and B, you're not protecting yourself from any potential changes that may occur to the back-end data format. So use the directory services tools and everything will be good, hopefully. So there is one other thing I want to mention. There is one other thing I wanted to point out here, and that is in the config directory. Let's see if I can find it.

Here it is. So the config directory is the authoritative source for lots of configuration information for your server, in particular the Kerberos configuration. So library preferences, edu, MIT, Kerberos is not the main source of that information anymore. It's actually this directory. So whenever you want to go troubleshoot this stuff, this is really where you should look. The library preferences, edu, MIT, Kerberos is the main source of that information. So if you want to go through the library preferences, edu, MIT, Kerberos is basically created from data stored here.

So I'm calling this location out because I don't know of any other places where you would say, hey, look here for stuff, but look here for stuff. Okay, and I just wanted to show you quickly the local Kerberos key distribution center. So the LKDC is a new feature in Leopard client and Leopard server, and it basically pushes single sign-on down to desktop machines who are not open directory masters. But because Mac OS X server is a superset, we have the LKDC in server as well.

So to show you some of the backend bits of that, I can grab a Kerberos administration shell using K admin dot local, and I could run a command such as list principles. Principle is just fancy term for like a record in the Kerberos system. And we see a bunch of principles here. Like we see ones that I would expect based on the fact that I was an open directory master. I have like, you know, name slash server name, and then the realm I have is server dot WWDC.

We've also got some crazy ones in here. Look at these, like SIFS, LKDC, SHA-1 hash, big unreadable string, another at SHA-1 hash realm. So these are provided by the local KDC. The upshot is you shouldn't really have to worry about this too much. It's designed to interoperate with everything else you've got going. So basically the point is that your machine is essentially hosting, two different Kerberos realms.

If I grab a process listing, I can see that Curb 5 KDC is running with two different realms. The first one there, after the first dash R, is my local KDC realm. And the second one, which is sort of continued on the second line there, is server.wwc. One interesting thing is if I actually look at the Kerberos key tabs that are installed on my system using K-list-KE, I see all of my server at WWDC tickets, but I don't see any local Kerberos, I don't see any LKDC key tabs installed here.

If I'm an open directory master when I'm doing this, it doesn't fully initialize all the LKDC stuff, which shouldn't really be a big deal because you're already Kerberized. But this would be a difference between an upgrade install versus a clean install, which I'll show you later. So if you don't see these LKDC entries in your key tab, don't freak out because if it's an in-place upgrade, then they won't be there. And back to Sean.

So what about some other services? Well, what about DNS? We know DNS is important. If you're running a Mac OS X server as a DNS, give yourself a round of applause because it is really good. Thank you. So the thing is that if you've customized the DNS files and you do an upgrade, an in-place upgrade... Leopard has a different way of dealing with the DNS configuration files and you're going to get the option to Transmogrify, to use a Calvin and Hobbes term, those DNS configuration files.

You don't have to. DNS will continue to work fine, but you won't be able to administer it from the GUI anymore. But chances are if you've made custom configuration changes to your DNS file, you're not using the GUI in the first place. So just be aware of that fact. If you choose to do that, you're not going to be able to administer those anymore. And printing.

You want to reset your print queues, import your settings, use the server admin command line tool, right? Your server admin settings, old print settings, suck them in. In the firewall. Cool. If you have custom rules, everything imports fine. So if you're doing an in-place upgrade and you have the firewall, which is critically important because you don't want users attacking your machine, everything is fine.

And what about certs? Older certs work fine. You can suck them in. If you have customized configuration files, you need to make sure that the path is the same. By that I mean if you're using Mail or using LDAP or something else and you've pushed it off to a customized configuration file, when you do that in-place upgrade, you want to make sure the path that references where those certificates are is exactly the same. At this time, I'm going to turn it back over to Andre. We're going to show you a few things that we just talked about.

All right, thanks. Okay, so this is the third in our sort of rapid-fire sequence of demos. And I'll show you one thing I forgot to show you in the last one, which is the difference in the way that the computer records and computer lists are managed. Basically, we have an extra button in our little button bar up here.

And so we have the third one that shows all of our computer records discreetly and the fourth one which shows us our computer lists. And list is just a group for computers, basically. You would use that as a target for things like managed preferences and such. Another important difference that I should quickly call out is the fact that if you have authentic.

Binding enabled on your server, people who are users in your system can actually create their own group records by doing an authenticated bind to your directory. And while that may sound scary, it's actually pretty cool because when they do that, it actually initializes Kerberos on their system and actually installs key tabs for their services on their workstation or server and integrates them with your Kerberos environment.

So by doing a trusted bind, you're actually setting up single sign-on for the services on their machine, which, of course, is cool. Because more passwordless login is beneficial to everyone. So now I will show you the stuff in this demo, which is the DNS stuff. So first thing to note is that DNS actually works fine without touching anything. So I've done the in-place upgrade, and here I am.

I'm going to show you just a quick zone transfer here. So if I do, again, my dig command that I did before, which shows me all the records in my zone, everything still works. You may have noticed that I'm still an open directory master and so you could probably infer that my DNS is still working just based on that. But I still have all of my DNS records, so that's good. But if I were to actually go and try to manage these records in Server Admin, as soon as I click on the DNS tab, it offers to upgrade the DNS configuration for me.

And I can choose not to upgrade it if I don't want to, but that basically just means I can't edit the configuration using Server Admin. But if I do want to upgrade it, I just click Upgrade. And then it just kind of works like you would expect it to. I can see all the records in my zone and can go back here and do another zone transfer and see that, hey, all the records are still there.

So you shouldn't really have to do much for DNS. It's always, of course, good to back up your DNS settings ahead of time just in case. But DNS should just work for you. So that's handy. There is a new repository for some DNS configuration settings in ETSI DNS.

And I'm only calling this out because this is a new directory in Leopard. So you'll have some items in here which are included from the primary DNS configuration file, DNS server configuration file. And so we support configuration for views, DNS views and such. So for example, if you twiddle some settings, I can look at publicview.conf here.

For example, right now I'm allowing local networks to do recursion through my DNS server. If I were to, for example, disable that, by removing this entry and saving, changes to none. So now if you're on the none network, you can recurse. And we see that it updates the file here. So one theme here that you'll see consistently with Mac, Wist and Server config files, ideally, is that the comments will tell you if it's okay to touch the stuff or not. Listen to those comments. It's in your best interest, I promise.

So if it says don't edit this file, you really shouldn't edit this file because your changes could be overwritten the next time server admin has to go and update the file due to some of the changes. Now, for most services, Apple does give you a place to put your own hand-edited configuration in a file that is typically included through a main config file, but the separate file is not maintained by the admin tools, and so it's safe for you to put things in there. And one example of that would be IPFW. So I had a firewall running in Tiger.

I can do IPFW show, or I could go in the admin tool, and we see all of my rules here, and the one that I want to point out is this one, which is a custom rule that I had configured in ETSI IP filter, IPFW.conf. So because this is an in-place upgrade, obviously all those directories are going to be maintained in the ETSI IP filter directory. So the firewall works without you having to do anything.

You'll notice that it's on. It's catching packets. You can see in the second and third columns there that we are actually matching packets, and the firewall is active. And yeah, there's not even, you'll notice that it doesn't actually configure my firewall service for me in the sense that it doesn't enable service configuration, which basically means I have to select my server name, go over to services tab, and then if I want to edit my firewall settings, check the box, click save, then firewall shows up in my list, and I can go and edit just like I would normally edit.

And that is fairly straightforward, and that is all I want to show you. Oh, excuse me, I have print settings as well. So in the sense that you have to do a little bit of work. So if I go into my print and fax thing here, I see that I've got no print queues, whereas before you saw the dummy queue.

So if I want to import my print settings, easiest way to do that is to have simply exported the print settings from server admin in Tiger, and then I just go import settings in server admin. So I'm going to go ahead and import my print settings, and then I'm going to go import my print settings from server admin in Tiger, and then I'm going to go import my print settings from server admin.

Print config.plist and I okay that. So now I've got back over here in print, I can see that I've got my dummy queue. I switch back to server admin. Hey, there's my, or excuse me, system preferences. There's my dummy queue. So the print settings do require a little bit of, well, they do require some hand massaging there in order to restore your settings. And that's all for that demo. So I'll kick it back over to Schoun. Thank you, Andre.

So what about file sharing? Well, you already saw it. The file share share points used to be inside NetInfo. When Andre went into the config container, you saw the share points. All the share points are held there, right? So private var DB, nodes default, they're all inside there. And you can use the sharing command if you want to, to actually confirm that all your share points are still there.

What about automounts? If you have automounts, maybe group automounts, maybe you have an NFS automount, maybe network home directories, might be a good idea for you when you're doing an in-place upgrade to unshare that automount, save the change, and reshare that automount just to write the record back. If you already see the record, you should be fine. But if it didn't pull the record in, not a problem. Just unshare it, save the change, and reshare it. Okay? Web and mail? Apache 1.3, just so 2007.

Upgrading to 2.2 uses server admin GUI. It was 32 bit, now it's 64 bit, screen fast. Any custom configuration files, back them up. Make sure you got them. You can use one of the plethora of migration tools that Apple has inside of system library server setup migration tools. In this case, it's the web config migrator command line tool to do that.

What about mail? If you're running a Tiger mail server and you're doing an in-place upgrade, after you restart the computer, you may actually have to go into server admin and restart the mail service. You're going to have to click on that start button. It's really tough, but you may have to restart the mail service manually. You can also use the Cyrus IMAP tool to actually migrate the information over.

Okay, obviously if you're running Clam AV, Spam Assassin, anything else, make sure you have the latest versions. If you do an upgrade in place, go back out, recheck, make sure you go back out to Spam Assassin or Clam AV, make sure that the virus definitions are exactly the same and those are up to date. So I want to turn it back over to Andre to talk about these. Okay, so we have a short demo here to talk about mail and web.

So as Schoun mentioned, we'll start with the web. So first thing we notice is that it did not add it to the list. So I will go once again, select my server name, click settings, find web, check the checkbox, click save. So if I were to just, and we do see that the web service is running, so that's good. But if I were to grab my browser, try to actually hit one of my websites. Uh-oh, 404, let me try the other one. Oh no, 404. Actually, this isn't a 404.

Well, it will be in a minute, but the SSL stuff keeps working because it's giving me the certificate prompt due to my self-signed certificate. But then it's a 404. Oh no, what happened? You have to back up and restore your library document, library web server documents. Well, wherever you put your website, basically the document root, if you have it stored somewhere else, back that up and be ready to restore it. So I will do that now.

Basically, I just have a very simple setup here. So I'll go to Library web server, Documents, and grab my simple little document root directories here, drop them in. And now when I reload, hey, there's my SSL website, and there's my other website. So the upshot is take care of your document roots.

So that is the sort of, so again, I guess the other thing I wanted to point out is aside from the document root stuff, it did just work, right? I didn't have to mess with any settings in server admin. But if I did go into server admin, And select the overview tab.

Right at the bottom there, there's a little button that says upgrade Apache version. And this would basically transmogrify myself from Apache 1 to Apache 2. And so I'll just go ahead and tempt fate by clicking that button. And I have a dizzying array of choices here. I wonder if I left it with 1.3 and clicked continue, what would happen? Let's not try that. 2.2.

And a little service configuration assistant. One common theme you'll see in Leopard Server is whenever you have like a multi-step operation, you'll get like this other little window that comes up. That's a service configuration assistant window and it's sort of there to help you do step-by-step things where there might be like a branching tree, different, you know, like a choose your own adventure kind of thing, which is sort of hard to represent in the server admin UI, so they have this separate stuff, which is pretty helpful actually. So we've done the upgrade. If I go to sites, I see my sites are still there. I can go back to Safari and everything still works.

I could even quit and relaunch Safari to make sure that everything still works. And there's my SSL warning again, but hey, look, it's good. So we have... Mail as well. And the mail isn't as hard to deal with, but you will notice that the mail service is not running. So I click start mail and I get a little warning, I guess, because the firewall is turned on. And mail will start up.

Ideally. And so there's some state issues with this UI apparently, but if I launch Mail.app, Which is still configured, although you wouldn't know it from this window because it's like, oh no, my settings still there? Yes, they actually are. I click continue, it's upgraded my mail database because remember this is the in-place upgrade. I did actually show you Mail.app briefly in Tiger Server. And so what we have here is... and Eric from Mail.app.

So we can basically jump back in here, check my mail settings and make sure that They are correct. And they are actually not in the sense that my Mail.app is configured to use SSL. But if I want to use SSL, I would actually have to reselect -- oh, it does say require. There we go. I think we just have a little state issue there.

Stay offline. I'll just quit and relaunch mail. And there we go. So I get the certificate validation error. And I click Continue. And hey, look, there's my Kerberos prompt. and hey, look at that, it's an unread message. Well, it was actually read before, so you may have some issues with message state in the sense that the flags may not be preserved.

I'm not sure if there's a way to work around that, but at least in the in-place upgrade scenario, I'm kind of showing you what actually happens. So this actually happened in an in-place upgrade. So I don't actually know if there's a way to work around that, but do be aware of that.

So I could go back into my terminal and do a K list. And we see that I've got my Kerberos tickets for IMAP and my Kerb TGT. So the mail service did continue to work. Without much prompting, I just simply had to start it again. That's all for that demo. Back over to Schoun. Thanks, Andre.

All right. So we've talked about an upgrade and over the next few minutes we're going to take a really quick look at migration. So I'd like to invite up Jeff Walling to the stage. So Jeff, come on up. And we're going to talk about migrating from one server to another. Jeff. Thanks, Schoun.

With a migration, what we're really talking about is the ability to move from one instance of OS X Server to another instance of OS X Server, preferably from Tiger to Leopard Server. And more than likely what we're looking at is migrating from one box, one physical OS X Server to another OS X Server. For example, moving from a PowerPC Mac over to an Intel Mac.

We're also going to look at things like restoring files from an older version of OS X Server, bringing those into your new Leopard Server instance. Merging custom configuration files for file services and other services. How to import over all your pertinent databases like your Open Directory Master Database. And we're going to talk a little bit about some of the migration tools that are available to help you do some of that migration.

One of the most important things that we need to talk about when we look at a migration is the ability to pull over all of our open directory information into our new server instance. So we need to look at what we do with regards to the user database.

How do we get all of our users out of our old OS X server instance and bring them into our new OS X server instance? How do we extract those records and reimport them safely? How do we get the user's passwords out of the password server database? And how do we get their Kerberos principles out as well so that when we do our migration, it's seamless to the end user. Everything looks exactly the same. It functions exactly the same.

When we export settings out of our previous instance of OS X Server, we have a couple of different ways to do this. We have a couple of different tools either via the UI or via command line. When we export out our open directory settings, all of our user information, our password server database, we can choose to use Workgroup Manager, we can choose to use Server Admin. When we export our service settings out, we can choose to use Server Admin, we can choose to use the command line, the Server Admin command.

When we export and bring over or migrate our user data, easiest way to do that and preserve all of our file system ACLs and all the other information that we need to preserve in our user data migration is to simply wrap all that data up into a zip file, a tar file, however you'd like to zip all that information up and then migrate the data over so it preserves all the file system ACLs. So export all of your information out.

When we look at exporting information out of the server, especially our user groups, our computer lists, all of our open directory information, the first tool that pops into mind is Workgroup Manager. If we use Workgroup Manager to export our users out of the server, out of our previous open directory master, one of the things that we lose are our users' passwords. So if we use the export setting out of Workgroup Manager in, say, Tiger Server, we're going to lose our users' passwords. However, if we use Server Admin to do this.

and create a disk image from our Server Admin, our open directory master settings, we get both the password server database and the Kerberos server database, and we get the full backup of everything that's involved in the open directory master. From the command line, we can also use DS export to export all our information out and server admin to pull out all the service settings as well as server admin from the UI.

If we choose to take more of a manual approach to get all of our information out of our Open Directory master, we can use the LDAP search command to back up all of our user information. One thing to point out here is that any changes that you've made to the schema in your previous instance of OS X Server are going to be overwritten when they're imported back into the Leopard Server.

If we use LDAP search to export our user information from our previous instance of OS X Server, we also need to export the user password databases and the Kerberos database. So we use MakePassDB and the KRB5 util to export all of that information out of both the password server database and the Kerberos database.

Once we have all of our information backed up, we've used server admin or the server admin command line to back up all of our service information. We've used either server admin or work group manager to back up all of our open directory information. We've backed up all of our user data. We've put that into a zip file, ready to move over to our new system, our new instance of OS X Server.

We need to look at a method for importing the services and bringing all that information back into our new system. So the first step would be to copy over your user created data, all of their files. Bring that zip file over into the system, unzip it, untar it, put it back in the state in the system where you need it to be. Make sure that your home directory structure, if this was a home directory server, make sure that your home directory structure is configured the way that you need it to be configured.

Next, import your open directory information back in. Rebind into Active Directory if you need to. Import all the information back into your directory services. Set up and test all of your services and your permissions. So import any service settings that you have, AFP, SMB, import those service settings back in and test, test, test. Make sure that everything you have is working the way it should be working.

One caveat to this that I want to point out, if your server is also running as a DNS server, for example, you're hosting a DNS for your network and your server is also an open directory master. The one change in this step process needs to be that when you reimport your services and your settings, you're going to need to do DNS first. Otherwise, your open directory master is not going to come back up properly. So be sure if your server is running as a DNS server that that pops up and that repopulates first, then bring in your open directory settings and follow the rest of these steps.

As with the export, we showed you how to do some manual steps. Same thing with the import. If we choose to go with a manual method instead of restoring from a database, we can use LDAP add to bring information back in from our exported information and migrate into our new OS X server instance.

We also need to bring back in the password server databases and the KDC database. One thing to really point out here, because we're using a merge, when we use MakePassDB to merge our two password server databases, you need to make sure that your previous directory administrator account, long name, short name, password, all match up with the new directory administrator account that you're creating on your new OS 10 server instance. So that when the password servers get merged with the MakePassDB command, you can still log into your server with the same user account information.

Always verify that everything went properly. Use KAdmin.local to make sure that all your principles got pulled over correctly for your KDC and use your MakePassDB and dump all the information out of your password server database to make sure that your password server slots line up for what you had in your previous instance of OS X Server to your new instance of OS X Server.

Access control lists take a little bit more care. If we look at file system access control lists, file system access control lists are stored in the HFS+ file system. So if we zip up our previous user data and move that data over to our new server, our new OS 10 server instance, and unzip that information, the file system ACLs are gonna be preserved. That stuff's all gonna come over with us. Our service access control lists are now located in the local database.

So they are now located in the same local database where our local users and information is stored. Our directory service ACLs are stored in a brand new location. If we look at the two examples below, we have a normal standard container of main server.pretendcode.com, where our information is stored in the standard container for our directory services. Our directory ACLs are now stored in a separate container outside of the standard container in CN equals config.

We use pretty much the same tools to bring the information back over to our new server instances we did to export them from our previous instance. So we use Workgroup Manager and Server Admin from the GUI and we use DS Import and Server Admin from the command line to bring all that information back in.

Schoun's mentioned in some of the previous slides the migration tools that Apple has available. And here's the path, system library server setup migration extras. And there are migration tools available to migrate almost all of your services and settings from your previous instance of OS X Server over to your new instance of OS X Server. And here are just a few, the Web Configuration Migrator, the IPFW Configuration Migrator and the Jabber Migrator.

When we look at migrating services from 10.4 over to 10.5, there are a lot of services that we can move. And the next couple of slides give you the paths and information of each one of these locations for these services. I'm going to go through these pretty quickly, but I want to point out down at the bottom that all this information is in the upgrading and migrating manual that Schoun's going to show you the URL for at the end of the slides.

So, I know you're not going to have time to write all these down, but when we look at web, Tomcat, JBoss, WebObjects, QuickTime Streaming, QuickTime Streaming Server Publisher, we can migrate all that information as well as Mail, NetBoot, iChat, MySQL, Print, FTP and AFP. Moving on, SMB, NAT, DHCP, DNS, IP Firewall and VPN. You can get the paths and locations for all of this information in the upgrading and migrating manual.

I'm going to turn it over to Andre for a demo. Thank you very much. And this is the intended to be slightly longer demo showing the migration path. So we have a fresh Leopard server here. While it's not totally fresh, I went ahead and updated it to 10.5.3. You should do that too, by the way, before you finish with your migration procedure. So let's take a look at what we have in Server Admin.

And it should be first launch configuration. So we don't even have any services configured yet, in the sense that there will be nothing listed on the left to actually configure. So instead of clicking check boxes like a billion times, I'm just going to do a little shortcut here.

So server admin, the command line tool, you can say server admin settings and then a service name and it'll print out settings. You can take that actual chunk that it prints out and shove it right back in as a way of reloading those settings. So what I've done just there is turned on service configurations, which if I reload the UI by hitting command R. So now we have one service. Nothing's running.

So let's get started with restoring some of our service configurations. So if we want to be an open directory master, then I will select open directory, click change, go through the old setup assistant or service configuration assistant, type in my password there. Wait a minute. What's wrong? Anyone notice? I'll click continue. Looks like it's going to work, right? It's spinning gear. That's got to be good. Dun dun dun, anticipation builds.

And hey, it worked, right? So I click on Overview. What's wrong here? My Kerberos is stopped. Anybody know why? I was hosting my own DNS. Guess what I didn't do first? Restore my DNS settings. So I'm going to demote back down to standalone. which fortunately is a pretty quick process.

So if you follow the upgrade and migration document, it will walk you through the appropriate order for doing everything. And I would stress that because the order is quite important, especially in the case of Open Directory Master where you need to have DNS. So if you were to look through that guide, you would basically see information about how to backup and restore your DNS config files. I'm gonna take a slight shortcut here in the sense that I've got all the commands that I need sort of already ready to go here.

So I'm just gonna drop those in. And basically it's just restoring my DNS config files from backup. And I should now be able to configure my system preferences to use myself as a DNS server. 'Cause remember, this is a clean install. I can't just configure and start the DNS server. I have to use my own DNS service.

So instead of using system preferences, I'm going to use network setup, which is a nice command line tool along with system setup that you can use to automate. Or do at least command line scripting for a lot of these things. That would usually require the GUI. So if I then refresh, excuse me, I guess I have to start the service too. So I start the service and my zone's at. Hmm, let me try quitting and relaunching this guy.

Because you do need DNS to be an open directory master. Uh-oh. It's a dreaded indeterminate state bullet. Ah, there we go. Hey. So it's noticed that I have old DNS configuration. It wants to upgrade that for me. I click upgrade. and now there's my zones. Whew, that was close. All right, so now I can be an Open Directory master.

So once again, go through here, Open Directory master. Going to use the same admin name and password that I used before. And there's the screen that I was looking for before where it's prompting me for my Kerberos Realm and LDAP search base. You typically want to accept these defaults, but the point here is that it should be able to suggest default values that are based on your DNS domain name. If it can't do that, that typically means your DNS has a problem. So I'm going to promote myself to a master. And we are running out of time, so I'm just going to show you some of the key highlights from the rest of this demo.

The big thing for most would be to restore your users, passwords, group accounts, that sort of stuff. And so the easiest way to do that is to simply use an Open Directory archive restore. So when I was in 10.4.11, I used the archive capabilities to export an encrypted disk image And now I'm going to import that image. I'm going to navigate.

There's my image. Actually, there's my directory. Oh, that's the wrong-- sorry. Restore from. Hey, at least it saved my directory. So I will restore. And before I do that, let me just launch Workgroup Manager just to show you that I do, in fact, have an empty container. And that's the wrong admin name, but .

All right, so I see that I'm in LDATv3. I see that I have no users, no groups, no computer lists. So when I click OK-- Get the little barber pole. And boy, that was fast. Did it even work? It's almost disconcertingly fast. But if I go back into Workgroup Manager and refresh, Refresh. I do see that I have stuff. Stuff is good. And I can, for example, test my Kerberos credentials by using a KNIT.

and I can use K list to see that my Kerberos does in fact still work. And so at this point basically you would continue to restore your service settings following the admin guide. So each service is a little different. Sometimes you can just restore the property list that you backed up from Tiger. Sometimes you actually have to go and move config files or directories of config files or directories of database files like in the case of mail. Sometimes you actually have to go and run one of the system migrator scripts manually.

These are things that would normally happen for you in an in-place upgrade. And all that's in the upgrading and migrating documents. So you might have to like copy some files and then, you know, path to a Ruby script or something that would actually do the processing and conversion of the old format to the new format.

And then you would be able to use the admin tools and continue on with the service. And because we're almost out of time, I'm going to go ahead and stop there. There was a bit more, but I think you get the idea. So I'll turn it back over to whoever wants to take the mic. Thanks, Andre. You're welcome.

One thing we haven't talked about thus far is how to migrate your open directory replicas. And the question really becomes is whether or not we need to migrate those replicas or just start them over from scratch. Because a replica truly is a copy of your open directory master. So the ability to migrate your open directory master gives you the ability to really start from scratch with your open directory replicas. Create a brand new instance of OS 10 server and simply repromote those new servers to be replicas of your brand new migrated open directory master.

When it comes to home directories, we mentioned this before, when you're backing up and migrating all of your user data, simply zip all of that information up so it preserves the file system ACLs, preserves all the information that you need to migrate from your previous server instance over to your new server instance, copy that data over, unzip it, and you're ready to go.

One caveat with migration is if you need to change the IP address of your server from what it previously was to what it will be now in the future. To do that we use the change IP command. And change IP runs a set of numerous scripts to be able to change over all the information that includes your previous IP address and your previous host name to your new IP address and new host name.

So when you're dealing with change IP, first make sure that your new IP and host name are correct. If you're changing your IP address, make sure that your new IP address has DNS resolution, forward and reverse resolution already set up and working for it. Run the change IP command. We have two examples of what the change IP command can do down at the bottom. Change your network settings to your new IP address.

So running the change IP command does not update your network system prefs. You have to go into system prefs, go into network, change to your new IP address, change to your new computer name in the sharing system pref, typically reboot the machine and you'll be ready to go with your new IP address and new host name.

And that's it for migrating. I'm going to turn back over to Schoun and finish this up. Thanks, Jeff. So where are we? We need to make sure we have our customized configuration files. You handled every service. You tested it. You may have gained some gooey command line experience when you've done this.

What do you need to do? You attended the session. Check it off your list. Back it up at least once. Test in a private environment. Make sure that it works inside a private environment. There's the URL. You can find it at manualsinfo.apple.com. You can go on out and look for that. It's with everything else.

And upgrading and migrating, it's always been a process that was not totally, totally error free. But Apple has done an excellent job of doing all the background and the hard work for you. Planning, testing is the best defense against having a production server that just might go down.