And welcome to session 616. So what are we going to talk about today? Well, we do this session every year, and we typically talk about three or four different technology areas in depth. We talk about how they work, how developers can take advantage of them, and so on. And every year, the server team has a real difficult time picking those topics. It's not because we don't have anything to talk about, but because we have so many different technology areas to pick from.

As many of you know, we have tens of different services and components in Mac OS X Server. And for each release, for each feature, each service, we typically have three or five new features, so it's pretty challenging. But luckily, some of these major areas, such as Open Directory, Xgrid, ACL, Kerberos, we have our own dedicated session, so that makes it a little bit easier. And anyway, this year, we picked these four areas to talk about. And we talked about all these areas in yesterday's Mac OS X Server update session. But today, we're going to double click on them and then talk about them more in details.

So we're going to start off by talking about the managed network browsing. It's a brand new Tiger client server feature. It's going to make it much easier for people to browse, especially in a large organization.

Failover and High Availability. We had this feature since Jaguar Server, but we made some significant improvements in this release in Tiger Server, so we're going to be talking about this. And also we're going to talk about how developers can take advantage of this and extend this capability. And last but not least, we're going to talk about the certificate management feature. It's again a brand new feature in Tiger Server. So let's jump right into managed network browsing.

So we introduced network browsing in Panther. It's a feature where a user can browse for file services and connect to them directly in the Finder window. Managed network browsing is built on top of that functionality. It's an incremental enhancement to make it even easier to use. But before we talk about that, let's take a look at how it works behind the scenes for Panther.

To get this feature to work, we actually have three different processes involved. At the top level, of course, we have the finder. And to finder, all of these network zones and file servers actually shows up as folders and files. And that's done by AutoManor, which in turn talks to NSL, or the network service location API built into the system to find out those list of servers and zones.

NSL talked to Directory Services. So as many of you know, the Directory Services have different plugins for accessing different directory systems, such as LDAP and Active Directory. In addition, it has a number of service discovery plugins, one for each protocol, and then the other ones that are actually responsible for finding those servers on the network and reporting back up. So that's how it works today. Very simple.

This feature works fairly well for consumers and small work groups, but doesn't work too well in large organizations, especially with large networks. It looks something like this. There's just too much information. You have too many network zones. You have too many servers in each of them. And a lot of these zones and servers come and go, so it's somewhat unpredictable and unstable. And also, in most cases, these zones are organized by physical network infrastructure, so usually by buildings rather than by more logical grouping such as by corporate org chart or by projects. So these are the problems that we wanted to solve.

And also, in most cases, these zones are organized by physical network infrastructure, so usually by buildings rather than by more logical grouping such as by corporate org chart or by projects. So these are the problems that we wanted to solve. So instead of looking at something like this, where there's a bunch of raw network data, you can create something like this that's a little bit more organized for your organization.

So let's look at some of the sub-features. You can create arbitrary neighborhoods. The neighborhoods are those folders that you see here. And you can list them so it doesn't have to be a flat list. So for example, maybe inside the engineering folder, you may have server engineering, finder engineering, application engineering, and so on.

You can also mix and match dynamic and static contents, meaning for each folder, you can say, I want these servers that I'm going to specify to show up. Or you can say, for this folder, I want to show all the servers that are discovered at runtime on the client machine in these network zones. And you can mix and match them.

You can also define multiple views so you don't have to have a single view for everybody. You can create five or ten different views and then show it to different set of people. And lastly, you can replace or append to the existing view that user would see today in Panther.

So the screenshot here is the replaced version of it. If you'd like, instead, you can do something like this. So what you've defined shows up on the top, and then below it, you see the raw network zones. So let's do a quick demo so you can see what I'm talking about.

Okay, so we have a Panser client here, and if you click on the network, you see a bunch of zones. What we did here was, whoops, we're running a special tool that does a fake registration of a bunch of different zones and servers so we can really simulate the large corporation or institution.

