Good afternoon and welcome to session 606, Mac OS X Server in Depth. Before we start, I'll just spend a minute or so talking about some of the specific goals we had for this release, the Pencil Server release. First, we wanted to enhance our admin software with more features, improved usability, more integration, and so on. Second, we wanted to provide ways to simplify the setup and configuration of lots of different servers. So for example, Rackprobe XSERVs. And next, we wanted to complete our transition from NetInfo to LDAP server as our primary directory server for scalability and many other benefits.

And also, establish a single sign-on strategy around Kerberos authentication. This is really important to us. And lastly, improve our Windows compatibility features, both in terms of being able to fit into existing Active Directory networks, as well as being able to replace aging NT servers out there. There are tons of them out there.

Since we're going to be talking about directory services and authentication in two different sessions in details, we have session 106 coming up right after this and have session 610 tomorrow morning at 1030. We're going to be focusing on the three remaining items that are listed here. With that, we divided this session into four subsections.

First, we're going to talk about server admin software and architecture behind it, and also how developers can plug their software into the architecture. Second, we're gonna be looking at the details of the server assistance new features that's gonna enable you to set up a bunch of different servers simultaneously very quickly.

And then we're going to be talking about Windows features. We're going to be talking about how we implemented it on top of Samba 3, and also how we integrated it with the rest of Mac OS X Server components. And lastly but not least, we have a handful of tips on developing for the pencil server platforms. So we're going to be talking about things like optimizing your server software and such.

So these are the four things we're going to talk about today. And since we usually have sort of mixed audience of both developers and sysadmin type people in these server sessions, we're going to try and have useful information for both of those audience groups sort of mixed in everywhere. So let's just start talking about the admin software.

In Jaguar Server, we have two separate applications for configuring and monitoring servers. Server settings for configuration and server status for monitoring. In PanSource Server, we are combining those two into a single application called Server Admin. and has a bunch of new features which I'm going to come back to, but also have a new GUI for a number of services that did not have GUI in the past. For example, we now have QTSS management integrated with the rest of Mac OS X Server services, so you no longer have to go to web-based admin to manage the streaming server.

We also now have Open Directory GUI because we keep adding these new features to Open Directory that requires configuration, such as replication support for LDAP and Kerberos. And we finally have DNS GUI as well, since a lot of people have been asking for this for the last four or five years. Thank you for waiting and hope you're going to like it. And we also have GUI for NAT application server, which includes things like JBoss and such. And of course, we also enhanced existing GUI for services such as web and mail with a bunch of new features.

At the application level, actually before we start, how many of you went to the Mac OS X Server overview session before this? So pretty much everybody. So you know some of the new features. So we do have this new replication feature that you can replicate configuration services by simple drag and drop, which is a pretty cool feature. We also have GUI for remote software updates, so you no longer have to go to the server machine to perform software update or go to terminal to do so.

Read-only mode. So now that we combined configuration and monitoring, there was one problem. And that is, we think many of you want to keep this application up and running all the time so you can monitor things, but if you walk away from the machine for a few minutes, go to the bathroom or wherever, people can just come up and then change their configurations. So to prevent that, we implemented this thing called read-only mode, where the application will not let you make any changes to your configuration until you type in your admin password to unlock it. And I'm going to demo that in a few minutes.

We also have a summary view where, at a glance, you can look at the status of all the servers and services so you don't have to go to individual servers and see how things are going. This will be useful for computational clusters or web server forms or different environments where you have a large number of servers that you want to monitor simultaneously. And there are other features sort of scattered throughout the application, so you can try out your CD and then check it out.

So you can connect to both Jaguar servers and Panzer servers. However, in Jaguar server, it's monitoring only, so you cannot configure.

Sorry. So now I'd like to give you a little demo of Server Admin, but the problem is this application's been popular and it's been demoed in two other sessions. I'm running out of things to show you, but I do have a couple things I wanted to go over.

So the first thing is, let's see, go to AFB, and as everybody's seen, you can do drag and drop replication here between different servers. We can also drag this onto a desktop, and this makes a backup copy of your configuration. Thank you. So later on, if you need to reinstall the server or whatever else, you can just go ahead and simply drag back in.

