Ladies and gentlemen, please welcome Manager Core Server Development, Kazu Yanagiharra. Good afternoon, and thank you for attending session 802, Mac OS X Server In-Dev. Here is what we're going to cover today. We're going to start off by talking about remote server administration and the monitoring capabilities of Jaguar server, and also what you can do to make sure your software is fully remote capable as well. After that, we're going to talk about Apple's directory services architecture, open directory. Since there's a separate session on Thursday, we're going to only talk briefly about this here.

Then we're going to talk about high availability services in the Java server, followed by some updates in the file services area. And lastly, we're going to talk about web-related features that's built into the Java server. And of course, there's a Q&A session at the end. And here's what we hope you're going to learn today in this session.

Okay, remote server administration and monitoring. We've been hearing from many and many of our customers that they want to run their servers headless, remotely, without the monitor attached. In fact, we've been hearing this from Apple's internal ISN organization, and it really helps them save space, helps them save money, and in many cases, they just want to throw their servers away into the unsecured closet and be able to manage those servers remotely from anywhere, including office, home, or even on the road. And of course, they want to monitor multiple servers simultaneously without being at the server as well.

So we've listened to our customers and are making some changes in Jaguar Server to meet that requirement. First, the OS itself now boot without having the monitor attached, which is not the case with the current version of Mac OS X Server. Second, we're upgrading all of our management software so it's all remote-friendly. Most of them already were, but some weren't.

For example, in print server management software, today you have to create print queues manually on the local machine. With Jaguar Server, you can do so remotely from the network. or the other utilities such as directory services tools will also be remote friendly. And lastly, with Jaguar Server, admins will be able to set system preferences or perform software update over the network remotely as well.

So with these changes and new capabilities in Jaguar's server, some of your software may have to be changed so that it runs well on all the configurations our customers will have. For example, if the server doesn't have a monitor and keyboard attached, it means likely there is no system login session, which means your software cannot rely on having Finder there to send an Apple event to, using AppleScript, or having dependencies on Cocoa.

So exactly what do you need to do? You need to really decouple any GUI application, any GUI component that's built into your server software, and make sure that remaining core functionality is packaged as a daemon that can run in the background. And make sure that separated GUI component can run not only on the server machine, but also on any remote machine, and be able to connect to the server machine.

Let's look at an example. Let's say you have a backup software that's based on Cocoa and it runs on a server machine today and perhaps have a couple menu items such as Backup Now or Configure Backup Software. This won't work very well because the admin doesn't want to walk all the way to the server closet, attach monitor and keyboard, and select menu item every time he or she wants to configure the backup software.

So here's what you need to do. You need to separate the backup software into two components: the Cocoa GUI application and the backup engine that can run in the background. And you also need to make sure that the Cocogui application that you separated can also run on the remote machine and be able to communicate with the backup engine running on a server machine.

Also, since the Cocoa GUI application is running on a remote machine, or maybe running on a remote machine, you may want to provide server browsing UI so that your user can easily select a target server. And you can use the new DNS service discovery API to achieve this.

And if you're interested in this API, there's a session, 8.11, Zero Configuration Networking, or I guess it's now called Rendezvous, on Thursday at 2 p.m. And lastly, now that you have two different components, you may want to consider packaging those two parts into two separate installers. It's going to make life much easier for users that way.

Now, here's an example of how we designed one of our server administration software, NetInfo Domain Setup. The core functionality is implemented as a command line tool, shown here in orange, and it always runs on the server machine. And then the Cocoa GUI application that user double-clicks on is just actually a small wrapper, and it simply makes a call to the command line tool to actually do the actual work.

And here's what happens when the Cocoa GUI applications run on a remote machine. It first presents the user with a user interface that lets them select the target server. Then brings up an authentication dialog where a user can type in the admin name and password of the target server, not of the local machine.

The application then uses the name and password to establish a secure shell session to the server machine and simply invoke that tool within the session. With this technique, we didn't have to write any new authentication code, networking code, and still be able to actually support remote administration. So this is something you may want to think about also. It worked out pretty well for us.

