Jan 00 NetManage
Volume Number: 16 (2000)
Issue Number: 1
Column Tag: Net Management
Network Management
by John C. Welch
Working with Mac OS and Windows in a Unix environment
Welcome
This article is based on my experiences in the last year and a half in converting my non-Unix network from AppleTalk and NetBIOS to 99% pure TCP/IP, or as close as I could get. Although this article primarily focusses on Macs, I will also deal with the PC side, as they are both intertwined in this project.
Background
When I started in my current position, the original non-Unix network was, to put it mildly, a mess. This was not due to incompetence, or a lack of desire to do things right, but to two elements:
- The Macs had been so easy to network, that there hadn't been a need to think about them, so they just 'grew in place.' This caused a lot of hidden problems, which I will go through in more detail. The Macs were there, they mostly worked, and therefore were okay, as far as the net managers were concerned.
- Both of the current staff were ignorant of the ways that the WinTel architecture functioned, and had bought all the PCs pre-configured from a local vendor. A nice idea, but as we will see, not a practical one.
I was lucky in a way, since as there was no actual architecture for the non-Unix machines, I was free to create one. The downside of this, of course, is that I had to create one from scratch, and as any artist will tell you, creation can be painful. (I do consider myself an artist in that most of what I do requires an eye for the creative, as any I.S. pro will tell you).
Problem Identification
The Macintoshes at this site were running a mixture of Mac OS versions 7.0.1 to 7.5.5, with various forms of MacTCP and Open Transport (OT) TCP/IP stacks installed. AppleTalk was intensively used for all printing and file sharing duties. All Unix server access was performed via Syntax's Total Access Server (TAS), running on Solaris. All Windows network access used AppleTalk network stacks running on the PCs. All printing was via various forms of Apple's LaserWriter driver over EtherTalk.
The PCs were all Windows95, with various service packs, accessing the Unix file systems via TAS, and the Macs via AppleTalk stacks. All printing was done through either AppleTalk, or Hewlett Packard's (HP) JetAdmin software, and in some cases both. The printing was further complicated by the JetAdmin version's requirement for NetWare as the printing protocol. In effect, the PCs were using four protocols just to live on the network.
Backups were performed for these systems by a Mac running Dantz Development's Retrospect 4.0. Although an excellent and reliable product, the backups were running across a mixture of AppleTalk and TCP/IP, slowing overall performance.
The problems with this system, or lack thereof, were many:
- Due to all the different MacOS versions, troubleshooting a problem required sitting at that user's Mac, and testing, because trying to reproduce the problem elsewhere introduced too many variables into the test.
- The multiple versions of the Mac networking stacks made troubleshooting network-related problems difficult and tedious. Even relatively simple problems required weeding out known issues with versions of OT and MacTCP.
- The PCs using AppleTalk and NetWare were causing more than a few problems for those systems.
- The use of AppleTalk and NetBIOS on a TCP/IP network caused performance and reliability issues for the Unix users as well as other platforms.
- There was no central way to monitor the printer queues to see when a job was blowing up or stalling the printers, because the Macs and PCs printed directly to the printers. In addition, the PCs were using vendor-specific drivers for printing, again making maintenance difficult.
- Although TAS is a good server product, using AppleTalk and NetBIOS as an interface for Network File System (NFS) shared file systems was adding a layer of complexity to the network.
- The PCs had various types of 'combo' cards installed, attempting to combine networking, video, and sound onto the same card. In each case, only the video worked, so additional sound and networking cards had to be installed, resulting in duplicate cards for these functions. This made the hardware reliability of the PCs sketchy at best.
- Finally, the backups needed to be reduced to a single protocol where possible.
The Fixes
Get everyone on the same OS page
The first order of business was to move each platform onto a current and consistent OS version. By this time, Mac OS 8.0 had been released, so all capable Macs were upgraded to this version. This left about five Mac IIsi's out in the cold, because OS 8 would not run on Macs with that processor, (68030). Rather than upgrading them to version 7.6.1, we decided to purchase new machines for these users, and for other users whose needs outstripped their hardware. Since the G3 was not available to us, the machine settled on for desktop Macs was the 8600/300, with the Mach 5 604e processor. The 8600s were equipped with 128 MB of RAM, so that Connectix Corp's Virtual PC (VPC), also purchased with each Mac, would be available (see sidebar).
Emulation issues
Although I have seen many people dismiss VPC and other emulators out of hand, by making sure that each Mac was able to devote 100 MB of RAM to VPC, we have gotten consistently good performance out of the product. I have seen performance equivalent to that of Citrix's MetaFrame product at least in almost every case.
For laptop users, we purchased either PowerBook 3400/240s or 2400/180s, along with one first -generation PowerBook G3. This phase took approximately five months to complete. When we finished, only one 68K Mac was left in use, and it was targeted for replacement within the next month.
The result of moving everyone to the same OS level is that the Mac users realized immediate gains in reliability and performance. One of the side benefits was that a growing desire to replace all the Macs with PC's was now seen as unnecessary. The same benefits occurred with networking, since everyone was now using the same version of OT (1.2), this gave them gains in performance and reliability. From an IS perspective, [TK fill in missing sentence fragment or remove]the consistency between the platforms immediately slashed maintenance and troubleshooting time as problems could be duplicated or verified at more than one workstation.
On the PC side, all the machines running Windows95 were upgraded to the most current Operating System Release (OSR) version. This allowed the use of PowerQuest's PartitionMagic to convert the Windows machines' hard disks to FAT32. Use of FAT32 resulted in a more stable file system, and some fairly impressive (300MB to 700MB), space recovery on those drives, along the same lines as the gains Mac users experience when moving to HFS Plus with Mac OS 8.1. In addition, the troublesome combination video/sound/network cards [TK were these mentioned earlier in the list of problems? If not, identify 'em more thoroughly here] , which had only worked as video cards, were replaced by reputable models. We used ATI or Matrox (video), SoundBlaster (sound) and 3Com, (network) cards. The new cards resulted in each of these features now being usable, and eliminated a lot of squirrelly drivers from the mix. Finally, the HP JetAdmin software in the PC's was updated to allow the use of TCP/IP instead of NetWare and AppleTalk to print, again, eliminating errors and problems by simplifying the configuration.
We started in August '97, and by January '99, we had finished one part of the conversion to TCP/IP. We also joined the Apple Developer Program, installed two new web servers, including a Power Macintosh 8600/300 running WebStar 2.x and Rumpus, 1.x, (For FTP services). [TK mention the platform?], converted from 2 Mb Ethernet with a 10Mb backbone, to 10Mb Ethernet with a 100Mb backbone, upgraded all the Sun machines to Solaris 2.6, and installed a new email system. The next step was to deal with the printing issue.
Printing the Unix way for fun and profit.
The printing differences between Unix and the other machines had been the cause of a few arguments in the company. The Unix users could easily check on each other's print jobs, and printer status, but could not tell when the delay was caused by a Mac or PC print job. Since in the science world, a PostScript file of a color plot sent to our color printer (a Tektronix Phaser 550 with the 1200dpi option, if you're curious) could easily exceed 20MB, making the wait for an unknown job to finish mildly frustrating, especially if you had one of your own to process.
The most logical solution was to get the Macs and PCs to use the existing Line Printer (LPR) server, and print over TCP/IP, which increased the efficiency of printer usage, and allowed for more accurate print job monitoring, plus eliminated a lot of AppleTalk and NetBIOS usage. The Macs were helped by the fortuitous release of Mac OS 8.1, which included the LaserWriter 8.5.1 drivers and LPR printing support. The upgrade was quickly implemented and by mid-February to early March, all our Macs were printing solely via TCP/IP to our main Unix print server. The Mac users were happy that their print speed was much faster (spooling to a server is faster than spooling to a printer), the Unix people were happy that the number of unknown print jobs had dropped by over half, and the IS staff, were happy because we now had better control over how the printers were being used.
On the PC side, our TCP/IP printing architecture was implemented in two phases. The first was the purchase of a site license for the Exceed X-Windows package, from Hummingbird. Primarily intended as a way for Windows users to access Unix programs instead of using telnet, the Exceed software included an LPR print server, which allowed us to create new ports for the existing HP and Tektronix printers. These new ports rerouted the print jobs to our main Unix print server. All users were now placed in the same printing queue(s), which provided better monitoring and control over print jobs and problems. In addition the PC users received faster printing times, and fewer system errors from the HP drivers, which were turned off at this point. For our, Windows NT users, that OS has built - in LPR capabilities, so it was a matter of installing the correct printer drivers, and connecting them to the appropriate ports.
The next step for the PC users was to replace the multiple vendors' printer drivers with one better suited to the printers we own and the way we print. Since all of our printers are PostScript, the only logical choice was Adobe's. The Adobe drivers were installed, and again, printing became a much more reliable and forgettable process. (It is my firm belief that in the IS business, the best programs are the ones that do their job so well, you forget they are running. Obviously this list is too short.) A side benefit was that we are now able to use one PostScript Printer Description (PPD) file for all of our platforms, so that all of our users can print with consistent capabilities and quality, regardless of platform. This final phase was only completed within the last few months.
Connecting the whole world in a consistent way
The final and most complex step to our total solution was the file connections. There had been no standard way for all the computers on our network to connect to each other, so as a result, we had a chaotic conglomeration of confusing configurations and protocols, from TCP/IP (Unix), to NetBIOS (PC), to AppleTalk (Mac).
Although we were using the TAS product, it had several disadvantages, among them, speed, (it was agonizingly slow on the AppleTalk side, to the point of causing even our G3 systems to grind to a halt to even mount a drive). TAS was also a very complicated product to deal with, the worst example being the way it dealt with the Mac OS's dual file fork system. TAS would keep the resource forks in a separate directory, and use index files to match them when a Mac would attempt to access them. Unfortunately, this was unreliable, as about 20% to 30% of application files would become corrupt under this system. In addition, if a file was moved or added using the standard Unix commands, and it was a Mac file, it lost the resource fork, and become corrupt and crashed machines when accessed via AppleShare (we determined TAS was responsible for this by FTP'ing the same file to a Mac, which allowed it to be used without error.)
On the PC side, the password setup was unreliable for Windows 95/98, and for Windows NT, because it required a registry edit to enable plain text passwords. Since well over 50% of our systems and 95% of main servers are Unix machines, the obvious solution was to install an NFS client on the Macs and PCs. After some diligent and obscure searching, I found a solution for both platforms, IntragyAccess, from Ascend Communications. IntragyAccess is a suite of TCP/IP applications, including an LPR client and Server, an FTP server, and, most importantly, an NFS client. By installing the NFS client on both the PCs and the Macs, we were able to complete most important part of the puzzle: Unix fileserver access. To handle the issue of non-Unix file access, for things like PC to Mac filesharing,we implemented two solutions .
First, we purchased a G3/300 AppleShare IP (ASIP) server. Version 6.0 of ASIP supported Windows access via Server Message Block (SMB) protocols, so this Mac is able to function as a network install point for both the PC and Macintosh machines. Due to the implementation of a LPR server in ASIP 6.X, it has also, on occasion, functioned as our backup printer server. The server is also our Retrospect server, and has 3 sets of mirrored hard drives, and backs up to a seven - tape Digital Linear Tape, (DLT) changer, and also holds a Zip, and a 2GB Jaz drive. (The floppy was pulled to make room for the Jaz.) The G3 server is also running FilmakerPro as one of the main applications on the corporate intranet. To allow the PCs and Macs to share files easier, we have begun to install DAVE, from Thursby Systems. This allows the Macs to use SMB as a filesharing protocol for two - way file access between Mac and PC systems. DAVE is essentially an IP-based NetBIOS stack for the MacOS, so it fits in nicely with our network strategy.
Conclusions
Although the complete changeover described took a year, and went on simultaneously with a lot of other projects, it has been worth it so far. Cross-platform file access (considering we have more than 3 versions of Unix, that is a bit more than the usual meaning of cross-platform) has improved in both speed and reliability. With all our printing routed through the same server queues, monitoring and handling print jobs has become much easier. Although the printer hardware is no faster, the spooling process is faster and the users are quite pleased. Currently, unless a Mac to Mac file transfer is taking place, almost 100% of all traffic on our network is TCP/IP, and we are able to maintain an average speed of 6+Mb/sec on our 10BaseT Ethernet lines. In short, it has been a rousing success.
That is not to dismiss the effort behind the upgrade. This was a year of hard, and often frustrating work. Neither PCs or Macs really are yet designed for 100% TCP/IP utilization, but it is getting much easier. It takes a lot of planning, diligence, and discipline to stay focused on what can be an ephemeral goal, but the end result is a better used and maintained network, that can easily handle almost any client.
Resources
John Welch (jwelch@aer.com) is an I.S. Professional at a weather and atmospheric science company in Cambridge, Mass. He has over fifteen years of experience at "making computers work." He has worked on almost every platform, and is keeping his options open.
