Return to Floodgap ANSwers

Floodgap ANSwers: Mac OS Services

Using Mac OS client software requires enabling the AppleTalk stack in AIX (see the AIX on ANS FAQ). ANS AppleTalk is potentially insecure and may expose your server to being remotely controlled by a malicious attacker. Only use the NWServer infrastructure on a trusted internal network.

One of the most unique features of Apple Network Server AIX is its built-in support for Mac OS clients, and one that probably escaped the notice of most of its users (I didn't learn about this until many years later). Using AppleTalk, Mac OS clients can make requests of a remote Network Server, including sending it remote jobs or commands, performing system administration, or even mounting a command shell.

The magic is due not only to ANS AIX's built-in AppleTalk stack but also a unique server-side implementation of Apple Events and a system process called the Program to Program Communications Daemon (ppcd). In the NWServer scheme of operations, a Mac OS client can ask the AppleTalk network for servers that implement a particular service (a server may of course run multiple services), and finding one, can authenticate to it and request services by opening an AppleTalk network connection and/or sending Apple Events. The support for this feature on the Mac side is provided by the standard AppleTalk PPC Toolkit (Program to Program Communication, not to be confused with PowerPC; the feature works on 68K and PowerPC clients) and the PPCBrowser interface, supplemented by the Network Server extension. To the Mac, the ANS just looks like another Mac that implements remote Apple Events. On the server side, ppcd looks at a list of services in /etc/ppcd.conf and starts an appropriate daemon based on the signature of the AppleEvent it receives (think of it as an AppleTalk RPC implementation, or an Apple events-aware sort of inetd). The daemon uses the AIX implementation of the Apple Event Manager and the built-in AppleTalk stack to exchange events, or send and receive data over an ADSP (AppleTalk Data Stream Protocol) socket.

Daemons can be built with any compiler, including xlc or gcc (though you'll need xlc for certain "flexible" daemons that require directly manipulating Mac-compatible data structures), while the clients are simply regular Macintosh applications. On your AIX system, you can look under /usr/lpp/apple.remoteutils/src for both the source code for the clients (in CodeWarrior and/or MPW projects as BinHexed self-extracting archives) and the server daemons. The daemons link against AIX's Apple Events and AppleTalk libraries. Here's an example of how to build such applications, with sourcecode on Github.

This sounds like it would be an amazingly useful feature, particularly for enabling remote applications to be run on the much more powerful and preemptively multitasking ANS and allowing the Mac process to only have to service UI events, but Apple dropped the concept when the ANS was dropped and never resurrected it. While it might be possible to use AppleTalk-aware operating systems to emulate the data connection, I don't know of any other server OS that has ever implemented the Apple Events side, and changes to the Apple Event Manager in Mac OS 9 have made OS 9 incompatible with these clients. Thus, sadly, only an AIX ANS and a pre-OS 9 (8.1, 7.x or A/UX recommended) Mac can take advantage of this infrastructure; no Macs since can do so. Still, it's worth looking at how it functioned if for no other reason than historical interest.

Setting Up the ANS for Mac OS and A/UX Clients

The Mac OS client software is stored in /usr/lpp/apple.remoteutils/clients as a BinHex self-extracting archive; some ANSes may also have it on a floppy disk in the accessory kit. If this file is missing, you can get it from the Software page. Once expanded, drop the CommandShell VT102 and Network Server Passwd Tool extensions on the System Folder (to move them to Extensions), put the clients in the folder you want them, and reboot the Mac. On A/UX, only the Network Server Passwd Tool needs to be installed; Logout to refresh your Finder session.

Before starting the clients, AppleTalk and ppcd need to be running. Start AppleTalk from smit (if you don't know how, see the AIX on ANS FAQ) by going to Communication Applications and Services, AppleTalk, Start AppleTalk in Single Port Mode (or as appropriate). On a system with a single interface, the default et0 is usually correct (the AAUI port). Press ENTER/RETURN to start AppleTalk; you will receive a confirmation and information on the network. Back up to the AppleTalk smit menu and go to AppleTalk Services, Program to Program Communications Daemon (ppcd), Start the 'ppcd' Daemon. The default options should be acceptable. Press ENTER/RETURN to start the daemon and wait for smit to signal "OK." Start the application of your choice and try to connect.

Screenshots

These screenshots were taken on spindler, my clock-chipped 40MHz Quadra 800 running Mac OS 8.1 and A/UX 3.1.1, talking to stockholm.


Let's start with CommandShell, which as it implies, opens up a shell to the ANS over AppleTalk (both rather cool and rather frightening at the same time). This is the user interface for the PPCBrowser. The server appears as a "Macintosh." Once selected, a compatible service of the requested signature then appears if present under "Services" and can be selected.

As a parenthetical note, on OS 9, no services appear. Although an IP checkbox appears, it doesn't work if you type in the ANS' IP (ANS AIX doesn't know about Apple Events over TCP/IP), and in fact occasionally crashes the application.

Entire original image (14.7KB)   

The user then authenticates using their AIX username and password. (Not encrypted!) Services can be configured to allow guest access in /etc/ppcd.conf.

Entire original image (14.2KB)   

A shell window then opens, exactly as if you had opened a Telnet window, except that the connection is over ADSP. To complete the illusion on the AIX side, the login appears to be from the pseudo-host "cmdshell." Normal login security still applies; you can't log in as a disabled account this way, at least. Something like this might be very useful for shell access on machines that only have LocalTalk.

Entire original image (9.7KB)   

Next is the Disk Management Utility. This is a much more convenient way to create and manage logical volumes and file systems than mucking about in smit but unfortunately this is the only system administration utility implemented. Nevertheless, if you're allergic to the command line, I can see where this would have been popular for basic storage tasks.

Entire original image (21.2KB)   

Now the Fractal Demo. This is rather cool: the Quadra asks the server for a set, and the server computes it and sends it back for display.

Entire original image (45.3KB)   

Zoom! Zoom!

Entire original image (85.1KB)   

There are at least two versions of the NWServer clients. The first release I know of, 1.0.1, included a Status Demo ("Javelin") application that stockholm apparently does not like and threw an AppleEvent error message. This appears to rely on the older 4.1.4.1 daemon which was updated for AIX 4.1.5.

Entire original image (13.7KB)   

The Status Demo included with version 1.0.2, however, works properly.

Entire original image (12.9KB)   

1.0.2 also includes a Status-Who Demo ("Trident") which implements two views, a who view and an uptime view (I guess the AppleTalk equivalents of rwho and ruptime). The uptime view not only updates periodically but shows a scrolling history. (Speaking of, I suppose I oughta fix the Quadra's clock.)

Entire original image (15.3KB)   

Interestingly, the uptime view pulls up two compatible service signatures on stockholm. They both work apparently the same, but originate from different sources (the two-headed flexibled, which implements the Who view and the uptime view simultaneously, and the single-headed simpled, which handles only uptime). Notice the "trident thang" window in the background. Ha ha! Those crazy Apple dweebs! Also, the message on the PPCBrowser window is configurable; rather than ask for a CommandShell server, it's asking for a "Unix Server."

Entire original image (13.5KB)   


Finally, A/UX. Notice the A/UX CommandShell open in the background -- the reason you don't need to install the VT102 tool is because the VT102 tool is actually the same one A/UX has for its own CommandShell, even though the applications are completely different.

The usefulness of the NWServer architecture on A/UX is a bit less since A/UX can have hybrid applications that are fully local with the same multitasking advantages. However, the ANS is much more powerful than this Quadra, the fastest Mac that can run A/UX, and of course the remote administration tasks are indispensible in any case. Plus, since A/UX has MacX, you can run CDE applications over the network.

Return to ANSwers

Entire original image (14.8KB)   


generated by Floodgap Super Image Browser 1.788.0