A supplement to Novell's CNE Study Set -- IntranetWare/NetWare 4.11
by David James Clarke, IV

Featuring: 

• NetWare 4.11 Operating System 
• IntranetWare TCP/IP 
• IPX/IP Gateway 
• The Novell Web Server 
• FTP Services for IntranetWare 

The Internet and World Wide Web can be very intimidating at first. But don't let them fool you. The WWW is simply an electronic mechanism for publishing multimedia documents. The analogy of an information superhighway appeals to many because they can visualize themselves cruising the "Infobahn" at the speed of light. To extend the analogy further, your browser (Netscape Navigator, for example) is a friendly, graphical "sportscar" and Web sites are "cities." Each city has a variety of "buildings" that you can visit -- Web pages. These multimedia Web pages are published using HyperText Markup Language (HTML). Addionally, TCP/IP is the "concrete" of the Infobahn and HTTP (HyperText Transfer Protocol) is "cyber-fuel." Finally, the IPX/IP Gateway provides a "bridge" between your local electronic city and the Infobahn. 

In this section, we're going to learn how to use Novell's Web Server to publish multimedia HTML documents from an IntranetWare server. Here's a quick preview: 

 
What is the Novell Web Server?
Installing the Novell Web Server
Configuring the Novell Web Server with WEBMGR.EXE
Troubleshooting the Novell Web Server 

 

TIP Novell changed the name of the Web Server in early 1997. It used to be called the NetWare Web Server. Since Novell's future lies in the hands of IntranetWare, the product name has been changed to the Novell Web Server.

What Is the Novell Web Server?

The Novell Web Server is a set of four NLMs that work together to publish multimedia HTML files to local intranets or the global Internet. These files are read using graphical browsers and the HTTP protocol. All of this magic runs on the foundation of IntranetWare/NetWare 4.11 (as you can see in Figure 540SG-9). (For a quick introduction to Novell's Web Server, see Novell's CNE Study Guide for IntranetWare/NetWare 4.11, pages 1162-63.)

Figure 540SG-9: Novell's Web Server
 
 

Installing the Novell Web Server 

Now that you understand the basics of WWW publishing, let's take a closer look at how Novell's Web Server works. As I mentioned earlier, the Novell Web Server consists of four NLMs that run on the IntranetWare platform (see Figure 540SG-9). Here's a brief description: 

• HTTP.NLM activates IntranetWare's built-in Web Server functionality and initiates the HTTP protocol. This allows the Web Server to handle incoming client requests and serve appropriate HTML documents. Basically, this is the NLM that fuels your workstation's browser. 
• BASIC.NLM is the Basic programming language interpreter. This server module provides support for Common Gateway Interface (CGI) scripts written in Basic. Web pages on the IntranetWare server are much more dynamic when enhanced with CGI scripts. These are the neon lights outside your web site's buildings. 
• PERL.NLM is the Perl script interpreter. Similar to BASIC.NLM, it provides support for CGI scripts written in Perl. 
• NETDB.NLM is the Network Database Access NLM used as an interface between IP services and NDS. When NETDB.NLM is loaded, several APIs are also loaded to support IP services such as NFS, NetWare/IP, and the Novell Web Server. 

From a software standpoint, the Novell Web Server requires TCPIP.NLM for routing communications. In addition, you'll need a unique IP address for each Web Server. Finally, you may consider adding LONG.NAM name space support for Java applets. (For more details on IntranetWare name space support, see Novell's CNE Study Guide for IntranetWare/NetWare 4.11, pages 1195-1197.) 

 

REAL WORLD Java is an object-oriented, platform-independent, multithreaded programming language for multimedia and animation Web authoring. Java applets are precompiled Java programs that can be embedded in an HTML document. When used with a Java-enabled browser, the applets' code is transferred from the Web Server to the browser system -- where it is run. We're talking fireworks, here!  Java applets use the .class filename extension. Since these filenames are longer than the allowed 8.3 NetWare naming convention, you'll need to activate LONG.NAM to support Java applets. Also, keep in mind that name space support requires additional RAM. The recommended limit of 32MB is starting to look more reasonable.  Once you've satisfied the server's hardware and software requirements, it's time to install Novell's Web Server. This can be accomplished from a locally mounted CD-ROM or remote server. Both methods use the same instructions; however, a remote server installation will require NDS authentication.  To install the Novell Web Server on an IntranetWare platform, follow the instructions outlined in Novell's CNE Study Guide for IntranetWare/NetWare 4.11, pages 1164-1167.)