Thank you. That will be handy for other people. And the read-only mode. So let's go to this menu here and then lock now. And application tells you everything is locked out. So with that, you see this little icon here that says Read Only, and everything in the settings panel is now, cannot be edited. So same thing if you go to the Windows. It's all grayed out. Same thing for FTP. It's all grayed out.

And you can unlock it by just going here, typing in admin password, and you're back in business. You can also set a timer, so after a certain amount of time, the application automatically locks itself, so it works much like the screensaver. So that's the server admin, 30 seconds demo.

Back to the presentation, please. Now let's look at how this one works behind the scene. Server Admin is a Cocoa application, and there is a plugin for each of the services that you saw in the left-hand column. So there is a plugin for AFP, there's a plugin for the web service, and so on. On the server side, we have a stripped-down version of Apache Web Server with a few custom modules that we developed, and it's working as the admin server engine. And the server admin talks to the backend engine by passing XML backend force over HTTP, usually also over SSL.

Whenever there's a request that comes from the GUI application, the engine dispatches to one of the CGI's. Again, there is one CGI for each of the services. There's AP CGI, web CGI, and so on. Individual CGI's do know how to talk to its own particular service. can do things like start and stop the particular server or service.

You can get real-time status information from the service, and you can also read and write configuration file or configuration information for the service, which are usually stored either in the config file or up in the directory server. And as needed, the CGI also signals the application to refresh its configuration or restart if necessary.

And by the way, these CGI's are all just regular Unix command line tools. Thank you. So that's the real basic design of our admin application, or admin architecture. And if you notice, we try to use standard technology whenever possible. So HTTP, XML, Apache, CGI, SSL, and so on.

And also, with this modular design, it was really easy for us to develop and debug this product. For example, to debug this client-side GUI application or the plugin, we didn't have to even have the server-side. We could simply pass XML into it and test its functionality. And vice versa is true, too. We could just use a web browser and pass the XML file to the backend to test the server-side.

We could also test the CGI, so you could unit test it by simply SSH into the server and directly invoking it since they're just Unix command line tools. This worked out pretty well for us. Right now, it is not public, but if there's enough demand, we would like to make it public. If you're interested, please let us know.

I heard seven. Eight. Okay, thank you. I guess we have to look into making it public. We have been actually working with one particular developer to port their administration software to Server Admin, and it looks like they have something up and running now, so I thought it would be neat to actually have it demoed. So now I'd like to welcome Steve Olson, who is the Technical Director of Engineering at Sybase.

Thank you, Kazu. I think most of us here who have had the job of managing a network of servers can appreciate and understand the value of having the right tool for the job. We at Sybase have heard that from our customers just about every single day. So we're very pleased that Apple has provided this extensible framework that allows us to plug in our server management capabilities with the admin framework that Apple has provided.

Apple understands user interfaces. We don't. But we understand our database and what needs to be done. So they've provided a very elegant framework that makes a very nice user interface for the administration of our server. So what we have, well, we've done that. We've been working with this toolkit for about 10 days now. And we have a first pass at what we think will be available with the Panther release when Panther comes out.

So standard disclaimer applies here as I demo this. It may change quite a bit by the time we actually release this. So I've got a Jaguar version here. I don't have the Panther release. And what I have is a plug-in on the admin tool side and the Apache module on the server side that understands something about Sybase. So the general status tool says what is the state of the service. And the service is our adaptive server enterprise. Amen.

You can do things like read the transaction logs. We have a usage indicator that tells us the general summary of what's going on inside the server in terms of load, the number of users connected, the databases present in the system and their size and attributes and so forth. Databases map to devices, physical devices, so we have some information about those. An engine is an operating system process. We associate one engine per CPU so we can get information about that.

Any locks that are present in the system, various monitor information is available. We have, after learning the framework, it took us a day or two to sort out what this Cocoa environment is about. The challenge before us was then figuring out what information to present to you to make it useful and meaningful. We have, for example, over 200 configuration values, yet there's probably a dozen or so that are very commonly used.

So our task is going to be to sort out which one of these are most relevant. We will expose them all, but in the settings, sorry, in the settings value we'll provide maybe a dozen or so configuration settings that, for example, numbers of users, memory, cache sizes and so forth that are typically used by our customers when they want to reconfigure the server. We've been having a lot of fun with it.