So if you click on XAMPP, you see different servers and so on. And what we're going to do is we're going to create a custom view and replace this. And to do that, we're going to launch Workgroup Manager. This is where we implemented the feature. And to do that, we're going to launch Workgroup Manager. This is where we implemented the feature. And let's add a couple neighborhoods. So maybe one called Sales.

and the other one is called Marketing. And another one is called Server Group. And now we're going to start adding some servers into this neighborhood. And there are three different ways that you can add static servers to each of these neighborhoods. One way is if you haven't already have a computer record for that particular server or servers, you can open up the drawer and you can just drag them in.

So that's one way. Another way is you can just go ahead and drag directly from finder. So if you look at the QA folder, see our server. and So that's another way. And now let's actually create a nested neighborhood. Let's call this team members to point to all the servers that belongs to the server engineers.

And the third way to create them is by hand, manually. So let's say if I have an employee named Bob who is working from Hawaii and we want to add a pointer to his personal file sharing machine. You can just name it, Surfing Bob, and then just type in the URL.

Tag it, add it in here, and then actually the computer record automatically gets created for that server for future. And everything we've added here so far are the static servers. These information is all stored in directory services. But you can also add some dynamic contents. To do that, you just select this one. And I happen to know that all the server guys are sitting on the fourth floor of the Anza 3 building in the north and south zone. So what we're going to do is go here and then select the Anza 3 fourths, and north and south, and add.

So what we're telling managed network browsing is when this neighborhood is clicked in the client machine, showSurfingBox machine, but as well as everything else that was discovered runtime in these two different network zones. So this looks good. I'm going to go to settings and then set it to replace and save. Let's go back to Finder, go to the network. Now you see the custom view that we just created.

Okay, so now if you look at here, you see everything that we've added, and you can collect them. Or you can go in here, you see the Surfing Box machine here. But you see all other servers that are discovered in those network zones. So we actually mix and match the dynamic and static contents.

And if you'd like, you can also go back here and then set it to add and save. There you go. So now you see both FAT-UBD find on top and then FATs on the network at the bottom. And we haven't made changes to the finder yet, so we couldn't actually distinguish between these custom views and then FATs on a network. So we did a little hack, and then right now we put a little dash in the front, so it actually shows up on the top. But by the time we ship, it should be a little bit better looking. All right, so that was a demo. Thanks.

Right, so now let's look at how this works behind the scene. What we did was in Tiger, we made the NSL a little bit smarter. So it now knows how to talk to directory services and then get the view configuration information and behave differently based on that information. And of course, we also made changes to the Workgroup Manager, so you can actually create and edit those configuration information and store them in directory services.

And by the way, this technology, this feature works with any directory system, so it doesn't have to be LDAP. It could be Active Directory with some schema changes, or it could even be local NetInfo if you want to test it. And that's actually how I just did a demo to just keep it simple. So we had all these three things running on the same machine.

Now take a look at what gets actually stored in the directory when we do all this configuration editing. There are three different record types that's involved that we're interested in. The network view, neighborhood, and computer record types. So at the top we have network view record, and it basically just contains information such as should I append or replace, and then pointers to the top-level neighborhoods that you've created. Something like this. And the network neighborhood records contains basically pointers to all its contents.

So it points to other neighborhood record if it's nested, or to different computer records if you have a bunch of different servers specified, or references to network zones if you have dynamic contents. So what we just demoed here would look something like this inside the directory if you want to take a look at that system.

And again, you can create multiple views. It doesn't have to be just one view. So you can create five or 10 of these things or 50 of those things. And that gets us to the next topic, and that is how does NSL pick a view when they have multiple different view records in the system.

It basically follows a set of rules. So what it does is, it first looks at the directory and sees if there's a computer record for the client machine that it's running on. Not the server computer record, but the client computer record. And if it finds one, it checks to see if there is a preferred view record specified in that. And if there is one, use it. If not, it looks at the local preference file and see if there is a preferred view that it should be using.

