Networking the OS X Public Beta

By John C. Welch

How well does OS X fit into the networked world

Welcome

In our last look at the OS X Public Beta, we did a general overview of the operating system, and looked a little at networking, mostly at the settings in NetInfo Manager. This time, we'll focus almost entirely on how the Public Beta fits in to other networks, and connects to other Operating Systems.

One of the disadvantages to trying to really exercise the networking features of a beta is the lack of documentation. This has long been one of the real problems with being a Mac OS network administrator, lack of Apple documentation. Almost none of my reliable resources for administering Mac OS networks come from Apple. Instead they come from a host of web sites, Developer TechNotes, third-party books, and 16 years of supporting Macs. For OS X, this needs to change. Yes, third parties will always be a supplement to Apple, but I, and my colleagues in the administration field need to be able to get a complete set of documentation to NetInfo, OS X and NFS, etc. from Apple. In Apple's defense, the deal they have struck with FatBrain.com is a step in the right direction, but as of yet, I have only seen developer documentation come out of it, and Apple has always tried to be conscientious here. There needs to be a similar flood of administration and other similar documentation, and it needs to start happening before the full release, so that the day OS X goes into full release, I will have had access to the documentation I need to begin implementing it that day. If I have to wait a month, 2 months, etc. then in addition to that delay, there will be another month or so delay while I familiarize myself with the documentation, and figure out how I can use it to set up Mac OS X for my network. Most of my fellow administrators will probably be doing the same.

Luckily, for now, there is a decent amount of documentation from such sources as the Omnigroup's mailing lists, and various web sites such as MacNN, etc. But that will not be adequate for long, and with OS X, Apple can not rely on the Mac community to make up for a lack of manufacturer - provided documentation. I don't think they will, but a reminder can't hurt.

NetInfo

You cannot talk about networking OS X without delving into NetInfo. In fact, you cannot talk about administering OS X without dealing with NetInfo. So what is NetInfo? Well, according to Apple's Tech Info Library Article 60038:

"NetInfo is a hierarchical distributed database that is used to keep track of administrative data in NeXTSTEP, OpenStep for Mach, and Mac OS X Server. It can store information on user and group accounts, e-mail configurations, NFS (network filesystem), printers, computers and other resources. Since this information is stored in NetInfo these resources are easily configurable, and can easily be shared over in a network environment."

In other words, NetInfo is how a Mac OS X administrator would maintain their OS X - based network, both at the machine level, and at the network level. NetInfo is also a hierarchal domain model, which, at it's simplest, means that you can have one network that binds together many separate and even independent subnetworks, or subdomains into one organized super-network. With this model you can have, theoretically and unlimited number of subdomains in a root, or '/' domain, ('/' is the NetInfo indicator of the root of all domains on a given NetInfo network.) The machine that is running the / domain is the domain controller. An example of this is shown in Figure 1.

As you can see, the / domain, named Computers is the root domain. It has access to all other hosts/computers in that domain. The next levels are subdomains: eng and mktg, or in proper notation /eng and /mktg. These are both network domains, under the control of /, but independent of each other. They also have hosts below them. Each of the hosts in the /eng and /mktg domains is an individual computer, or local domain. This local domain can sometimes cause confusion, but there's a reason for it. In many cases, the permissions for a person on their individual computer may need to be different than their permissions on the network. You may want this person to be able to say, change some personal parameters such as screensaver settings on their local machine, but not for the / domain controller. So by having a separate local domain for each machine, you can differentiate between domain and local permissions. ( The correct NetInfo terminology in our example would be that / is the parent for /eng and /mktg, which are its children. The hosts in those domains are the children of /eng and /mktg, and the grandchildren of /. I don't really like to use this terminology, as it can get unwieldy quickly, so I go with domain and subdomain. Both work.)

