NOVELL TECHNICAL INFORMATION DOCUMENT TITLE: NFSSFT; SFT III Update for NW NFS Services 2.1 - NW 4 Edition README FOR: NFSSFT.EXE NOVELL PRODUCTS and VERSIONS: NetWare NFS Services 2.1 - NetWare 4 Edition ABSTRACT: The SFT III Update for NetWare NFS Services 2.1 is a software update to the NetWare NFS Services 2.1 product that enables the NFS Services 2.1 software to run on NetWare SFT III 4.10. Self-Extracting File Name: NFSSFT.EXE ----------------------------------------------------------------- DISCLAIMER THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION. ----------------------------------------------------------------- SYMPTOM: NetWare NFS Services 2.1, NetWare 4 Edition requires this update in order to support NetWare 4.10 SFT III system software. SOLUTION: Install NFSSFT.EXE file as described below in Installation. This SOLUTION contains the following sections: General Information Installation Instructions Additional Release Notes TCP/IP Configuration =============== General Information =============== NFSSFT replaces some but not all of the NFS 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 NFS Services 2.1 NetWare 4 Edition. NFSSFT 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 NFS Services 2.1 product. NetWare NFS Services cannot function properly by itself and would be unstable on SFT III. NFSSFT patch can be installed before or after the NFS Services product itself. ================= Installation Instructions ================= 1. (Optional step) After the base SFT III system is installed, make complete backup of SYS:SYSTEM and any critical data directories. 2. Apply all the latest NetWare SFT III Operating System patches to the base SFT III system. Also, apply the latest version of DS.NLM. You can get these either from NetWire or from the Web site at http://www.novell.com. 3. Configure TCP/IP on the SFT III server. Detailed instructions are at the end of this document. 4. (Optional step) Make a backup of TCPIP.NLM. The installation process automatically upgrades TCPIP.NLM if the installation program (INSTALL.NLM) detects an older version. 5. From a workstation attached to the NetWare SFT III 4.10 server, create a directory named NFSSFT on any NetWare volume on the Primary MS Engine. MD NFSSFT 6. Copy NFSSFT.EXE into the new directory. NCOPY NFSSFT.EXE SYS:NFSSFT 7. Type NFSSFT to extract the files. CD NFSSFT NFSSFT 8. From the console of the MS engine, check the mirror status to ensure both partitions are synchronized. MIRROR STATUS 9. From the server console, run UNISTOP.NCF as a general precaution. UNISTOP 10. If NFS Services 2.1 is already installed on this machine, make sure that you are at the console of the same machine now. This software update and NFS Services 2.1 both should be installed on the same physical machine. When both partitions activates, this will be the primary server. 11. Load the installation program. LOAD INSTALL 12. Select PRODUCT OPTIONS. The Currently Installed Products list appears. 13. Press to install a new product. 14. Press to specify the location of the NFSSFT directory. The "SPECIFY DIRECTORY PATH" dialogue box will appear. 15. Enter the path to the directory where the NFSSFT files were previously extracted, in the DISK1 subdirectory. SYS:/NFSSFT/DISK1 After the installation program installs the files, the "Currently Installed Products" list will contain a new entry: NFSSFT NetWare NFS Services 2.1, SFT III Update 16. Exit the Installation program or press to return to the system console prompt. The installation of the update software is now almost complete. 17. Copy the file NFS.NAM manually from the Netware boot directory on the server where this update was installed to the boot directory of the other server in the SFT III pair. This is necessary because the NFS.NAM is loaded from the DOS partition, usually the C: drive, which is not mirrored. All console commands which access files in the DOS partition go to the DOS partition on the Primary MS Engine. 18. If NFS Services 2.1 is not already installed on this machine, install it now according to its packaged instructions. 19. Installation is now complete, NFS Services is running, and the startup files have been modified for NFS Services to autoload the next time SFT III boots. If it is ever necessary to manually start the Services from the server console, load the TIMECHK.NLM. Although UNISTART.NCF is still present, as with pre-upgrade NFS Services, it is better to use TIMECHK instead. See notes below on Time Synchronization for more information. 20. Additional steps are needed to allow replication of the NIS database with other NIS servers because NIS broadcasts cannot propagate across the internal IP router of SFT III. Similarly, the NIS server on SFT III will never recieve the "ypbind -broadcast" from any other UNIX NIS client. To enable replication and proper operation of NIS: 20a. If NetWare is an NIS slave server, explicitly enter the IP address of the NIS master server. From UNICON, go to Manage Replica Databases and try to create a replica domain, and enter the domain name. When the broadcast fails, enter the IP address of the NIS master for the domain. 20b. If NetWare is an NIS master, NIS clients have to be explicitly bound to the IP address for the MS engine. =================== Additional Release Notes: =================== * If NetWare NFS file system is mounted using the "soft" option, then I/O errors on the NFS client may be seen if the primary server fails, since it takes time for the secondary server to take over. If you wish to prevent this possibility, use the hard mount option or increase the timeout parameter associated with the soft mount. * 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 IOEngine, e.g. telnet to IOEngine1 (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. NFS Services will not function properly if the time is not synchronized to the network. To ensure that the NFS 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 NFS 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 IO Engine1 - 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