Once the Novell Web Server has been installed, it can be activated (and deactivated) using two special startup files. The first one is called UNISTART.NCF and is stored in the SYS:SYSTEM subdirectory. It includes the following Web Server startup commands: 

• LOAD NETDB.NLM 
• LOAD HTTP.NLM -D SYS:WEB 
• LOAD BASIC.NLM -D SYS:WEB 
• LOAD PERL.NLM 

Congratulations, your Novell Web Server is alive! Hang ten! Now, all you need to do is figure out what to do with it. 

Remember, the Novell Web Server allows you to publish multimedia HTML documents to internal intranets and external extranets (such as the Internet). By default, everybody can see everything. While this is a good idea to propagate cyber-utopia, you may consider spending a little time in the "real world" and try customizing Web Server access restrictions. This and many more configuration tasks can be performed using IntranetWare's built-in graphical Web manager utility, called WEBMGR.EXE. Let's take a closer look. (Novell Web Server installation and management tasks are covered in much greater depth in Novell Education Course 656: Web Server Management.) 

Configuring the Novell Web Server with WEBMGR.EXE

The good news is that your Novell Web Server is up and running. The bad news is that nobody can find it. 

Until you configure Name Services, the Novell Web Server can be identified only by its 32-bit IP address -- such as 206.127.205.127. Granted, there are a few "supernerds" in the world who prefer to speak in binary terms, but chances are, most normal humans prefer to speak alphanumerically. Name Services accommodates humans by converting complex IP addresses to normal words. For example, "206.127.205.127" becomes "World-Wire.com." 