If not, it goes back to the directory and it looks for a view whose record name matches the MAC address of the machine this NSO is running on. If it doesn't find one, it looks for IP address match. If it doesn't find one, look for the subnet match. And if all the above fails, it just goes ahead and uses the default view, which we've actually used. And if there's no default view, or if the default view is turned off, then it just goes back to the default answer behavior.

So, let's summarize. With this feature, you have complete control over what your users would see in Finder when they click on that network icon. You can easily create, edit, and then preview them in Workgroup Manager, the tool you already know. You can mix and match both static and dynamic contents. You can replace/append, so it gives you a bit more flexibility there. And you also can create different views for different set of users.

And all the configurations stored in the directory, which means when you create that, it automatically gets propagated to all the replicas when the directory system replicates. And also you can use directory services command line tools for editing them from remote machine, from SSH, even on Linux machines. And all the configurations stored in the directory, which means when you create that, it automatically gets propagated to all the replicas when the directory system replicates.

And also you can use directory services command line tools for editing them from remote machine, from SSH, even on Linux machines. So that's actually all I had for the management work browsing. And now I'd like to introduce Rusty Tucker, who's going to tell us about file service and locking. Thank you.

Good morning. Locking in file services is an important part of any file system or file services, especially so in Mac OS X Server where we have such a variety of different file services serving a variety of different clients. So today we're going to start by taking an overview and review how locking works today for Windows over SMB, for Carbon clients over AFP, and Unix clients over NFS. Then we'll take a look at how we're enhancing this file locking interoperability on our platform for Tiger. Finally, then we'll wrap up with some notes for cross-platform developers can use to develop collaborative applications using this technology.

So we'll start with file locking in AFP and SMB. Fortunately, the two protocols provide very, very similar semantics in file locking. Both are using opens with deny modes. So they can open files read-only with shared access, read-write with shared access. That would be a read-write with not denying other readers or writers. And the most common case of read-write with exclusive access, which is what most applications do.

After opening a file read/write with shared access, collaborative applications will then ensure concurrency and serialize access to the files using range locks for the ranges that they want to read or write. In AFB and SMB, these locks are mandatory locks so that it's just a, other users are prevented from opening a file so they don't have to test locks and so on.

In Unix file locking, in contrast, it's an opt-in policy, so the locks are advisory. You need to test for the presence of the lock before opening a file. And you can use the Flock API to do so. You can take out an exclusive or shared lock on the full file. If you want to do range locking, you would use the F control APIs. It's an advisory lock that you would test for both exclusive or shared access.

I'm sorry. Oh. I'm on the wrong-- back to slides. Thank you. We don't have a demo for locking.

As I was saying, both advisory and mandatory schemes work very well. But in both cases, the applications have to agree on a scheme that they're going to use to ensure collaborative access to the files. In the Unix, using Unix locking, applications must choose whether they're going to use the F-lock to guarantee for concurrency or F-control. They can't use both. They're basically exclusive one or the other.

Which leads us to the way that Samba and AFP map the open and deny and locks onto the Unix semantics. Standard Samba uses the F control to map its range locks to the F control. So in this case, it's not mapping any lock when it takes an open or deny. AFP, on the other hand, maps its open denies to the F lock.

And you can see here, this is basically the standard architecture. and David For that. So in Tiger we want to enhance this and really unify the way that AFP and SMB provide locking to their clients. Doing this will be able to support concurrent access, not just ensure consistency, but be able to have concurrent access from the two platforms on a given file to provide shared editing for collaborative applications. Working with NFS, because we don't have a perfect mapping between the semantics of the AFP and SMB locking with the Unix file locking, will favor data integrity over concurrent access with NFS.