Now I will talk a little bit about remote server monitoring. With Jaguar Server, you'll be able to monitor remote servers in three different ways. First, for Unix fans, you can continue to use Terminal, SSH, and command line tools such as Netstat and Top to keep their eyes on the remote servers. It's simple, but it works real well for some of our users. And if you're developing a server software on Jaguar Server, you may want to think about delivering a tool that lets those users actually monitor your services over the command line.

The second way is using SNMP. We ported NetSNMP, a popular open source package, to a Jaguar platform, and it's being shipped as part of both desktop and server releases of Jaguar. includes an agent and 15 or so basic MIBs with which admin can remotely monitor CPU utilization, the free disk space, and so on using industry standard tools such as HP OpenView. And there's definitely a developer opportunity here to deliver additional MIPS for the Jaguar Server desktop, a Jaguar Server platform.

The third way is an application called Server Status, which is a brand new application that's built into the Jaguar server and I would like to show it to you right now. Demo 2, please. Go. Okay, let's launch server status. Takes a couple seconds. What's up already? Let's connect to a server.

Okay, so on the left-hand side, we are connected to this server right here. And on the right-hand side, you see several tabs. The overview tab contains basic information about the server, such as the version number of the OS, the serial number, and basic network configuration. The next tab, Logs, lets you display different system logs.

You can select any one you'd like from here. And it's actually a live view, meaning as information gets added to the log file, this automatically updates and scrolls up. We have not implemented the hardware tab yet, but you would see things such as CPU utilization, network throughput, and information on mounted volumes here.

Now, if you look at here, you also see a list of all the services that are available on the server machine. And the ones that are currently active is marked with a blue circle, and also their service names bold face. So, for example, AFP Server, the directory services, FTP, and Web are currently running.

Clicking on AFP Server, you see again different tabs. The overview tabs again shows you the basic information about that particular server, AFP in this case. You can go to the logs to see either error log or access log. And again, this is live. You can also go to Connected Users window here.

You only have one user connected right now. You can either send a message or disconnect. And the last tab is Graphs tab, which lets you see the histogram of either throughput or number of connected users over a period of time. And you can specify the time right here, anywhere from last one hour up to last seven days.

Now, walking down the services list, you notice all the services have the Overview tab in a consistent way, so you can actually see what's going on there at a glance. And most of them also have Logs tab, so you can see their log files. Some of them don't, but most of them do. And some services such as Mail or the print servers have their own unique tab. For example, for the print server, there's a queues tab that lets you view different print queues and status on each of them. And so on.

Now, you can connect to as many servers as you'd like, and they all get listed on the left-hand side right here in this column. So once you start to get too crowded, you can do things like showing only the currently active services, or you can do filtering by either service name or the server name, or both. So for example, you can say something like services that contains letter W, and it will display that.

Now let's instantiate another window here. This is a different window by looking into same data. The list here is identical. But you can use this multiple windows to actually view different services. So for example, in this window, you may be looking at list of connected users to the AFP server. And you can actually hide this guy. Hide this guy And you may be watching web service right here. Maybe it's throughput.

And you can shrink this guy and hide it. And you can really instantiate as many windows as you'd like, so you can simultaneously monitor number of different servers, or different services, or different tabs within the same service running on the same server. Lastly, we do have the standard Mac OS X toolbar on the top. The one on the left-hand side lets you jump to different administration tools for Jaguar Server. And on the left-hand side is a set of commonly used commands, and of course you can customize it just like any other standard Mac OS X application.

So that's the real high-level overview of server status application. And back to the slide, please. And now I'd like to talk a little bit about the architecture of server status. The application itself is a Cocoa application that communicates with the backend server using XML over HTTP, and of course with SSL for security.

On the backend, on the server machine, this way, you have a stripped-down version of Apache web server with a couple of custom modules that we've developed. There is also a set of command line tools, one per service, that knows how to talk to the particular service and gather information.

So for example, when the user clicks on AFP connected users tab, the server status application sends an HTTP request to the web server. Web server invokes the AFP command line tool, which in turn talks to the AFP server, gather whatever information it needs to gather, and send the data back up the chain.

This design is working out pretty well for us. It's real simple, but it's real easy to unit test, easy to debug using standard tools out there. And notice that back end is web server, meaning if we decide to support web browser-based UI in the future, it's going to be relatively easy for us to migrate.

