Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2001-301
$eventId
ID of event: wwdc2001
$eventContentId
ID of session without event part: 301
$eventShortId
Shortened ID of event: wwdc01
$year
Year of session: 2001
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC01 • Session 301

Mac OS X Server

Networking and Security • 52:09

This session covers essential server features such as Directory, Web, File, Print, Mail, Macintosh Manager, NetBoot, and Network services. Learn how to integrate your applications with Mac OS X Server.

Speakers: Eric Zelenka, Greg Burns, Rusty Tucker, Rob Neville, Greg Vaughan

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

My name is Tom Weier. I'm the Network and Communications Technology Manager in Developer Relations. And I have the privilege of introducing Session 301, Mac OS X Server Overview. As many of you have heard from the keynote yesterday and some of the other sessions, we've got a new X Server. And to talk about that, I'm going to invite up Eric Zelenkia, Product Marketing Manager for Mac OS X Server.

[Transcript missing]

So today we're going to be discussing a little bit, we're going to be updating you on Mac OS X Server. You'll hear a little bit more about the details and the features of Mac OS X Server. We'll give you an update as to the technologies that are included in Mac OS X Server.

And we'll also discuss some developer opportunities that are afforded to you by developing products and solutions for Mac OS X Server. So specifically, we'll educate you on what is Mac OS X Server, how Mac OS X Server relates to Mac OS X. Again, the developer opportunities and then we'll point you to some additional sessions, some breakout sessions where you can learn more about developing for specific technologies.

So our server strategy at Apple is simple. Our goal is to deliver innovative, scalable solutions that are built upon internet and industry standards. We want our server platform to be the premier platform for high performance networking, whether that's workgroup or internet server solutions. Our servers should be very easy to use. They should be easy to manage and administer. They should offer a full range of services. They should be able to integrate easily into existing networks and existing infrastructures. And again, they should embrace and support open standards.

So what is Mac OS X Server? Avi introduced it yesterday in his presentation. But Mac OS X Server is really a combination of a couple things. Mac OS X Server builds upon the innovation and the power of Unix and everything that we delivered with Mac OS X. Mac OS X Server also includes a suite of internet and networking services. includes a lot of open source solutions and includes a similar interface to our Apple Share IP product. So it's very easy to use, very comfortable. A teacher or work group administrator can easily adopt Mac OS X Server and learn it without a lot of technical knowledge.

So Mac OS X Server again, it builds upon the industrial strength server platform that we have in Mac OS X, and Darwin, and a lot of the open source solutions that are out there on the network, on the internet. It integrates a lot of server solutions for file and print, we'll go into more of these later, internet and web, networking and security, desktop management, and directory services. And again, Mac OS X Server offers a superior ease of use with its secure remote administration interface.

So this is basically the architecture of Mac OS X, Mac OS X Server. Mac OS X Server again sits on top of Mac OS X. It supports the Directory services architecture. And you can see that the services that we provide are layered on top of the Directory services. So all of the services, whether it's our file services or networking services or desktop management solutions, all support Directory services. And then on top of that, we provide the nice, clean, easy to use, elegant interface for remote administration.

So how does Mac OS X Server differ from Mac OS X? Well, they're very similar in some ways. They're both based upon the great Darwin Operating System Foundation. They both feature the reliable, high-performance BSD networking stack and tools. And they both feature the Aqua user interface. They differ in that Mac OS X Server is a server platform. It's not the operating system. Mac OS X is the operating system.

This is our server platform. It builds upon Mac OS X. Mac OS X Server also features a full range of services for, we discussed earlier, like file sharing and networking solutions. We have integrated remote administration, management, and logging. So a server should produce reports. It should allow you to remotely administer it.

Mac OS X Server also features a series of fault tolerance systems to recover from failures if one of the services crashes it will automatically restart it. We have some hardware integration there as well. Mac OS X Server also builds upon some additional open source solutions which are not included in Mac OS X. And also some Apple design solutions like Macintosh Manager 2 and NetBoot 2. And again, Mac OS X Server is a complete solution. Out of the box, everything that you need to set up your server to integrate your clients on your network is provided in Mac OS X Server.