Each domain controller, regardless of level has a NetInfo database that has various information for that domain only, such as users, groups, machines in that domain, services running, printers, etc. They also know who the domain controller above them is. However, each of these domain controllers is separate from any other domain controller at the same level. So, while I may have administrative permissions in /eng, I may only be a normal user in /mktg. The / controller supercedes all subdomain controllers, so if I have administrative privileges for the / domain, then I have them in both /eng and /mktg.

This separation of domains is important. This way, a network admin can limit / admin permissions to only those who absolutely need it, and give /eng admin privileges to another person who needs them for that domain, yet not for /mktg. This allows for easier maintenance of the subdomains, by allowing for smaller sizes, without making them so independent as to be uncontrollable. This also allows for easier user maintenance, as then you only need to enter user information in once. This is due to NetInfo being able to replicate needed information to not only the subdomain controllers, but to other computers that act as backup domain controllers. Domain separation also allows for easier management of printers, users, or any other resource that is a part of the domain.

Even on a standalone machine, NetInfo is what is running much of the basic functions of the OS. Things like services, network settings, user settings, etc. If you look at NetInfo Manager, you'll eventually find the results of almost any preference setting you can imagine.

This is also where a lot of confusion regarding NetInfo starts. NetInfo Manager is not designed to be a general use NetInfo editor. In other words, it's a good place to change NetInfo settings, but not such a good place to create them from scratch. Ideally, NetInfo settings are set and changed from other applications, such as the System Preferences control panels for system settings, Multiple Users for users settings, Print Center for printer settings and so on. In other words, it's a somewhat organized warehouse for preferences. The NetInfo Manager allows you to change and set not only individual behaviors, but overall NetInfo domain settings as well. Unfortunately, the name lends itself to thinking 'Oh, this is where I do all my NetInfo work.', and this is not normally the case. There are occasions where you have to do this, but ideally, you, or someone would write an application that collects input from a user in a user friendly manner, and then uploads that information to NetInfo. This is the safe way to do it, and the recommended way.