This is a very convenient tool to help us manage. By the way, you can start and stop the server without having to use a terminal window or anything else. It's a very convenient way to look at everything going on in the server from a single workstation. One thing that is very nice is that if you've got a list of servers here, you can get a summary view of all servers and each service appears as a dot.

Which is either red or green or some other color. And you can get a very clear overview of everything running on your network. So that's what we've done and this will be available with our product, our 12.5.1 release, which we're tying to the release and availability of Panther. Thank you.

So let's go back to the architectural diagram. I know many of you like Mac OS X, Mac OS X GUI, and Cocoa, but some of us still like to use Terminal for managing servers. So for those people, we actually developed a new command line tool. It's also called Server Admin. And with this tool, you can do everything that you can do from GUI and more. So I'd like to show that to you right now.

Switch to this machine here. Okay. Okay, so let's go to terminal. You can do a server admin list that lists all the services that are installed on the server. And of course, you can use this to start or stop any of them. You can also get status on any particular service you'd like.

So you can do something like full status AFP. That gives you a list of how the server is doing. So the AFP server is running. This is the time it was started. And guest access is on. There's currently one user connected from this machine here. And throughput is zero since the client is sitting idle.

And you can also issue commands that are specific to any particular service. For example, you can do, So that lists all the currently connected users with information such as name of the login name, the IP address, and how long the person has been connected for, and so on. Of course, you have commands for disconnecting the user, sending messages, and so on. But probably the most common use for this tool is doing the configuration of different services.

For that, you can just do settings. And again, if you specify any of the services, let's do AFP, that lists all the configuration options for the AFP server and what the current settings are. So if you look at it, you've got the maximum number of threads, 40, the max guest is minus one, which you think means unlimited, the error log size, and so on. You can also, if you know exactly what you're looking for, you can simply type in one of the options and it shows you status of that. So this tells you that login greeting setting The text is not set, so right now it's empty.

Of course, you can set configuration as well. So let's go here and use the login greeting. If you go to the GUI and look at it, sure enough the login greeting's empty right now. You can go here and specify, let's see, welcome to WWDC. That's it. If you go here and refresh, it works. So.

Again, you can pretty much do everything that you want you can do from the GUI from this terminal application. But you can also use this as a building block to build your own custom solution on top of it. And to illustrate that, we wrote a real quick, simple shell script that I wanna show it to you.

So let's say you add new websites to your server frequently with mostly same options, and you want to do that from command line. You can use our short script called @site. And actually before start, let me go to GUI here. Web, Settings, Sites, and make sure the only site that's defined right now is the default, so there's no other virtual hosts.

But we're gonna go ahead and add one. So @site, specify IP address. And let's see the port number. Let's make it 8080. Name of the site, my site, and the web folder. There you go. So if you go to the GUI, here is the site. Now you have this website up and running.

Of course, you double click on it, you got the web floor that we specified and so on. So now let's look at how this works. So, add site is just actually a single line shell script. So what it does is use this set to substitute some of the strings in this data file at site.in with the argument that's been passed into the shell script. And then it pipes the output to our command line tool, which is running on .i, which is an interactive or input mode.

And then if you look at the data file, it's actually basically just a collection of the settings for the web server with a lot of default values, except for a few of them that start with underscore such as IP address and then the port number gets substituted by set. So it's real simple, but it works. So hopefully people can use this server admin command line tool to create your own custom solution.

So to summarize Server Admin, for system admins, we have a new Server Admin GUI application that combines configuration and monitoring and has a bunch of new features. We also have Server Admin Command Line tool that you can use to do pretty much everything that you can do in the GUI, or you can use it to use a building block to build your own custom solution on top of it.

For developers, we have a modular and scalable and flexible server admin architecture that you can plug into. If you're interested, let us know and we'd love to work with you. That concludes the server admin portion. I would like to welcome Scott Mulligan, who's going to tell us all about the new server and server assistant features.

