Volume Number: 19 (2003)
Issue Number: 4
Column Tag: Mac OS X
by John C. Welch
Writing a review of an operating system from the network administrator's point of view is always a bit odd. Especially when that operating system is Mac OS X. For one thing, most of the features in Mac OS X that other reviews center on don't really matter here. Aqua, haxies, and other user gadgets aren't that important. Rather, the deep esoteric parts of the OS get a rare moment in the limelight. It also means that the review is far more concerned with how Mac OS X plays with other environments than you would normally see. Now, this is not going to be a feature by feature review, but rather an overview of Mac OS X and Mac OS X Server from a network administrator point of view. With that in mind, onward and downward.
Mac OS X is an odd beast of an operating system for network administrators, especially those used to traditional Unix operating systems. There are a number of differences that will trip you up. Configuring Apache, for one. Other things like CGI access and SSL have rather unique configuration issues. Keep in mind that just because you know BSD and/or other flavors of Unix inside and out doesn't mean you have the same level of knowledge in Mac OS X. In other words, don't assume.
Once Mac OS X is set up, it's a great client, but getting there is painful. If you are not running Mac OS X Server, then creating things like groups and aliases is far more onerous a task than it ought to be. The only way is to either use NetInfo Manager, which is still not reliable enough to be completely trustworthy, or use command line utilities, such as niutil, and nicl. If you want to import a group of users, the command line utilities are the only reliable way to do this without Mac OS X Server.
"... is far harder without Mac OS X Server" is a recurring theme when administering Mac OS X. The only way Apple supports running Mac OS X networks is with Mac OS X Server, and as a result, trying to run Mac OS X without Mac OS X Server, while certainly doable, is a lot more tedious than it should be.
One of the big reasons for the tediousness in managing Mac OS X is Netinfo. While it was groundbreaking when it was introduced with NeXTSTEP, it does poorly compared to other directory systems like LDAP, Active Directory, and NDS. It's poorly documented, doesn't integrate will with other tools, and is for all practical purposes a single platform system. NetInfo Manager is, compared to any other directory management application, painful (a directory management tool that doesn't have online help is a bad thing). While NetInfo is certainly not as fragile or obtuse as the Windows Registry, it's not much better. The tools for dealing with NetInfo are (if possible) even worse than those for the Windows Registry.
Even on Mac OS X Server, there is no good tool for managing the directory as a thing. You can manage aspects of the directory, like users, groups, machines, printing, etc., but those are things you use with the directory. The only tool available to manage the directory itself, is NetInfo Manager. Compared to other directory tools, NetInfo Manager is lousy at managing NetInfo Directories and domains. If you are trying to implement and manage LDAP domains under Mac OS X Server, it's even worse. NetInfo was simply neglected for too long, and is too isolated to be as central as it is to an operating system trying to move into the future. Apple needs to put NetInfo in the same coffin as Mac OS 9, and the sooner the better. They need to get a real directory management tool while they're at it, too.
Since we're on the topic of directories and directory integration, we need to touch on what Open Directory actually is and is not. First off, it's not a specific directory type, although it's focused on LDAP. Open Directory is more of an architecture that allows different directory types to plug into the Open Directory structure. Mac OS X ships with a number of Open Directory plugins, including LDAPv2, LDAPv3 (new in Jaguar), and NetInfo. Note that the plugins don't have to be 'directories'. Rendezvous, AppleTalk, SLP, and SMB are also part of the Open Directory container. If you think of Open Directory as a container for pouring different ways to manage Mac OS X on a network, then it gets less confusing. Third parties can also write plugins for the Open Directory architecture. Thursby Systems DAVE 4 is one example.
Figure 1: Directory Access showing Open Directory plugins
As we see in the illustration above, the settings for various Open Directory plugins are configured via the Directory Access application, found in /Applications/Utilities. This brings me to one of the biggest complaints I have with Mac OS X and Mac OS X Server as a network administrator, and that is documentation. While I can easily download gigabytes of information on every development API on the platform, here is the sum total of Directory Access' help on setting up your system to work with Active Directory:
If you want a Mac OS X computer to get administrative data from an Active Directory server, the data must exist on the Active Directory server in the format required by Mac OS X. You may need to add, modify, or reorganize data on the Active Directory server. You must make the necessary modifications by using tools on the Active Directory server.
We all understand that Apple has limited resources compared to some, but for Mac administrators, getting their Windows counterparts to work with them is hard enough; forcing them to tell a Windows administrator that the only way to get the Macs to integrate properly requires schema modifications, or third party products on the Active Directory server is just not going to fly. In the networking world, Apple is the little guy. They need to make the extra effort. The same applies to other directory schemes. While the support for more 'standard' LDAP schemes, such as OpenLDAP and Sun's Directory Server, is better, Apple still needs to make this as simple as selecting the Directory Server type, clicking "Add my machine to this domain", and entering an administrative password.
This is not to say that Open Directory is worthless. Quite the contrary. By including proper support for things like LDAPv3, LDAPv3 over SSL, and support for using Berkeley configuration files across the network, Apple has made Mac OS X's directory services support work on the level that we need it to. The LDAPv3 support in Open Directory is well thought out, and answers most, if not all of the problems with LDAP support in Mac OS X prior to Jaguar. Things like using SSL to encrypt the data flow, using a specific distinguished name and password when connecting to the LDAP server, and being able to set custom mappings (even writing them to the server from the client if need be) all show the hard work that Apple has put into the plumbing of Open Directory. The implementation is still not there yet. A great deal of the benefits of LDAP are lost as soon as they hit NetInfo, and its rather poor implementation.
There's no AppleScript support in Directory Access, or indeed, any of the Mac OS X Server tools from Apple, so you can't automate any of this setup. If you want to set up a hundred new Macs, there's a lot more manual work than there ought to be. Being able to automate client setup is a critical need for any administrator, and for Mac administrators that means AppleScript. Learning shell should not be necessary to run a Mac.
Since Mac OS X and Mac OS X Server are based on FreeBSD, how do they stack up as Unix operating systems? The answer is both "really good" and "really annoying". For the most part, an experienced Unix administrator will be quite at home with Mac OS X. They will find themselves stumbling a bit as they hit differences, however. User home directories are not where they 'should' be. The default file system isn't UFS. There are no tape drivers, so you can't just use tar, gnutar, dump, etc., to do quick and dirty backups. Dump would have major issue with HFS+ anyway.
There's also no command line toolset that makes doing things via SSH a bit easier than running command after command. One of the best examples of this is SMIT, found on IBM's AIX. It runs in both X11 mode, and command line mode. SMIT is really nothing more than an application that takes input, and uses that input to run various administrative related shell commands. But even over the command line, it gives you a basic menu driven method for getting work done. Thanks to the command line mode, SMIT works quite well over dialup, something that Apple's GUI tools do not do well at all. As Chuck Goolsbee, ListMom for the Mac-Mgrs list says, "SMIT Rocks!".
Apple has done a much better job of making sure there are command line versions of the GUI utilities in Jaguar, especially for things like remote setup, remote network setup, software update, remote installations, and others. This was a critical issue for many administrators, as there was simply no way to migrate to Mac OS X if the only way to do things was via a GUI. (Of course, prior to Jaguar, you couldn't use Mac OS X Server to manage Mac OS X boxes, so that was a problem that Jaguar alleviated.) We all understand that to most users, the command line is anathema,. Even some Mac administrators have opined that Apple shouldn't have released Mac OS X without a GUI equivalent for every single command line utility. This is just ridiculous. While the command line should never be a requirement for users, administrators fall under different rules. For administrators, the command line is a force multiplier that they have needed for quite some time.
While Mac OS X currently doesn't ship with an X11 implementation, the recent release of the X11 preview at Macworld Expo shows that Apple is taking this environment seriously. No, X11 is not Aqua, nor is it as easy to use as Aqua. It is, however, a standard GUI environment available for every Unix in use, and thanks to things like GNOME, and KDE, X11 is getting close to being as easy to use as Aqua. In addition, there are a number of critical applications like MatLab and IDL that will probably never show up as full Aqua applications, but rather as X11 applications. Other Unix applications, such as Open Office, are likely to show up first as X11 applications, with Aqua versions coming later. With that in mind, it is far more intelligent for Apple to have an X11 implementation that is easy to use, configure, and integrates properly with elements like Aqua. We would like to see Apple take this even further, and integrate X11 into Mac OS X to the extent that there is no difference, to the user, between an X11 application and a 'true' Mac OS X application. If Apple can get X11 to a 'double click and go' state, then they will have answered a huge complaint from the Unix world.
This area of OS X has probably seen more improvement under Jaguar than almost any other area of the OS. With Jaguar Server, Apple finally shipped a server that had the tools to properly administer Mac OS X. While there has been a great deal of public comment about Quark slowing Mac OS X adoption, the lack of tools to run Mac OS X networks prior to Jaguar Server hurt that adoption rate in places with multiple Macs as much, if not more than any one application.
Again, while Apple provides you with solid GUI tools to run your server and your network, they are marred by the same stumbling blocks that crop up all over Mac OS X. For example, you can use Kerberos to authenticate clients connecting via FTP and AFP, but not SMB or NFS. There is one click support for AppleTalk over SSH, but nothing else, even though FTP and NFS both benefit greatly from additional security. Apple's GUI tools for Windows file sharing are so limited that you should essentially ignore them, and use SWAT, an open source, web based Samba configuration tool instead. Even with SWAT, Apple's modifications to Samba are still hit and a miss. They hit by integrating Samba and Open Directory, but miss by making it painful, and in some cases impossible, to use the more interesting features of Samba, like its ability to be a Windows NT 4 Primary Domain Controller. Once again, it's that last 20% of the effort that makes a product great, instead of merely adequate.
Apple's provided mail server, while much improved over earlier versions, is still frustrating when you compare it to other products such as Communigate Pro. There are no easy ways to enable functions like IMAP or POP over SSL in the UI. On the other hand, enabling Kerberos authentication is a single checkbox away. Of course, setting up Mac OS X Server as a KDC, heck setting up Kerberos servers in general is not easy.
Apple's implementation of Apache is the same mix of ease of setup, and frustration at the hands of odd implementations. Setting up CGI access for user sites on a Mac OS X Server box is more work than it should be, and completely different than almost every other Unix platform. But then again, you find that setting up SSL is as easy as can be, although SSL access is a less common need than CGI access. You can enable WebDAV for the server as a whole, but you have to then enable it individually for each site. It is not clear that you have to do so, an issue that bites Unix administrators a lot, especially if Mac OS X Server is the 'new' OS for them.
This occurs across the board for many of Apple's tools. Firewall setup is easy, yet Apple just throws it's hands up at DNS, only allowing you to turn DNS on and off from the GUI tools. The rest has to be done via config files and the command line. Considering that Apple's server tools will not work, or work very badly if DNS isn't set up correctly, this service should have a far more comprehensive set of tools. Certainly more than just an on/off switch. Apple's server monitoring and status tools give you an excellent display of hardware and service conditions, but the only effective tools to kill a runaway process are ssh, top, and kill from the command line if you aren't at the system console.
Mac OS X and Mac OS X Server are still in fairly early stages of development, and that needs be taken into consideration when reading the negative comments above. On the whole, they are both excellent tools for administrators. However, the continuous stream of stumbling blocks thrown in an administrator's path makes that excellence hard to see at times. What needs to be done is a matter of focusing. Apple needs to start making each minor update a chance to focus on one set of problems, fix them, and move on to the next. Each update is still trying to do too much at once. As a result, you end up with minor improvements and glaring omissions (like the XServe drive bay door problem, still not fixed as of Mac OS X 10.2.3). Administrators would be better served by an update that only deals with Apache issues, or Samba issues than by one that fixes one or two issues each from a half dozen categories. The administration tools need to be taken to that next step as well. Windows file sharing and DNS administration tools lack of functionality must be fixed and soon. The lack of a good directory administration tool needs to be remedied as close to yesterday as possible. Finally, NetInfo needs to go away. It was a great product in its day, but the fact that it was neglected for so long, and the practical limitations of NetInfo on Mac OS X are two problems that are not going away, and are not worth fixing, when you have LDAP being used globally, and continually improved.
So, from the administrators viewpoint, Mac OS X is about 80% of the way to being a truly first class client and server operating system. Once that work is done, then Mac OS X will truly be the superior OS that it strives to be.
John Welch <jwelch@mit.edu> is an IT consultant for MIT Central IS, and the Chief Know-It-All for TackyShirt. He has over fifteen years of experience at making computers work. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing that the Mac is the superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.