I finally figured this out when after six months of working with the folks on the Omni  CONTACT _Con-4AFFE0E22 OS X Server Admin list, (an excellent resource by the way, and I highly recommend it to anyone wanting to use the OS X Public Beta in a networked environment. Subscribe at http://www.omnigroup.com/community/mailinglists/), and hunting down links on the web, just why there was no real information on using NetInfo Manager. The reason for this is because you're not supposed to. Even older NeXT documentation talks about getting things done in terms of other applications, not NetInfo Manager. This is good, because it is trying to keep people from mucking about in NetInfo, and really, truly destroying their operating system. As an analogy, doing things in NetInfo manager, without knowing what you are doing and why, is about as hazardous as using ResEdit on your System file without knowing what your are doing and why. It's 'a bad thing'.

AppleShareIP

This is an obvious one to go over, as it should be the easiest and most completely supported networking model in the Public Beta. Should be, but tends not to be. The most obvious situation is the lack of support for 'pure' AppleTalk. This is not as much of a problem as one would think, as in most cases, networks that are 100% AppleTalk only are rare. The other issue is that the Public Beta doesn't use the Name Binding Protocol, or NBP.

NBP is how the Chooser allowed you to see network devices. When you selected AppleShare, and a zone, if any, in the Chooser, your Mac sent out a NBP request to that zone, or network if zones aren't used. Any AppleShare devices that are able to respond correctly to an NBP request send back a reply that contains, among other things like type, and (sometimes) zone, the server name. The server name is what shows up in the Chooser. Since the Public Beta doesn't support NBP, it does not show up in the Chooser. Nor can it see, in the OS X network browser, any NBP - only servers.

Instead of NBP, the Public Beta uses Service Locator Protocol, or SLP to discover network resources. Examples of SLP - enabled servers are AppleShareIP (all file-sharing services), Mac OS 9's TCP/IP file sharing, and ExtremeZ - IP from Group Logic. SLP is an internet standard, and Apple was the company that approached the IETF with the idea of SLP as a way to bring over the ease of use to the TCP/IP world that NBP had given the AppleTalk world. This is not to say that a Public Beta machine is unreachable without SLP, it just isn't browseable. You can still connect to it via the AFP URL mechanism, i.e. afp://thismachinenameorIPaddress, or the server IP address button in the Chooser.

Other changes to the Apple Filing Protocol, (AFP) between versions 3.0, (the Mac OS X version), and AFP version 2.2, introduced in AppleShareIP 5.0 include:

• Support for longer pathnames and pathnames with Unicode characters
• Support for Unix privileges
• The ability to check for Unix privileges on the server
• Checking to see if the server supports directory services
• Larger file sizes and disk drive sizes
• Authentication method queries
• Log in directory name queries
• Mapping Unicode user and group names to user and group Ids
• Reconnections
• Longer attention messages

So even though pure AppleTalk is not supported, OS X is not cut off from AppleShare networks. But if you still have AppleTalk - only networks, or even LocalTalk networks, now is the time to start moving them to a TCP/IP - based network. OpenDoor, at <http://www.opendoor.com> has not only excellent products to help you do this, but excellent information on ways to accomplish this with as little pain as possible. In addition, there is an article in the January, 2000 MacTech, "Fitting the Desktop into a TCP/IP Environment", that describes some real - world adventures, (namely my own), in doing just that.

NIS

NIS, or Network Information Services, is the network management/directory service primarily used in networks based on Sun Microsystems's Solaris operating system. Like NetInfo, NIS can be used to track user information and privileges, host information, and other similar information. Sun has also developed a version of NIS, called NIS+, which allows for data encryption and larger numbers of users and hosts. Sun is pretty much the only user of NIS+, and OS X cannot be used with NIS+, so we deal with NIS.

NIS is directly supported in the Public Beta, and OS X Server as well, although Apple doesn't directly support NIS itself. (translation: NIS should work, the support is there, but if it doesn't, don't call us.) Also, a simply excellent and clearly - written guide to NIS and OS X is available at http://www.bresink.de/osx/nis.html, and goes into step - by step detail on using NIS on the Public Beta, including such things as configuration, troubleshooting, and even automount issues. Configuring NIS is somewhat tricky, and is not for someone who is unfamiliar and uncomfortable with the command line, and NetInfo. As well, the NIS implementation has one rather major error in that it is fairly static. It assumes that you are always going to connect to an NIS network.

This is best shown in the hostconfig file, found in /etc/hostconfig. (Actually, it's in /private/etc/hostconfig. /etc is a link, or alias, to /private/etc.) Normally, before enabling NIS, the services section looks like this:

# Services
AFPSERVER=-NO-
APPLETALK=-NO-
AUTODISKMOUNT=-YES-
AUTOMOUNT=-YES-
CONFIGSERVER=-NO-
IPFORWARDING=-NO-
MAILSERVER=-NO-
MANAGEMENTSERVER=-NO-
NETBOOTSERVER=-NO-
NISDOMAIN=-NO-
MACHIPC=-SECURE-
TIMESYNC=-YES-
QTSSERVER=-YES-
WEBSERVER=-YES-
SERVER=-NO-

To enable NIS, we change the NISDOMAIN line value from -NO- to the name of an NIS domain, i.e. ournisdomain.nis. Then, at boot time, the Public Beta machine searches for the NIS server for that domain, and connects to it, so that at login, you can use the NIS services available to you.

The problem arises when you aren't in that NIS domain, or on a PowerBook that isn't on any network. The boot halts at the NIS server lookup, and never times out or otherwise moves on. This obviously needs to be fixed in a way that doesn't require constantly re-editing the hostconfig file. As well, OS X does not work well with the standard NIS automounter.

Automounting is the process where, upon login to a machine on an NIS network, certain network drives are automatically connected, via NFS to that machine. This can be things like shared application directories, a user's home directory, etc. There are a couple of ways to do this, AMD and autonfs. Neither of these are supported by the Public Beta automounter. To use NIS automounts, you need to create a BSD-Unix fstab, (file system table). Each line has to be of the format:

export      mount_point      vfs_type      options    dumpFreq    passno

The export is the server and path to the exported filesystem. (In unix-ese, exporting a filesystem is the same as sharing a volume in mac-ese.) The mount_point is the local directory on the OS X machine that the export is to connect at. You can enter whatever you like here, it's going to be ignored by the OS X automounter. 'vfs_type' is the file system type. Since this table is only used for network mounts, this is always 'nfs'. The options section is a comma-separated list of mounting options. One of them must always be 'net', which is required for NIS Automounting. Other options are:

• rw: read/write access
• ro: read-only access for all users, including root
• rdonly: same as ro
• suid: set user and set group identifiers will be respected
• nosuid: set user and set group identifiers will be ignored
• exec: binaries from the mounted system can be executed
• noexec: opposite of exec

There are about two dozen or so other options that can be used here. The bibliography at the end of the article has a link that thoroughly explains NIS to NetInfo.

This fstab file must be on the NIS server, and the server's yp-Makefile has to be modified to create the new NIS map. Also, because the there has to be an additional key column, the final table will have seven columns.

However, there is still an issue with where those directories will be mounted. By default, the Public Beta puts the directories in /Network/Servers/exporting_servername/path, which is a link from /private/Network/Servers/exporting_servername/path. However, if the network you are on expects home directories to have the path /home/path, then you are going to have some troubles with files programs not working right. The manual way to fix it is to create a symbolic link to the Public Beta directory from a /home directory that conforms to your home directory standards. The other way involves changing the automounter options, found in /System/Library/StartupItems/NFS/NFS. If you are not comfortable with editing Unix configuration files, I would recommend the manual method.

LDAP

Lightweight Directory Access Protocol, or LDAP is emerging as a major player in the network management arena. A non-vendor protocol, it has much of the advantages of NetInfo as far as capability is concerned, but with a much broader base of support. LDAP is domain - based like NetInfo, and can manage users and other resources on a network. It is most widely used as an email addressbook standard. LDAP is not only a product in its own right, but is also supported by the two biggest directory service vendors, Novell and Microsoft.

While the Public Beta supports LDAP, the support is not as full-featured as NIS or NetInfo. This is not a real surprise, LDAP is still a relative newcomer in this arena. The only Apple information on LDAP is in a TIL article, number 24902, last updated in May of 1999. This is actually an article on the lookupd, which is the process that the Public Beta to uses to implement things like NIS, NetInfo, LDAP, etc. The TIL article only mentions the basic information that are supported. I have been talking to some people, most notably Luke Howard on OmniGroup's OSX - admin list to try to get a coherent set of instructions on how to implement LDAP support, but it looks to be up to Apple to really get full support for LDAP in OS X implemented properly, as opposed to NetInfo hacks.

The one upside to LDAP support becoming widespread is that, depending on how well this is done, OS X's LDAP support could allow it to play in a network based on Microsoft's Active Directory. Although I have not had the time to test this, since AD supports LDAP, and LDAP connections, in theory, a Mac running OS X could authenticate and participate in an AD domain. If any of you have tried this, please email me and let me know how it worked, or did not work.

Considering the AD information above, this is limited to non-AD networks. The news here is pretty good, and looks to get better soon. The nice thing is, you can have the Public Beta acting as both a server and a client to Windows PCs. The only bad news is the installation of the related products is not as nice as it could be.

Samba

This is the freeware Server Message Block, (SMB) server that runs on pretty much every version of Unix, including the Public Beta. It allows Unix machines to share resources, files, and printers. There is a client component to Samba, but it is a command line only application, and not the most elegant way to have the Public Beta act as a client. Samba is open - source software, and you can download and build the application, or download it as a pre-built binary. (I downloaded mine from MacNN, http://osx.macnn.com/features/installsamba.phtml)

Installing Samba is done from the command line, which is my only real quibble with the application. If someone were to repackage it in a nice OS X installer package, it would be quite nice. In any case, I opened a terminal window, and followed the install instructions on the MacNN page, which are quite simple:

1. Download the package to your desktop
2. If you have Stuffit Expander 6, then use it to expand the tar.gz file, (the version that ships with the Public Beta will do gz files okay, but gags on tar files.), or from a command line, enter: tar -xvzf /Library/Desktop/Samba.tar.gz This will expand Samba, and create the directory on your desktop.
3. In the terninal window, enter su - (this allows you to act as root, which is needed to install Samba correctly. If you were already logged in as root, this step is uneccessary.) When prompted, enter the root password.
4. Enter cd~$user/Library/Desktop/Samba (this line changes directories back to the desktop you were in before you did the su - command. This is needed, because when you become root, you are now in root's home directory. The $user should be replaced by the username you used to download the Samba file. The ~ lets you avoid the entire pathname, which would be /users/$user/Library/Desktop/Samba.) Again, if you downloaded the file as root, and are still root, then you would just cd to /Library/Desktop/Samba.
5. Enter ./SambaInstall.sh (this says, run this SambaInstall.sh that is in this directory. Because of the way Unix handles paths, you often will have multiple versions of the app, and if your normal path has a version of the same app, without the ./ in front of the application name, you may be running a different version than you think you are.)

Once the install script finishes running, Samba is installed, and after a restart, will be running. However, there is one other part that you will want to install, and that is SWAT, which is a web - based administration tool for Samba. This allows you to configure Samba via a web page, without having to edit configuration files. To install SWAT, you have to reboot so that the Samba processes are running. To check this, open the Public Beta's process viewer application, and make sure that smbd and nmbd are running. Open a terminal window, and:

1. Enter the su - command, unless you are root already.
2. Change directories until you are back in the folder you installed Samba from.
3. Enter ./SWATInstall.sh (This runs the SWAT install script)

Once this has finished, you can open up a web browser, either locally, or on any computer that can see the Public Beta mac, and connect to SWAT by using the URL http://machinename:901 . You will need to log into SWAT as root to do any real configuration setups. As there are hundreds of options available in Samba, depending on your needs, and your network, I will not attempt to even begin listing all of them here, but rather highly encourage you to read the online help available in SWAT. It is quite thorough, and gave me all the information I needed to set up my Public Beta machine. The online help will also allow you to configure Samba to plug into existing Windows networks without disrupting that network.

Samba does an excellent job, once set up, of allowing your Public Beta Mac to share files with Windows PCs and other SMB clients such as DAVE, from Thursby Systems. It can act as a domain server for Windows95/98 pcs, but not to NT or 2000 systems yet. That feature is in work, but there is no date on this. This feature, to be part of Samba 3.0, would allow Samba to act as a Windows NT 4.0 Domain Controller, not an Active Directory controller. The Samba team is hoping to integrate Samba into Active Directory domains via Kerberos or LDAP. As always with Open Source products, the more people they have working on it who know what they are doing, the faster it gets done. If you have the skills and the time, by all means, go to http://www.samba.org, and sign up.

Sharity

Okay, we have set up Samba, and Windows folks can see our stuff, but now we want to see theirs. Well, as I mentioned before, there is a command-line utility called smbmount that will allow you to do this, but this is the Mac OS after all, and while odd things for server applications may be acceptable, on the client side, we want our GUI! Well, fear not, for we have our GUI.

The answer is Sharity, a GUI client for CIFS networking. (CIFS stands for Common Internet File System, and is essentially an improved form of SMB.) Sharity is produced by Objective Development, at http://www.obdev.at/Products/SharityForOSX.html . Sharity allows you to browse and mount Windows and Samba server shares within the Public Beta. The install and setup is all GUI based, although a bit odd. You download an installer, which then installs the Sharity installer. To run this installer, you have to be logged into the OS X machine as root. The installer won't work otherwise.

Sharity, like Samba has a lot of options, and I'm not going to go into them all. It is also still in beta, so it can be quirky at times, but when it is working, it is fast, and easy to use. I would like to see Sharity emulate the AppleShare networking in OS X, and mount the shared drive on the desktop as well as in the /Network directory path, as that is what Mac users expect to see on their Macs, and since Apple is continuing this for network shares, other network connectivity vendors should follow suit. Actually, I like the idea of the drive being in both places. For example, with an AppleShare mounted drive, it shows up in both Connected Servers and the Desktop, giving you two methods to access it, depending on your needs.

Another similarity to Samba is that Sharity does have solid online help. Although most of it currently references the Linux versions, the information applies across platforms well enough to get you to where you need to be. In any case, between Samba and Sharity, you can fit the Public Beta into a Windows - based network reasonably well, and have better hardware and software to boot!

Novell

Although there is currently no OS X - native offerings from Novell, that will soon, (according to Novell) be remedied. Native File Services for Macintosh are due to be released in the first quarter of 2001. This will allow for Mac clients to authenticate and access NetWare 5.X and 6 networks and resources. There is no client component for this, it works through Apple's native authentication, and Novell's NMAS authentication services. This does allow OS X Macs to use Novell Directories, and the resources managed by Novell Directory Services, (NDS).

What this does not mean is a single signon for Novell Networks. According to information from Novell, Native File Services is a 1.0 release, and will not have single signon capabilities. The are looking to include that in a future release, so anyone currently using Novell networks should talk to their representatives, and let them know how important that feature is to you.

Conclusion

Again, we all have to remember that this is a beta, and a beta of a client at that. There are a lot of things we may want from it that are more suitable to a server version of OS X. At the moment, the Public Beta seems to be doing a decent job of fitting in, but that needs to be improved. There needs to be much better support for other networks that aren't NetInfo based. The setups for LDAP and NIS in particular should be streamlined, and put under a proper interface. Yes, some enterprising developer may do this on their own, but OS X is an Apple product, and Apple needs to take the lead here. Apple also needs to work with developers such as Novell and Microsoft, to help ensure a seamless networking experience for OS X, both as a client and as a server. Having a simple menu to select between different networking systems, and having it work seamlessly once that choice was made would do much to eliminate the last of the old "Macs are incompatible with X's network system" arguments.

Apple should also look into making Samba an integral part of the OS, and even talk to Objective Development, or Thursby about having an integrated SMB client in the OS. By having those capabilities as part of the basic OS, the door is opened to improve upon those basic abilities, but the OS would be able to communicate better, and more easily with the outside world. Again, this is the kind of thing that would really give Apple a universal network client. Considering the level of network in most computer owners homes is getting more complex by the month, Apple should be able to use this the day OS X ships.

The bibliography is a list of URLs that I have found useful in putting this article together. Along with that, I'd like to give a special thank you to everyone on the OmniGroup Mac OSX-admin list. A lot of this article would have been much harder without them.

Bibliography and References

• Version Tracker's OS X section:
  http://www.versiontracker.com/vt_mac_osx.shtml
• The OmniGroup's OS X mailing lists:
  http://www.omnigroup.com/community/mailinglists/
• Apple's OS X mailing lists: http://lists.apple.com
• MacNN's OS X section: http://osx.macnn.com/
• Information on NIS and NetInfo:
  http://www.bresink.de/osx/nis.html

John Welch <jwelch@aer.com> is the Mac and PC Administrator for AER Inc., a weather and atmospheric science company in Cambridge, Mass. He has over fifteen years of experience at making computers work. His specialties are figuring out ways to make the Mac do what nobody thinks it can, and showing that the Mac is the superior administrative platform.