Thanks. Hi there. Good afternoon. I'm Scott Mulligan, and I'll be spending a few minutes with you discussing the server assistant. The Server Assistant is the first application that runs on a freshly installed server. And its objective is to To get the system set up in the most basic setup state so that it can be fully configured at a later time after it's been rebooted. So in the Jaguar server, The server assistant is always run on the system console, and the system keyboard and mouse is used to capture setup data.

Additionally, to accommodate headless servers and to provide additional level of convenience, the Jaguar Server Assistant can be run from a remote system in order to perform both setup and installation. Of course, in Panther Server, we've come up with a couple ways that we can improve this experience even more.

So with the popularity of Mac OS X Server, we realized that many of our customers are buying multiple servers, and thus they're setting up multiple servers. So with Panther Server, we've designed it so that they will be able to set up multiple servers simultaneously from a single interview process. This will be accomplished by running the server assistant from a remote system and targeting the specific servers that you want to set up. It will look something like this.

Servers that are eligible for setup on the local subnet will show up in a list. And the system administrator simply selects the servers to be set up. Additionally, the administrator may add servers to this list by providing an IP address, thus enabling the remote setup of a server that's not on the local subnet. Once the target systems are selected and authentication information has been provided, The administrator proceeds into a standard setup interview where the setup information is collected and at the end of the interview all the servers are set up.

There's also another scenario that we've found that some of our customers are running into. It turns out that some of our customers actually reinstall their systems from time to time. And others, due to the specific nature of how they use our servers, actually end up resetting their systems up more frequently as they repurpose our servers from one particular task to another.

For these folks, setting up the server is something that they'd rather not deal with at all. So for these folks, we thought, why not have the servers set themselves up? Of course, you need to provide the setup information once, but you could save it to a file to be used again later.

So in Panther Server, the server assistant has been designed to actually go out and discover or set up profile data on its own. It does this by looking for the setup data. In local file systems, which can include local hard drives and various types of removable media, such as CDs, FireWire drives, USB drives, etc.

Additionally, the server assistant will look and try to discover setup data that has been saved to a directory server. If a directory server is accessible and it holds setup data that pertains directly to this server, then the setup assistant will utilize that data to set up the server. So, what does this mean? Well, for one thing it means that your iPod can set up your server. Imagine saving setup profiles for dozens of servers onto your iPod, or a FireWire drive, a USB thumb drive, maybe even a CompactFlash card reader.

You walk up to your server, plug it in, and your server sets itself up. Or maybe you save these profiles onto your directory server that's on your local network. Your servers just set themselves up. You wouldn't have to plug anything in. They could just find the info they need, set themselves up, all on their own.

So how does this work? Well, first of all, we have a special setup daemon that runs on the server when the server needs to be set up. And there is a special place on the server that the server setup daemon examines from time to time looking for setup data.

The daemon loops periodically checking to see if this data has shown up. But there are other places the daemon could attempt to find the setup data. Directory servers, for example, or local file system. The daemon will examine these places as it proceeds through its loop. And if it's able to find the relevant setup data, it will utilize it And then it will restart the system. So these last few slides have focused on the back end process that actually enables this auto setup feature. Let's look at the bigger picture though.

As I showed you in the previous slides, there's a server setup daemon that is running on the server. And there's a specific place that it examines for that setup data. But there's also a GUI application. And that GUI application can be running locally on the server or it could be running on a remote system, say your desktop in your office.

In either case, this GUI application presents an interview to the administrator in order to collect the setup data. And at the end of that interview, if the server is to be set up at this time, in other words, at the end of the interview process, that setup data is delivered to this specific location on the server that the server setup daemon examines from time to time. And if that's done, it enables the server to set itself up.

But as we said, the server setup daemon can discover data in other locations, as in the directory server. So therefore... The GUI application has to have the ability to save to, to connect to, to begin with, to connect to a directory server and save to a directory server. The setup data. And once this is done, of course, it allows the server to set itself up.

And, as we mentioned before, the same thing can be done with the local file system. I'd like to point out that the local file system here may not be local to the server at the time that you save it. It may be your iPod, but when you carry it over and plug it into your server, it becomes local file system on the server. On the other hand, it could be a partition that already exists on this server.

Okay, so the setup profile for your server may contain sensitive data that you don't want other people to see. If that data is saved onto some form of removable media that you actually safeguard yourself as the administrator, such as your iPod, that might not be a problem. But that's not always the case.