And then finally, because we, and underlying the servers, we need to take out the Unix locks, we'll have to use strict locking to emulate the mandatory nature of the locks as provided to the clients on the Windows and Mac platforms. All this will be delegated to a new system framework for range locking. Back to the architectural diagram, we'll have AFP and Samba talking to POSIX and Carbon layers. Between the two of them will be a range locking framework to negotiate access to files with the proper semantics.

So double click on some details on how this is actually implemented in the framework. As with AFP, we're going to map the open deny calls to an F-lock. And you can see, according to this chart, we have basically three different options to do from the F-lock. We can take no lock at all.

We can take an exclusive lock or a shared lock. And so this is not, doesn't provide the full match to the semantics provided by the open deny calls. So where the locking will give us consistency with NFS, we'll use internally map the consistency between the open deny calls within the framework.

So byte range locking will be fully enforced by the framework. We won't be taking an F control because it won't be possible. We already have the F lock on the file. And the reason for doing this is that the byte range locks are really more transitory in nature, whereas the F lock persists for the entire time that the file is open, giving us a better story around consistency with other applications and NFS. The locked database is memory mapped for better performance. And we'll emulate the mandatory nature of the locks by testing within the framework and AFP and SMB for the presence of both the range locks and denies before we open files or perform read and write operations.

So a few notes for developers that want to take advantage of this in collaborative applications. On the Mac platform, you'll want to use the Carbon APIs to access this capability. And first test for the capability on the file system by testing for the open deny bit. Mac OS X provides support for many different file systems. Each of them have a variety of capabilities, and not all support open deny or range locking.

Finally, when you have found that that capability exists, use the PPH opened and I sync call. And in this case, specify IO read/write with shared access. PPA OpenDenySync also has variations that allow for async operations and also operations on the resource fork. and finally use PB lock range sync to gain exclusive access to a range of bytes that you want to either read or write.

From the Windows platform, you want to use the Create File API. And here, the default is that you'll gain exclusive access. So you want to define, provide, specify, I should say, that you want read/write shared access. And then finally use the lock file API or lock file extended to gain exclusive access to the range of bytes that you want to read or write from your application.

Locking is just one of the many areas that application developers can take advantage of on the Mac OS X platform. There's a session later on today, Best Practices for Application Developers, that session 108 today at 5 o'clock. You can gain more information around performance and other APIs that are available to file system developers. And there's a number of online resources that you can use to your advantage as well. And with that, I'd like to introduce Chris Jalbert, who will provide some information on failover and high availability.

OK, when we were working on the slides for this stuff, something that failover and high availability has actually been in the server product for quite some time. But it seems like not a lot of people know about it. Our sales engineers when they go out, they try to talk about some of the extra features that Mac OS X has, Mac OS X server, and they'll mention this.

And most of the customers are like, really? So I think the first thing to talk about is what is failover? First of all, it's part of a high availability solution. Apple has a lot of different components to tell a story now about high availability, and some that are hardware and some that are software.

Failover is a software piece. And it provides the transparency of availability for short-lived protocols, primarily Datagram, which are best known as UDP-based protocols, and certain short-lived TCP protocols, such as HTTP, where you connect to the web service and you download a document and then continue making connections. And the basic premise behind it is that when the primary node fails, the backup will take over that primary IP's publicly accessible IP address and then offer the same services that were on the primary. And it's typically backed by a RAID or a SAN file system. for extra data integrity on the file system level.

So here's a typical hardware setup. On the top, you'll see that I've put a DNS server, and the idea here is just the notion that you'll have the two servers, your active server and your backup server, but there needs to be something else out there that has some information that the clients are going to reference. And the easiest thing to point out is a DNS server. That's the thing that will resolve the IP addresses for the primary and the secondary.

And again, we've demonstrated the backup with the RAID available to both machines. One thing that's been omitted from this picture for simplicity is the fiber channel, which is the stuff in blue, often will have a special fiber channel switch wired up in there so that both servers can access both sides of the RAID. It just has to do with a hardware configuration.