Now, this whole thing is private right now, and there is no public API, but we are looking into and we're interested in opening this one up to developers if there's enough demand. So if you think this is something that might benefit you or may help you write a better software for a Java server, please give that feedback to our developer relations person, Tom Weyer. We'd appreciate any feedback you may have.

Okay, let's move on to the next topic, open directory. As I've mentioned earlier, there is a separate session on Thursday to talk about this technology in detail, so here we're going to only briefly talk about it. And also, there were a lot of mentioning of this technology in Eric's presentation in previous sessions, so there are some overlapping, but it's a really important technology, so I want to reiterate.

So far is it. It's Apple's directory services architecture that lets different applications share information on the network. And it's being utilized by a number of services in Jaguar Server and also by different components in Mac OS X Desktop, such as system preferences and login window. It's been available in previous versions of Mac OS X Server, but the Jaguar released a number of new enhancements, including the password server.

Using Open Directory Read and Write API, developers can access any directory system without needing to know the details of the particular system. And as Eric mentioned earlier, Apple ships with NetInfo plugin, LDAP plugin, both versions 2 and 3, and a plugin to access flat files, read-only. And of course, Open Directory also provides an API so you can create your own plugin to access any other directory systems out there, such as NIS and Novell directory, or even database, if you'd like.

So what kind of information do you want to store in a directory? We hear a lot of questions about this. And it's actually pretty much anything from user attributes, machine attributes, any information that you want to share among multiple applications, or even service preferences. So let's look at user attributes as an example.

Let's say you are writing a VPN server that supports per user quota on how long they can stay connected. Instead of saving that per user quota information inside your own data file, you would want to store that information in a directory in the user record. And you can do so pretty easily by using Open Directory's API to find that record, add the attribute, and later on find it.

Another example would be service preferences. So you can store the VPN server's preferences in directory instead of, again, in your own data file. And that way, the VPN admin GUI can simply use directory services API to access the information anywhere on a network, so it really simplifies implementation of remote administration support in your software.

Now, Eric also talked about Password Server. It's based on SASO standard, and it lets services verify passwords over the network, but it does not allow you to retrieve it for better security. It supports a number of popular authentication methods out there, including NTLAM Manager hash, APOP, CRAM MD5, any of the Apple's authentication methods used by Apple Share and other protocols, and SHA-1. And Password Server also provides a number of password policy features, such as disabling accounts after a certain time, while enforcing minimum password links.

So that's really the five minutes real high-level overview of open directory. And we encourage you to attend the Thursday session at 3:30 p.m. if you're interested in learning more about this technology. It's in the room C right across from this room. And also, if you are interested in checking out the API documentation, it's available on the developer website at developer.apple.com/techpubs. And now that it's being open sourced, you can download the whole open source code base from Apple's open source website as well.

Okay, now I would like to invite Scott Mulligan, manager of Server Infrastructure Group, to tell us about high availability services in Jaguar Server. Which button is it? Which one? Okay, thanks. Good afternoon. My name is Scott Mulligan, and today I'll be talking to you briefly about high availability services.

First, let's make sure we understand what we mean by high availability services. In short, the goal of high availability services is to make sure that servers and services always function and are always available. Some of you may be familiar with the utility we first introduced with Mac OS X Server 10.1 called Watchdog. The watchdog is a utility that launches service processes and then monitors them.

It can detect if a service fails and then relaunch that service, making it once again available. Another high availability feature tied to the Watchdog utility is heartbeat restart. The heartbeat restart feature Utilizes a specific feature of the server hardware in order to detect when the operating system has crashed or has hung, and then it can restart the operating system. Details on the watchdog utility are available in its man page.

In Jaguar Server, we are proud to announce the addition of two new high availability services. The first of these is a new utility called Disk Space Monitor. The goal of Disk Space Monitor is to monitor and manage the amount of free space that is available on system volumes.

It does this to assure that services will not be interrupted due to a lack of free space. To accomplish this goal, Disk Space Monitor periodically checks volumes to see if they're short on space. And if a specific user-definable threshold is exceeded, it will utilize a notification script to alert the administrator Allowing them to know whether of the... Excuse me.