So now I'd like to invite up Greg Burns. He's the director of Internet Server Software. And he'll go into more about Mac OS X Server Platform and the services it provides. Greg? Thanks Eric. Let's talk more about Mac OS X Server and some of the technologies that we provide and that we've delivered in Mac OS X Server with the new release.

Eric's provided a good overview of Mac OS X Server, but I want to talk in a bit more detail about some of the things you should know. And then towards the end of the presentation in a few areas, we're going to go into some more depth in particular areas that you as developers should know about developing for Mac OS X Server.

[Transcript missing]

So in addition to all this scalability and performance benefits, another thing that's new with Mac OS X Server with the new release is that we can take full advantage of symmetric multiprocessing. This is something that, unlike Apple Share IP in the past, we're now fully able to take advantage of the multiprocessor hardware that we deliver in the server product for great performance. And as Eric mentioned, we've added fault tolerance systems as well. So we have a few things that we've added to the server product.

One is a watchdog process that will look over the services that are running and make sure they continue to stay running. And if one should quit unexpectedly, it will start it up again and make sure the services stay online. Another is a combination of hardware and software that basically will monitor the overall system and make sure that it's alive.

And if the system should hang for some unexpected reason, it will restart it. So even if your server is located 20 miles away in a remote office and it goes down in the middle of the night, you don't have to worry because it will continue to hang. will automatically restart itself and stay running and stay online.

So now let's go into some of the services and the capabilities that are provided in Mac OS X Server. So key to Mac OS X Server is the Directory Services layer that is used by all the services in Mac OS X Server. Okay, so Directory Services provides basically an integrated set of services, an API, and a back-end database that can be used to share information about users and resources on the network. So client applications on the desktop and server applications can use the API to access directory information. And in addition, we provide the back-end database in the form of NetInfo, a distributed replicated directory server.

This is utilized by all the services in Mac OS X Server. So whether it's File, Web, Print, Mail, all of them access the network directory information and access the shared accounts. And in addition, we realize that there are people that have existing directory infrastructures. Uh, primarily using LDAP that are going to want to be able to integrate Mac OS X Server into those environments. So in the directory, we've provided LDAP support to allow Mac OS X Server to integrate into these environments.

So if you have an iPlanet LDAP server or a Windows Active Directory server, you can take a Mac OS X Server and basically deploy it in that environment. And any service that you have up and running will be, have access to new user accounts that are added into these servers as soon as they're added. So it's fully dynamic. and fully integrated.

So, basically this picture shows you how it's all put together. In the green there in the middle you have the API which is the key piece that anybody writing an application needs to be aware of. That's available on both the client and the server and that allows you to access the directory. So, you see the Apple software there, our Mac OS X services that take advantage of the directory through this API as well as developer software that can use it as well.

In order to access the various directories, you have the choice of going through the existing directories that we provide plug-ins for, NetInfo and LDAP. Or as a developer you can write your own plug-in for an existing directory. And other people as well, IT organizations can do this as well for proprietary directories.

So to summarize, the API is included with every Mac OS X product, desktop, and server. Allows access to any directory. The APIs provide a central point to access network resources in the directory, and also to authenticate user accounts to the directory. It's extensible, so new directory support can be added via the plugin architecture. And we've added NetInfo and LDAP support included in the core server OS.

Okay, looking at our menu of services here that are provided in Mac OS X Server, the first is file and print services. And obviously these are very important in the education and graphics markets, very highly used in the LAN environment. And in addition to all the reliability things that we talked about that we've improved in Mac OS X Server, we've also focused a lot on performance. So we have a truly high performance solution here that we're delivering. We've been doing benchmarks against Windows 2000, and we've found that this is Mac OS X Server is truly the fastest server for both Mac OS and Windows clients. And so we're really happy about that. Another thing.

Thanks. Another thing that's important is that we need to be able to support all clients. So we've added support for, obviously, we had AFP and Windows support in Apple Share IP. We've added NFS as well with Mac OS X Servers and Unix underpinnings. And, of course, FTP. So no matter what client you're coming from, you're fully able to access the server.

And, of course, with AFP, we've enhanced that with AFP 3.0 to take full advantage of the new Mac OS X file system layout. So things like Unicode file names, long file names, privileges have all been enhanced in AFP 3.0. In addition, all these file services can use both HFS Plus and UFS. So unlike a previous release of Mac OS X Server, you truly are independent of the underlying file system storage. And, finally, our Windows support.