Another thing to point out is that the private network, which is on the right side of the diagram, can either be Ethernet or FireWire. With the IP over FireWire, you can actually use that as your private network, and it's a cheaper option by just kind of daisy-chaining FireWire between your servers without having to have an extra network switch or hub, and adds additional reliability because you don't need that extra hub there.

So I think the first thing to point out is that failover and high availability have been around since Jaguar. There was a failover product that we shipped with that. However, the philosophy that we had when designing that was that no two sites are alike. Any time that we tried to figure out, well, gee, what would be a useful solution for customers? What would be a typical scenario? We couldn't come up with any.

And when we asked the sales engineers, they were telling us, oh, well, this customer needs QuickTime, and this customer needs websites, and this customer needs home directories. So what we thought the easiest thing to do was, well, how about we just kind of provide the infrastructure and not the complete solution because everybody's going to have to customize it.

Everybody's site's going to be a little bit different. And all we did for the infrastructure then was just to manage the state of the peers, the primary and the secondary, and then do the failover of the IP address and email notifications and then ran executables, which is the customized part of the site that the administrators would have to do themselves. And we defined it and documented it so that they could do so in the way that would meet their own individual requirements.

But there wasn't a lot of deployment from our customers because it was too difficult to set up. And in particular, the additional network interface in the previous releases had to be very carefully set up. And most of the times when we would go to look at what had happened in a site that wasn't working, it was related to the network setup.

And further, not having a user interface really seemed to scare a lot of people away because it required fairly significant network knowledge about how the site was going to work. And that they'd have to use VI to edit the etc host config, which seems to scare a lot of folks.

That was primarily by leveraging the IPv6 stuff that's now built in. And with that, the daemon can actually auto-configure as much as possible on the system. So the daemon comes up, tries to figure out where it is in the world, and then auto-configures what it can auto-configure for the private network and be able to communicate, sort of auto-discovers what's going on, and then will start the heartbeat between the two nodes.

The one thing that people did seem to like were the external scripts that allowed customization. So we're definitely keeping that in this release, and we're improving the documentation and again providing some more samples for that. And the real reason for this change is to build the foundation for future directions that we can go once we have these two daemons that are sitting there to talk to each other about the reliability of hardware. And the step that we took for that was to expand and secure the communication model.

So the daemons are actually now talking over IPsec so that the authenticated IPsec, for those who actually know much about IPsec, it was a learning experience for me, so that when one node talks to the other, they know that, yeah, it's okay, that's coming from somebody that I can trust. And that allows additional communication. Like one node to actually tell the other. And then another node to shut down. Generally, you don't want to do that unless you can trust where it's coming from. And so those future directions require this kind of secure communication model.

We're on to the next. There we go. So the other thing to talk about is what's not in Tiger. There's something known as instant or live failover. This is a very, very difficult thing to accomplish, which means that as soon as the primary node is offline, the secondary takes over. As if nothing happened, it has a complete state of information. And it's a very sophisticated problem. And again, we're building the foundation for the future. This is our first step. And this is not something that we can accomplish in the Tiger time frame. Load balancing.

Load balancing is often solved with other devices' existing hardware. There's some open source software to actually be dealing with that. Again, we're building a foundation. So load balancing is not in Tiger. The other thing that we-- we added a restriction that the file services can only be running on one node at a time, on the primary and not on the secondary. Other services. They can be running on the secondary.

But the file services, the locking stuff that they added, and the file system itself underneath, we were worried that there might be some issues about concurrent access and stuff like that. So to be safe, we wanted to make sure that data integrity was primary, as was mentioned earlier. So for this release, the file services can only run on the primary. When it fails over, it'll switch to the secondary and then be handed back on the manual failback. Again, we're building a foundation, and we hope to improve on that in the future.