Therefore, any time data is saved from the GUI application, whether it's to a file or to directory services, an option is provided to encrypt that data. The encryption utilizes a user-provided passphrase that is used as the key for both encrypting and decrypting the data. Encryption is accomplished using the CAS5 CBC algorithm of the OpenSSL command line tool.

The server setup daemon process will wait for the data to become decrypted. So if the data is available but it's encrypted, it will wait for that data to become decrypted. However, while it's waiting, it has also been designed to see if it can find a decryption key. So it will look in local file systems, in a specific location on those local file systems, to see if it can find that decryption key. It will not look in directory services.

For obvious reasons. But if it can find that key, it will utilize it to decrypt the file. So you can imagine having this key file on your iPod, and while the data may be available and encrypted, all you need to do is walk up and plug in your iPod and it goes. Additionally, the GUI application itself has a mechanism for delivering this passphrase directly to the server. And in that case, that passphrase is used to decrypt the data directly.

Now you may remember I said that you might be able to save dozens or even hundreds, if not more, of these setup profile data files onto your iPod. This is how you keep track of them so that you know which setup file goes with which server. Basically, the server setup daemon process looks for these setup files by name, and it looks in a particular order. So these are the naming conventions, and this is the order in which it looks for them.

To begin with, it'll look for a file that's named with the Ethernet hardware address .plist. Then it'll look for an IP address, followed by a hostname .plist, and then finally the hardware serial number. And then we also provide a catch-all name, which is just the word generic, which will match any server.

So let's take a quick look at generating a setup profile using the server assistant. And then we'll look at how we can examine that file using the plist editor. So could you switch over to this machine please? So here I have the server assistant. I'm going to bring it up. And we'll be working on it with this in sort of an offline mode.

And in order to make this go a little bit quicker and I don't have to type in a lot of stuff, I'm actually going to load in a configuration file I've saved earlier. And in my home directory here, in the admin home directory, I have one called serversettings.plist.

So I'm gonna load that in. So as you can see, you can use Server Assistant to actually edit configurations you've saved before. So it's been brought in and you can see we've already set up certain things. We could actually change this if we wanted to. Oops, gotta be able to type.

Continue on. Here I've already got a server name set up for it, network interface. Here I already have Apple File Service and FTP service enabled, but I'm also going to turn on Mail service. Continue on. We have our time zone. We'll go ahead and have it use a network time server. And at the very end of the interview process, you have a summary page that you can review the settings that you've made. You can see all those here. You can go back, make changes if you like. And then over here you have the ability to save this.

Now you can save it as a text file, which is basically going to be just like this part right here that we were looking at that I was scrolling through. Something that you might be able to print out, put in a file cabinet somewhere. Or you can save it as a configuration file. And this is where you save it into a plist file. And here's your option to save it encrypted if you'd like.

You could also save it to a directory server. So I'm going to go ahead and save this as a configuration file. And I'm going to save it into the admin home directory. I'm going to go ahead and call this server02.apple.com.plist. And it's been saved into the home directory, so let's go take a look at that.

and So here's my home directory and you probably just saw that blink as the file was added to the list here. So we can open this file with our property list editor. And you can see this is just a simple XML file. Let's look at the services that we set to auto start.

As you can see, we have File, FTP, and Mail, which are the settings. Up here, the Admin User. I had, I changed it to Snidely, Snidely Whiplash. So that's it in a nutshell. And at this time, I'm going to turn the podium over to Rusty Tucker, who's going to talk to you about Windows compatibility. Thank you.

Thanks, Scott. Even before we started, you guys were booing my demo, so we might as well bring up number four here and get it out of our system. What is there not to love about an operating system that demands you give it the three-finger salute just to log in? So if we go back to the slides, but seriously, we've got a lot of neat things in Mac OS X Server that help you integrate into existing Windows networks and support Windows networks.

So where we are today, the Jaguar server provides basically a standalone server for Windows clients. That's all based on Samba 2.2X. Provides good, very robust and high performance SMB file and print services. But that comes with a number of functional limitations in how people would like to deploy it. We don't have a way to change password. You can't provide domain logins. You can't host Windows Home directories. And we have no way of taking the client or the server to fit into an existing active directory network, for example.