It comes from Samba, which I'm sure many of you are familiar with. And in addition to adding Samba into the product itself, we've made sure that it's really well integrated with Mac OS X Server. So in terms of integrating with the Unicode file system layout of Mac OS X and the directory APIs, as well as the management utilities, we've made sure that that all fits together well and provides a truly integrated and easy-to-manage set of file services. On the print side, we support Windows and Mac printing, and that integrates into the Mac OS X printing environment for PostScript printers.

And this picture kind of gives you an idea of how all of this fits together and makes it really easy to set up and manage. All of the configuration for shared directories and privileges is shared by all of the file services. They all can access the underlying file services whether it be UFS or HFS Plus. And they all use the directory services to access the account information in our shared directory.

Moving on to Internet services is obviously another key part of server environment to be able to do comprehensive web hosting and Mac OS X Server provides a great deal of support here. In addition to the basic web services, we also have a mail server product that we provide as well as in Mac OS X Server. We have media streaming with the QuickTime streaming server and we have an application server environment with the WebObjects 5 deployment.

The Mail Server is a server that has been brought over and improved from Apple Share IP. We've removed some of the limitations that existed in the Apple Share IP products such as improving the ability of the database to scale, increased the size limitations there. We've continued to maintain some of the key features though like the high performance message store and the fact that it's fully integrated with the Directory.

The IMAP administration port makes it easy to access the database locally or remotely from IMAP through the protocol or from any IMAP client. One of the key things we wanted to improve in the Mail Server for X is to really make it more flexible. The Mail Server is really easy to set up, it's really easy to use, it's fully integrated, but with that integration came some inability to modify it and so we wanted to improve on that. And so what we've done with X is we've allowed you to use it the way it exists with the integration.

We've allowed you to use the integrated SMTP router, but we've also allowed people to set it up so that you can use a send mail as your back end SMTP router. And so that allows people that really want to customize the server or if developers want to add additional capabilities on top of the Mail Server platform, they're able to do that through send mail. And so we've really increased the flexibility in the Mail Server with Mac OS X.

Another product on the internet side is the QuickTime streaming services which provides both support for live media and on demand media of QuickTime being streamed across the internet. You can stream any hinted QuickTime media placed on the server as well as stream live events from a broadcast application by reflecting them through the server.

In addition, you can take servers that are reflecting and basically build up multiple chains of basically servers reflecting the servers to build very large distribution environments for a really truly scalable architecture. It's fully standards based on RTP and RTSP so it's fully compatible with other servers and clients.

And it's fully open source and it runs on a variety of platforms and we're now in our third release and I'll talk about that in a minute. And overall this product has been really popular. We've had over 135,000 downloads now of QuickTime. We've had over 135,000 downloads now of QuickTime streaming server and a huge number of those have been on Mac OS X Server itself.

[Transcript missing]

Of course, a core part of web services is the web server itself and all that goes around it. And I'm sure many of you are familiar or know that we include Apache as the core web server foundation in Mac OS X Server. And so we want to talk a bit more in depth about what we've done with Apache and some of the additional facilities we provide around that. So for that, I'm going to bring up Rusty Tucker from the X Server Engineering Group.

Hi, thanks. We've got a really interesting story to tell around Apache and Mac OS X Server. I think it's really good news for third party developers and there's a lot of new opportunities there. This could be a short story, I guess. As a developer, when I first took a look at Mac OS X Server, it's really unique because you've got the best graphic interface, the ease of use that Macintosh has always had, and Unix under the hood. And those combine to make this a really unique web server development environment.

So of course we started off with Apache and it comes with impressive qualifications. Millions of sites served, a very large and active development community. It's very stable and very secure. And it's important to know that the version of Apache that we ship on Mac OS X Server is very standard. But we've added to it some of the best and most sought after tools from the open source community including PHP, MySQL, ModPearl, and Tomcat.

[Transcript missing]

Apache is typically really all about being the most flexible web server and it hasn't always been known as the speediest web server. And so we've tried to improve that by adding speed to the flexibility with the front end performance cache. In addition, we've added configuration for secure sockets layer and configuring Apache to be utilized as a caching proxy.

When we talk about Mac OS X Server as a great web application development platform, what really stands out is WebObjects, which is a consistent award winner in a deep and rich environment in its own right. You'll be hearing a lot about that in different sessions here this week and also more in this presentation.