The other thing is there are no multi-node access to the RAID. And again, this is kind of a-- sort of the reason or the side effect for that file services only on one node. If you want multi-node access to the RAID, there's a product called XAN, and there's a lot of sessions about it here. You're welcome to go through those sessions and get more information.

So here's the user interface. This is the interface that we propose. You'll notice it's actually fairly simple. Up at the top is what I've been calling the public node, and we're still trying to come up with a better name for that. That's basically just the DNS name for the primary node. That's where everything is keyed off.

So you enter that in, and that's what the secondary machine will babysit. We've added additional email addresses in the previous release. We could only have one. So now you can have as many as you want. And then the all-important failover now and failback, which will change to failback now, to do the manual failback.

And the status window inside Server Admin will show you the status of where you are with some explanatory text to help guide you through it. Also, we tried to provide some explanatory text to help you set it up. Again, it's somewhat of a complicated scenario, but we're trying to simplify it as much as possible for our customers.

So in Tiger, we currently have a single daemon process. In previous releases, we actually had two. We had one that was sort of broadcasting, another one that was listening. So we've combined them into one to simplify the communication model and help with the enrichment of the communication model. It runs over authenticated IPsec for our security, and it uses standard plists for communication. So it's a command sequence with arguments and passes data and something that looks like notifications and commands and stuff like that.

And it's all based on plist. And then for the private network, we use IPv6, which is automatically set up. So that means that the customers don't have to set up a whole other private network and give 10 addresses or anything to their FireWire address or their private ethernet address. And then the daemon auto-configures from the DNS name, as I mentioned on the previous slide. We've enhanced some. We've added the helper scripts that were there previously.

They were notify failover and process failover. And we've added some-- the site-specific scripts, sorry, the customized stuff that customers would use, that's in the same location. So if someone actually managed to set up IP failover in the previous releases and got doing exactly the way that they wanted to do it, when they upgrade to Tiger, they won't lose that customization. And it will still function for them as it did previous, with the exception of the manual failback.

So how do you enable your service for failover? Well, first of all, when possible, don't be tied to specific IP addresses. Because much like in a mobile environment, where you've got your laptop that's going between ethernet and airport and different airport zones, when you're dealing with failover, IP addresses will come and go.

So if you're tied to a specific IP address, and that IP address goes out from under you, then your service generally is going to be a little confused. So one of the ways to get around that is to use the system configuration framework and become network aware. There's actually another session-- I think it's tomorrow-- on how to write your app to be network aware.

And that applies to the server product, which is generally a much more static environment than a desktop, particularly a laptop. But it's still important for dealing with failover. The other thing is that you should be able to gracefully handle the mounting or unmounting of file systems. In a failover case where we're dealing with file services, generally that means the home directories are going to come up on the secondary machine.

And in the failback case, those home directories are going to go away. So that means that if you're depending on stuff in the file system, they may come and go on you. And when possible, don't keep open references to those files on the file system, because it could go away.

And the other thing is you might want to consider if you're writing a client, the client side of this is to consider automatic reconnect. So when that service is lost temporarily, you can automatically reconnect if you've got credentials, or if you're using the single sign-on technology, just to be able to reconnect to the server once the secondary takes over.

And the other thing you might want to consider for future directions is an automatic redirection of clients. So if there is a bank of servers, like in the case of the primary and the secondary, or perhaps more if the customers have set that up that way. When you connect to the first one, the service could respond to the client, "I'm sorry, I'm really busy right now. Please try this other site instead." So that's something else to consider. That is just an enhancement on top of the failover that we think would be beneficial to customers.

So for services that can't be modified, so for things that are open source, things like Apache or open source FTP that isn't really designed to have a lot of customization just for Mac OS X, you can use these customized scripts that I talked about before. And there's a well-defined sequence of what happens when an IP address is to be acquired or released. And it will process the directory in library IP failover.