It will send a notification to the administrator informing them of the situation. If a second user-definable threshold is exceeded, the disk space monitor will execute a recovery script. That recovery script can take certain predefined actions in an attempt to free up disk space on those volumes found short to be free of disk space.

This slide lists the default recovery actions that Disk Space Monitor can take. As you can see, these recovery actions are geared toward managing log files. This is because on a server, log files are usually active and recording the transactions of the services that server is providing. As such, these log files are continually growing. Log files are probably the number one cause for volumes running short of free space. But notice that this slide says default actions. Since Disk Space Monitor uses a recovery script, that script is extensible by the administrator so that it can deal with a variety of file types.

The second high availability service we're announcing today is called IP Failover. With IP Failover, the system administrator can create a server scenario whereby a standby server can take over the network address of a primary server when failure is detected. When the standby server detects that the primary server is no longer functioning properly, it will perform... The failover action, taking the IP address of that server. When it detects that the primary server is again functioning properly, it will perform what we call a failback action, relinquishing the primary server's network address.

The standby server will send email notifications for all transitions, and a mechanism is provided for the standby server to perform multiple ordered actions before and after acquiring or relinquishing a network address. Here are a few tidbits on IP failover. First of all, standard OS mechanisms are used to notify network services of the transitions. There is an option for providing notifications without actually performing the IP failover. You'd utilize this if you just wanted to monitor a system.

Failover scripts are extensible, allowing system administrators to custom tailor IP failovers' actions to their specific needs. IP failover's simple and flexible design makes it easy to leverage in a multitude of scenarios. And it is an excellent solution for certain scenarios. For example, For example, take the case of a server that's providing static data over the world wide web.

Sorry for the pause. In that particular case, IP failover would be one component of the complete solution. It would be providing the static data. However, I would want to point out on this slide that the actual mirroring of the data to the standby server is not a component of IP failover.

This is a typical usage slide. Here we have a primary server and a standby server. Each have a public address and a private address. So each of these machines has two network interfaces. Disk storage is mirrored to the standby server. Again, IP failover does not accomplish that mirroring. That's done by another mechanism.

So both of these machines have a well-known address and a lesser-known private address. The primary server has a process that's repeatedly broadcasting on the network that it's alive and well. And the standby server is listening for those messages from the primary server. Here we see the broadcast process of IP failover on the primary server and the listening process of IP failover on the standby server. Note that broadcasts are sent over both networks.

In a real scenario, the primary server will probably be doing something interesting, like serving up product data sheets via the World Wide Web. Here you can see the web server sending and receiving data to and from the network while the broadcast process continues to send its packets over both network interfaces.

Of course, the standby server may be doing something as well, like Like analyzing SETI radio telescope data for a project underway at UC Berkeley. So let's look at the failure situation. It looks like somebody's tripped a circuit breaker here. I guess it's a good thing our standby server's on a different circuit.

So you can see the broadcast packets have stopped coming into the standby server and a failure is detected. Immediately, an email notification is sent. Next, an ordered set of pre-acquisition scripts are run. In this case, we have a single script which is going to shut down the SETI analysis program.

Stopping the study analysis program relieves the load on our standby server so that it may do the important work of providing the service that our primary server was doing before it went down. Next, the standby server must acquire the public address of the primary server. It assigns that address to the network interface that corresponds to the public network.

And then finally, an ordered set of post-acquisition scripts are run. In this case, we have a single script that starts the web server. and the web server is started. At this point, our standby server is servicing web requests, masquerading as the primary server, and it's listening for the primary server to return.

Now here are a couple of important points about the way IP failover works. First, the failover action will only take place when the broadcast packets are missing from both the public network and the private network. And second, if broadcast packets are missing on only one network, we have what we refer to as an anomaly.

Anomalies do not cause the failover action to take place, but they do cause the notification action to take place. Here is an example of an anomaly. As you can see, the primary server continues to perform in a normal fashion. And, as you can see, it's not particularly desirable for the standby server to acquire the primary server's public network address.