We've also included MySQL, which is a multi-user structured query language database. Most interesting dynamic web applications require an SQL backend and now you've got one in Mac OS X Server. PHP provides portable scripting language for Apache and it's highly integrated with MySQL. Pearl is really great at text manipulation and also provides database access. And Tomcat provides Java serverlets and Java server pages so that you can use the Java programming language to extend Apache with greater performance and CGI.

More on the applications to Mac OS X Server and the Web Server. We've integrated Apple Technologies, Sherlock for full text searching of your website, Directory Services so you can take advantage of the Directory Services architecture and provide a great way to authenticate and control access. So you don't need to muck around with HD access files or roll your own access control using a database backend. It's taken care of automatically and integrated through Directory Services.

To ease the transition from Mac OS 9, we've included legacy support for Mac OS ACGIs including those running under Classic. Of course, you want to move to a native technology to take advantage of the performance and reliability that X Server provides. And we've also included a custom Mac binary module that allows for the transfer of classic files that include a resource fork.

One area that Mac OS X has broad support for is in the web distributed and authoring versioning protocol known as WebDAV. You'll find it's a set of extensions that allows HTTP to easily manage the content of a website. In OS X Server you can control the use of WebDAV through the user interface.

And you'll also find WebDAV client support in some of the best authoring tools. What's very surprising is that you find WebDAV support built into Mac OS X as a client file system API. So websites can appear on your desktop just like any other remote server volume, which means that Finder, Cocoa Apps, Carbon Apps, and any command line application can access and edit the contents of a website just using standard file system APIs.

As we talked before, Apache is a very popular web server serving 17.9 million sites by one recent count. Apache has achieved this with providing full support of HTTP, reliability, flexibility, as evidenced by the modules and capabilities that we include with Mac OS X Server. We've worked closely with the kernel team to optimize for Apache and the result is really great performance on 100BaseT and Gigabit Ethernet networks.

We thought we could do even better and as a result created the performance cache. The performance cache is tightly integrated with Apache so that Apache is the responsibility for filling the back end of the request. It generates the HTML either from static pages or through its modules or CGI's.

Where the performance cache takes care of the front end of the request and serves from memory the results of that generation. And the results are pretty astounding. We've been able to more than double Apache's performance on Mac OS X Server in static page performance while maintaining all the flexibility and reliability that's built into Apache.

Module and content developers can also take advantage of this front-end performance cache just by adding expiration and cacheability headers to the responses that you normally generate. So if your module is already friendly towards caching proxies on the internet, it will already automatically exploit the advantages of the front-end performance cache.

So to summarize, the Mac OS X Server is a deep and rich development environment for web applications. You can take advantage of the performance cache for higher performance at basically no cost in your development. And it represents a lot of, a number of developer opportunities including the porting of additional Apache modules to Mac OS X or plug-ins for Mac OS 9. Innovations that extend Apache and exploit this unique server operating system. Development of web-based tools that ease the management of Mac OS X Server itself. And of course, killer web applications built with WebObjects, Perl, PHP, or Tomcat. So, I thank you and give you back to Greg.

[Transcript missing]

So that's it for web services. Of course, another key feature of Mac OS X Server and something that really differentiates it from a lot of the other Unix servers that some of the core technology is derived from is the administration capabilities. Of course, we have Mac OS X and Aqua itself obviously provides a very strong and easy to use platform. And we have full Aqua UI for managing all of the key services in Mac OS X.

So again, we have a very easy to use server product. The administration secure can be used. You can manage it remotely or locally, multiple services. The key here is that you have all of the key features of the services that can be managed from this application. And of course, the services like Apache are Apache under the hood.

So if someone needed to, they could go under there and access the Unix services themselves and configure them themselves underneath the hood. But again, you don't need to because all of the administration takes care of this whole thing. So again, we have a very easy to use server product. The administration secure can be used. You can manage it remotely or locally multiple services. The key here is that you have all of the key features of the services that can be managed from this application.

And of course, the services like Apache are Apache under the hood. So if someone needed to, they could go under there and access the Unix services themselves and configure them themselves underneath the hood. But again, you don't need to because all of the administration takes care of this for you. And you can easily do things like setting up complex multi-hosted websites in minutes with the UI and the administration tools.