Each directory will have as its name the IP address that will be acquired or released. So first it runs a test script to determine whether or not it should acquire or release the address. And if it fails, if it returns a non-zero status, then it will abort the acquisition. And if it fails, if it returns a non-zero status, then it will abort the acquisition or the release.

This is much less important in Tiger. In previous releases, this was the way to prevent automatic failover or automatic failback. If you just wanted to be able to be a notification mechanism, you could have the test script do this. But with this feature added and a little more control for the users, this script in particular becomes much less useful.

However, the other scripts, which are the pre-acquisition and pre-release scripts, in addition to the test script, are also more useful. But in addition to the peers, which are the post-acquisition and post-release scripts, are where all the meat happens in terms of dealing with those services that aren't failover ready. So in the case of an acquisition, we'll run the test script.

We'll run all of the pre-acquisition scripts, so all the scripts that begin with this pre-ACQ. And then it will actually acquire the address using ifconfig and then run the post-acquisition scripts. So in the release case, it's very similar, but it's clearly using the release version of the scripts.

So this is a case where, let's say, the primary is running the web service, and on failover, you want the web service to be running. Well, you wouldn't do anything in the pre-acquisition, but in the post-acquisition, you would start up your web service. And in the release, you want to shut it down before you get rid of the IP address, so you would shut down Apache in the pre-release script. So that's something that will be... One of the samples, just to demonstrate. So in previous releases, we didn't pass any arguments to the script.

We figured there was enough information that the scripts or executables could figure it out. However, to simplify some of the logic so that all of the scripts and executables aren't doing the same thing, we've changed the invocation a little bit to pass in whether or not we're acquiring or releasing and exactly which IP address that we're operating on.

So to summarize about failover, we currently offer a bunch of components for high availability. There are some that are software, like Watchdog and LaunchD. LaunchD is actually-- we'll have another session later in the week. Failover, which I've talked about. There's also automatic hardware reboot, which if the machine freezes, I think, is actually how the user interface specifies it. It'll reboot after some period of time, which is typically five minutes. And we also have some hardware solutions, like XAN and XSERV RAID.

One of the things about failover in Tiger, compared to the previous versions, it's going to be a lot easier. So we hope that a lot of customers will be using it. But that also means that your services could be affected. So where possible, design your services with failover in mind.

And generally, that doesn't require a lot. First, it means to be network agnostic, to be aware of changes in the network and the file system, and to be fault tolerant, which I know is a really broad word. But it just generally means that when you go to open a file, it may fail. And you just need to be able to handle that kind of stuff gracefully.

And for those services that can't be modified, you can leverage the failover scripts and provide sample scripts to your customers to ensure that your services stay up or come back up on the secondary when a failover does, in fact, happen. So the second topic that I'll be talking about today is certificate management.

Sorry, I'm having a little problem with the clicker. So certificate management, there was some stuff in Panther. There were a lot of different services that could actually make use of certificates. Most of them were based on open source projects. Open Directory, although that was our creation, makes use of some certificates, primarily in the LDAP for LDAP over SSL. Mail, Postfix, and IMAP can actually use SSL certificates there as well. VPN uses certificates for its L2TP protocol. And web, of course, the original SSL.

However, the configuration was very inconsistent across them and required a lot of manual setup. You needed to generate the keys by hand and needed to enter in the appropriate information in the user interface. And the services often couldn't share certificates. You had to create a certificate for each service instead of having sort of one global for the machine.

So for Tiger, we've changed that. And we've centralized certificate management in the Certificates tab in the server settings. So there'll be some UI screenshots, and I'll show you what I mean by that. But the idea is that all the certificates you create, you do so in a central location.

And then it'll integrate in with a certificate authority website. So we actually have the means to take a certificate signing request. And you can either paste it in their website or email it to a certificate authority. And we leverage the new certificate assistant that's in Tiger so that you can actually email those certificates to the local CA for signing. And inside each service that could actually leverage the certificates, we present a list of those available certificates rather than the previous UI. So here's the new Certificates tab.

