« OS X To Windows | Main | Integrating OS X »

created 30 Oct. 2000

Connecting OSX to Unix

Well, last time we talked about connecting the OS X PB to Windows machines, and the products available to test for that purpose. This time we are going to focus on connecting to Unix networks.

There is an interesting dichotomy here, as this is both some of the easiest, and most convoluted connections of the group.

First off, the standard Unix connection tools are all here, telnet, rsh, rlogin, ftp, nfs, lp, etc. Things like Telnet, rsh, rlogin are all currently command line only applications, although the Carbon version of MacTelnet is due quite soon now, and even in its current state, shows great promise, as it is scriptable, something the command line remote access tools are not.

This is of great benefit to those of us with time, effort and money invested in AppleScript, as porting those to various shell scripts would be non-trivial in both time and effort. For those of us who are used to things like shell scripts and PERL, the PB includes those capabilities as well, so that regardless of your scripting preferences, you have all the basic tools you need, although I imagine that AppleScript will give you better access to the GUI elements and the applications that aren't command line applications. Apple is being good about giving us low level access to AppleScript, so that regardless of your language choices, you should be able to integrate that language into AppleScript in some fashion.

FTP is there as well, again, no big shock, this is a Unix based OS. For those of you who prefer a GUI - based FTP client, (like me), there are products such as Transmit, from Panic. You can of course use web browsers for downloads, but I prefer the functionality from an FTP client. Although there are more Mac FTP clients available, as of yet, only Transmit has been Carbonized. As with things like MacTelnet, the primary advantages to a product like Transmit are that you don't need to start dealing with command lines, and you get AppleScript.

The next connectivity issue is NFS. At the moment, this is primarily one way, that is, the PB can easily mount other Unix NFS shares, but sharing PB drives is a bit trickier. This is primarily due to unresolved issues with NFS and HFS+. If you use UFS for the PB, you avoid the NFS issues, but you loose the ability to run the Classic environment, so it's a trade-off. As well, although I have found a reliable method for accessing other NFS drives, I haven't found a reliable method for creating NFS mounts in the PB, so I'm waiting for either Apple, or a third party to handle this.

In any event, the NFS procedure I use is relatively simple. You have to start NetInfo Manager, and unlock it. To unlock it, you must authenticate as root, with root's password. Considering that unlocking NetInfo unlocks the 'keys to the kingdom', this is a sensible precaution. Once in NetInfo, you will want to select the /mounts directory. This should be empty. You will want to create the following properties and values, one for each mount:

• property: value
• vstype: nfs
• dir: (local directory where the remote share attaches, i.e. /Network/public)
• name: (remote server and that server's share, as computer:/sharepath, i.e. server:/home/myhomedirectory)
• opts: bg

A sample NetInfo screen shot is shown below, (names changed to protect the innocent.)

One thing to make sure of is that you create the dir parameters manually. I personally create the destination/local directory before I create the mount entry. Once this is done, then you should be able to access the remote files from within the Finder window. I found that I sometimes had to reboot to see the mount, but this wasn't consistent. I presume this will not be required in the release. Another note is that the remote volume does not show up on the desktop in the same manner as AppleShareIP volumes. I would sincerely hope that Apple allows for this behavior to be selectable. That way, both Mac and Unix people can have the behavior they expect from remote volumes. Finally, because you statically create the destination directory, even if you are not on the network, the directory is still on your Mac, albeit empty. For those administrators with Unix experience, this is the norm, for the Mac administrators without this experience, this will be something new to watch out for. This works very well with Sun Solaris boxes. I have not had a chance yet to test it with Linux or SGI shares. It should work okay, although there does tend to be issues with the way Linux and SGI approach NFS. These aren't insurmountable, but beware of them.

The final connectivity protocol we'll look at is the X Window System. This is the basis for most Unix GUIs, and is also the primary method for running applications that physically exist on other servers in the Unix world. Before we start with X products for OSX, a brief overview of what X is should be looked at. (I would like to thank Sandy Nicholson for this explanation, posted as a comment to an earlier column I did.)

1. The `X protocol' is at the core of X. It is essentially an agreed binary representation for graphical and textual information to be displayed in windows, as well as keyboard and mouse input information. Messages formatted according to the X protocol might be internal to a computer, or they might be transmitted across a network (even across the Internet).

2. An `X server' is a program that implements the X protocol on a given computer, by actually rendering graphics and text for you to see, and by converting your mouse clicks and key presses into appropriate X protocol messages.

3. An `X client' is any program that communicates with an X server (using the X protocol), in order to interact with the user of the machine on which the X server is running. To the end user, it appears as though each X client is running on their machine, though in fact some or all of them could be running remotely.

4. An `X window manager' is a specialized X client, often (but not necessarily) running on the same machine as the X server. It provides basic window management functionality (things like raising and lowering windows, moving them around and iconizing them). To use X, you don't actually need to use a window manager, but it's pretty awkward if you don't!

Okay, so the X-Window app I have been playing with is Tenon Intersystems' XTools. This is a commercial X Window product that allows you to run X applications, such as GIMP, Netscape, etc. on your OS X Mac, or other computers to run X applications that reside on an OS X Mac. For example, there is no Carbon or Cocoa version of Netscape 4.7.X. So, without XTools, I am stuck with trying to use the Classic version, or booting into OS 9 to use Netscape, or trying to run the Carbonized version of Mozilla. But with XTools, I can log into one of our Unix servers, and run the Solaris version, shown below.

So with XTools, or the free port of XFree86, I can run any X application that exists on my network, from Netscape to MatLab, to IDL, and the only slowdown is if the network is running slow. This gives OS X users access to an exponentially higher range of applications that span the entire spectrum of application types, from vertical market high-end applications, to games. Admittedly, this capability existed for OS 9, with similar products such as Exodus, from PowerLan. But it's very important that this capability is available for OS X, as it is based on Unix. Even better than being just able to run remote X applications is the reverse of this. Other Unix computers or systems with X Window packages can run applications that reside on the OSX Mac, if they follow the X Window specifications. So that means that a multiprocessor OS X Mac could easily act as a compute server for a research firm, running such products as IDL and Mathematica. X Window capability simple extends OS X's reach to an incredibly large span, and that can only help not only Apple, but everyone who uses OS X.

So, finishing this installment, OS X has the essentials needed for good Unix connectivity. There's some blots on this, such as the awkwardness of setting up NFS, and I left out the WebDAV capability in Apache, (primarily because I haven't had a chance to really work with it personally), but the plumbing is there, so now Apple needs to get the user fixtures in place.
The next, and final part of my series on OSX connectivity will be on integrating the PB into non-NeXT/OSX Server/NetInfo networks.

Comments