It's important to note that the private network is used to verify failure and detect recovery. Anomalies never cause the failover but always trigger notification. Failback works similarly to failover with notifications and pre- and post-address release extensibility. For example, using the web server scenario from the previous slides, the failback would occur as follows.

First, the standby server would notice that the primary server had returned to full functionality. Next, it would run the set of pre-release scripts. In this particular case, it would just shut down the web server. Then it would relinquish the public address that belongs to the primary server. And then finally, it would run a set of post-release scripts. In this case, it would restart the SETI analysis program.

This slide lists the various components of IP failover. The broadcast process, the listener process, the notification script, a variety of sample scripts that we intend to provide, and then of course the man pages that go along with these programs. Now I would like to introduce you to Rusty Tucker, manager of our file systems group.

Hi, my name is Rusty Tucker. I'm going to take a few minutes today to bring you up to date with some of the changes we're making in file services for Jaguar Server. The Jaguar server includes a number of upgrades, especially in the area of security, performance, administration, and support for AFP home directories. The first thing we'll take a look at are the security upgrades.

As you may have heard, we have Kerberos support baked into the OS now. There's a framework that's based on the MIT work included in Jaguar Server as well as the Jaguar Desktop. What we've done in file services is take that and include Kerberos v5 support in both the FTP and AFP servers.

In AFP, we've taken the extra step of including Kerberos v5 mutual authentication. Mutual authentication not only authenticates the client with the server, but also the server with the client. The net effect of that is that this ensures that the server you're connecting to isn't being spoofed on the network.

For Kerberos v4, we're supporting that in the AFP client as a legacy option only. So if you have an existing infrastructure with Kerberos v4 deployed AFP services there, the Jaguar client will fit right in. The final security upgrade is for secure connections, secure AFP connections. Here we've taken the Mac OS X, leveraged Mac OS X support for SSH and reduced that to just a single checkbox in the Mac OS X client to turn on AFP connections, AFP sessions, tunneled through an SSH connection. And this provides encryption for the full AFP session, not just the password transfer, but the data transfer as well. So it keeps your data private in any transfers across the Internet.

Jaguar includes a number of AFP performance improvements. A number of these, we've optimized the TCP stack that's in the kernel, and that helps not only AFP but any networking application. We've also made optimizations within the AFP server itself. The effect of this overall is that now with AFP sequential read performance, we're getting up to 700 megabits per second. But even if you don't stress your servers that high, even at the lower data transfer rates, AFP is consuming far less resources, and that leaves a lot available for more for your web and mail services that are running there.

The AFP server now allocates threads in response to demand. And so what that means is that the AFP server can adjust its footprint to meet the load that's currently demanded. And this gives us a lot better scalability. Mount times have improved. We've improved that currently by two seconds, and we're continuing to work to improve it more. Where you'll see this is when you're in finder's connect to menu item and logging into an AFP server. That'll be much faster in the Jaguar client.

The Jaguar client also employs data caching when you're opening files in a read-only access. And, of course, this is going to be a big improvement for any kind of data that's read repeatedly. And it doesn't work so well for access to database-type files. So the AFP client avoids these caching strategies when files are opened read-write or in a read-shared mode. So you'll want to take advantage of that in your code.

Jaguar now includes quota support on both HFS Plus and the UNIX file system bottoms, and we've updated AFP to take advantage of that. You'll notice applications will be receiving disk quota errors now, and so you'll want to update your applications to take advantage of that and provide appropriate error messages when that occurs. These quotas are managed by Server Manager within the user's home directory. Although anything that would be manually configured, AFP would also take advantage of that.

We've completely rewritten the sharing user interface for Jaguar. It's all done in Cocoa. It supports in-place file system navigation and the ability to set privileges in a batch mode, which we think is really going to be great productivity enhancement for system admins. We also support per-service SharePoint, so that means now you can create one SharePoint that is just unique for AFP and another, for example, that is FTP only. It isn't just one button, share is all, although that mode is an option, and you can go in there and tweak it.

The SharePoint names, by default, the SharePoint names will be the same as the directory that's being shared. But we got a lot of feedback that people wanted to improve on that, create a custom SharePoint name for different SharePoints, even to the point of providing a unique SharePoint name for different services.

