Mac OS 9 with a Net
Previously, we looked at some installation and compatibility issues with Mac OS 9, as well as some major new features: Sherlock 2, Multiple Users and Voice Verification, plus the Keychain and Apple File Security. This article examines some of Mac OS 9’s networking and file sharing features.
<https://tidbits.com/getbits.acgi?tbart=05624>
<https://tidbits.com/getbits.acgi?tbart=05625>
Internet File Sharing — A significant power-user feature in Mac OS 9 is the capability to use both Personal File Sharing and Program Linking over the Internet. Personal File Sharing, which enables users to access files on a remote Macintosh over AppleTalk, debuted with System 7 back in 1991, and though it’s limited to ten simultaneous users, it has proven the be one of the Mac OS’s most-loved and most-used features.
Now you can use those same capabilities over the Internet, thanks to a special background-only version of Open Door Networks’ ShareWay IP that Apple has rolled into Mac OS 9, adding only a single activation checkbox to the File Sharing control panel. You configure users, groups, and privileges as you normally would for Personal File Sharing – except now users can connect to your Macintosh by entering your Mac’s IP address into the Chooser (using either a DNS name or an IP number), or perhaps by locating your Macintosh in the Network Browser application. Although TCP/IP File Sharing may not be too useful for folks with dial-up Internet access (and hence ever-changing IP addresses) it’s handy for accessing machines with fixed IP addresses from the road or anywhere else that’s not on your local AppleTalk network. Note that AppleTalk must still be active in the AppleTalk control panel for TCP/IP File Sharing to work – the feature simply provides access to AppleTalk-based services you’ve already defined.
<https://tidbits.com/getbits.acgi?tbart=04961>
Program Linking – otherwise known as the Program-to-Program Communications (PPC) Toolbox – was another feature that appeared way back with System 7, although it hasn’t enjoyed the widespread popularity of File Sharing. Program Linking enables applications on separate machines to communicate with each other over a network, all controlled by the users and groups privileges set up in the File Sharing control panel. However, since most programs don’t talk to other programs by default, few users took advantage of this capability, and using it to its full potential often required scripting. I may be alone in the universe, but I use Program Linking regularly, both to monitor the status of servers on my network, and also to perform everyday tasks – in fact, issues of TidBITS would never make it to our Web site or be distributed via email if it weren’t for Program Linking. For many users, the utility of Program Linking over the Internet will be the capability to run AppleScript scripts that can interact with applications on remote machines via the Internet.
TCP/IP File Sharing and Program Linking raise security questions for many users. Although Internet sharing features are not enabled by default (and guest access isn’t available at all for Program Linking over TCP/IP), once they’re turned on your Mac’s security is limited to the quality of the usernames and passwords you’ve defined – and, of course, whether you’ve enabled guest access. Theoretically, your Mac could be accessed by anyone on the Internet, rather than just the comparatively few souls on your local AppleTalk network. Although you can certainly protect your Mac adequately using good, hard-to-guess usernames and passwords and disabling any sort of guest access, Open Door Networks – the same folks who developed these capabilities in the first place – offer enhanced utilities with improved security and monitoring features. ShareWay IP 3.0 adds logging features and the capability to enable or disable IP-based connectivity on a user-by-user basis. You can also change the port number of TCP/IP File Sharing to something besides the standard port 548. Special pricing is available for Mac OS 9 owners. Open Door also offers versions of DoorStop, a stand-alone firewall that offers highly selective allow-or-deny access of Internet services on a Macintosh going back to Mac OS 8.1.
<http://www2.opendoor.com/shareway/ MacOS9upgrade.html>
AppleScript 1.4 — Program Linking over TCP/IP creates new possibilities for Internet-enabled scripts. Typically, AppleScript scripts are confined to running on your local computer as one-shot tasks you trigger yourself or as Folder Actions that act automatically on your behalf. Only ambitious scripters have used the PPC Toolbox to run scripts over AppleTalk, but the rewards of doing so can be substantial: you could open or close databases on a Web server, transfer data to and from remote applications, shuffle files between folders on a remote Macintosh, launch and quit applications on another machine… in short, just about anything you could do with a script on your local Mac, you could do remotely if you were willing to tussle with obscure syntax and scripting tricks.
AppleScript 1.4 adds two enhancements to this scenario – in addition to prepping AppleScript for the forthcoming world of Carbon and Mac OS X. First, AppleScript 1.4 enables the use of "eppc" URLs in tell statements, so scripts can connect to remote machines running Mac OS 9 with TCP/IP Program Linking turned on:
tell application "Finder" of machine "eppc://pointless.quibble.com/"
beep
end tell
Second, AppleScript has a new "using terms from" block to get around the infamous "double-tell" trick of writing scripts for applications on remote machines: you can use terminology from a local application to compile a script that will execute on a remote system:
using terms from application "FileMaker Pro"
tell application "FileMaker Pro" of machine "eppc://pointless.quibble.com/"
open database "Contacts" with password "LaVidaPoca"
end tell
end using terms from
Unfortunately, Apple doesn’t document these capabilities online or in any of the materials that ship with Mac OS 9. Hopefully, Apple will update its AppleScript Web site soon discuss these features, as well as additional scripting enhancements in Mac OS 9. In the meantime, Bill Cheeseman’s AppleScript SourceBook is a good place to look for information about AppleScript 1.4.
<http://www.apple.com/applescript/>
<http://www.applescriptsourcebook.com/ applescript/applescript140.html>
Network Services Location — Although AppleTalk is often maligned by network administrators (especially those who don’t use Macs), Apple’s age-old networking protocol has always offered good ease of use, simple administration for small groups, and features still not found in many modern networking environments, such as the ability to "see" network resources dynamically as they appear and disappear from a network. Nonetheless, AppleTalk faces two fundamental problems: AppleTalk isn’t based on Internet technologies, and network administrators believe (mostly erroneously) that AppleTalk services consume lots of bandwidth as they "chatter" to locate other AppleTalk services.
So, Apple started working on Network Services Location (NSL), a protocol-independent way for programs to learn about services available on a local intranet. The key phrase here is "intranet", not "Internet" – although these services can operate over the Internet because they aren’t bound to any one protocol, they aren’t intended to encompass the entire Internet. The idea is to bring some of the best features of AppleTalk – discoverability and ease of use – to other protocols and network services.
Apple quietly introduced support for NSL in Mac OS 8.5 and 8.6, although there were no visible manifestations. Apple solidified NSL in Mac OS 9, although users may still find it confusing and hard to use until applications and servers intelligently take advantage of its capabilities.
In Mac OS 9, NSL includes plug-ins for four services – DNS, LDAP, Service Location Protocol, and AppleTalk. In theory, this enables NSL-savvy applications like the Network Browser to locate and connect to network services using any one of these protocols. Items from each of these services appear in "neighborhoods" – hierarchical groupings of network items – that can contain items from any of the available network services, as well as other "sub-neighborhoods". Depending on your LAN setup, the Network Browser might be able to see your local FTP servers, Macs running Personal File Sharing and Personal Web Sharing, Web servers on your intranet, organizational information kept in an LDAP directory server – plus everything you’d expect to see on an AppleTalk network, including zones and file servers, but not printers. Apple’s Personal File Sharing and Personal Web Sharing use Service Location Protocol (SLP), a new way for clients to learn about available network servers, so these services automatically appear in the Network Browser as local services under Mac OS 9.
There are several catches with NSL and SLP. First, Apple shipped SLP 1.0 in Mac OS 8.5 and 8.6, and SLP 2.0 in Mac OS 9. These two versions are not mutually compatible, so Mac OS 9 systems can’t discover SLP services on Mac OS 8.5 and 8.6 systems and vice versa, creating confusion for users. Fortunately, version 1.1 of the SLP plug-in from Mac OS 9 (which implements SLP 2.0; it’s called "SLPPlugin" in the Extensions folder) will work with Mac OS 8.5 and 8.6 systems, but Apple doesn’t document this trick, and it could create administration headaches. Second, although SLP-savvy clients can discover services on a local network, there’s currently no way to organize or administer them. On medium-to-large networks SLP is designed to work with servers called "directory agents," which register and administer network services. Directory agents enable the scalability of network services, permit centralized administration of what is and isn’t allowed to advertise itself as a network service, and define how those services are organized. However, no SLP directory agents are available right now, although Apple claimed it intended to ship a directory agent for SLP last May at WWDC. So, SLP services can’t easily be organized at the moment, which limits their utility.
All this might be moot if your LAN’s routers – or those of folks with whom you’d like to communicate – don’t support IP multicasting. IP multicasting is a technology designed to facilitate IP-based audio and video transmission – basically, instead of each client or audience member requiring a separate data stream, each client can receive the same data stream, thereby using the network more efficiently. Although most recent routers support IP multicasting, older equipment may not. In the absence of directory agents to coordinate network services, SLP-savvy clients rely on IP multicasting to query the network for desired services. If those queries don’t go anywhere, the services on the same LAN can’t be discovered and won’t appear in the Network Browser.
(Open Door Networks has published a good discussion of SLP and the Mac; it bears reading if you’re interested in SLP’s history and development.)
<http://www2.opendoor.com/shareway/SLP.html>
So the SLP situation is complicated: what about using NSL in real life? On a small network, NSL can come close to AppleTalk’s ease-of-use, especially if users standardize on Mac OS 9 or at least version 1.1 of the SLPPlugin extension. In other situations, using NSL’s utility may be hard to predict.
You can add neighborhoods to the Network Browser by entering DNS machine names or IP numbers. However, you can only delete neighborhoods using the Finder – some neighborhoods appear in the Favorites folder in the Apple Menu, others are buried deep in your Preferences folder – or using control panel settings (see below). This difficulty of configuration is an unneeded aggravation since most neighborhoods won’t work as people expect.
The Network Browser creates neighborhoods for you when it starts up. If you’re on an AppleTalk network, the Network Browser displays an AppleTalk neighborhood which works much as you’d expect. Since NSL has an LDAP plug-in, it also tries to create a neighborhood based on any LDAP server settings you’ve specified in the Hosts settings of the Advanced tab in your Internet control panel. (If you don’t see an Advanced tab, you need to switch to Advanced mode using the User Mode command on the Internet control panel’s Edit menu.) Even if you can connect to the specified LDAP server, LDAP resource listings in the Network Browser may be nearly useless: email addresses don’t appear as Internet resource files but rather as entirely new neighborhoods which, in turn, contain the entire LDAP directory information again, ad infinitum. Any URLs associated with an LDAP entity are listed separately, creating more confusion.
The Network browser may also try to create a neighborhood based on information you have entered in the search paths fields in your TCP/IP control panel. These neighborhoods display any services discovered using SLP (right now this means only Personal File Sharing over TCP or Personal Web Sharing) or DNS. Unfortunately, the only way a service can be "discovered" using DNS is if the DNS server administrator has created TXT records in that domain identifying services. The format for this record is tucked away in an Apple manual on NSL; if you think network administrators dislike AppleTalk, they’ll respond even less favorably to hard-coding references to services into their DNS zones.
<ftp://manuals.info.apple.com/Apple_Support_ Area/Manuals/software/NSLAdminGuide.pdf>
In short, Apple has introduced some new fundamental networking technologies with Mac OS 9 that may be useful now to some users in specific environments. However, until server and application support improves, many of these new capabilities may exacerbate confusion about how to access network services.
Remote Access — Apple has also rolled the features of Apple Remote Access Personal Server into Mac OS 9, enabling a Macintosh to answer modem calls from clients using either PPP or ARAP (Apple Remote Access Protocol) and grant access to either the local computer or the entire local network – this puts Mac OS 9 on par with the dial-up access capabilities built into Windows 98. Remote Access is handy if you need to access your desktop Mac from your PowerBook while you’re away from the office, and potentially access your entire office network at the same time.
<http://www.apple.com/networking/ applepersonalserver.html>
You can set up call answering in the Remote Access control panel (select Answering from the RemoteAccess menu); Remote Access can act as a PPP server and assign an IP address to a caller using TCP/IP, or allow a caller to use a pre-determined IP address. The File Sharing control panel’s User & Groups tab determines which users have the ability to dial in to a Macintosh using Remote Access: dial-in privileges must be enabled on a user-by-user basis, and can be configured to call a user back at a pre-defined number rather than granting immediate access. Mac OS 9’s Remote Access capability isn’t sufficient to support a pool of remote users – it supports only one modem – but does offer the most current modem scripts for Apple and third-party modems, improved DNS negotiation, support for MS-CHAP, and improved compatibility with AppleTalk/PPP servers. Remote Access also keeps an activity log, so you can check to see if folks are abusing the service or trying to break into your system. Although I haven’t tried this in almost two years, there’s no reason Windows or Unix machines wouldn’t be able to connect to Remote Access using PPP, although they would need AppleTalk software to access any AppleTalk services.
Looking Ahead — Even all this detail doesn’t fully cover Mac OS 9’s changes, and we’ll be looking at some additional features in a future issue, along with the groundwork for Mac OS X that Apple has laid in the foundations of Mac OS 9.