So the first thing we'll talk about is fitting into Active Directory networks. Both the client and the server can do this with the Active Directory plugin. Provides proxied authentication, UID and GID mapping back to the Active Directory directory. And you can come and see the directory services session tomorrow for some more information about that. But there's one thing that's really missing here in this scenario, and That's it, you still have Windows NT servers on this network. So what we'd like to do in Panther is provide a way to replace those Windows servers on the network.

And so the Panther server can be configured as a primary domain controller. And what that means is that it provides directory and authentication services to the Windows clients on the network. And that lets you support Windows home directories and single sign-on. So Windows user, they log into the login window that we saw in XP, provide their name and password once, and to any services in the domain, they will not need to provide that name and password again.

It also supports the roaming profile so that the settings follow the user when they log in from machine to machine. And we can provide unified management using the server admin and the workgroup manager administration tools. So what is a Windows Network login? What are the components of that? First of all, when you log in, it comes and downloads the roaming profile from the network. And this is all the settings for the user, including their desktop picture, settings for Internet Explorer, and so on. It's really, in the Mac OS X world, it's similar to what you find in the Twiddle public, or Twiddle library, all the preferences in there.

The second thing is the home directory mount, and that contains shared items, and it's really analogous to our Twiddle public. It's a way for you to share files and things with other users on the network. And you can also define a startup script, which can be used to mount other SharePoints or run applications every time that you log in.

And we've chosen Samba 3 in order to implement this in Panther Server. We chose Samba 3 because it provides Unicode support on the wire. This is supported by all the modern Windows clients. And it also provides a plug-in architecture, not only for the user accounts, but also for us to get directory information back. And lastly, we've added to this a way to support our just-in-time home directory creation and setting quotas, as we do in AFP.

And so we'll take a brief look at how we've actually implemented this and how the block diagram sets up. We've got Samba 3.0 as a starting point. By default, it wants to integrate with local private databases, especially Samba 2.2 did this, and even Windows NT servers do this with the Windows Registry and their SAM database. In our architecture and environment, we want to switch that out and set it up to work with Open Directory. And we're working with the password server and LDAP server on the back end.

And the plugins for Asamba are going to allow us to do this. First of all, we've got the Auth plugin. The plugin is actually called AuthOpenDirectory, provides authentication services to the clients. And that hooks us up to the LDAP server on the back, or not to the LDAP server, but to the password server, where we can get LANMAN and NT hash authentications for the Windows clients.

Second directory plugin through the directory plugin API is called the PDB Open Directory, and that supports all the getting and setting of user attributes, and that's basically talking to the LDAP service on the back end. So once we've got that all hooked up, now you can use our administration tools, click, such as Workgroup Manager to actually create Windows user accounts, set their passwords, set password policy, and so on.

And lastly is integration into the server itself. As you've seen with the server assistant setup, we want to provide a way for servers to be able to configure themselves. And a way to do this with clients is to provide just-in-time setup for the home directories and also to set quotas like AFP Server does. And this is provided through the root-per-exec configuration and some scripts and tools that we've written.

and source code for all this available from the Darwin site, including our plugins. You've heard before there's tight integration between the Windows users and the Mac users in the directory, and it's actually the same user account, same user password. We've extended the user record to provide the attributes that are required by Windows users, and they're distinct from Mac users, so there's no overlap there.

The drive letter for mounting the home directory, UNC address of the SharePoint where their home directory is going to come from, the login script path, and the path to the roaming profiles. And the computers themselves need to authenticate before they join the network, and so we've had to extend the computer record to support that as well. So now we'll look at a demo and back to demo three.

First thing we'll take a look at is how you actually set up a PDC. And you'll notice that whenever we're looking at setting up Windows, whether it's Windows computers, Windows users, or Windows, the service itself, we'll have the Windows label on all those items. And like with all the other services, we've got an overview, logs, connections, graphs that shows connected users, and of course, settings.

