Most network management functions for a NetWare 4.x server can be performed by managing its object representation in the NDS tree using tools such as NETADMIN and the NetWare Administrator. Some network management functions, however, can be done only at the server console.
This chapter discusses some of these server management functions and the programs that perform them.
Programs that run on the server machine are written in such a manner that they can interface correctly with the NetWare operating system that runs at the server computer. These programs are different from the familiar .EXE and .COM programs used by DOS, OS/2, Windows NT, and Windows 95 workstations. Just as the .EXE and .COM programs interact with DOS, the programs that run at the server must interact with the NetWare operating system functions. These server programs are called NetWare Loadable Modules (NLMs).
NLMs are different from DOS .EXE and .COM program files in some significant ways, however. DOS programs run under the control of DOS, but they do not become part of DOS.
When NLMs run, they hook into the NetWare operating system, as seen in figure 7.1. Once hooked, the NLMs run as part of the operating system itself. Another way of understanding this process is to think of the NetWare operating system as producing a software NLM bus to which other NLMs can attach in the same way that adapter boards can be attached to a PC's internal bus. Figure 7.2 shows this conceptual view of the software NLM bus. The software NLM bus can support a variety of different NLMs that enhance the capability of the NetWare operating system. Some of the NLMs shown in figure 7.2 include the following:
Disk drivers (.DSK extension)
LAN drivers (.LAN extension)
Network Management NLMs (MONITOR.NLM, SERVMAN.NLM, and so on)
Communications; Additional protocol module support (TCPIP.NLM, APPLETLK.NLM, and so on)
Network Printing Support (PSERVER.NLM, NPRINTER.NLM)
Name space support NLMs (.NAM extension)
Language Support (KEYB.NLM, and so on)
Media Management
Server Monitoring
Uninterrupted Power Supply (UPS)
Application NLMs and gateways
Data Migration
Figure 7.1 NetWare Loadable Modules and NetWare core OS.
Figure 7.2 NLM software bus.
NetWare Loadable Modules typically are stored in files that have an .NLM extension. As you can see from the preceding list, special NLMs might have a different extension that indicates the function they perform. LAN drivers have a .LAN extension, disk drivers have a .DSK extension, and name space support NLMs have a .NAM extension. Table 7.1 summarizes the different NLM extensions.
Table 7.1 Common Extensions Used for NLM Names
NLM Extension | Meaning |
.DSK | Disk driver |
.LAN | NIC driver |
.NLM | Management utilities, server applications |
.NAM | Name space modules |
NLMs were introduced to enable NetWare 3.x to have a more dynamic and flexible system configuration for the NetWare operating system. NetWare 4.x uses NLMs for the same purpose. You should, however, be aware that NetWare 3.x NLMs and NetWare 4.x NLMs are not 100 percent compatible. Some of the system APIs (Application Programming Interfaces) have changed, so you should upgrade your NLM applications to those that are designed to run with NetWare 4.x.
PRACTICAL TIP: If you are running NetWare 3 NLMs or NLMs written to NetWare 3 API standards, you will get the following message:SERVER-4.10-1587: This module is using 1 outdated API call. You should upgrade to a newer module when it becomes available.
This is not a serious error message provided that is the only effect of running the old NLM.
NLMs also remove the need for static linking, which was used in NetWare 2.x in which object modules selected during the installation process were bound together. The static linking mechanism is called NetWare generation for NetWare 2.x.
NLMs enable software modules that run at the server to be linked at runtime, or at the time they are loaded in memory. This linking at runtime is called dynamic linking. Readers familiar with OS/2 or MS Windows might have heard of DLLs (Dynamic Link Libraries). The Dynamic Link Libraries in NetWare 3.x are called NetWare Loadable Modules (NLMs). NLMs are more than DLLs; they actually are processes or tasks that run under NetWare: Dynamic Link Libraries + Processes = NLMs NLMs can be viewed as a group of cooperating software tasks or engines.
NLMs are activated by typing the command LOAD followed by the name of the NLM:
LOAD NameOfNLM
NLMs that come with NetWare are installed on the SYS:SYSTEM directory on the server. The LOAD command, therefore, searches the SYS:SYSTEM directory for NLMs. If NLMs are installed in another location, their full path name needs to be specified or their location made known by using the SEARCH command at the console. To add SYS:MANAGE to the search path, issue this command:
SEARCH ADD SYS:MANAGE
The search path SYS:MANAGE is added at the end of the search path list. To make SYS:MANAGE the first path to be searched, use this:
SEARCH ADD 1 SYS:MANAGE
NLMs can be deactivated by unloading them via the UNLOAD command followed by the name of the NLM:
UNLOAD NameOfNLM
PRACTICAL TIP: Most NLMs come with their own internal unload procedures. It is always preferable to use the exit option within the NLM rather than a forced unload from the console.
When an NLM is loaded, it takes up a certain portion of the server RAM and competes with other processes for CPU time. The amount of memory taken by an NLM can vary depending on the task being performed and the size of its code. The actual amount of memory used can be monitored using the MONITOR.NLM. Some NLMs make system calls to allocate additional memory for the tasks they are performing. Also, this requested memory can be released during execution. The actual size of the NLM, therefore, can vary during execution. When an NLM is unloaded, all allocated resources (called resource tags) are returned to the NetWare NOS.
NLMs are written by Novell or third-party developers. Currently they are written using WATCOM's or MetaWare's 32-bit C or C++ compilers. NLMs may depend on other NLMs before they can run. The RSPX.NLM, for example, cannot be loaded until REMOTE.NLM is loaded. Also, when an NLM is loaded, it is expected that all the external interfaces it needs are already in memory. An NLM can be written to automatically load (autoload) other NLMs that it needs. If an NLM is not written to autoload its dependent NLMs, and if it cannot find the dependent NLMs already loaded in memory, an error message about unresolved external references is reported and the NLM will not load. Certain NLMs such as network card or disk drivers can accept command- line parameters or options to modify their behavior. The actual options depend on each NLM and are embedded in the program code for the NLM. In the case of disk driver and LAN adapter NLMs, if the required options are not specified, you are prompted for the parameter values. The SMC8000 NLM, for the Standard Microsystems EtherCard PLUS adapters, for example, can be loaded in the following two ways:
LOAD SMC8000 port=280 frame=ETHERNET_802.2
or
LOAD SMC8000
In the first example, all the parameters are specified on the command line in the parameter=value syntax.
In the second example, the parameters are not specified. On loading, SMC8000 prompts the user for these parameter values.
NOTE: Older LAN driver NLMs for Ethernet boards default to using the ETHERNET_802.3 frame type, whereas the newer LAN drivers use ETHERNET_802.2. Because NetWare 4.x uses ETHERNET_802.2 for Ethernet adapters by default, you should be aware of this difference when using older LAN drivers.
The SERVER.EXE file is the program file used to start the NetWare 4 server. It consists of two parts: the NetWare loader and program, and the core operating system called SERVER.NLM. SERVER.NLM and a number of other NLMs, such as the DS.NLM (for NetWare Directory Services), together form the core of the operating system.
The NetWare core includes the following services (see fig. 7.3): Authentication
Directory services
File services
Routing Security Both the core operating system and the NLMs use memory that is managed in a similar manner. Some of the server memory management considerations are discussed next.
Figure 7.3 NetWare core services.
STUDY NOTE: On the CNE exams, you may be asked indirect questions in the form of "what if" scenarios. You may be asked, for example, how you can improve server performance under certain conditions. One of the possible answers may be unloading unneeded NLMs. In general, your answer depends on understanding all of the material covered in this section.
Many of the commands in NetWare 4.x have been enhanced, whereas others have remained the same from a user's interface perspective. NetWare 4.x has a completely redesigned memory architecture that enables it to manage memory from a global pool rather than the separate memory pools of the NetWare 3.x architecture. Therefore, some of the problems of memory depletion from dedicated memory pools that could occur while running NetWare 3.x console commands and utilities have been eliminated.
NetWare 4.x uses the paged-memory architecture of the Intel processors to manage memory in units of 4 KB pages. It does not, however, implement virtual memory in the same way that general purpose operating systems such as Unix, OS/2, and Windows NT do. Virtual memory enables an operating system to swap data and programs between memory and a hard disk; this process is too slow to be of much use in a network operating system such as NetWare, which must provide rapid service to large numbers of users. All of the critical data structures and programs needed for NetWare operation reside in memory. If more memory is needed for applications to run at the server, the memory used for file caching is used up.
A new HELP command is available that enables you to learn quickly the syntax and function of a command. Figure 7.4 shows the output of typing the HELP command. To obtain more detailed help on the command LANGUAGE, you can type this command:
HELP LANGUAGE
Figure 7.4 The console HELP command.
STUDY NOTE: The new console command for obtaining help on console commands is HELP.
Figure 7.5 shows help on the LANGUAGE command. Typing the LANGUAGE command displays the current language (see fig. 7.6).
Figure 7.5 The HELP LANGUAGE command.
Figure 7.6 The LANGUAGE command.
Tables 7.2 through 7.5 show the NetWare 4.x commands of which you should be aware.
Table 7.2 shows the configuration commands.
Table 7.2 Configuration Commands
Commands | Description |
CONFIG | Displays configuration information such as server name, IPX internal number, parameter settings for disk and LAN drivers, and binding information between protocol stacks and LAN drivers. |
DISPLAY SERVERS | Displays servers and hop count information that this server knows about. |
DISPLAY NETWORKS | Displays all network numbers and their hop count/tick information that this server knows about. |
MODULES | Displays a list of loaded NLMs. |
NAME | Displays the server name. |
TIME | Displays server date and time and whether time synchronization is active or synchronized on the network. |
VOLUMES | Displays volumes currently mounted, the name spaces they support, and whether compression, suballocation, and data migration have been enabled. |
UPS STATUS | Displays UPS status. Works only if the UPS NLM is loaded. |
UPS TIME | Displays UPS time. Works only if the UPS NLM is loaded. |
Table 7.3 shows the installation commands.
Table 7.3 Installation Commands
Commands | Description |
LOAD | Used to load NLMs. During installation, disk driver and LAN card NLMs need to be loaded. |
MOUNT | Once a volume is created during installation, it must be mounted before it can be accessed. |
BIND | Provides an association between a transport protocol and the ODI LAN drivers. |
ADD NAME SPACE | Optionally, name spaces for Macintosh, OS/2, and NFS can be added to a volume. |
PRACTICAL TIP: To add Windows 95 name space to a volume, add the OS/2 name space using the following server console commands:LOAD OS2 ADD NAME SPACE OS2 TO VOLUME NAME
Table 7.4 shows the maintenance commands.
Table 7.4 Maintenance Commands
Commands | Description |
CLEAR STATION | Clears a station's connection. Removes all file server resources allocated for the workstation. |
DISABLE LOGIN | Disables logins. Prevents users from logging in while maintenance work is being conducted. |
ENABLE LOGIN | Enables users to log in. Cancels the DISABLE command. Enables ADMIN accounts that were locked out by intruder detection. |
DISMOUNT | Makes a volume unavailable for access. Can be used for volume maintenance and repairs. Other mounted volumes can still be used. |
DOWN | Gracefully shuts down the server. Data in server memory is flushed to server disk. If users are logged in or are accessing files, it informs them that the server is shut down. |
SECURE CONSOLE | Makes the console secure by removing DOS from the server and prevents keyboard entry into the internal debugger. Only the console operator can modify server date and time; only NLMs in the search path can be loaded. |
SET | View or modify current operating system parameters. The SERVMAN NLM provides an easy interface to view or modify SET parameters. |
REMOVE DOS | Removes DOS from file server memory. Additionally, prevents NLMs from being loaded from DOS drives. If DOWN and EXIT commands are used, the server reboots. |
UNLOAD | Unloads an NLM from server memory. Used to reinitialize and reconfigure system and application NLMs. |
UNBIND | Unlinks a communication protocol from the NIC driver. |
Table 7.5 shows the screen commands.
Table 7.5 Screen Commands
Commands | Description |
CLS | Clears console screen. |
SEND | Sends a message to a currently logged or attached user using his or her login name or connection number. |
BROADCAST | Sends a message to all currently logged/attached users. Can also send messages to all currently logged/attached users. Also can send messages to a list of users or connection number. |
EXIT | Returns to DOS after issuing the DOWN command. |
Table 7.6 shows some of the new server console commands that have been introduced with NetWare 4.x.
Table 7.6 New Console Commands
New Console Command | Description |
ABORT REMIRROR | Terminates remirroring of the specified logical partition. |
REMIRROR PARTITION | Attempts to start the remirroring of the specified partition. |
MIRROR STATUS | Displays a list of the mirrored logical partitions and their status. |
LIST DEVICES | Displays a list of storage devices. |
SCAN FOR NEW DEVICES | Registers any devices added since the server was started. |
MAGAZINE | Responds to console alert messages to perform indicated actions, such as magazine insertion and removal. |
MEDIA | Responds to console alert messages to perform the indicated action's insertion and removal. |
RESTART SERVER | Restarts a downed server. |
LANGUAGE | Enables the NLMs to use specific language files. |
These commands are discussed in greater detail in the following sections.
The ABORT REMIRROR command stops the remirroring of the logical partition. Mirroring is the ability to have a second NetWare partition contain the same data, at all times, as a NetWare partition. It introduces redundancy at the NetWare partition level to improve its fault tolerance. The general syntax for the command is
ABORT REMIRROR number
where number is replaced by the logical partition for which you want to stop mirroring. Figure 7.7 shows the help that includes an example on the ABORT REMIRROR command.
Figure 7.7 Help on ABORT REMIRROR.
The ABORT REMIRROR command is the opposite of the REMIRROR PARTITION command, which is explained next.
The REMIRROR PARTITION command attempts to start the remirroring of the logical partition. Its general syntax is
REMIRROR PARTITION number
where number is replaced by the logical partition you want to mirror. Figure 7.8 shows the help that includes an example on the REMIRROR PARTITION command.
Figure 7.8 Help on REMIRROR PARTITION.
The REMIRROR PARTITION command is the opposite of the ABORT REMIRROR command that was explained previously.
The MIRROR STATUS command is used to display all mirrored partitions and their current status. Its syntax is
MIRROR STATUS
Figure 7.9 shows an example of typing the MIRROR STATUS command. Notice that because there is a lack of mirrored partitions, this fact is reported. For mirrored partitions, five possible status values exist. These status values are explained in table 7.7.
Figure 7.9 Example MIRROR STATUS command.
Table 7.7 Mirror Status Values
Mirror Status Value | Description |
Being mirrored | This shows that the partition is in the process of being mirrored. The percentage of mirroring that has been completed is also displayed. |
Fully synchronized | This indicates that the partitions are functionally identical (synchronized). This should be the normal state. |
Not mirrored | This shows that the partition currently is not mirrored. This should be the status when the ABORT REMIRROR command is issued. |
Orphaned state | This indicates that the partitions do not have the same data. You can use the Disk Options in the INSTALL NLM to correct this problem. |
Out of synchronization | This indicates that one of the servers does not have the same data and that, therefore, they are not synchronized. |
This displays a list of storage devices such as disk driver, tape driver, optical disk, or any other storage device. Its syntax is
LIST DEVICES
Figure 7.10 shows an example of typing the LIST DEVICES command. Notice that only one device is displayed. If a new device is added since the server was last started and its device driver is activated, it is often necessary to use the SCAN FOR NEW DEVICES command to register the device. The SCAN FOR NEW DEVICES command is explained in the next section.
Figure 7.10 Example LIST DEVICES command.
The SCAN FOR NEW DEVICES command registers any new hardware and devices that have been added since the server was last started. If the server does not recognize a device as part of its boot sequence, you must issue this command after you load the driver for that device. The syntax of this command is
SCAN FOR NEW DEVICES
Typing this command does not usually produce any visible display (see fig. 7.11). You must issue the LIST DEVICES command to see any new devices that have been found by the SCAN FOR NEW DEVICES command. Figure 7.12 shows the output of the LIST DEVICES command after the generic SCSI tape driver TAPEDAI.DSK has been loaded and the SCAN FOR NEW DEVICES command has been executed. Notice that a new device, the HP 35470A tape drive unit, is now registered.
Figure 7.11 The SCAN FOR NEW DEVICES command.
Figure 7.12 The LIST DEVICES command after the SCAN FOR NEW DEVICES command.
A magazine holds one or more media (optical disk, tape) for the secondary storage device used in data migration. The MAGAZINE command is used to confirm whether magazine requests issued by the server have been satisfied. This command is used in conjunction with secondary storage devices used with the data migration facility.
AUTHOR'S NOTE: The MAGAZINE and the MEDIA commands (discussed next) are reminiscent of the messages seen on the console of mainframe systems for the computer operator to mount a new tape or disk.
The syntax of the MAGAZINE command is
MAGAZINE request
in which request is replaced by INSERTED, NOT INSERTED, REMOVED, or NOT REMOVED.
Figure 7.13 shows the help message screen for the MAGAZINE INSERTED command. Notice that this command acknowledges the insertion of the specified magazine in response to the console alert message Insert Magazine. The MAGAZINE INSERTED command is a way of communicating to the system that the requested action has been performed. If you issue the MAGAZINE INSERTED command when no console requests have been made, no harm is done. You are told by the system that no requests are outstanding (see fig. 7.14), and your command is ignored.
Figure 7.13 Help on MAGAZINE INSERTED command.
Figure 7.14 The MAGAZINE INSERTED command when no requests are pending.
PRACTICAL TIP: If you issue the MAGAZINE INSERTED command when no console request has been made, the command is ignored.
The following MAGAZINE request commands work in the same manner:
MAGAZINE NOT INSERTED |
MAGAZINE REMOVED |
MAGAZINE NOT REMOVED |
The help messages for these commands are shown in figures 7.15, 7.16, and 7.17.
Figure 7.15 Help on MAGAZINE NOT INSERTED command.
Figure 7.16 Help on MAGAZINE REMOVED command.
Figure 7.17 Help on MAGAZINE NOT REMOVED command.
The MEDIA command is used to confirm whether media requests issued by the server have been satisfied. This command is used in conjunction with secondary storage devices that are used with the data migration facility.
The syntax of the MEDIA command is
MEDIA request
where request is replaced by INSERTED, NOT INSERTED, REMOVED, or NOT REMOVED.
Figure 7.18 shows the help message screen for the MEDIA INSERTED command. Notice that this command acknowledges the insertion of the specified media in response to the console alert message Insert Media. The MEDIA INSERTED command is a way of communicating to the system that the requested action has been performed. If you issue the MEDIA INSERTED command when no console request has been made, no harm is done. The system tells you that no requests are outstanding (see fig. 7.19), and your command is ignored.
Figure 7.18 Help on MEDIA INSERTED command.
Figure 7.19 The MEDIA INSERTED command when no requests are pending.
AUTHOR'S NOTE: If you issue the MEDIA INSERTED command when no console request has been made, the command is ignored.
The following MEDIA request commands work in the same manner:
MEDIA NOT INSERTED |
MEDIA REMOVED |
MEDIA NOT REMOVED |
Figure 7.20 Help on MEDIA NOT INSERTED command.
Figure 7.21 Help on MEDIA REMOVED command.
Figure 7.22 Help on MEDIA NOT REMOVED command.
In earlier versions of NetWare, the only way to restart the server was to issue a console command called DOWN to shut down the server, exit to DOS, and run the SERVER.EXE program. The RESTART SERVER command can be used to restart execution of the server after the DOWN command has been executed but before the EXIT command to exit to DOS.
The general syntax of this command is
RESTART SERVER [optionalParameters]
where optionalParameters can be the following:
-ns | For not using the STARTUP.NCF files |
-na | For not using the SYS:SYSTEM/AUTOEXEC.NCF file |
-d | For entering into the NetWare OS low-level internal debugger (used only by software developers) |
The [ ] brackets around optionalParameters indicate that the parameter is optional.
Please note that you must down the server before you can run this command.
The LANGUAGE command is used to specify the language to be used for the message files. This enables the NLMs that are written to support internationalization to display their options and help files in different languages. The general syntax for LANGUAGE is
LANGUAGE [language] [option]
The [ ] brackets around the parameters indicate that they are optional.
The language parameter can be the name of the language or a language identification number. The languages and assigned codes are shown in table 7.8. You should check the version of NetWare 4.x that you have for the languages available. To select the SPANISH language, for example, you can execute
LANGUAGE SPANISH
or
LANGUAGE 14
Similarly, you can use the language name or language identification number for any of the other languages listed in table 7.8, if this support has been installed at the server.
Table 7.8 Language Parameter Values for the LANGUAGE Command
Language Identification Number | Language Name |
0 | Canadian French |
1 | Chinese |
2 | Danish |
3 | Dutch |
4 | English |
5 | Finnish |
6 | French |
7 | German |
8 | Italian |
9 | Japanese |
10 | Korean |
11 | Norwegian |
12 | Portuguese |
13 | Russian |
14 | Spanish |
15 | Swedish |
Figure 7.23 shows the server console screen that has these commands issued. Figure 7.24 shows the MONITOR NLM running after the LANGUAGE command was set to use Spanish language message files. This assumes that support for the language has been installed on the server. Figure 7.24 shows that the Esc command was typed. You can see the prompt in Spanish for exiting the MONITOR NLM. Figure 7.25 shows the top level help for the MONITOR NLM.
Figures 7.26 through 7.33 show the MONITOR NLM and its help screen displayed in English, French, German, and Italian. You may want to compare the MONITOR screens in different languages.
Figure 7.23 The LANGUAGE command for Spanish.
Figure 7.24 The MONITOR NLM in Spanish.
Figure 7.25 The Help screen for MONITOR NLM in Spanish.
Figure 7.26 The MONITOR NLM in English.
Figure 7.27 The Help screen for MONITOR NLM in English.
Figure 7.28 The MONITOR NLM in French.
Figure 7.29 The Help screen for MONITOR NLM in French.
Figure 7.30 The MONITOR NLM in German.
Figure 7.31 The Help screen for MONITOR NLM in German.
Figure 7.32 The MONITOR NLM in Italian.
Figure 7.33 The Help screen for MONITOR NLM in Italian.
PRACTICAL TIP: To install language support, follow these steps:1. LOAD INSTALL (the INSTALL.NLM is a special NLM used for installing, maintaining, and upgrading a NetWare 4.x server).
2. Select "Maintenance/Selective Install."
3. Select "Other Options."
4. Select "Install an Additional Server Language from the CD-ROM" or "Install an Additional Server Language," depending on whether you have a CD-ROM or floppy distribution media.
STUDY NOTE: The language message files can be installed using the INSTALL NLM.
The console command-line processor uses special function keys to switch between screens for different VLMs.
The Alt+Esc keys can be used to switch between screens in a cyclic manner, as shown in figure 7.34. In this figure, the display screens for three of the modules are shown. You can use Alt+Esc to go to the next console screen. If you press Alt+Esc enough times, you return to the screen where you started.
PRACTICAL TIP: To switch between several screens quickly, you can just hold the Alt key and keep pressing the Esc key until you are at the right screen.
Figure 7.34 Switching between server console screens.
Pressing Ctrl+Esc displays a menu of the different screens available for viewing. These screens are numbered starting from 1. Entering a screen number causes the console display to switch to that screen.
You should know about the three major categories of NLMs that follow:
As discussed earlier, when NLMs are executed, they are loaded and closely integrated with the NetWare 4.x operating system. NLMs are loaded with the LOAD command, entered at the server console.
The management NLMs deal with those NLMs that are specifically designed for management of the server resources. These include the following NLMs:
These NLMs are discussed in greater detail in the following sections.
Using the INSTALL utility, you can install a new NetWare server, upgrade a NetWare 3.x server to a NetWare 4.x server, or perform a selective installation of different aspects of a server. To begin INSTALL, load it from the console with the following command:
LOAD INSTALL
The INSTALL NLM is used to install a server for the first time. You can use INSTALL to perform install and configure components of NetWare 4.x. Some of the tasks that can be performed using INSTALL include the following:
The MONITOR NLM is the principal tool used to manage and monitor the NetWare server. It provides information about the following:
Connection information
Disk information
LAN/WAN information
System module information
Lock file server console
File open/lock activity
Cache utilization
Processor utilization
Resource utilization
Memory utilization
Scheduling information
Figure 7.35 shows the MONITOR NLM main screen. As you can see from this screen, MONITOR can be used to display information on a variety of server statistics. The MONITOR NLM is the primary tool for server management. It is complemented by the SERVMAN tool for controlling the less obvious parameter settings. Some of the new options that have been added, compared with NetWare 3.x server, are Scheduling Information and Processor Utilization. Processor Utilization was also available under the NetWare 3.x MONITOR, but it required you to start MONITOR with the P switch (LOAD MONITOR P, LOAD MONITOR /P or LOAD MONITOR -P).
Figure 7.35 The MONITOR main menu.
NetWare administrators can use MONITOR to keep track of resources (called resource tags) used by the NLMs that are running in server memory. Monitoring these resources alerts the network manager to NLMs that are using excessive resources. This precaution allows corrective action to be taken before a major problem develops.
Detailed coverage of MONITOR is beyond the scope of this chapter. It is covered in a later chapter dealing with advanced administration topics.
Many of the characteristics of a NetWare 4.x server are configured using SET parameters. These parameters can be configured using the console SET command. You will learn, however, that many SET parameters exist, and that most have long names and several possible values. They can be difficult to remember and enter correctly.
The SERVMAN tool is a new server manager NLM that provides a convenient menu interface that enables you to change and view the SET parameters, configure SPX/IPX, and view network information.
The SET commands are used to control the server performance and configuration parameters. The syntax for loading the SERVMAN NLM is
LOAD SERVMAN
Figure 7.36 shows the SERVMAN main screen. The Server Parameters option enables you to view or change the SET parameters. Changes made here are used to update the STARTUP.NCF or AUTOEXEC.NCF files. SERVMAN is also an excellent tool for obtaining quick online help concerning the meaning of each of the SET parameters. The SET parameters are organized in categories for easy reference. Figure 7.37 shows these categories when the Server Parameters option was selected from the list of Available Options. To view any of the SET parameters in a particular category, simply select that category. Figure 7.38 shows the SET TIME parameters in the Time category. As each parameter is highlighted, a brief description is displayed.
Figure 7.36 The SERVMAN main menu.
Figure 7.37 SERVMAN Server Parameters.
Figure 7.38 The Time category.
Another interesting category is the File system category. Some of the newer parameters here deal with file compression. (File compression was discussed in Chapter 1, "Introduction to NetWare 4.x.") Figures 7.39 and 7.40 together show all the compression-related SET parameters.
You can use these parameters to control the start time (Compression Daily Check Starting Hour) and the stop time (Compression Daily Check Stop Hour) for the file compressor.
You can set the Minimum Compression Percentage Gain parameter to determine whether a file should be compressed. The default value for this parameter is 2, which means that unless there is at least a two percent reduction of the compressed file, the system does not keep the file in the compressed state.
Figure 7.39 The File system category--compression parameters: Screen 1.
Figure 7.40 The File system category--compression parameters: Screen 2.
The Days Untouched Before Compression parameter determines how long (in days) the system waits after the file was last accessed before compressing it. The Decompress Percent Disk Space Free To Allow Commit parameter is used to determine the free disk space required before compression can begin. Its default value is 10 percent.
The Maximum Concurrent Compressions parameter can be used to limit the number of compressions going on. Compression is a low priority task and should not normally impact the server performance. You can reduce this parameter if your server performance is affected.
The SERVMAN options can be used for viewing storage information on devices, volume information, and network information. The Storage information option can be used to display information on the storage objects (see fig. 7.41). The Volume Information option can be used to display information on the mounted volumes (see fig. 7.42). Information on the highlighted volume is displayed on the top part of the screen.
Figure 7.41 The Storage information option.
Figure 7.42 The Volume information option.
The Network information option can be used to display information on the network (see fig. 7.43). Besides monitoring the network traffic such as number of packets transmitted and received, you can use this screen for troubleshooting.
Figure 7.43 The Network information option.
A high number of Unclaimed packets indicates that an attempt is being made by network users to obtain a service that is not supported on the server. This parameter represents the number of packets for which there was no protocol stack.
If "Packets waiting to be sent" or "Get ECB requests failed" is high, that is an indication that the number of communication buffers is insufficient to handle the network traffic.
When power is abruptly removed from a NetWare server, files on the server can be damaged, perhaps irretrievably. In all cases, it is advisable to use an Uninterruptable Power Supply (UPS) with a NetWare server. The batteries in the UPS provide a few minutes of power to the server in the event of a power failure. During those minutes, the power failure can be corrected or the server can be shut down in a controlled way so that files are not corrupted.
Because power failures can happen at any time, often when the server is unattended, it is desirable to enable the server to shut itself down in the event of a prolonged power failure that is exhausting to batteries in the UPS. The UPS NLM provides a software interface between the UPS and the NetWare server.
Most modern UPS systems have a hardware port that is connected to the server, often to a serial port, although other options also are available. The hardware driver for the UPS must be attached to the server before the UPS NLM is activated. Usually, the attachment is via one of the serial interfaces to the server. No menu screen is associated with the UPS NLM. The command to load the UPS.NLM is as follows:
LOAD UPS
You are prompted for additional parameters as the UPS NLM loads.
The power is supplied to the server via the UPS device, even under normal circumstances of no power failures. The UPS device provides a well-regulated power supply, and if the main power line fails, the UPS is able to continue supplying this power while its batteries last. If the main power supply fails, the UPS sends a signal to the server that power failure has occurred. The UPS.NLM receives the signal and is able to perform an immediate shutdown of the server or to wait a certain amount of time before initiating a shutdown. Many UPS devices are able to send a separate signal when the UPS battery is depleted, and this capability can be used to initiate server shutdown. In any case, you should refer to the UPS device documentation to learn about the details of interfacing the UPS to the server.
NetWare 4.x also provides two additional commands called UPS TIME and UPS STATUS to monitor the UPS time and status. These commands work only when the UPS NLM is loaded.
NetWare 4.x supports the following enhancements:
These enhancements are implemented by special NLMs, which are called enhancement NLMs.
STREAMS is a general-purpose transport protocol interface developed by AT&T that enables protocol stacks to be built dynamically. The head of the STREAMS protocol is the STREAMS interface, and the tail is usually the network card driver. On NetWare servers, the tail of the STREAMS is designed to connect with the ODI drivers loaded at the server. Between the head and the tail, any number of protocol elements can be connected as if they were part of a string or stream (see fig. 7.44). These protocol elements could be the transport and network protocols such as SPX/IPX or TCP/IP.
Figure 7.44 STREAMS enhancement.
The TLI (Transport Layer Interface), also developed by AT&T, is a higher-level interface than STREAMS. STREAMS is considered to be too low-level an interface for application programmers to use. The STREAMS interface was designed primarily to ease the process of adding additional protocols to Unix System V.
The NetWare TLI implementation follows the spirit of the AT&T definition but differs from it in implementation details because it works on an operating system that is unlike Unix. The STREAMS interface supports SPX/IPX and TCP/IP.
The STREAMS.NLM is required by the CLIB.NLM. If STREAMS.NLM is not loaded when CLIB.NLM loads, it is autoloaded. The SPXS.NLM and IPXS.NLM implement the SPX and IPX protocol interface to the STREAMS.NLM.
AUTHOR'S NOTE: In addition to TLI, the BSD sockets interface can be used by application programmers. The BSD (Berkeley System Distribution) socket interface was developed as part of BSD Unix at the University of California, Berkeley. It is a very popular and simple programming interface to the TCP/IP protocols.
Network management has become increasingly important for today's more complex networks. A variety of network management tools can monitor the network for messages generated by network devices. Devices are equipped with software known as an agent, which can produce messages or even respond to queries or commands from the network management console.
NetWare 4.x provides such a network management agent. The network management agent is implemented by the NMAGENT.NLM. This NLM is autoloaded whenever a LAN driver is loaded. The NMAGENT.NLM is a network management agent that reports on network statistics collected by the LAN drivers. It can, for example, report on the number of packets transmitted or received via a particular LAN driver interface. For Ethernet networks, it can report on the number of collisions detected by the server's network adapter.
Figure 7.45 shows the NMAGENT.NLM for a LAN driver NLM. Third-party network programs can poll the NMAGENT.NLM for LAN statistics. Some of these statistics can also be viewed by the MONITOR NLM, which can poll the local network interfaces and report them.
Figure 7.45 The Network management agent--NMAGENT.NLM.
Remote booting for diskless workstations is implemented by the Remote Program Load NLM, called RPL.NLM. Diskless workstations do not have local disk storage devices and are used to lower the cost of workstations and to improve security. Because there is no local storage on the workstation, you cannot copy files between workstations and the network. Users are unable to install programs on the network or to copy data from the network. This eliminates a common source of computer viruses on the network.
Figure 7.46 shows that with RPL.NLM support, diskless workstations can send requests to the server to download the operating system boot image that is then used to initialize the workstation. The diskless workstation boots from the network, rather than from a local storage device.
Figure 7.46 Remote Program Load.
Source routing is used in IBM Token-Ring networks to support data transmission in a network consisting of several interconnected Token-Ring networks (see fig. 7.47). The Token-Ring LANs are interconnected by IBM Token-Ring bridges that follow the source routing instructions embedded in each Token-Ring frame to send the data to the interconnected Token-Ring LANs. The initial route is discovered by the source station, and this is the reason that this technique is called source routing. Once the sending station discovers the best route to a destination, the route path is included in every Token-Ring frame sent to that destination. The route path consists of ring number/bridge number pairs, and the interconnected bridges simply follow the instructions in this route path to send it to the next Token-Ring LAN. NetWare client software is generic in nature and works with different network topologies. To support the additional requirements of source routing, the program's ROUTE.COM must be loaded at the NetWare workstation. Additionally, ROUTE.NLM must be loaded at the NetWare server.
The ROUTE.COM program must be loaded after the ODI driver is loaded, but before loading the IPXODI.COM protocol stack. An example of how you could modify the STARTNET.BAT in the C:\NWCLIENT directory to support source routing in a Token-Ring network is shown here:
Figure 7.47 Source routing.
@ECHO OFF C: CD \NWCLIENT SET NWLANGUAGE=ENGLISH LSL TOKEN.COM ROUTE IPXODI VLM CD \
The ROUTE.COM shown in the previous example loads with a default set of parameters. You can customize the behavior of ROUTE by using additional options. The general syntax of the ROUTE command is as follows:
ROUTE U,BOARD=b,CLEAR,DEF,GBR,HOPS=hc,MBR,NODES=n,TIME=s, ÂTRA=rac,TRO=roc
All parameters for the ROUTE program are optional and can be entered in any order. The ROUTE command can be used to set the ROUTE parameters the first time it is loaded. If it is loaded again, it can be used to change the configuration of a previously loaded source route configuration.
The U parameter is used to unload a previously loaded ROUTE.COM from memory.
The BOARD=b parameter specifies the board number b assigned to the board by the ODI interface. If it is not used, the default board number 1 is assumed.
Specifying the CLEAR parameter clears all node addresses for the loaded ROUTE.COM.
The DEF parameter causes source routing to use the Send Default (Unknown) Node Addresses ALL ROUTES Broadcast. If this parameter is not entered, Single Route Broadcast is used.
The GBR parameter causes source routing to use the Send Broadcast (FFFF FFFF FFFF) Addresses ALL ROUTES Broadcast. If this parameter is not entered, Single Route Broadcast is used.
The HOPS=hc parameter specifies the number of bridge hops (hc) to configure for source routing. The default value is 7, and the maximum is 13.
The MBR parameter causes source routing to use the Send MultiCast (C000 xxxx xxxx) Addresses ALL ROUTES Broadcast. If this parameter is not entered, Single Route Broadcast is used.
The NODES=n parameter specifies the number of node addresses (n) to support. The default is 16, and the maximum is 1000. If a value less than 8 is entered, the actual value used is 8.
The TIME=s parameter specifies the number of seconds (s) to wait before declaring that a known route is timed out. The default is 10, and the maximum is 255.
The TRA=rac parameter specifies the This Ring Alternate Count (rac) for Broadcasts. The source router alternates between source-routed and nonsource-routed frames. The default is 0, and the maximum is 255.
The TRO=roc parameter specifies the This Ring Only Count (roc) for Broadcasts. The default is 0, and the maximum is 255.
For additional details of how source routing works, you can refer to NetWare: The Professional Reference by New Riders Publishing.
A very useful utility for managing the server is the Remote Console utility. This utility is run at the workstation as the RCONSOLE.EXE. At the server, the NLMs REMOTE.NLM and RSPX.NLM need to be loaded. Once these NLMs are loaded, a workstation can become a server console by running the RCONSOLE.EXE program.
The order of loading the NLMs is first REMOTE.NLM and then RSPX.NLM. When REMOTE.NLM loads, you can specify a password as an argument to the LOAD REMOTE command. If you do not specify a password, the REMOTE NLM prompts you for one. The commands to run Remote Console follow.
At the server:
LOAD REMOTE password LOAD RSPX
At the workstation:
RCONSOLE (Located in the SYS:SYSTEM directory)
When REMOTE is loaded, you must select if you want to use SPX or Asynchronous access, then the password used to access the server at the console can be typed on the same command line. To use a password of xyzzy, for example, you can use the following command:
LOAD REMOTE xyzzy
If a password is not specified, the REMOTE.NLM prompts you for one. If you want remote console support to be loaded whenever the server is started, you can include the commands for loading REMOTE.NLM and RSPX.NLM in the AUTOEXEC.NCF file that is kept on the server's SYS:SYSTEM directory. If a password is not specified on the command to load REMOTE.NLM, the server boot load sequence halts until you type in the password. For this reason, you may want to include the REMOTE password in the AUTOEXEC.NCF line.
Including the REMOTE password in the AUTOEXEC.NCF file introduces another problem. Anyone with access to the AUTOEXEC.NCF can see the password. If the server console is not locked, anyone can use INSTALL.NLM or EDIT.NLM to view the AUTOEXEC.NCF file. Also, anyone with access to the SYS:SYSTEM or AUTOEXEC.NCF file from a workstation can view the commands (and the password) in this file. To solve this problem, NetWare 4.x supports the E encryption option that can be used with REMOTE. Instead of specifying the actual password, you specify an encrypted key that represents the password:
LOAD REMOTE -E encryptedkey
The encrypted key is a numeric quantity that represents the password but is not the password itself. The encrypted key can be obtained after you load REMOTE.NLM. A new command called REMOTE ENCRYPT becomes available when REMOTE.NLM is loaded. You can type the following at the server:
REMOTE ENCRYPT
The command prompts you to enter a password. An encryption key will be displayed. You can use this encryption key in the LOAD REMOTE -E command in the AUTOEXEC.NCF file. If you want to use the password XYZZY, for example, you can use the following command at the console after REMOTE.NLM is loaded:
REMOTE ENCRYPT XYZZY
The encrypted key for password XYZZY is CADDA33333. You can use the following in the AUTOEXEC.NCF file:
LOAD REMOTE -E CADDA33333
Using the encrypted password preserves the integrity of the actual password used to access the server console.
The REMOTE ENCRYPT command also asks if you want to save the LOAD REMOTE command to the LDREMOTE.NCF file. If you answer Yes, it includes LDREMOTE.NCF in the AUTOEXEC.NCF file.
RSPX includes support for packet signatures. Packet signatures are special encryption codes used to authenticate each packet sent between workstation and server. Packet signatures make it extremely difficult to forge packets. Packet forging is a technique that is used by programs written to break the security of a network. In this technique, an illegal source duplicates the packets sent by a legal source to the server. NetWare uses packet signatures that use the MD4 (Message Digest 4) encryption algorithm to uniquely identify packets. The default for RSPX is that packet signatures are ON. RCONSOLE.EXE on earlier versions of NetWare (3.x) does not support packet signatures. If you are running a copy of RCONSOLE.EXE while logged in to a NetWare 3.x network, to connect to REMOTE.NLM running on a NetWare 4.x server you can turn packet signature off by loading RSPX with the SIGNATURES OFF parameter:
LOAD RSPX SIGNATURES OFF
Figure 7.48 shows the Remote Console components. The reason REMOTE.NLM has to be loaded before RSPX.NLM is interesting. From figure 7.48 it is clear that RSPX is lower in the functional hierarchy than REMOTE.NLM, because it implements the communication protocol stack and REMOTE.NLM implements the Remote Console Facility. For this reason, you might think that RSPX.NLM should be loaded first. When RSPX.NLM loads, it expects to logically bind to entry points in the LAN driver and the application to which it connects. The LAN drivers already are loaded when the server is activated; therefore, RSPX can bind to the LAN driver without any problem. If the REMOTE.NLM is not already loaded, RSPX.NLM is unable to logically connect to it. For this reason, REMOTE.NLM should be loaded before RSPX.NLM.
A major difference between RCONSOLE for NetWare 4.x and prior NetWare versions is that the functions of ACONSOLE, for asynchronous communications I/O, are now integrated in the NetWare 4.x RCONSOLE.
Figure 7.48 The Remote Console components.
Figure 7.49 shows the opening screen when RCONSOLE is run at a workstation. Notice that the two options shown are Asynchronous and SPX. If the Asynchronous option is selected, you are given a list of Asynchronous Options (see fig. 7.50). The Connect To Remote Location option enables you to view a list of remote locations accessible through RCONSOLE. Before you can use this option, you must use the Configuration option to configure asynchronous operations.
Figure 7.49 The Remote Console main screen.
Figure 7.50 Asynchronous Options.
Selecting the Configuration option (see fig. 7.51) enables you to select the device and modem configuration parameters. You can select the baud rate (bits per second), the modem initialization and reset command, the modem reconnect command, the modem dial command, and the modem hang-up command.
Figure 7.51 The Asynchronous Configuration option.
You can supply a user identification by which the connecting station is known to the remote server. You can also enter a callback number. The modem type can be Hayes-compatible or a null modem. The choice of null modem cable is useful, especially when used with serial line boosters (amplifiers). You can then manage the server from fairly long distances within a local building without using the LAN. This technique is particularly useful if a problem exists with the network cabling.
When the SPX option is selected, as shown in figure 7.49, you are given a list of available servers to which to connect (see fig. 7.52). When you select a server, you are prompted for a password. After typing the password used with the REMOTE (or the first Admin password), you receive a connection to the server console (see fig. 7.53). The connection message on the screen lists the date and time the connection took place and the network number and node address of the station that was granted the connection. From figure 7.53, you can see that the network number is 000E8022 and the node address is 0000C0664E19.
AUTHOR'S NOTE: The REMOTE and RCONSOLE utilities are bindery-based. You can use the password that was supplied with REMOTE to access the server console or the first Admin password that was assigned during NDS installation. If you change the password for the first Admin user, you cannot use this new password with RCONSOLE. You can, however, continue using the REMOTE password. If the Admin password was not specified during installation (left blank), you will not be prompted for a password when using RCONSOLE to access the server.Specifically, this is because RCONSOLE uses the Supervisor password that is synchronised with the Admin password at install. You should be able to change the Supervisor password using SETPASS SUPERVISOR /B (provided you have a bindery context set at the server).
Figure 7.52 The RCONSOLE Available Servers list.
Figure 7.53 Connection granted to Remote Console.
In earlier NetWare versions, you could invoke the RCONSOLE menu by using the + key on the numeric pad. The control keys for NetWare 4.x RCONSOLE are different. To see the RCONSOLE menu, you must use the Alt+F1 keys. Figure 7.54 shows the RCONSOLE menu when the Alt+F1 keys are pressed.
Figure 7.54 RCONSOLE Available Options.
The Select A Screen To View option displays a list of screens mounted on the server console. It performs the function of the Ctrl+Esc keys at the server console.
The Directory Scan option enables you to obtain a directory listing on any server volume directory or on any DOS directory on the server DOS partition. When you select this option, you are prompted for a directory name. The directory contents are displayed in a window.
The Transfer Files To Server option enables you to transfer files from a local workstation drive or a network drive (obtained by using the MAP command at the workstation) to the server volume or to the DOS partition of the server. When copying to a subdirectory on the server partition, however, you can only specify the directory name to copy to. You cannot copy file1 to the server as file2, the names must remain the same.
The End Remote Session With Server (Alt+F2) option is used to end the connection with the remote server. The Resume Remote Session With Server (Esc) option closes the RCONSOLE menu options windows and returns you to the server console screen.
The Configure Keystroke Buffering option enables you to introduce delays (milliseconds) in transmission of keystrokes, buffer keystrokes until a special key code, Alt+F8, is sent (Manual send), or enable keystroke buffering on demand by pressing Alt+F9 (On demand). This option can be used to reduce the amount of packet traffic sent over low-speed links.
The new options, when compared with NetWare 3.x, are Invoke Operating System Shell, which exits to the workstation command shell, the Workstation Address option, and Configure Keystroke Buffering. You must type EXIT to get back to the RCONSOLE menu. The new Workstation Address option enables you to see the workstation's node address (see fig. 7.55). In figure 7.55, the workstation address is shown in a box on the top left corner. Other shortcut keys are available. The Alt+F2 keys enable you to quit RCONSOLE. The Alt+F3 and Alt+F4 keys enable you to scroll through screen consoles (forward and backward). The Alt+F5 key enables you to view the workstation address. The RCONSOLE control keys are summarized in table 7.9.
Figure 7.55 The RCONSOLE Workstation Address option.
Table 7.9 RCONSOLE Control Keys
Control Keys | What They Do |
Alt+F1 | Invokes RCONSOLE menu |
Alt+F2 | Exits RCONSOLE |
Alt+F3 and Alt+F4 | Scrolls forward and backward through console screens |
Alt+F5 | Views workstation node (network) address |
NOTE: Remember the RCONSOLE control keys of table 7.9, because questions regarding them may appear on the test.
RCONSOLE.EXE normally is stored in the SYS:SYSTEM directory so that only system administrators can have access to this program. Ordinary users usually do not have access to the SYS:SYSTEM directory. If you are running RCONSOLE from a stand-alone workstation and using a modem to access the NetWare server, you must copy the following files to the stand-alone workstation from the SYS:SYSTEM directory: RCONSOLE.EXE, IBM_RUN.OVL, _RUN.OVL, IBM_AIO.OVL, and _AIO.OVL. You also must copy the following files from the SYS:SYSTEM\NLS\language (replace language with ENGLISH or another supported language) directory: RCONSOLE.HEP, TEXTUTIL.MSG, TEXTUTL.HEP, and TEXTUTIL.IDX.
If you are running RCONSOLE using a modem, you need to load AIO.NLM, AIOCOMX.NLM, and RS232.NLM at the server. These NLMs must be loaded after the REMOTE.NLM is loaded. The load order for these NLMs is shown next:
2. AIOCOMX
3. RS232
AIO and AIOCOMX provide asynchronous I/O communications support. These NLMs implement the API support for asynchronous communications. When RS232 is loaded, it prompts you to enter the COM port number (1 for COM1, 2 for COM2) and the baud rate. Baud rates that are supported are 2400, 4800, 9600, 19200, and 38400. You can specify some of these parameters from the command line. To specify that COM1 is to be used at a data rate of 19200 bits per second, for example, you can use the following:
LOAD RS232 1 19200
Additionally, you can specify the C or N parameter to the RS232 NLM. The C parameter specifies that the callback feature is enabled. Use the N parameter to specify that a null-modem cable is being used instead of real modem devices.
When RS232 is loaded, the MODEM command becomes available. The general syntax of this command is as follows:
MODEM [modemstring]
The modemstring is a Hayes modem command string that is sent to the connected modem. When this command is executed, the results of executing this command are displayed on the screen. The [] around modemstring indicates that the modem string is optional. If the MODEM command is entered without specifying the modem string, the MODEM command prompts you for the string. The MODEM command also supports file indirection. In file indirection, the modem commands are included in an ASCII text file. This text file can be specified in place of the modem string by preceding the file's path name with an @ symbol. You can, for example, send the modem commands stored in SYS:ETC\MODCMDS\MODINIT.TXT by typing the following command:
MODEM @SYS:ETC\MODCMDS\MODINIT.TXT
You can use RCONSOLE to install NetWare 4.x system files. RCONSOLE is convenient if the CD-ROM containing the NetWare 4.x distribution is attached to the workstation and not the server machine. After loading REMOTE and RSPX at the server, you can load RCONSOLE at the workstation and connect to the server console. You can then type
LOAD INSTALL
to run the INSTALL NLM. Next, make the following selections:
Several new NLMs are supported in NetWare 4.x. These are listed in table 7.10. The sections that follow discuss their functions and capabilities.
Table 7.10 New NetWare 4.x NLMs
NLM Name | Description |
DOMAIN | Creates a protected domain for running NLMs. |
DSREPAIR | Enables repair of problems with the NDS database. |
RTDM | Supports the Real Time Data Migration feature. |
NWSNUT | NLM Utility User Interface library. |
TIMESYNC | Time Synchronization NLM to ensure that ser-ver times are synchronized across the network. |
DSMERGE | Used to merge roots of separate directory service trees. |
CDROM | Enables a CD-ROM attached to the server to be shared. |
KEYB | Enables keyboards for different languages to be used at the server console. |
SERVMAN | Enables the configuration of SET, SPX/IPX, and other server parameters. |
SCHDELAY | Enables priortization of server processes. You can use this to increase the scheduling delay of processes. |
The DOMAIN NLM uses the ring protection architecture of the Intel 80x86 processor family to create memory domains. Figure 7.56 shows the Intel ring architecture and how it is used by NetWare 4.x OS. The NetWare OS kernel runs in ring 0, the most privileged mode of the processor. Running an untested or malfunctioning NLM in this ring could crash the server.
Figure 7.56 Intel ring architecture and NetWare 4.x.
Using the ring architecture of the Intel 80386 processors, the untested NLMs can be run in an outer ring such as ring 3. NLMs in this ring obtain services from the kernel through a protected inter-ring gate call mechanism, which prevents direct access to the ring 0 memory. A small overhead is associated with the inter-gate calls, so NLMs running in a protected domain run slower than they would if they ran in ring 0 (kernel or unprotected domain). On the other hand, misbehaved NLMs running in a protected domain are prevented from altering the operating system environment.
To enable the protected OS domain capability, you must run the DOMAIN.NLM. The syntax for running the DOMAIN NLM, assuming that it is on the NLM search path, is
LOAD DOMAIN [/R 1 | 2 | 3]
When you run the command
LOAD DOMAIN
the protected domain is set up in the default ring of 3. You can use the /R n option to load the domain in ring number n, where n is 1, 2, or 3. Thus, to set up a protected domain using ring 2, the command is
LOAD DOMAIN /R 2
You must check your version of NetWare 4.x to see if domain support for a ring other than ring 3 is available.
The DOMAIN.NLM must be loaded before loading any other NLM, such as MONITOR or INSTALL. Once the DOMAIN loads, other domain-specific commands become available. These are described in table 7.11.
Table 7.11 Domain Commands
Domain Command | Description |
DOMAIN | Displays the current domain and the modules in the current domain. Modules in other domains also are listed. |
DOMAIN HELP | Displays help information on DOMAIN. |
DOMAIN RING=n | Changes the OSP domain to ring n. |
DOMAIN=domain_name | Changes current domain. domain_name can be OS (ring 0) or OS_PROTECTED (the ring where OSP is established). Use this command preceding any NLMs that you want to load. |
When the DOMAIN NLM is loaded, you can use the command DOMAIN=OS or DOMAIN=OS_PROTECTED to change the current domain to the OS domain (ring 0) or the protected domain. NLMs loaded from the LOAD command are loaded in the current domain, so you can use this DOMAIN command to load the NLMs in the OS or OS_PROTECTED domain. The keyword OS_PROTECTED can be abbreviated to OSP. You can type DOMAIN=OSP rather than the longer DOMAIN=OS_PROTECTED command.
Figure 7.57 shows the effect of running the DOMAIN command on the top part of the screen. When the command DOMAIN is run, a list of NLMs in the domain is reported (see fig. 7.58). Figure 7.58 reports that the current domain is OS and that this is ring 0. The OS_PROTECTED domain is ring 3. All NLMs are loaded in ring 0. These include the REMOTE.NLM and the RSPX.NLM that were loaded after the LOAD DOMAIN command (see fig. 7.57).
Figure 7.57 The LOAD DOMAIN command.
To load the EDIT.NLM in the protected domain, you must issue the following command:
DOMAIN=OS_PROTECTED
Figure 7.59 shows the effect of executing the preceding command. Notice that the status message shows that the current domain is OS_PROTECTED. Next, you can load the EDIT NLM:
LOAD EDIT
Figure 7.58 The DOMAIN command.
Figure 7.59 The DOMAIN= OS_PROTECTED command.
Figure 7.60 shows that the EDIT NLM was loaded successfully. Figure 7.61 shows a list of NLMs in the different domains obtained using the DOMAIN command. Notice that the current domain (OS_PROTECTED in this case) is listed first and reports that it contains the NetWare Text Editor NLM (EDIT.NLM).
Figure 7.60 Successful load of EDIT in OS_PROTECTED command.
Figure 7.61 The EDIT NLM in OS_PROTECTED domain.
The DSREPAIR utility is used to correct problems with the NetWare Directory Service database, such as unknown object-type objects, or corrupted NDS objects. It also repairs NDS records, schema, bindery object representations in the NDS, and external references to other X.500 directories. The syntax of using DSREPAIR is as follows:
LOAD DSREPAIR [=U] [-L logfilename]
The =U and -L options are optional. The =U option specifies that DSREPAIR should be run in the unattended mode without any user intervention. The -L option can be used to specify a file name logfilename, where errors are to be logged. The default error log file is SYS:SYSTEM\DSREPAIR.LOG.
NOTE: The default error log file used by DSREPAIR is SYS:SYSTEM\DSREPAIR.LOG.
Figure 7.62 shows the options when DSREPAIR is loaded. You can run the DSREPAIR.NLM in the unattended full repair mode by selecting the Unattended full repair option. This is the simplest mode for running DSREPAIR. Figure 7.63 shows the status messages being generated for the unattended full repair option. At the end of the DSREPAIR session, the repair log is displayed (see fig. 7.64). You can select the Time synchronization and Replica synchronization options to perform the indicated tasks.
Figure 7.62 The DSREPAIR main screen.
Figure 7.63 Status messages generated when DSREPAIR is being run.
Figure 7.64 The DSREPAIR repair log.
If you select the Advanced options menu, you will see a list of advanced configuration choices (see fig 7.65). A useful option is the Create a database dump file that copies the NDS database in a compressed form in the DSREPAIR.DIB file that can be used for offline repairs (see fig. 7.66).
The RTDM NLM is used to enable support for data migration. The syntax for loading RTDM is as follows:
LOAD RTDM
Figure 7.65 DSREPAIR Advanced Options.
Figure 7.66 DSREPAIR--Create a database dump file option.
RTDM is the enabling module that manages the movement of data from one media type to another in a user-transparent fashion. You still need the near-line storage hardware and the drivers from the manufacturer to implement data migration.
Data migration is a feature of NetWare 4.x that permits data that has not been used in a defined period of time to be migrated to secondary storage devices.
Data migration is implemented using High Capacity Storage System (HCSS). HCSS is a storage and retrieval system that can extend the capacity of a NetWare server by integrating optical libraries into the NetWare file system. HCSS can work in conjunction with data migration so that migrated files can be moved from the faster but lower-capacity NetWare volumes to the slower but higher-capacity media that comprises the HCSS.
As far as the user is concerned, the operation of data migration and HCSS is transparent. Files that have been migrated to the HCSS are accessed with the same commands as files that reside on the NetWare volume. If a migrated file is accessed, it is automatically de-migrated.
Migration is performed on an individual file basis depending on the last time the file was accessed. This is called the least recently used criteria and the current volume usage. Least recently used criteria for files refers to files that are the least active, or that have not been accessed for the longest amount of time. If the current volume usage exceeds a capacity threshold, data migration occurs. Capacity threshold is defined as the percentage of the server's disk that is used before data migration begins.
Migration enables high capacity secondary devices to be treated as a logical extension of the server's disk storage. A volume's effective storage appears to be much larger than it really is. When data that is stored on near-line storage devices is needed, it is brought back in (de-migrated). If the data is not in use for a predefined interval of time, it is migrated back to near-line storage.
The NWSNUT NLM provides the NLM Utility User Interface. It is a library NLM that exports its functions to other NLMs. It implements the server console display routines that have the look and feel of the C-Worthy libraries that are used for the workstation utilities. Management utilities like MONITOR and INSTALL make use of this library to provide a consistent, menu-driven user interface. The syntax for loading NWSNUT is as follows:
LOAD NWSNUT
NWSNUT is autoloaded by many of the modules that need its services.
For compatibility with NetWare 3.x NLMs, the NUT.NLM is provided. Normally, you do not need to worry about this NLM because it is autoloaded by the NetWare 3.x NLMs.
The TIMESYNC NLM is used to monitor the internal network time on the server and use information on time obtained from other time servers to synchronize the server time. This NLM is autoloaded whenever the NetWare server is started.
When TIMESYNC loads, it reads a file called SYS:SYSTEM\TIMESYNC.CFG that contains the time configuration parameters. These parameters can also be set by the SET commands or the SERVMAN utility. The time parameter can also be specified as an argument to TIMESYNC NLM. The general syntax for activating TIMESYNC.NLM is as follows:
LOAD TIMESYNC [timeParameters]
where timeParameters are the time parameters for the TIMESYNC NLM.
The DSMERGE NLM is used to merge the roots of two separate NDS trees into one single tree. Remember that information between separate NDS trees (trees that have separate roots) cannot be directly shared. It may be desirable to merge the trees to share this information.
Normally, the network NDS tree should be designed beforehand so that this merger is not needed. But in the case of unforeseen events, such as corporate mergers, it may be desirable to have a single NDS tree.
You use a tool such as SBACKUP to back up the NDS database on the two trees before attempting the directory merge. The general syntax for loading DSMERGE is as follows:
LOAD DSMERGE
The preceding command should be run on the server that has the source tree that you are merging with the target tree. The objects in the source tree become part of the target tree. As a result of the DSMERGE operations, only the root objects are merged. Container objects and leaf objects maintain their identities under the newly merged root, which means that complete names of objects in the source and target trees should not change in the merged tree. You must make sure that containers at the same level in the source and target trees have unique names. If you have two containers in the separate trees that have conflicting names (same names) for a level of the tree, you cannot merge the trees. You can, however, move objects from one container into another container, delete the empty container, and then merge the trees.
STUDY NOTE:In the DSMERGE utility,
- the objects in the source tree become part of the target tree.
- only the root objects are merged.
- container object names for the same level of the NDS tree have to be unique in the source and target trees.
The biggest conflict for unique names is at the Organization container level. Within two differently named Organization objects, it is possible to have Organizational Unit objects that have the same name. There is no conflict in this case. If the organization names in the source and target tree are different, following the suggestion of moving all objects to another container and then deleting the organization container is not a task for the faint-hearted (maybe a task for the foolhardy!). According to the NDS schema, the Rename right applies to leaf objects, not to container objects. So, Organization objects cannot be renamed, according to the current NDS definition.
Another issue concerning merging of NDS trees is that the time source for the two NDS trees must be coordinated. If an external time source is being used, both trees must have access to the external time source.
Additionally, make sure that all servers (repositories of NDS replicas) in the NDS trees are up and running before attempting DSMERGE.
NOTE: When merging trees, merge the smaller tree with the larger tree for fewer problems and shorter merge times. That is, run DSMERGE on the server that has the smaller NDS database.Also, the NDS schemas of the two trees must be the same for a merge to complete successfully.
CD-ROM support is enabled by loading CDROM. Before doing so, you must ensure that the appropriate device drivers for your CD-ROM are running. As a precaution, you should ensure that DOS CD-ROM drivers are not loaded, because they conflict with NetWare 4.x CD-ROM drivers. For SCSI devices, you can load either ASPICD.DSK or CDNASPI.DSK. Because these drivers normally are placed in the C:\SERVER.40 directory, make sure you specify the correct path name. Alternatively, you can use the SEARCH ADD command as shown in the following:
SEARCH ADD C:\SERVER.40 LOAD CDNASPI
Figure 7.67 shows the result of loading the CDNASPI driver. The CD-ROM unit is the SONY CDU-541 and has the SCSI ID of 01. The disc drive is set to a SCSI ID of 0, and the tape drive (HP 35470A) has a SCSI ID of 1. The host bus adapter SCSI ID is 7. This ID is typical for CDs.
Figure 7.67 The LOAD CDNASPI command. You must next load the CDROM NLM. Figure 7.68 shows the effect of loading the CDROM driver. Notice that the CDROM NLM supports the ISO 9660 and the High Sierra format. The device is identified as device #1.
Figure 7.68 The LOAD CDROM command. After the CDROM loads, a number of CD commands become available. For a list of these commands, type the following command:
CD HELP
Figure 7.69 shows the help screen for CD commands. Either of the CD DEVICE LIST or CD VOLUME LIST commands can be used to obtain the volume name or volume number. You need the volume name or number to mount the CD. Figures 7.70 and 7.71 show the effects of executing the CD DEVICE LIST and the CD VOLUME LIST commands.
Figure 7.69 The CD HELP command.
Figure 7.70 The CD DEVICE LIST command.
Figure 7.71 The CD VOLUME LIST command.
The next step is to mount the CD by using the following:
CD MOUNT volumename
or
CD MOUNT volumenumber
where volumename and volumenumber were obtained from the CD DEVICE LIST or the CD VOLUME LIST command.
Figure 7.72 shows the INSTALL screen that shows the mounted CD-ROM volume. Its default block size is 64 KB, and file compression, block suballocation, and data migration are turned to Off because they do not apply to a read-only volume. From the screen, you can see that the CD-ROM volume name is NETWARE_40. So, to map a drive H to this volume, you use the following command:
MAP H:=NETWARE_40:
Figure 7.72 The Volume Information showing the mounted CD-ROM volume.
When the CD-ROM is mounted, a special data file is written to the root directory on the server's SYS: volume that contains information that was used to mount the volume. You can use this file to reduce the mount time, if you need to remount the CD-ROM volume. You can use the /R switch with the CD MOUNT command to specify that the special file will be used during the remount process. Thus, to remount a volume, you can use the following command:
CD MOUNT /R
Because CD-ROM is a removable media, a special command called the CD CHANGE command can be used to change the CD-ROM. Typing the command
CD CHANGE volume
where volume is the volume name or volume number of the new disc, causes the system to prompt you to remove the current CD-ROM disc, install a new CD-ROM disc, and mount the new CD-ROM disc.
You can use any of the other CD-ROM options (such as /MAC, /NFS, /G) with the CD CHANGE option.
The /MAC option can be used with the CD MOUNT or CD CHANGE command to specify that the CD-ROM disc contains a Macintosh file system, and it should be mounted as a Macintosh file system. You can access this file system from a Macintosh workstation if you have NetWare for Macintosh running at the NetWare server.
The /NFS option can be used with the CD MOUNT or CD CHANGE command to specify that the CD-ROM disc contains a Unix file system and should be mounted as a Unix file system. You can access this file system from a Unix workstation if you have NetWare for NFS running at the NetWare server.
You can use the Group Access (/G) option with the CD MOUNT or CD CHANGE command to grant users controlled access to the CD-ROM volume. To grant controlled access, you must create an NDS group object in the same context as the server to which the CD-ROM device is attached. You can assign membership to this group. Then, you can use the CD GROUP command at the server console to assign access to this group. If you created a group object called CDUSERS, you could then give access to this group by using the following command:
CD GROUP CDUSERS 1
The preceding command registers CDUSERS as a group that can use the CD-ROM and assigns it a group number of 1. It also displays a list of currently registered groups, including the group you just registered. The group numbers can be from 0 to 9. Group 0 is by default assigned to group EVERYONE. To use group 0 with group EVERYONE, you must create a group object called EVERYONE, because this group does not exist by default in NDS. You also have the option of assigning group 0 to any other group object name.
You can use the CD DIR command to list the files in the CD-ROM. This command is particularly useful if you want to quickly determine whether the CD-ROM contains the files that you need. To see a directory listing in the root directory for volume number 1 with name NETWARE_40, for instance, you can use the following:
CD DIR 1
or
CD DIR NETWARE_40
To dismount a volume, you can use the CD DISMOUNT command. To dismount volume number 1 with name NETWARE_40, for example, you can use the following:
CD DISMOUNT 1
or
CD DISMOUNT NETWARE_40
To see a list of groups registered with the CD-ROM, use the following command:
CD GROUP
To remove access to the CD-ROM from a specific group, use the following command:
CD GROUP DEL groupnumber
To remove the group CDUSERS that was assigned group number 1, for example, you can use the following command:
CD GROUP DEL 1
When access is granted to the CD-ROM, the users by default are given Read and File Scan ([R F]) access to the entire volume. Because the CD-ROM is a read-only volume, other NetWare file system rights such as Supervisor, Create, Write, Modify, and Access Control are not possible.
Once the CD group numbers are assigned, you can use the following:
CD MOUNT volume /G=groupnumber
To assign group 5, called READERS, access to the CD-ROM volume BOOKS, for example, you use the following:
LOAD CDROM CD GROUP READERS 5 CD MOUNT BOOKS /G=5
If the BOOKS CD-ROM was to be mounted on volume 1, you could use the following:
CD MOUNT 1 /G=5
The KEYB NLM is used to change the keyboard type for a specific language for the server console. The general syntax of the command is
LOAD KEYB [parameter]
where parameter is one of the following countries:
United States
United Kingdom
France
Germany
Italy
Spain
Figure 7.73 shows the effect of loading KEYB without a parameter. A brief help on the different keyboard types that are supported is presented. Figure 7.74 shows the effect of loading the keyboard of the locale France. The keyboard support for France implemented by code page 437 is loaded. This code page provides the translation to the characters used by keyboards for France. An example of the effect produced by this command on United States keyboards is that the keys Q and A are exchanged. That is, for the United States keyboard, if you press the key Q the letter A is displayed, and if you press the key A, the letter Q is displayed.
Figure 7.73 The LOAD KEYB command.
Figure 7.74 The LOAD KEYB FRANCE command.
The SCHDELAY NLM is used to prioritize server processes. Its primary purpose is to increase the scheduling delay for processes. This technique can reduce server CPU utilization if it is too high.
The general syntax for this NLM is as follows:
LOAD SCHDELAY [processName = number]
where processName is the name of the process and number is the amount of delay.
Loading SCHDELAY without any parameters shows the list of processes that are running and their current delay values (see fig. 7.75), which are 0 in this case. To increase the delay of the Media Manager process to 5, use the following command:
LOAD SCHDELAY MEDIA MANAGER=5
Figure 7.75 The LOAD SCHDELAY command.
Figure 7.76 shows the effect of executing the previous command. To change the delay for a particular process to 0 (no delay), use the following command:
LOAD SCHDELAY processName = 0
Figure 7.76 The LOAD SCHDELAY MEDIA MANAGER command.
To change the delay for all processes to 0 (no delay), use the following command:
LOAD SCHDELAY ALL PROCESSES = 0
You also can control the scheduling delay using MONITOR. Figure 7.77 shows the screen displayed when you select Scheduling Information from the Available Options in MONITOR. Notice that the scheduling delay for Media Manager is 5 from the command executed in figure 7.76. You can increase or decrease the scheduling delay by highlighting the process name and using the + or - keys.
Figure 7.77 Scheduling Information in MONITOR.
The NetWare console does not provide direct access to the NetWare file system such as commands to copy, erase, view contents, and move files. However, the EDIT.NLM can be used to view the contents of text files. In general, it is desirable to restrict access to the server machine. This goal can be accomplished by using any of the following:
If you are preparing for the NetWare 4.x Administration exams, review the chapter with the following goals:
In this chapter you have learned about NLMs and their role on a NetWare 4.x server. You also learned about the different types of server console commands and the NLMs used to manage the server. You were presented with a brief overview of SERVMAN and MONITOR NLMs and how to configure Remote Console at the server.
Test questions are either single choice or multiple choice. Where a single answer is desired, this is indicated by a l. Some questions require you to select more than one answer; this is indicated by the n preceding each answer. Certain questions are repeated in different ways, so that you can recognize them even when the wording is different. Taking practice quizzes not only tests your knowledge, but it also gives you confidence when you take your exam.
A. ?
B. HELP
C. HELP CONSOLE
D. HELPCMD
A. MEDIA
B. MAGAZINE
C. RESTART SERVER
D. REBOOT
E. LANGUAGE
F. KEYB
A. LANGSET
B. SET LANGUAGE
C. RESTART SERVER
D. REBOOT
E. LANGUAGE
F. KEYB
A. RESTART SERVER -NA
B. RESTART SERVER -N=AUTOEXEC.NCF
C. RESTART SERVER -N=STARTUP.NCF
D. RESTART SERVER -NS
E. RESTART SERVER -I
F. RESTART SERVER -D
A. INSTALL NLM
B. MONITOR NLM
C. SERVMAN NLM
D. LANGUAGE NLM
E. ADDLANG NLM
A. Alt+F1
B. Alt+F2
C. Alt+F3
D. Alt+F4
E. Alt+F5
A. Alt+F1
B. Alt+F2
C. Alt+F3
D. Alt+F4
E. Alt+F5
A. Alt+F1
B. Alt+F2
C. Alt+F3
D. Alt+F4
E. Alt+F5
A. DSREPAIR
B. DOMAIN
C. DOMPROT
D. OSP
A. MEMPOOL
B. MIGRATE
C. RTDM
D. RTM
A. MERGEDS
B. DSMERGE
C. DSCOMB
D. DSCON
E. PARTMGR
A. CDROM
B. CD_ROM
C. CD-ROM
D. CDLIB
E. LIBCD
A. SERVMAN
B. MONITOR
C. INSTALL
D. KEYB
E. SET
A. SERVMAN
B. MONITOR
C. INSTALL
D. KEYB
E. SET
A. DOMAIN
B. RING
C. DOMLIB
D. PROTECT
A. DOMAIN=2
B. DOMAIN PROTECT=2
C. DOMAIN PROTECT RING=2
D. DOMAIN RING=2
E. DOMAIN /R 2
A. DOMAIN OS =ON
B. DOMAIN=OS
C. DOMAIN=OS_PROTECTED
D. DOMAIN=NW
E. DOMAIN=OS_PROTECT
A. DOMAIN OS =PROTECT
B. DOMAIN=OS
C. DOMAIN=OS_PROTECTED
D. DOMAIN=NW
E. DOMAIN=OS_PROTECT
A. NDSREPAIR
B. VREPAIR
C. DSREPAIR
D. DIBREPAIR
A. SYS:SYSTEM\DSLOG.TXT
B. SYS:SYSTEM\DS\DSLOG.TXT
C. SYS:SYSTEM\DS\DSREPAIR.LOG
D. SYS:SYSTEM\DSREPAIR.LOG
A. the objects in the source tree become part of the target tree
B. the objects in the target tree become part of the source tree
C. containers in the source and target tree are merged
D. containers in the source and target tree are merged, and if there are duplicate container names the container in the target tree is renamed according to well-defined rules
A. Connection Information
B. Scheduling Information
C. Lock Server Console
D. Resource Utilization
E. Delay Task
A. EXTEND SPACE
B. ADD NAME
C. EXTEND NAME SPACE
D. EXTEND NAMES
E. ADD NAME SPACE
A. VOLUMES
B. SHOW CONFIG
C. CONFIG
D. LOAD CONFIG
A. CLEAR
B. CLS
C. CLEAR SCREEN
D. CLS SCREEN
A. REMOTE.NLM, RSPX.NLM, REMOTE.EXE at work-station
B. RSPX.NLM, REMOTE.NLM, REMOTE.EXE at work-station
C. RS232.NLM, REMOTE.NLM, REMOTE.EXE at work-station
D. REMOTE.EXE at workstation, RS232.NLM, REMOTE.NLM
© Copyright, Macmillan Computer Publishing. All rights reserved.