AFP home directories are a really important part of Jaguar Server. Our goal here is to make the AFP home directory just a transparent replacement for your hard drive, except that it's available from anywhere on the network. So part of our work there was to provide automatic reconnect within the AFP client.

So any time the connection is lost, the AFP client can transparently reconnect you to the server. There's no having to re-log in, really no notice in any loss of the connection. Now for a server admin, this means you can turn on idle disconnect on your home directory servers, and that'll help you support a large number of users with a single server.

We've also updated the AFP protocol, which is now at version 3.1, to provide better UNIX fidelity. And a lot of what this means is that we're following the UNIX permissions model a bunch more closely than we did with the Apple share servers or AFP 3.0. Today, in an AFP connection, you'll see the true owner and group as well as the permissions that are coming directly from the server. We also support symlinks and delete while open for better compatibility with BSD command line tools and Cocoa applications.

Part of the feedback we got in Mac OS X Server 10.0 and 10.1 was that admins wanted to be able to do user imports much more quickly than we had supported. So now we're deferring to improve that speed. We're deferring the creation of the home directory to actually when you log in over AFP.

You may notice a very small delay in the login time, much less than a second on the first connection, but there's no penalty after that. In fact, if you saw Eric's demo here in the previous session, that in fact happened. So now I'd like to turn this back to Kazu, who's going to wrap up with the web platform.

OK, web platform. So, a Jaguar server with its collection of industry standard software plus Apple-developed software is a great web platform. At the foundation, we have Apache, the world's most popular web server. We bundled the latest version of Apache 1.3.x as well as a number of popular open source packages.

And on top of that solid foundation, we've implemented a high performance front-end cache that pretty much doubles the performance of static page serving. We also bundle a few Apple-developed modules, such as enhancing capabilities for things such as allowing short-look search of your website. And then on top of all of that, we have set up administration and monitoring software, such as the Server Status application you saw earlier.

So let's look at some of the tools that are built into Jaguar Server. Jaguar Server first ships with WebObjects. It's a top-rated application server from Apple. And if you're interested in this technology, I believe there are around 15 sessions this year at WWDC, so you can learn all you want about it.

We also bundle MySQL, which is a very popular database package out there. And if you'd like to have a scripting engine, we have both PHP and Perl that's pre-installed as part of the Jaguar server. We also have Tomcat if you want to use Java Serverlet or want to serve JSP pages.

Jaguar server also include a fast and robust implementation of Java VM complete with a whole development environment. We also have a patch 2 bundle, as Eric mentioned earlier, although the default server is still 1.3.x. And last but not least, we have a built-in media streaming server, QTSS. It lets you stream both live and stored media in different formats, including QuickTime, industry standard MPEG-4, and MP3.

And it has a long list of cool features such as Playlist Broadcaster, which lets you create your own internet radio station pretty easily. So with QTSS, you can easily integrate streaming live media into your whole web solutions. And there is a separate session on QTSS on Thursday, so it would be great if you can join us there and learn more about this cool technology.

Here's a list of some other sessions that you may be interested in. We've talked about directory services already. It's on Thursday at 3:30 p.m. in Room C. The QTSS session is also on Thursday at 2:00, across the street in the Civic. And if you're interested in learning more about Managed Desktop, which is basically Mac Manager for Mac OS X and more, there's a session on Friday at 9:00.

And then the Netboot and Netinstall session is on Thursday at 10:30. The server feedback session this year is on Friday at 5:00, the last session of the conference. There is a corporate session on Thursday at 5 o'clock. And lastly, the Zero Conf Networking or Rendezvous session is also on Thursday at 2 o'clock.

If you have any questions about developing software for a Jaguar server platform, please contact our developer relations person, Tom Weyer. His email address is listed here. Lastly, here is a list of online resources if you want to learn more about Mac OS X Server. We have a product page at www.apple.com. If you go to Apple's open source website, you can learn more about the details of streaming server and open directory.

If you are interested in learning more about Mac OS X Server administration or want to be certified, you can find that information on our website at train.apple.com. And you can download information such as API documentation and AFP 3.1 protocol documentation from our developer website at developer.apple.com/techpubs/macos10. You have to navigate down to the networking section.