And so what's new here is that we have added additional roles for each one of the, for the service. It can be the standalone server that we had with Jaguar. It can be a domain member. So it can be not the server that's providing domain controller services to the network, but just be a server that's providing sharing services or supporting Windows home directories, or primary domain controller. And here you'll set the domain name and the computer name. Whenever we do that, when you set it up to primary domain control, it also enables WINS service to enable the Windows Internet Naming service on the network, which is really important for that.

We'll go to Workgroup Manager next. You can see we've got two users, Admin and Bill. Bill will be our Windows user. It's a very complicated user. Everything that we're going to see basically is the same as what a Mac OS X user would have. Password type, open directory, you can define groups that they have memberships in, home directory, they've got a SharePoint called users, mail, print services, and then the Windows panel.

And this is where you define the profile path, the login script, the location of where the hard drive, the mount point for the user SharePoint. So now that we've got that, now we can actually log in to this Windows computer if we want to bring up Demo 4.

And here we choose the domain that we're going to log into. In this case, it recognizes the in-depth domain that we've defined on the server. Type of password, it logs in, downloads the user settings, and then comes up with the familiar Windows desktop. Where we can go to my computer and actually see the mount point.

You can see it actually populates it with the Mac OS X directory, the home directory style for Mac OS X users. So they get the movies directory, library, public pictures, everything. So this same user can also log in on Mac OS X machines on this network. And we'll go ahead and do that. We gotta log him out. First of all, he wants to save the settings back to the server. Now that that's done, we come back to demo three.

This user has done his forward migration and is now a Mac OS X user. and you see the same home directory. So that's that.

So next up, Greg Vaughan will bring us a little information about developing for Mac OS X Server. Hello, I'm Greg Vaughan. Yeah, as he said, I'm going to talk about developing for Mac OS X Server, so I guess all you sysadmins can sort of tune out now. So the first thing I want to talk about is XServe. XServe is the primary platform for Mac OS X Server. Because of that, you need to be aware that any applications you write for X Server are likely to be running on a system that's got no keyboard, no monitor, no logged in user.

This sort of environment limits the frameworks and APIs you can use in Mac OS X. Obviously, you're going to want to avoid the GUI APIs, AppKit, HIToolbox. You need to be careful about APIs that might want to bring up dialogues, you know, like logging in, mounting network volumes, you need to bring up an authentication dialogue. There's a lot of APIs that are perfectly fine to use in this environment. Core Services is an umbrella framework. It has a few, including Carbon Core. which is the lower levels of the Carbon API.

Foundations available. If you want to write a Cocoa app, you can write a server in Cocoa. Foundation has a lot of server-safe APIs. If you've got a C or C++ server, but you want to have some Mac OS X functionality like reading preferences out of a P list, Core Foundation has a lot of useful APIs callable from C.

So if you want to provide a user interface to your application, you're going to need to separate out that user interface from your core service. You've seen examples of this. Basically, our server admin product and our server assistant, both are implemented this way. Your GUI part's going to need to be able to run on a remote machine, so you're going to need to have a way of targeting what server you're talking to. Basically, you can type in an IP address, but Rendezvous provides a really nice mechanism for browsing and locating servers.

You're going to need to provide a networking connection between your two halves. If you've got administration data, often you want that to be an encrypted connection, but you don't necessarily need to write the networking software yourself. Our various services, we've employed a variety of techniques. Server admin uses HTTP over SSL and talks to an Apache web server on the back end. The sharing portion of workgroup manager actually uses open directory and open directory proxy to stuff values into the directory on the server that the service then reads out.

That's more of a one-way communication. And server assistant actually packages its functionality as a set of command line tools and then invokes those tools remotely using SSH. Finally, you're going to need a separate installer for the GUI portion so it can be installed on your admin client machine.

Next thing I'd like to talk about is a bit about performance. I'm going to pass on a few things we've learned when we were optimizing the performance of our own services. One of the things we've looked a lot at is the reducing the system calls in servers. Even system calls that would normally be quite fast, you need to be aware in a server environment on a loaded server, calls into the kernel can cause contention between various threads and processes. The contention will cause lots of extra process flipping, which will result in wasted CPU time. For instance, when we were looking at Samba 3, we decided to make a couple changes.

We changed the read and write calls to pread and pwrite because it avoids the extra LSEEK. And we also, Samba implemented some locking using F control calls, and in this case, spin locks seemed to be fine. We switched to that. And these two changes alone resulted in a new system. noticeable increase in performance.