The last thing about some of the core services in Mac OS X is the network services. If you're setting up a sophisticated networking environment, you may need to take on some additional work for TCP like setting up DNS servers or setting up DHCP servers. And Mac OS X provides a set of networking services that allow you to do this. It's fully standards-based, so all of the relevant standards, DHCP, BootB, DNS, SLP, are all supported by Mac OS X Server.

We have DHCP which provides support for dynamic TCP address management and can also be used to set up NetBoot clients included in Mac OS X Server. Mac OS X itself includes a technology like Mac OS 9 did called SLP that allows you to dynamically register resources on the network. It is TCP's equivalent of name registration like NBP for those of you that are familiar with AppleTalk.

And it really allows plug and play of resources and services on the TCP network like AppleTalk but without all the chattiness of AppleTalk. And the basic registration and lookup is included in the clients. But what Mac OS X Server adds is a more sophisticated server and administration capability that allows you to set up scopes which are sort of like zones in AppleTalk to really manage a network, an SLP network for a large number of clients.

And of course those of you that want to do DNS, there's a DNS server in there as well and we'll be adding more sophisticated UI to that in the future. the Unix underpinnings as well. We have the Unix networking stack and the IP filtering that goes with that for firewall protection.

So that sort of covers the core foundation services in Mac OS X Server. The next area, of course, that's key to a lot of our customers is the desktop management that includes Macintosh Manager and Netboot. And for that, I'm going to bring up Rob Neville, who's going to talk to you more about desktop management in Mac OS X Server.

Hi, I'm here today to talk to you about desktop management with Mac OS X Server software. Desktop management comes in basically Two different flavors with Mac OS X Server. You have your basic Mac Manager which is a server, the server controls your client software in a variety of different environments. However, we also have Netboot and we're releasing a Netboot 2.0 server in this release which enhances and increases the performance and the capabilities of Netboot.

For Mac Manager, basically what we wanted to do is we have a certain set of goals. We wanted to make a simple administration experience. We wanted to work in an integrated environment with industry standards. And we wanted to allow you to administer the server for Mac OS X and Mac OS 9.

We wanted to make sure that as we move Macintosh Manager forward that we maintain compatibility with the thousands of Mac Manager clients that are out there. And we wanted to make the experience that Macintosh Manager users have More integrated into the Mac OS X Server environment so that what we're doing is we're no longer using a separate users and groups environment.

[Transcript missing]

What does that mean? Well, you have a single username and a single password for all of your services. The users use the same Users and Groups database. Because the Users and Groups database can access Directory services and accesses Directory services on Mac OS X Server, that also means that you can store your Users and Groups data not necessarily on the Mac OS X Server. They can be back-ended on an LDAP server or an Active Directory server.

This is the place where your Macintosh user will have his home directories. And the experience will be very similar to what you get under Mac OS X with their user home directories. Our admin for Macintosh Manager is in Carbon. That means that you can run it on a Macintosh The client support runs from Macintosh operating system 8.1 to 9.x. This version also contains Kerberos support. And the last item is we're planning to do a technical article in the coming weeks hopefully to discuss what you would do to have your applications fit inside a Macintosh Manager environment.

This is basically the Macintosh Manager architecture. Macintosh Manager server sits on the same machine as your Apple Share server, your Mac OS X Apple Share server, which both sit on top of Directory services, as I discussed. Your user profiles are stored through Directory services. Your users and groups database can be stored locally on the Mac OS X Server or they can be stored remotely since they're accessed through Directory services. And your clients sit out on the network wherever they will as does your administration.

Netboot. We've made a few changes to Netboot. We wanted to simplify the workgroup administration. We wanted to have multiple desktops share the same server hosted boot image. We wanted to be able to protect that image from user modification. And we wanted to make desktop OS upgrades trivial. We work currently with a standard unmodified Mac OS 9 system. and currently we work with Mac OS 9 system only. The boot performance that we've experienced in this server is comparable, believe it or not, to a local disk.

We have some improvements. Some of these are in the product now. We interoperate with standard DHCP servers. In a previous version, you had to have a hard-coded IP address for each individual Mac Netboot client. With the current release of 2.0, the client gets its IP address from DHCP. This allows for you to be able to add a new client dynamically to your Netboot environment.

