|
Install UXPSFT.EXE file as described below in Installation.
Self-Extracting File Name: UXPSFT.EXE
This SOLUTION contains the following sections:
General Information
Additional Release Notes
TCP/IP Configuration
===============
General Information
===============
UXPSFT replaces some but not all of the UNIX Print Services 2.1 files. It cannot run on its own, and cannot be used to upgrade from NetWare NFS 1.x or NFS Gateway 1.x to NetWare UNIX Print Services 2.1 NetWare 4 Edition.
UXPSFT is not intended for use with native 4.10. The SFT III upgrade to NetWare 4.10 operating system is required.
If you remove this SFT III update from an NetWare SFT III server, make sure that you also remove the NetWare UNIX Print Services 2.1 product. NetWare UNIX Print Services cannot function properly by itself and would be unstable on SFT III.
UXPSFT patch can be installed before or after the UNIX Print Services product itself.
===================
Additional Release Notes:
===================
* The RARP Server is not supported on NetWare SFT III. The RARP NLM will exit when loaded on SFT III.
* The remote access services are available only through UNICON. Do not enable remote access (FTP and XCONSOLE) by using INETCFG utility. Instead, use UNICON to do the same thing.
* XCONSOLE does not use the fault-tolerant features of SFT III, since the NLMs related to XCONSOLE service load in the I/O Engine. Therefore, in the event of the SFT III Primary Server failure, the XCONSOLE service stops and any XCONSOLE sessions are terminated. However, the service can be restarted through UNICON and new XCONSOLE sessions can be created by attaching to the IO Engine of the new Primary Server.
For example, consider an SFT III system having the following IP addresses for its IO Engines:
IO Engine 1: IP addr=154.88.219.48
IO Engine 2: IP addr=154.88.219.49
REMOTE.NLM and RSPX.NLM are loaded in both the IO Engines.
Let us assume that IO Engine 1 is initially the Primary Server.
To start an XCONSOLE session, the following steps are carried out:
1. Start the XCONSOLE service through UNICON.
2. Open an XCONSOLE session from an XServer by connecting to the Primary Server IO Engine, e.g. telnet to IO Engine1 (IP addr=154.88.219.48)
Subsequently, the Primary Server fails and IOEngine2 takes over as the new Primary Server. The XCONSOLE service stops.
To restart the XCONSOLE session, follow these steps:
1. Start the XCONSOLE service through UNICON.
2. Open an XCONSOLE session from an XServer by connecting to the Primary Server current IOEngine, e.g. telnet to IOEngine2 (IP addr=154.88.219.49).
You cannot start XCONSOLE on both IO1 and IO2 concurrently, because they share the same MS Engine.
XCONSOLE clients (X servers) can attach to the IP address of the primary I/O engine. Attempts to access the MS engine will fail.
* TIME Synchronization is important. UNIX Print Services will not function properly if the time is not synchronized to the network. To ensure that the UNIX Print Services are loaded only after time is synchronized, this update modifies MSAUTO.NCF so that it loads a TIMCHK.NLM instead of executing UNISTART.NCF. The TIMCHK.NLM in turn executes UNISTART.NCF, but only after the time is synchronized. Do not manually start the Print Services or use UNISTART until time synchronization is complete (the console command TIME reports that "Time is synchronized to the network.".)
===============================
TCP/IP Configuration on NetWare SFT III
===============================
The SFT III system from an TCP/IP network perspective consists of the following:
1. The two IO Engines - IO1 and IO2 connected to the physical network, each having a unique IP address and using the same Subnet Mask as used by other Nodes on the Subnet.
2. The MS Engine resides on a Virtual LAN and is not directly connected to the physical or the real network. The MS Engine interfaces to the real network through the IO Engine. The two IO Engines (can be visualized to) have a common IO Engine interface which resides on the Virtual LAN along with the MS Engine. Let us call this common interface as the IO Engine-MS Engine Internal interface.
The Virtual LAN in effect is a stub-subnet with the IO Engines acting as routers between the real network and the Virtual LAN (the IO Engine on the Primary Server routes IP packets between the MS Engine and the real/physical network).
The two nodes on the Virtual LAN, the MS Engine and the IO Engine-MS Engine Internal Interface, have a common stub-subnet Mask and each has a unique IP address.
From the above description, it is clear that an SFT III system requires four IP addresses: one for IO Engine 1, one for IO Engine 2, one for the MS Engine and one for the IO Engine-MS Engine internal interface.
However, it is important to note that addresses in the stub-subnet mask address range cannot be allocated to any other node on the real/physical network. Therefore, the actual range of IP addresses to be allocated or reserved for the SFT III system extends beyond four addresses.
Figure 1. TCP/IP Configuration Example
+-------------------------------+
| Mirrored Server - MS Engine |
| 154.88.219.33 |
+-------------------------------+
|
|
| Virtual LAN
----------------------------------------------
|
|
(IO Engine-MS Engine | Internal Interface)
|------------54.88.219.34-----------|
+-----------------+ +-----------------+
| IO Engine 1 | | IO Engine 2 |
| 154.88.219.48 | | 154.88.219.49 |
+-----------------+ +-----------------+
| |
| Real Network 154.88.219.0 |
--------------------------------------------------------------
Let us assume some example addresses. An SFT III system is to be setup on a class B subnetwork; the Subnet IP address is 154.88.219.0. The Subnet Mask used by the IO Engines will be 255.255.255.0 (FF.FF.FF.00) - the same as for any node on a Class B Subnet.
Let us assume that the range of IP addresses from 154.88.219.32 to 154.88.219.63 is available.
The stub-subnet mask can be configured to one of the following:
Stub-Subnet Mask Number of IP addresses to be set aside
exclusively for the Stub-Subnet
1. 255.255.255.248 (FF.FF.FF.F8) 8
2. 255.255.255.240 (FF.FF.FF.F0) 16
3. 255.255.255.224 (FF.FF.FF.E0) 32
Let us assume that we select the Stub-Subnet Mask as 255.255.255.240 and that we choose to allocate the following IP addresses for the Nodes on the Virtual LAN or the Stub-Subnet:
Node IP Address Stub-subnet Mask
MS Engine 154.88.219.33 255.255.255.240
IOEngine-MSEngine Internal Interface 154.88.219.34 255.255.255.240
Stub-Subnet Mask = 255.255.255.240:
240 = 1111 0000
33 = 0010 0001 (MS Engine)
34 = 0010 0010 (IO-MS internal interface)
Stub-Subnet Address = 154.88.219.32:
Node ID for MS Engine = 1
Node ID for IO-MS internal interface=2
Now the range of IP addresses from 154.88.219.32 to 154.88.219.47 has to set aside or reserved exclusively for the SFT III system and cannot be used by any other node on the Class B subnet. So, we allocate the IP addresses for the two IO Engines as follows:
Node IP Address Subnet Mask
IO Engine 1 154.88.219.48 255.255.255.0
IO Engine 2 154.88.219.49 255.255.255.0
To setup TCP/IP configuration on SFT III system, the following steps are to be carried out:
1. Load INETCFG in IOEngine1 - select Bindings Option, add/select TCP/IP protocol and configure the IP address and the Subnet Mask for IO Engine1.
Then select the Protocols Option, select TCP/IP protocol and configure the following:
"IP address for the SFT III Network" (i.e. IP address for the IO-MS Internal Interface) and the "Subnet Mask of SFT III Network" (i.e. the Stub-subnet Mask)
2. Load INETCFG in IO Engine2 and repeat the same steps as was done on IO Engine1.
3. Load INETCFG in the MS Engine - select Protocols Option, select TCP/IP protocol and configure the following:
"IP address for the SFT III Network" (i.e. IP address for the MS Engine) and the "Subnet Mask of SFT III Network" (i.e. the Stub-subnet Mask).
Once the TCP/IP configuration for the SFT III system is complete (and TCP/IP has been loaded in both the IO Engines and the MS Engine), you can verify the same by doing a PING operation to the MS Engine IP address from another node (say, a Unix host) on the network.
Note that the IO Engine - MS Engine Internal Interface address must exist on the same network as the IP address bound to the I/O engines, as seen below in MSAUTO.NCF.
Note also that the RIP = YES parameter is required for proper function, to allow RIP broadcasts to go to the network.
Do not modify these files with any text editor, use INETCFG only.
After successful configuration, the .NCF script files used by NetWare SFT III during bootup will contain the network configuration. Using the same example, the script files would contain:
I/O Engine 1 SYS:ETC/IO1/NETINFO.CFG (IO engine 1) contains:
LOAD TCPIP RIP=YES FORWARD=YES
BIND IP NE2000 ADDR=154.88.219.48 MASK=255.255.255.0
BIND IP MSEngine ADDR=154.88.219.33 MASK=255.255.255.240
I/O Engine 2 SYS:ETC/IO1/NETINFO.CFG (IO engine 2) contains:
LOAD TCPIP RIP=YES FORWARD=YES
BIND IP NE2000 ADDR=154.88.219.49 MASK=255.255.255.0
BIND IP MSENGINE ADDR=154.88.219.33 MASK=255.255.255.252
SYS:ETC/NETINFO.CFG (the MS engine) contains:
LOAD TCPIP RIP=YES FORWARD=NO
BIND IP MSENGINE ADDR=154.88.219.34
|