You have two choices for activating Name Services on your Novell Web Server: Host Table or Domain Name Services (DNS). (For more information, consult Novell's CNE Study Guide for IntranetWare/NetWare 4.11, pages 1168-69.) 

That's better! Now your Novell Web Server is up and running, with a friendly neon sign outside welcoming users in. At this point, Web Server configurations are in a default state -- that is, Novell made all the assumptions for you. Is this a good idea? It depends on your level of expertise. Mortal humans can probably live happily with the Novell Web Server defaults. CNE Superheroes, however, have greater responsibilities. Remember, the fate of the global electronic village hangs in the balance. It's time to exercise your IntranetWare talents using WEBMGR.EXE. 

Novell's Web Server Manager (WEBMGR.EXE) is a Windows-based configuration utility that handles everything from HTML documentation to user-access restrictions. This is probably your most valuable and powerful cyberspace tool. 

WEBMGR.EXE is stored in the SYS:PUBLIC subdirectory, by default. Because it's a Windows-based utility, you may want to create a program icon or shortcut for automated launching. In either case, make sure the client computer has a drive that maps directly to the SYS: volume of your Novell Web Server before you begin. 

Once you activate WEBMGR.EXE, you see a gray intro screen. To open an existing Web Server configuration, choose File and then Select Server from the menu bar. You are then prompted for the root directory of the Web Server. By default, it's SYS:WEB. Make sure you provide the full IP address or host name for your Web Server. This information is required. 

Once you've chosen your Web Server, the WEBMGR Configuration Screen appears (see Figure 540SG-10). The Configuration Screen includes five tab buttons for Web Server management. They are: 

• Server 
• Directories 
• User Access 
• System Access 
• Logs 

Let's take a closer look. 

Server Configuration with WEBMGR

As you can see in Figure 540SG-10, the Server configuration tab includes seven important fields. These values control what the Web Server looks like and how it operates. Here's a quick list: 

• Full Server Name -- Should already contain the host DNS name or the IP address you specified during installation. This field is required. 
• TCP Port -- Earlier, we were introduced to ten common Internet services. They are based on specific port numbers. By default, the Novell Web Server will accept HTTP requests on port 80. This is the World Wide Web. For a detailed list of services and corresponding port numbers, refer to Table 540SG-3 in the IPX/IP Gateway section. 
• Administrator's E-mail Address -- The default Web Master's e-mail address. This is a central depository for user problems. Choose wisely. 
• Directory Containing HTML Documents -- By default, the document root directory is SYS:WEB\DOCS. This is where users are initially dropped to access multimedia Web pages. You can customize the document root directory as needed. By default, users get Read and File Scan privileges to this part of the directory tree. 
• Directory Containing Log Files --The Novell Web Server uses log files to track server access. By default, these files are stored in the SYS:WEB\LOGS subdirectory. You can customize this directory as needed. 
• Enable User Documents -- If you want to allow users to publish their own Web documents from their home directories, check the Enable User Documents box. Then, type the name of the subdirectory in the User Subdirectory field. Keep in mind that this subdirectory is relative to the user's home directory -- which is typically SYS:USERS\username. 
• Enable NDS Browsing -- Allows your global villagers to stroll through the NDS tree using the built-in NDS browser. This feature is turned On by default. 

 

 
 
 
 
 

The Directories tab allows you to configure specific areas of the Web Server file system. First, you select the directory, and then you add, change, or remove it. These directories handle HTML documents, image files, scripts, and CGI applets. 

When you add a new directory using WEBMGR, it inherits the directory options and access control settings of the parent. This saves time. If you'd like to create a directory with different access control settings, however, WEBMGR is glad to help. Follow along with Figure 540SG-11: 

• Existing Directories -- simply highlight an existing Web Server directory to work on. This window can also be used to remove an existing directory configuration. 
• Directory Path -- an input box used for adding new directories. 
• Contains -- a drop-down list that indicates the type of files the Web Server directory can contain. 
• Features -- enables you to activate Indexing and/or Includes. If you activate Indexing, the Index Options list appears. 

User Access Configuration with WEBMGR 

The Novell Web Server enables you to restrict user access to important document and configuration directories. When you activate this feature, the Web Server authenticates the user's NDS object before fulfilling a document request. This level of customization is accomplished using the User Access tab within WEBMGR. Check out Figure 540SG-12. Here's how it works: 

• Directory -- a drop-down list which allows you to choose any directory from the previous Directories tab. 
• Authentication Method -- select Directory Services for NDS authentication. 
• NDS Context -- indicates the context where your NDS User objects reside. 
• Network Users -- once you choose an NDS context, the Network Users window lists all valid User objects in that context. Simply select an authorized user from the list and click the Add to Authorized Users List button. 
• Authorized Users -- a second user window which lists all users who are authorized to access the selected directory. 

 

REAL WORLD By default, Novell Web Server access control restrictions are enabled on a per-directory basis. This means they don't flow down through the file system like all other access rights. If this bothers you, deactivate per-directory access control by following these steps:  Use any text editor to modify the ACCESS.CFG file in the SYS:WEB\CONFIG subdirectory.  Locate the directory entry corresponding to the parent directory in which you want access control flowing to begin.  Edit the AllowOverride statement to read:  AllowOverride none Save the file.

In the previous section, we learned how to restrict access to Web Server directories by user. WEBMGR also enables you to restrict directory access by village -- thati is, by IP address and/or host name. When you activate System Access restrictions, the Novell Web Server checks the client's IP address or host name before fulfilling a document request. Check out Figure 540SG-13. Here's how it works: 

• Directory -- Like User Access restrictions, this drop-down list identifies the directory you want to manage. 
• IP Address or Domain Name -- An input window that identifies the authorized IP address or host name. Interestingly, you can restrict directory access by full or partial IP address. For example, if you restrict directory access to 206.127.205.131, only clients within the CyberState host can access documents in this directory. However, if you restrict according to a partial IP address (such as 206.127.205), anybody within the 206.127.205.0 subnet will be able to access documents in this directory. That includes clients from up to 254 IP hosts. Finally, you can restrict directory access according to a specific DNS Domain Name (such as novell.com). This way, only clients within the novell.com domain can access documents in this directory. 
• Authorized Systems -- Once you choose an IP address or host name, you can authorize the system using the Add to Authorized Systems List button. Once you do so, the authorized system will appear in the Authorized Systems list. 

As with the previous tab, System Access restrictions do not flow down the file system. Use the "Real World" trick from the previous section to disable per-directory access control. 

Log File Configuration with WEBMGR 

The Novell Web Server enables you to customize the way log files are updated and stored. The Logs tab provides the following options (as shown in Figure 540SG-14): 

Log File Handling -- contains option buttons that indicate whether the Web Server starts a new log file when the current one reaches its maximum size. By default, ACCESS.LOG is archived to ACCESS.1 when it reaches its maximum size. If you choose not to roll the log files, the server keeps adding to them until the maximum size is reached or until you manually clear it. 

Server Debug Log Options -- contains option buttons that indicate whether the Web Server generates a debug log. This is a valuable option for Novell Technical Support, but it'll probably be "Greek" to all other humans. 

Maximum Log Size --sets the maximum size of the log files in kilobytes. Once a log file reaches its maximum size, the system rolls it into a backup archive and continues logging in a new file. This feature is controlled by the Log File Handling options. 

Maximum Number of Old Logs -- sets the number of old log files the system stores. This value only means something if the Web Server has been customized to roll logs. When the SYS:WEB\LOGS directory contains the maximum number of old log files, the Web Server deletes the oldest one before opening a new log. 

 

 
 
 

Figure 540SG-14: Log File Configuration with WEBMGR.EXE
 
 

Once you've customized any of the previous five WEBMGR configurations, you must restart the Web Server for them to take effect. First, click OK in the WEBMGR configuration screen. Then, click the Save and Restart button. You'll be prompted for the Web Server password. Type the password in the space provided and click OK. Keep in mind, however, that your client must be configured for TCP/IP communications in order to restart the Web Server using WEBMGR.EXE. Otherwise, the utility saves your changes but does not restart the server. In this case, you can restart the Web Server manually at the server console prompt: 

• Unload HTTP 
• Load HTTP 

Now that you've installed, activated, and configured your Novell Web Server, there's only one task left: troubleshooting. Unfortunately, things go wrong . . . even in virtual cyberspace. Let's take a closer look. 

Troubleshooting the Novell Web Server

In general, the Novell Web Server is a robust Internet publishing device. While it rarely breaks down, the Web Server's performance is sensitive to a variety of internal and external pressures. As an IntranetWare CNE superhero, you should understand the impact of three vital Web Server performance components: 

• MaxThreads 
• Maximum Packet Receive Buffers 
• Web Server content 

MaxThreads

The MaxThreads parameter specifies the total number of worker threads the server can assign at any given moment. It's important to note that each HTTP request from a Web client starts a new worker thread. 

By default, the Novell Web Server maintains a main thread and 16 associated worker threads. When the Web Server is activated, the main thread connects and binds to TCP/IP and then listens for HTTP requests from the default port -- 80. When a request is received, the main thread assigns it to a worker thread and then returns to its listening post. Worker threads then process the HTTP request. 

If all 16 worker threads are busy, however, the listen queue is full. Any further client requests are then left unanswered. This causes a variety of reactions from client browsers -- ranging from a "wait signal" to a full "time-out." 

As an IntranetWare CNE, you can monitor and adjust the Web Server MaxThreads parameter. At startup, the default value of 16 should be adequate. As Web activity increases, however, you may consider upgrading MaxThreads as appropriate. The maximum value is 256. Keep in mind that Web Server optimization is a delicate balance. Increasing the number of MaxThreads may not immediately increase performance. This is because each thread requires approximately 32KB of memory plus internal CPU resources. Running more threads concurrently takes up more server memory and processing time. 

Before adjusting the MaxThreads parameter, consider the following: 

• The memory available on the Web Server. 
• The expected number of inbound requests. 
• Whether any PERL, Basic, or CGI programs are being used. These services require additional threads or memory. 
• The memory and CPU requirements of any IntranetWare or third-party products that are also installed on this server. 
• Additional memory required by the server to support LONG name space. 
• To find the right balance between performance and MaxThreads, consider monitoring the HTTP server console for at least a week. The most important field on this screen is Peak Requests. This is a two-numbered field that indicates the maximum concurrent requests handled by the Web Server since it was loaded as compared to the current MaxThreads setting. If the number of peak requests exceeds 75 percent of the maximum, you may consider increasing the number of MaxThreads. 
• To increase the MaxThreads parameter, use a text editor to open the HTTPD.CFG file, which can be found in the SYS:WEB\CONFIG subdirectory. Modify the line below to reflect a new number: 

MaxThreads 16

• When you've finished, save the HTTPD.CFG file and restart the Web Server using UNISTOP.NCF and UNISTART.NCF. 

Maximum Packet Receive Buffers

Along with internal processing, communications support can have a dramatic impact on Novell Web Server performance. After all, MaxThreads don't mean anything if the client requests can't find their way to the Web Server. This performance component is handled by two server parameters: 

• Maximum Physical Receive Packet Size 
• Maximum Packet Receive Buffers 

To increase the Maximum Physical Receive Packet Size at the Novell Web Server, use SERVMAN.NLM. First, select Server Parameters and then Communications, and finally Maximum Physical Receive Packet Size. Next, enter the packet size for your network and press Enter. Press Esc twice and select Update and then AUTOEXEC.NCF and then STARTUP.NCF. Keep in mind that the Maximum Physical Receive Packet Size parameter must be included in STARTUP.NCF, so you'll need to DOWN and restart the server before it takes effect. 

Once you have the packet size under control, you may consider optimizing the amount of memory allocated by the server to receive incoming packets. This is accomplished using the Maximum Packet Receive Buffers parameter. By default, the IntranetWare server allows 100PRBs; however, Novell Web Server installation automatically increases the value to 1,000. This is important because each HTTP client request occupies a Web Server PRB. They can add up! 

Remember, Web Server optimization is a balancing act. Increasing Maximum PRBs will drain available server memory. If you're sure you have enough memory to support more PRBs, use SERVMAN.NLM to increase the value of this parameter at the IntranetWare server console. Just like the previous communications parameter, Maximum PRBs can be set in either the AUTOEXEC.NCF or STARTUP.NCF server configuration files. You'll need to DOWN the server and restart it so that the buffers become available. 

 

REAL WORLD It's important to remember that Web Server optimization is a balancing act. You'll need to make sure that the server has enough available memory to support an increase in Maximum PRBs. You can determine this with a simple calculation. Multiply the Maximum Physical Receive Packet Size by the increase in Maximum PRBs. Because each packet occupies a buffer, this calculation will tell you how much memory you need to support the new communications configuration.

Most Web Server performance problems can be traced to available MaxThreads or communication buffers; however, you can't ignore the type of content your Web Server is publishing. 

For example, large graphic files (up to 600KB) will take much longer to transfer than small text files (often less than 40KB). Additionally, multimedia, audio, and video can place a huge performance load on Web Server communications. For example, a stereo, one-minute audio clip can grow as large as 10MB. When you add video, the file size can double (to 20MB). 

Because each HTTP request uses a new thread, large multimedia files tie up threads for a long time. This dramatically impacts Web Server performance. 

Finally, HTML features (such as CGI scripts and imagemaps) can also affect Web Server performance. These services require considerable internal processing. If you don't limit the number of imagemaps and scripts on a Novell Web Server, you may find that they adversely affect server performance by slowing down response time or causing client packets to be dropped. The bottom line is: Nobody cares how fancy your Web site is if they can't access it. This is the equivalent of having a fantastic hotel just off the information superhighway ... with no parking! 

This completes our lesson in Web site construction using Novell's Web Server. Hopefully, you've gained an appreciation for what's involved in constructing buildings for our global electronic village. Novell has done a marvelous job in creating a Web Server that's simple to install, yet highly configurable. Additionally, with a little performance fine-tuning, users can access the Web Server almost at the speed of light. You can't ask for much more than that. 

Now, let's complete our journey through Novell's global electronic village by exploring the final cyberspace component -- FTP Services for IntranetWare. This is how virtual villagers transfer files. 

Forward to FTP Services for IntranetWare

Back to IPX/IP Gateway

Back to Cramsession