You'll notice that we have a list here. We show when it was created and the date of expiration. And these are currently only self-signed, because after all, they're examples. But this UI is very similar to most other table views, where you can add, edit, and delete stuff. You'll also notice that on the top level, it's actually a global setting for the server. So the General tab has things like the server name and the serial number, and the certificates are just a peer of that.

So this is how you would actually create a certificate. Standard stuff for setting stuff. And once you've actually create the self-signed certificate, we have a couple of buttons to request a signed certificate from a CA. And then once you get that result back, to paste it in. And these are what the dialogues look like. It's fairly simple. It can actually email it directly from the admin app.

So you don't even have to cut and paste anything. It'll just generate the email and send it off. Or you can drag that little icon over there. It'll actually drag a clipping with the certificate. And then once you get the result back, you just paste it in, click OK, and you have a bona fide signed certificate.

So that centralized list will really simplify the user experience. And the following services-- I'm sorry. I didn't mean to say it like that. We do have a bunch of services that actually use the new API and the user interface. Again, it's the same ones that you've seen from previous releases. But we're leveraging it with this new interface.

So just to show you an example, this is what configuring SSL for Open Directory was like in previous releases. So you could turn it on, but then you had to specify each of the different files and all that stuff well in Tiger. I think the battery is dying on the clicker here. In Tiger, it looks like this. It's just a pop-up. You pick one of them, and we do all of the stuff behind the scenes necessary to activate that certificate for LDAP over SSL.

Thank you, I'll pass the word along. Likewise, here's the old web UI. Same kind of thing, all these multi lines. And clearly, when you ask the customer, hey, make sure you spell that right, Well, that's the new UI. So greatly simplified. They just pick one out of the list. If it needs to be exported because the web server only understands OpenSSL, again, we do that in the background. So it's automatically activated for that particular service.

So what can you do to take advantage of certificate management in Tiger? Well, there's two command line tools. There's one that was available in Panther, Server Admin. And we've added a new one, Cert Admin, to simplify your use of certificates. So if you wanted to see all of the certificates on the system and get it as a plist because you're using Foundation or Core Foundation, and you want to be able to parse it and get all the parameters, you can execute this command. Go ahead, I'll let you all copy it down.

And that will actually generate a large plist with all of the certificates in it and all of the different settings associated with it. Most of the stuff that came from that settings panel, the creation panel, about the site name and the CSR and all that stuff. So this is a very rich output. However, if you wanted to put this in your UI, well, that's a lot of parsing.

So we've provided a more simplified tool, and that's the cert admin tool. And if you just say cert admin list, it just spits out the name so you can populate that pop-up just like we do. And if you need to export the certificate to OpenSSL because the service you're using only does OpenSSL instead of using Apple Security Framework, then we have a fairly simple command to export it, and you just give it the certificate.

And that's the site name. So we've tried to provide tools to really simplify your ability to leverage this, what we hope will be a very cool new feature for users to increase the security of their product. And hopefully these tools will allow you to leverage that as well.

So, why do we care about this? Well, because we all know that certificates are an important tool for securing data. SSL is a key thing and more protocols today have SSL extensions and maybe your protocol wants to do that as well. With Tiger Server, we've really simplified and centralized the certificate management and provided tools for you to leverage that and to be able to integrate them into your own service.

And that's it for certificate management. I'm sorry. I really think the batteries are dying here. It's clicking out on me. So hopefully you'll be able to leverage certificate management in your products as well. So for more information on all the things that we've talked about today, there's a lot of different stuff available on the DVDs. There's some documentation and release notes. And as additional drafts come available, those will show up through the developer websites.

And we have man pages on the stuff on the DVD, and we're adding more every day. So there's a lot of different resources on the web and a lot of different sessions as well to be able to get some additional information about some of the things we talked about, like network awareness and the best practices for file systems and things like that.