http://www.byte.com/art/9601/sec9/art1.htm (PC Press Internet CD, 03/1996)
Server ManagementThe sun never sets on The BYTE Site. Once I launched it, I became responsible for a service that a growing international clientele expects to be able to use 24 hours a day, 365 days a year.
How do you keep this kind of service humming? Two crucial variables -- the World Wide Web server application and the OS -- govern your management options. Here's a look at some combinations I've tried so far.
NCSA Server, BSD/OS
The most manageable Web servers run on Unix (or Unix-like) OSes. Consider the Dell PC on which I've been running the National Center for Supercomputing Applications (NCSA) server + BSD/OS combination. It's a headless box; I borrowed the monitor long ago and never returned it. Why bother? A telnet window on another workstation -- located on the local Ethernet or anywhere on the Internet -- is fully equivalent to the Dell's missing console. I can dial BIX from a DOS subnotebook, telnet to the Dell, stop the NCSA server, launch EMACS, edit the server's configuration files, and restart the server.
If the server and its related utilities were GUI-oriented rather than command-line-oriented applications, they could export the same control capabilities using the X Window System. You'd need more than a DOS subnotebook to run the X server, of course. But the point is that location doesn't matter in Unix computing: You can do just about anything from anywhere.
A healthy Web server needs to be running on a healthy system, of course, so the scope of the management task goes beyond just monitoring the httpd (the Hypertext Transport Protocol daemon) itself. You also have to pay attention to ftp and mail services; organize, prune, and back up files; and read and analyze system logs.
Unix doesn't make any of this easy for a novice, and mastering the seemingly endless number of interactions between shell scripts and configuration files requires a huge investment of time and effort. But advanced users leverage that investment by packaging routine management tasks into shell scripts and scheduling them to run periodically. Automation and remote access are the keys to effective system management. Unix shines in both departments.
Netscape Commerce Server, Windows NT
Telnet and EMACS get the job done, but should you really have to depend on 25-year-old character-mode tools? A number of second-generation Web servers, led by Netscape's, export management interfaces as Web applications. The Netscape server's administrative tool set has two parts: a collection of Hypertext Markup Language (HTML) forms that document the tasks a web master can perform -- creating a user database, viewing a log, securing a directory -- and a corresponding set of Common Gateway Interface (CGI) programs that perform those tasks.
When you install a Netscape server, you really install two servers attached to different TCP/IP ports. The public server, www.byte.com:665 in my case, presents a home page. The administrative server, which I set up at www.byte.com:666, presents an authentication dialog box and then a page of management options.
Why a separate server? One key administrative task is stopping and starting the primary server. Because the Netscape server's process control depends on CGI, you might be able to shut down the primary server using its own CGI mechanism, but you'd be sawing off the branch you're sitting on.
Because it leverages Web technology, Netscape's server administration enjoys the same portability as all other Web applications. Local and remote X, Microsoft Windows, and Mac browsers all run the administrative applications identically. On the server side, the CGI wrapper provides the same capabilities on any server OS. For example, I ran the Netscape Commerce Server on Windows NT, which lacks the remote access features that Unix provides. No matter. A user of Netscape's administrative tool set doesn't have to know what OS underlies the server.
WebStar, Mac System 7.5
A new member of The BYTE Network Project's family of Web servers is the Apple Internet Server, a Power Mac 6100/60 running StarNine's WebStar. Currently this machine is running as an intranet server -- it's connected only to the BYTE LAN, not to the Internet. I've mirrored the contents of The BYTE Site onto the WebStar server, and I'm now using it to collaborate with BYTE's design department on a redesign of the site's graphics.
WebStar's administrative application handles the usual chores: defining users and groups, configuring logging and suffix mapping, and tweaking communications buffers. It communicates with the WebStar server entirely by means of Apple Events. This means that on a LAN, you can administer WebStar from any Mac, since Apple Events readily cross machine boundaries on an AppleTalk network. This scheme won't work on an IP network, however. This is because even with Open Transport, Apple's latest transport-independent technology, core Apple networking services, such as file sharing and Apple Events, can't yet ride on IP.
What to do? Eric Zelenka from StarNine pointed me to a CGI application called RemoteAdmin.acgi (not shipped with the Apple Internet Server, but available from http://www.starnine.com). It exports an HTML forms interface to WebStar's administrative functions.
Like Netscape's approach, this arrangement affords both remote access and portability. Any browser, whether Mac-based or not, can now control a WebStar server over the Internet. The browser speaks HTML to RemoteAdmin.acgi, which in turn sends Apple Events to WebStar (see the figure "Managing WebStar on an AppleTalk Network"). Because the System 7.5 Finder can itself be driven by Apple Events, it should be possible to write a more ambitious CGI application that can manage files on a Mac server, operate Control Panels, and even restart a Mac.
WebSite, Windows NT
O'Reilly and Associates' WebSite provides a suite of Win32 management tools, including Server Admin, which controls security settings, data-type mappings, and transaction logging. It's really just an interface to the Windows NT (or Windows 95) registry where WebSite stores the values of its control variables.
Because the NT and Windows 95 registry editors are remote procedure call (RPC) enabled -- that is, you can point one machine's copy of RegEdit at another's registry, even across the Internet -- WebSite is as capable of the same sort of limited remote management as any Windows 95 or NT application that stores configuration data in the registry. To make RegEdit work across the Internet, add a line like
192.168.1.1 MYSERVER
to the WINDOWS\LMHOSTS file. This line maps the target machine's IP address to a NetBIOS name that Windows networking services, such as RPC, require. (See "Wide-Area Windows Networking," January 1994 BYTE, for more on NetBIOS-over-TCP/IP.)
This setup works, but it's slow over dial-up IP because RegEdit uses a slow link inefficiently. To improve performance and simplify the interface, WebSite's designers made Server Admin RPC-enabled. From my Windows 95 machine at home, I can tweak WebSite registry values on an NT server at BYTE over the Internet.
But while Server Admin works well in RPC mode, I've had poor luck using another tool, WebView, to remotely scan The BYTE Site for broken hypertext links. With WebSite, as with Windows NT in general, RPC-based remote administration is a hit-or-miss affair. You must specifically modify each application that exports a control interface through RPC, and even then your mileage varies, depending on the characteristics of the administrative application and its data.
So what's the general solution for remote management of NT systems and applications? Enter WinFrame.
Purveyor, WebSite, and WinFrame
Citrix Systems' WinFrame transforms Windows NT into a multiuser OS with a flexible and efficient remote GUI. For the past month, WinFrame has been running on one of The BYTE Site's development servers (a dual-processor Intergraph TD-4), and it has revolutionized how I develop and manage the site.
Check out the screen showing The BYTE Site's WinFrame command center. You're looking at my home Windows 95 PC on a 28.8-Kbps dial-up link to the Internet. The window titled "TD4" is a projection of the Intergraph server's console, and it could just as easily appear on a LAN- or dial-up-connected Windows 3.1 or DOS machine, or on one of the new WinFrame-aware terminals from Wyse.
There are a lot of things going on at once in this window. A detailed description follows.
WebView. The WinFrame server is running WebSite. In theory, I can scan its web from home using WebView's RPC capability. In practice, this process works faster and more reliably when I run it directly on the server and export its user interface using WinFrame.
Perl. The MS-DOS icon represents an instance of Perl running a script that summarizes the IP addresses in the production server's log.
Performance Monitor. Here I'm watching two Web-server processes: WebSite on the WinFrame and, through the WinFrame system, Process Software's Purveyor on the production Windows NT/Alpha machine. The WinFrame box can see the Alpha/NT box's Performance Monitor, because vanilla NT's Performance Monitor is RPC-enabled.
Until I installed WinFrame, I couldn't remotely monitor the Purveyor process because I couldn't directly access the Purveyor box's Performance Monitor. Ditto for Event Viewer, shown here watching both systems' event logs. Ditto also for Registry Editor, Server Manager, and User Manager.
File Manager. With megabytes of log data and reports accumulating every day, my server management routine involves slinging a lot of files around. With the two servers' file systems cross-mounted, I can run plain old NT File Manager on WinFrame's remote console and effectively manage both.
Users of Purveyor 1.1 will especially like being able to use File Manager remotely. Although 1.1 exports all its Control Panel functions to remote Web browsers by means of CGI/HTML, you still have to use a File Manager extension to set permissions on uniform resource locators (URLs). Purveyor on Windows NT can't export that function to remote administrators; Purveyor on WinFrame can.
Control Panel. Under Unix, GUI administrative tools are just wrappers around more-primitive command-line tools; that's why you can manage Unix remotely using just telnet. NT's versions of these tools are natively graphical, so they're easy to use, provided you're sitting at the console. But even if you use a third-party telnet on NT, you can't stop, reconfigure, and restart the system services that the Control Panel controls. WinFrame exports control over these vital services to the remote administrator running Windows 95, Windows 3.1, or even lowly DOS.
Back to the Future
So far I've described only the benefits of Windows NT remote control. WinFrame is currently the only player in this field. None of the Windows 3.x remote-control programs has yet stepped up to the plate, nor has Microsoft's own Systems Management Server. When they do, will Citrix wind up on the bench?
I don't think so. WinFrame's remote GUI is a godsend for the manager of an NT-based Web server, but its multiuser dimension makes it much more than just an NT remote-control product. The Citrix vision of Web-based computing represents a serious alternative to both the existing CGI/HTML standard and the distributed-component architectures currently being advanced by Sun and Netscape (Java) and Microsoft (Blackbird).
Consider the suite of Web-based tools I'm now writing to support administration of the Virtual Press Room (see "Perl Magic," December BYTE). First-generation Web technology dictates a CGI/HTML solution. That's doable, but if you've been following my CGI adventures, you know that mimicking a live GUI using a series of forms-based transactions can get hairy.
Second-generation Web technology (the Java/Blackbird approach) promises to export the live GUI through the Web as a dynamically acquired component. Sounds great, but I won't deliver tools next month based on Java or Blackbird; these technologies aren't ready yet.
WinFrame, in contrast, relies on old-fashioned development tools, such as Visual Basic and Delphi. And it updates the even-more-old-fashioned mainframe- or X-like model of computing, enabling Visual Basic/Delphi applications to run on a multiuser host with local access to data while displaying on Windows terminals.
Too retro for your taste? By the time you read this, Citrix will have shown a Web browser that displays off-the-shelf Windows and Win32 applications running on a WinFrame host located across the Internet. I'm bullish on Java and Blackbird, too, but there are a lot of Windows applications kicking around, and Citrix's approach ought to make you stop and think.
WinFrame also pours fuel onto the NT-versus-Unix debate. John Montgomery, who edits this column, neatly frames the issue this way: "NT gets you from zero to 60 more easily than Unix, but you need Unix to get from 60 to 100." I agree. And now that I've experienced the power of Citrix's Unix-like extensions, I'll never want to settle for vanilla NT.
TOOLWATCH
Microsoft Paint (included with Windows 95)
Microsoft Corp.: http://www.microsoft.com/
Not until I hit the road with a Windows 3.1 notebook and then needed to tweak some icons for the site did I realize how dependent I've become on the handy new bit-map-editing features of the Windows 95 version of Paint. Now if only it would read and write GIFs...
BOOKNOTE
Building Internet Firewalls, by D. Brent Chapman and Elizabeth Zwicky
O'Reilly and Associates, 1995 ISBN: 1-56592-124-0 Price $29.95 (http://www.ora.com/)
Perimeter networks, dual-homed bastion hosts, proxies, and screening routers all loom on my horizon. Fortunately, Chapman and Zwicky, who have been there and done that, have written the practical handbook I've been waiting for. This book will become another well-thumbed O'Reilly classic.
On an AppleTalk network (left), WebStar's administrative application can talk to the WebStar server locally, or across the network using Apple Events.
On the Internet (right), you can use any Web browser to talk via HTTP to Remote Admin, a CGI application that in turn speaks via Apple Events to the WebStar server.
Here's my home Windows 95 machine displaying the console of one of The BYTE Site's development servers: an Intergraph TD-4 running Citrix Systems' WinFrame (a Windows NT extension) and O'Reilly and Associates' WebSite. Finally there's a way to manage an NT system from afar.
Copyright © 1994-1995