This also, we've also added some scalability. In the previous release you could have one server per subnet. In the current release you could have multiple servers per subnet. However, since there are two different types of clients, we have a 1.0 compatibility version that's running in this current server. You can only have one 1.0 server per subnet. But if your clients are newer and you can have multiple servers that offer the 2.0 functionality per subnet, you can also talk across routers.

So what do you need to, how does this impact you other than as users of the product? Well you have to assume that the Mac OS that you're going to be talking to or that your users are going to be using is not persistent. And what does that mean? Well that means that the operating system is existing on a hard drive and could go away. Not on a hard drive, excuse me, on the network and could go away.

So this is a brief graphic of the way the server currently is working. Basically what you have is you can have your own existing network. You can plug a Mac OS X Server any place on that network on either side of the router. And your clients can get their DHCP services from that server. They can also NetBoot from that particular server.

And we've built in some load balancing so that if you have a certain number of clients coming in talking to Server A in this particular example, and it's fairly busy serving pages, it'll automatically route over to Server B and/or Server C. Next we're going to have Greg Vaughan talk about developing for Mac OS X Server.

Basically, I've been working doing server development at Apple for like over 12 years. We've talked about a couple developer opportunities here in conjunction with our product. What I'm going to focus on is actually developing writing reporting servers to complement the ones we provide in Mac OS X Server. It's a short presentation. I'm just going to point out a couple things to watch out for and some things in X Server that you can use to take advantage of and customize services.

So, porting Unix servers to X Server, I mean basically it's Unix, shouldn't be any more difficult to port to than any other Unix platform. There are a couple things to watch out for. Probably the biggest thing is the fact that HFS is a case-insensitive file system. Definitely, Unix servers may or may not rely on case sensitivity, but it's something to really watch out for because it can cause really subtle bugs.

When we were reporting Apache over, we had a problem with the security stuff because the URLs you enter in to restrict access, Apache would match case sensitive. And if the user used a different case, Apache would say, "Oh, this is fine. It's for something else." Then the file system would find the file you were trying to restrict.

So basically, that was something we ran into late and had to figure out a way to work around. It's subtle bugs that you really need to watch out for. If you have a server that basically you can't get to work any other way, you can always run it on UFS and get the case sensitivity, but it's not as nice.

Another thing is in /etc files like /etc/password or /etc/fstab, generally you're not supposed to really access those types of things. You're not supposed to really access those directly any way. There are APIs to access them. Definitely on 10, those files are redirected through the APIs to go to NetInfo and other directory services. So you should use the APIs. If you're reporting a Unix server, it's probably already talking to standard Unix APIs. For a server, that's generally a good thing. There are some APIs you can use on 10 that will help you add value. Directory services is certainly one.

The directory services presentation is right after this one, so you might want to stick around for that. Core Foundation provides a lot of different utilities that can be very useful. Things for dealing with Unicode or parsing XML files and stuff like that. And if you want to gain access to the HFS+ information, resource forks, type in creator. Carbon file system stuff is what you want to use.

You do have to be really careful though on 10. A lot of the APIs outside of the core services require a logged in user. And for a server, generally you'd like your service to be able to start at boot time and not have somebody logged in. So certainly want to separate out any UI related things. And you want to watch for APIs that require a user to be logged in on the server.

A couple of random little things. Starting the server. Most things in X Desktop are started through bundles in startup items. Basically it contains a script that starts your server usually based on a parameter in host config. And then there's a P list to determine start order. You can add your stuff to startup items to start a server. On X Server we also provide the watchdog process. This is the thing that provides reliability. I'll talk more about that in a second.

Admin user versus root. Basically servers often will run as root and that's fine. But when you actually log into the machine physically the users are going to log in as an administrator. And Unix won't treat them as root. So you do have to be aware of the things that administrators can and can't do and how they're going to interact with the server running as root.

As far as file system layout, if you've got a Unix server, probably it's going to have files in the normal Unix directories and that's fine. You do need to be aware of, if you have files that you want the user to interact with, log files or config files, since the Unix directories aren't visible from the finder, unless you want the user to have to go into the terminal and use VI, you may want to either move them or one of the things we do is provide a SIM link in a place like /library that points into the normal Unix place for the file to live.