We also in Samba decided to change the, for networking I/O, the read and write calls to receive and send. Read and write need to go through the file system code to look at the file descriptor to decide that it actually is a socket descriptor. Whereas receive and send can call directly into the network code, and that avoids some locking as well.

In AFP, we not only used Receive, but because AFP reads in a header and then knows how much data it wants to read in its packet, it actually uses the message weight all on Receive. Normally, Receive will wake up each time some data comes in, and if the process is just going to look at it and go back to sleep again waiting for the rest of the data, again, that's wasted CPU time.

Another thing we did in AFP was we decided to switch to memory mapped I.O. for reads because that way when you're actually doing the reading, you bypass the file system and go to the lower level VM system, which also can avoid some contention and improve performance. You do need to be a bit careful of memory mapped I.O.

because the VM system isn't going to be able to return errors. If you've got a sort of a drive that can go away, like a network mounted drive, it can be difficult to deal with that situation. So you want to avoid it for drives that perhaps can disappear, you know, unexpectedly.

Last thing I just want to say is if you're developing a server and you're looking at performance, it's important not to just look at the service itself, but its impact on the performance of the whole system. If the one service slows down the rest of the system, people are writing several servers on the same X Server, obviously it's not going to be popular if the entire system gets slowed down.

So the twin to performance is scalability. Basically, the main message is when you're developing your server, you need to look to the future, look to expanded requirements. We all know computers are getting more powerful, networks are getting bigger. If you have to re-implement your server next year for some new requirements, that's a lot of extra work.

So you just want to keep that in mind as you're designing things. Hard drives are certainly an example of this. XServe ships with XServe RAID. It can support two and a half terabytes. You need to be aware of the large files and large numbers of files you might need to deal with on the file system.

In addition, with directory systems, there can be large numbers of users in the directory system. We actually had to revisit some of our design decisions in Workgroup Manager, and we dealt with things like the LA school system, which put practically every child in the LA area into one large database. You're not going to be able to do things like enumerate through all the users, and so if you've got a UI for picking users, you need to be able to deal with that and do perhaps directed searches and choosing of users.

You also want to be aware of the large number of connected users you can have. As servers become more powerful, people are going to use them to serve more and more client machines. So you need to just keep in mind that the number of users that may connect to your service will increase over time.

At the same time, you need to allow for the variety of connection types. Even if you're developing a server that's intended to be used in a corporate workgroup environment, you're going to have users connecting over airport, users connecting from home using DSL and VPN, and these sorts of connections have a very high latency.

So even if you have an operation that's very fast when you're on the LAN, there's a large number of network round trips. For this type of environment, it can become extremely slow. So it's important to look at the actual network traffic and test for these types of connections.

Then the last little section, I just wanted to talk about a couple APIs that are available. Open Directory is certainly something we continue to push. It's a nice way to connect to a large number of directory systems. There's a flexible API. There's a plug-in architecture, so it can be expanded to talk to new proprietary systems. There's a session on this tomorrow you're certainly encouraged to go to.

Single sign-on is a big push in Panther, and it's going to become even more important in the future. So definitely, if you're doing a service, you need to look at supporting Kerberos authentication in both the client and the server. Hopefully, single sign-on will become very prevalent. People will get very used to connecting to network resources without having to authenticate. So if one service continues to pop up an authentication dialogue, people are going to become annoyed.

I just wanted to point out, it was mentioned in the server overview session that we've switched to an open source mail solution. Because of that, they're provided APIs for spam and virus filtering that weren't available in Jaguar, so that can be new opportunities to look at. Finally, if you're developing a media-related application, you might be interested in the QuickTime streaming server session tomorrow. It, again, has a plug-in API as well as being fully open source.

So that's the end of my little brief section. And basically, here are people to contact. I hadn't seen this slide before. And here's some of the sessions I just mentioned. In addition, the X Server feedback session is immediately following this one in North Beach. So if we run out of time for Q&A here, you're welcome to go and bug us there. All right, and this is just some open source pointers. And if you remember something later in terms of feedback, here's a page you can go to and harass us even after we're gone.