That way user can use, you know, TextEdit and other GUI apps to deal with those files. Directory permissions, again, because the administrator isn't going to be logging in as root. If he's going to write to a file, you need to make sure it lives in a place where the admin users have write access to.

Other services, the Watchdog service we've sort of referred to in the other sessions. It's the thing that provides the reliability of restarting servers. It's got a config file that you can add your own service to that will start it at boot time and if your service crashes it'll get automatically restarted.

It also, you don't really need to directly deal with this but it also will work with the hardware on the system so that the whole servers for some reason, you know, gets hosed. It'll basically restart the whole machine. If you have 10 server installed, it's got a man page that fully describes it so you can just do man watchdog and it'll say how to use the config file.

Servers basically, if it uses crypt authentication, you can continue to use that. If you want to provide other authentication methods, again, Directory services is the way we do that. You can go to the presentation after this and find it. We use that with Samba to provide NT style authentication. And it's also extensible, so you can provide other authentication methods.

As far as development tools, if you have a Unix app that has scripts and make files, it's usually easiest to continue to use those. You can use Project Builder to edit your source code and create a project for that. If you're writing something from scratch, I prefer using the GUI tools. You can always use VI if you like.

If you're writing something that specifically is for X Server versus X Desktop and you want to check to make sure you're running on a X Server system, there is a file, basically, serverversion.plist that only exists on X Server in System Library Core Services. You can just check for the existence of that file.

One final thing is, I want to make a plea. If you're writing a normal desktop app, the most important thing you're usually testing for is functionality. The server app, most important thing is you want the server to be able to run for like months. And so you really need to watch out for things like memory leaks that will affect system performance over time.

There's a couple other sessions you can go to in terms of debugging tools and performance tools. But you really want to pay attention to that when you're debugging your apps. Malloc Debug is an example of a good tool to look for memory leaks. And that's covered in other sessions.

So basically here's some other sessions that you want to go to. I don't obviously have time to really go into detail on this and it's well covered in other sessions. First couple have already happened. The Network Services location if you want to provide browsability for a server is very nice. And the Performance Tools and Debugging Tools are very good sessions. I highly recommend. And also the Directory Services one right after this. And Eric come back up.

Thank you, Greg. So why develop for Mac OS X Server? Well, Mac OS X Server is Apple's server platform for the next generation. Just like Apple is committed to Mac OS X as the future of our operating system, Apple is committed to Mac OS X Server as our future for our server platform. We've designed Mac OS X Server to specifically be a server.

It's not a desktop platform. This is a server platform. And by developing for Mac OS X Server, you can take advantage of that. You can take advantage of some of the server-specific features that we've provided like the fault tolerance systems and the access to some of the other services. And by building for Mac OS X Server, you can take full advantage of Unix and the open source development community and open source projects as whether they're projects that are out on the Internet today or they're code that's Apple's code. kicking back to those open source projects.

So some key developer opportunities for you. Obviously, one of them, which will be discussed more in the session that follows, is Directory services integration. There's a lot of different directory services, plug-ins that could be developed for integration with Kerberos, Native Active Directory, Novell, NIS, NIS+. There's server management and administration opportunities for you as a developer to build web-based management systems or some log analysis or reporting software. Server monitoring, backup and restore. So a lot of different opportunities are available to you.

On the web side, we discussed some of these earlier, but you could build other web interfaces and other applications for the web services. Whether it's taking advantage of the patching module integration that we have, web objects, Java servlets, or even building a database middleware solution. On the hardware side, there's RAID solutions that could be developed or storage arrays, power management systems. And in the design and publishing community, there are professional high-end printing solutions that could be developed and deployed on Mac OS X Server.

So this is more of a roadmap for some of the sessions that will follow. Notice the Directory Services one following here. We will have a session on QuickTime Streaming Server on Wednesday. There's a Mac OS X Server feedback session on Friday. Network service location for registering services on the network. Security in Kerberos on Thursday. And how to take advantage of AFP 3.0 and the Apple Share client. That's in Mac OS X on Thursday as well.

We've got some file system, open source, BSE services, and of course, WebObjects. So if you have any questions about developing for Mac OS X or taking advantage of some of the networking services that we provide in Mac OS X Server, feel free to contact Tom Weier. Hopefully all of you in this room know him right now. There's his email address.