Network Support Encyclopedia 96-1

home *** CD-ROM | disk | FTP | other *** search

/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / ngm192.exe / README.UPG < prev next >

Wrap

Text File | 1994-05-25 | 35KB | 701 lines

┌───────────────────────────────────────────────────┐ │ │ │ NetWare Global MHS │ │ Upgrade 2.0C for NW4.01 │ │ May 23, 1993 │ │ │ └───────────────────────────────────────────────────┘ UPGRADING FROM NGM v2.0b to v2.0c _________________________________ This file describes the steps required to upgrade NetWare Global MHS from version 2.0b to version 2.0c. This upgrade provides the following changes: 1. Illegal Memory Access: o NGMINS and NGMDEINS were passing a memory block without calling InitScratchMemory. o NGMEXTRC was trying to initialize an invalid handle which is no longer used. o NGMUPGRADE was passing an absolute pointer to create screen. This pointer is not valid in the upgraded NUT.NLM. o NGMADMIN was allocating memory using malloc and was trying to deallocate it using FREE() instead of free(). o NGMADMIN abended when deleting a gateway host. This problem was resolved by checking the pointer to the gateway host name before deleting it. o NGMSMF abended when adding a new application. Problem resolved by passing the correct pointer to application record. 2. Unreleased Resources: o When any module is loaded with -s option CreateScreen allocates memory . This memory was not released when the module was unloaded. Modified the modules DSYNC.NLM, NGM.NLM, NGMEXTRC.NLM, NGMSMF.NLM to use DestroyScreen() to release the memory. 3. Misbehaviours: o CMP now checks, during updates, that a deletion record's master host and the original record's master host are the same. This fixes the missing link problem. o Fixed PMR: Deleting a record did not generate opcode (Delete) in an ASCII CMP message. Check is made against PL_DESTROY instead of PL_DELETE. *NOTE* This patch is designed to upgrade NetWare Global Messaging v2.0b to v2.0c. If you have a version other than an official red box or patched version of NGM2.0b, this upgrade will not work. To determine your current NGM version, type 'load MODULES' at the server console prompt and verify that the version number for 'NGMADMIN.NLM' is v2.0b. If you have any other version, contact your local Novell representative to receive the appropriate upgrade for your system. WHAT DO YOU NEED TO DO FIRST? _____________________________ Use this upgrade to modify an existing NetWare Global MHS installation. Before you install this upgrade, verify that you have an official release of NetWare Global MHS v2.0b installed on your system. For information on installing NetWare Global MHS, refer to your "Installing NetWare Global Messaging" manual, part number 100-001200-001. WHICH FILES ARE UPGRADED? ------------------------- This upgrade changes the following files. 1. NGM.NLM 2. NGMSMF.NLM 3. NGMAMP.NLM 4. NGMADMIN.NLM 5. NGMINS.NLM 6. NGMEXTRC.NLM 7. NGMDEINS.NLM 8. NGMUPGDE.NLM 9. NGMDSYNC.NLM This upgrade does not change the serial number and maximum number of licensed users for your NetWare Global MHS installation. INSTRUCTIONS FOR INSTALLING GMHS ON NETWARE 4.01 ________________________________________________ Please read this entire document before starting an installation of GMHS on your NetWare 4.01 server. This GMHS patch for NW 4.01 works in Bindery Emulation mode ONLY. The following installation procedures MUST be followed to successfully install and configure GMHS on a NW 4.01 server. This patch version must be loaded ONLY on NW 4.01 (not 4.0) and you must use the CLIB and Btrieve specified in this document. Installing and configuring GMHS on a NW 4.01 server requires the following: 1. GMHS 2.0b software for NW 3.12 (Redbox or patch release) 2. GMHS 2.0c patch for NW 4.01 (Located on NetWire) 3. Proper versions of CLIB and BTRIEVE (Located on NetWire) *NOTE* These files can be found on NetWire in the following locations: BTRIEVE - NOVLIB Library 7 BTR61.EXE BTRIEVE.NLM version 6.10C dated November 19, 1993. (DO NOT use the CLIB version which is included in this self-extracting archive) CLIB - NOVLIB Library 4 LIBUP2.EXE CLIB.NLM version 4.01D dated February 24, 1994. Please make sure you have the installation media, the patch software, and proper CLIB and Btrieve software, prior to proceeding with the installation and configuration of GMHS on your NW 4.01 server. USER ADMINISTRATION/ACCOUNT MANAGEMENT ______________________________________ This section describes the guidelines for setting up and managing MHS mailbox accounts given the interaction between NDS and the Global MHS directory through the bindery emulation. This section assumes the reader is familiar with and understands bindery emulation and NDS. For a successful installation, it is very important to take the time to understand this section and understand the operation of your MHS application. APPLICATION ISSUES __________________ Most MHS applications have been developed with NetWare 3.x in mind. This means the applications may make certain assumptions about bindery use, traditional NetWare 3.x directory structures etc.. In determining how you will administer and manage the system, you must take into account how the application is affected by your system configuration. The following lists some of the known issues that you should understand before starting. Please contact your MHS application provider's documentation and/or tech support group to confirm these items before you start. 1. Some applications make use of the SYS:\MAIL\<userid> directory structure that was part of the NetWare 3.x system. NetWare 4.01 does not behave thevsame in this regard in that it does not provide users access to their SYS:\MAIL\<userid> directory by default. For example, Novell's own FirstMail mail application uses the SYS:\MAIL\<userid> directory as its default message store. If you upgrade your system from NetWare 3.x to NetWare 4.01, your rights are likely preserved. If you have done a fresh installation of NetWare 4.01, you must ensure that rights are properly assigned. 2. MHS applications vary some in how they locate the \MHS directory tree. Most applications use the MV environment variable (see Global MHS documentation for details). If your application uses the MV variable you must ensure this variable is properly set in your user's login scripts. If other methods are used, you must understand how the application is affected by the administration interactions described below. 3. Some MHS applications use environment variables to determine what their MHS mail address is while others use techniques that involve bindery calls. If the applications use environment variables, then you only need to make sure it is properly set as part of the login scripts. If bindery calls are used, then you MUST carefully follow the procedure recommended below and MUST NOT use the 'Advanced Configuration' method since applications will be unable to determine their mail addresses in that case. OVERVIEW OF NDS/GLOBAL MHS INTERACTION -------------------------------------- Global MHS uses bindery emulation to associate user accounts with physical mailboxes. A mailbox account is created by either importing users from the bindery or by adding users via NGMADMIN. Whenusing NGMADMIN to add a user, the utility confirms the existance of the user's account in the bindery. If there is no bindery user for the account being created, a new bindery entry is added for the new mailbox account. When using bindery emulation in NetWare 4.01, this Global MHS interaction with the bindery indirectly introduces some dynamics with NDS. For instance, if NGMADMIN is used to create an account forwhich no BINDERY entry exists, a new bindery entry is created in the bindery context for that server. This causes an NDS user object to be created at the same time in the container object associated with the bindery context. Conversely, when NWADMIN is used to add an NDS user object, a bindery entry is created for that user on every server which uses that bindery context. These two indirect interactions impose some constraints about managing Global MHS mailbox accounts. Understanding the interaction model is very important to ensure a successful deployment. To avoid complex manual administrative intervention, there are 5 recommended general guidelines which will help you. These are summarized in the following bullet points and will be explained in the following sub-sections. By following these guidelines, the major features of Global MHS will work successfully (e.g. bindery import, sender validation, passive server, etc.). A more complex manual process can be achieved but is not recommended since it adversely affects some of the Global MHS features. o Each NetWare 4.01 server which acts as either an ACTIVE or PASSIVE Global MHS server should use a bindery context which is unique for the entire network. o All NDS user accounts which are to have mailbox accounts on a common Global MHS server should be in the bindery context which is unique to that server. o The Global MHS long-names in the Global MHS directory are independent of the NDS names and a consistently applied naming scheme should be employed for the Global MHS names. o Global MHS mailbox deletion and NDS user object deletion are independent events. If you delete a mailbox for a user, the NDS account and bindery object remain intact. If you delete an NDS user object, the mailbox remains intact (if one was created). You must remember to delete accounts accordingly. o Use consistent methods for adding, deleting, and moving users to avoid missing steps that might cause conflicts in name or account locations. This is important because there are multiple ways to add users to the system and depending upon the method used, other procedures must follow. If you follow these guidelines, existing bindery dependent applications and all Global MHS features should work without any problem. However, you must confirm application compatibility with your application provider. UNIQUE BINDERY CONTEXTS ----------------------- If more than one server shares a common bindery context, the binderies for those servers will be identical. That is, user accounts in that context will receive bindery accounts on each of the servers. If bindery import is used to create Global MHS mailboxes and multiple Global MHS servers share the same context, then each user in that context will end up with multiple mailboxes (one on each Global MHS server sharing the same context). When Global MHS synchronizes routes, conflicts can occur. This conflict will also exist for a single Global MHS server which is the ACTIVE router for a PASSIVE Global MHS system. MAILBOX USERS IN THE SAME BINDERY CONTEXT ----------------------------------------- When using bindery import in Global MHS, only NDS user objects in the bindery context for that server will have bindery accounts that can be imported. NDS user objects in different bindery contexts will be invisible to Global MHS and therefore can not be imported. Therefore, if you want a user's mailbox to reside on a particular Global MHS server, that user's NDS account must exist in the bindery context for the target Global MHS server. If you have an existing NDS structure where users from multiple contexts must have mailbox accounts on the same Global MHS server, you must alter the NDS structure. One way to do this is to move all of the desired users into the same bindery context as the Global MHS server and then create NDS alias objects in the contexts where the user account originally was located. This will allow the users to continue to log in under their old NDS name (now an alias) while meeting the requirements for Global MHS to operate. *WARNING* If a user is in the wrong context and you create an alias in the right context, the desired affect will NOT be achieved! The actual non-aliased NDS object must be in the Global MHS server's context in order for a bindery account to be visible to Global MHS. If you choose to create Global MHS accounts using NGMADMIN, bindery accounts will be created if the user does not exist in that context. This will create an NDS account for that user in the bindery context of that Global MHS server. You will likely want to then use NWADMIN to complete user account. NDS/GLOBAL MHS DIRECTORY STRATEGIES ----------------------------------- Global MHS maintains a directory of mailbox names. These logical names are hierarchical location independent names in the same way that NDS names are hierarchical and location independent. Because Global MHS is running in bindery emulation mode, the Global MHS directory names are totally independent of the NDS names. For example, the user Susan Jacobs might have an NDS name of Susan.Jacobs.Marketing.San Fransisco.Acme and a Global MHS name of Susan Jacobs @ Marketing.Acme. When logging into the network, the NDS name is specified, but Global MHS knows Susan by the Global MHS name only. To avoid confusion, a consistent naming strategy should be employed. There are two recommended strategies. One strategy is to intentionally make the Global MHS tree and the NDS tree naming conventions unique. The second strategy is to make the Global MHS and NDS tree naming conventions identical. There are pros and cons to each of these and each installation should decide which strategy is best. Either strategy will be compatible with the upgrade for the forthcoming NetWare 4.x NDS integrated MHS solution. Unique naming conventions can be advantageous when people have selected NDS conventions that are excessively long or suggest physical locations or administrative partitions. For example, if you use naming conventions like David Peterson.Segment 6.Building 3.Phoenix.Davis Corp, you will likely not want the user's NDS name to be the mail name. Rather, you may find David Peterson@Davis Corp to be more appealing for mail purposes. Taking advantage of the independence between Global MHS and NDS naming allows you to construct flat, concise mail directories while maintaining deeper more descriptive NDS naming (for network admin purposes). The disadvantage of this scheme is that users will be known by two logical names and there is no directly apparent corelation between NDS name and the Global MHS name (visible via NDS or Global MHS tools). This corelation can only be determined by finding the NDS and Global MHS names which are associated with the same bindery account. Identical naming conventions can be advantageous if you want users to only be known by one logical name. For instance, if you want the NDS account Karen Woodward.Engineering.Software Guru's to be known as Karen Woodward @ Engineering.Software Guru's in Global MHS, then identical naming strategies are appropriate. However, if the NDS names you have are long complex names which are non-intuitive, then identical naming may not work well for you. *REMEMBER* The long name used in Global MHS is independent of the NDS name. If your Global MHS directory tree matches your NDS tree (by manually creating it this way), users will only be created in the default bindery context even if the Global MHS name is a different bindery context!! If you are using aliases to allow people to log into different contexts but use a common server for mail, you must manually create the NDS alias for the user object created in the server's bindery context. For example, you decide to create Jim Grubb @ Engineering.ABC by using NGMADMIN but the default context for the server is Operations.ABC. NGMADMIN will create a bindery account for Jim Grubb which results in an NDS user object Jim Grubb.Operations.ABC. To keep the naming consistent, you must remember to then use NWADMIN to manually create the alias Jim Grubb.Engineering.ABC and associate it with the Jim Grubb.Operations.ABC user object. Conversely, if you want to create users through NWADMIN. If you decide you want Jim Grubb to have a mailbox on the server in the Operations.ABC context and also be listed in the Engineering.ABC context, you must first create the Jim Grubb.Operations.ABC user object using NWADMIN. You then create an alias for Jim Grubb.Engineering.ABC which points to Jim Grubb.Operations.ABC. Finally, if you use NGMADMIN to add Jim Grubb you must remember to manually set the long name to be Jim Grubb @ Engineering.ABC. ACCOUNT DELETION ---------------- Global MHS will not delete bindery accounts if the mailbox is deleted through NGMADMIN. Generally, this is a desired behavior. Conversely, if you delete an NDS user object which has a corresponding Global MHS account, the mailbox is not deleted. This may not be the desired behavior since there is no longer a user associated with the account. You must remember to delete the Global MHS account separately from NDS user object deletion. CONSISTENT ADMINISTRATION ------------------------- The key to success is to employ a consistent administrative process for adding, moving or deleting users. This will ensure that you don't miss steps or introduce inconsistency in your naming strategies. For example, you might decide to always add users by first adding them via NWADMIN and then adding them through Global MHS bindery import (or NGMADMIN). Conversely, you might decide to first create the mailbox account via NGMADMIN and then use NWADMIN to complete account set-up. The following are two sample procedures you could adopt. User Add Procedure from NDS: 1. Add the NDS user object in the bindery context for the Global MHS server where the mailbox should reside. 2. Create any needed alias for the NDS user object in different context(s) if desired. 3. Use NGMADMIN to add the mailbox and set the MHS long name according to convention used. Delete User Procedure from NDS: 1. Note the MHS long name for the user to be deleted. 2. Delete the NDS user alias (if exists). 3. Delete the NDS user object. 4. Use NGMADMIN to delete the MHS account (noted from step 1). User Add Procedure from Global MHS: 1. Use NGMADMIN to add the MHS user and set the long name according to desired convention. 2. Use NWADMIN to edit the NDS user object in the context for the Global MHS server. 3. Use NWADMIN to create any alias for the NDS user object (if necessary). User Delete Procedure from Global MHS: 1. Note the NDS account associated with the mailbox to be deleted. 2. Use NGMADMIN to delete the MHS account. *NOTE* If you do not want to delete the user object, stop at this point. 3. Use NWADMIN to delete any alias associated with the NDS account noted in step1. 4. Use NWADMIN to delete the NDS user object noted in step 1. ADVANCED CONFIGURATION ---------------------- If you are willing to give up bindery import from Global MHS and do not want to use sender validation, and if you are unwilling to have the restriction of all unique bindery contexts for each Global MHS server with all MHS users in the same context for that Global MHS server, you can do so. This is not recommended because you must understand mailbox access rights controls in addition to fully understanding the interaction issues of NDS (introducing room for manual error). For those requiring this capability, this section describes the procedure. APPLICATION INCOMPATIBILITY WARNING: If you use the following procedure, bindery accounts will not be available will not be available for users in different contexts than the default context of the Global MHS server. Applications that use bindery information will not work for those users in other contexts. Refer to the earlier section on Application Issues before proceding with this configuration. OPERATIONAL WARNING: If you use this process, you must not use bindery import from Global MHS. Doing so will cause a host of problems. To reinstate bindery import compatibility, you must completely restructure your NDS tree according to the constraints listed under the recommended procedure. Secondly, because Global MHS uses bindery file ownership for sender validation, validation will not work. Third, any errors in setting up user rights in the MHS directory structure may rendor your Global MHS system inoperable. Again, Novell strongly recommends that you use the procedures listed earlier. This information is only being provided as a matter of convenience for highly skilled, and advanced MHS users who are willing to accept responsibility for proper and fully manual administration. User Add from NDS: 1. Add the NDS user object from NWADMIN in any desired context. 2. Use NGMADMIN to add a mailbox account and set the long name according to your desired convention. 3. Assuming the NDS user object is not in the bindery context for the Global MHS server, use NWADMIN to delete the user object that was created when NGMADMIN added the bindery account for the new mailbox account. 4. User NWADMIN to grant the NDS user object (created in step 1) proper rights to the MHS mailbox directory created by NGMADMIN. (\MHS\MAIL\USERS\<gmhs short name>). 5. Use NWADMIN to grand the NDS user object (created in step 2) proper rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees. *NOTE* Refer to Global MHS documentation to learn how rights are in the \MHS directory structure. User Add from Global MHS: 1. Use NGMADMIN to add a mailbox account and set the long name according to your desired convention. 2. Add the NDS user object from NWADMIN in any desired context. 3. Assuming the NDS user object is not in the bindery context for the Global MHS server, use NWADMIN to delete the user object that was created when NGMADMIN added the bindery account for the new mailbox account. 4. User NWADMIN to grant the NDS user object (created in step 1) proper rights to the MHS mailbox directory created by NGMADMIN (\MHS\MAIL\USERS\<gmhs short name>). 5. Use NWADMIN to grand the NDS user object (created in step 2) proper rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees. *NOTE* Refer to Global MHS documentation to learn how rights are assigned in the \MHS directory structure. UNRESOLVED ISSUES ------------------ This document will be updated pending verification of the following issues: 1. Compatibility with the SNADS protocol module. 2. Compatibility with the SMTP protocol module. 3. Compatibility with the Retix X.400 protocol module. PROCEDURE FOR INSTALLING GMHS ON NETWARE 4.01 _____________________________________________ Step 1: Verify that the following NW 4.01 configuration parameters are set as indicated. GMHS requires these parameters for proper installation and operation. a. Allow Invalid Pointers = ON b. Read Fault Emulation = ON c. Write Fault Emulation = ON You can verify this by: 1. Loading SERVMAN.NLM on the system console 2. Selecting 'Console Set Commands' 3. Selecting 'Memory' option If the above three parameters are not set to ON, please change them. All three parameters should be turned ON. Step 2: Establish the Bindery Emulation Context for all users on that NW 4.01 server. This is done using NDS administration utilities. Step 3: Add the group EVERYONE to the NDS Container associated with the above Bindery Emulation Context. Step 4: If this context has a user called "Admin" then please rename this user to avoid conflicts with GMHS's Admin user that is normally associated with the "Supervisor" Bindery user. Alternatively, make sure that the GMHS postmaster user is not 'ADMIN' (can be ADMIN1 for instance) in step 6. Step 5: Load the following versions of CLIB.NLM and BTRIEVE.NLM: CLIB.NLM version 4.01D dated February 24, 1994. BTRIEVE.NLM version 6.10C dated November 19, 1993. Step 6: Install GMHS from the media in the GMHS red-box following GMHS installation guidelines. If you need to change the name of the postmaster user from ADMIN to something else do so at this stage. Step 7: If you use the NGMStart.ncf file to run NGM you must edit NGMStart.ncf to have it load the correct versions of CLIB and Btrieve, specifying the directories where these new files were copied to in step 5. Do NOT use CLIB and Btrieve installed in the NGM\BIN directory by the GMHS install program. Step 8: Execute the GMHS patch copied down from NetWire. (See 'UPGRADING YOUR SERVER', below, for instructions on the patch upgrade procedure) Step 9: Load NGM following the instructions on running NGM. *NOTE1* The following message may be displayed on the server console during the installation of GMHS v2.0c on a NetWare 4.01 server: "Read from a non-present page Process: Pinstall.nlm 0 Module: NetWare Server Operating System Code offset in module: FD006A3FH Access address: 0000008EH" This message should not be considered a problem and is to be expected for an initial installation of GMHS v2.0c on NetWare 4.01. *NOTE2* When this patched NGM.NLM software is loaded, you will see the following warning message. "This module uses 4 outdated API calls You should upgrade to a newer module when it becomes available" This message is for informational purposes only. This version of NGM has been upgraded for NetWare 4. You should ignore this warning message. *NOTE3* There can be a NetWare problem when several multi-NLM products are loaded from AUTOEXEC.NCF. The primary symptom is the server may reboot itself while in the process of loading an NLM of a multi-NLM product. This reboot may repeat several times before the server manages to successfully come up with all products loaded. If you experience this symptom and your AUTOEXEC.NCF is loading multi-NLM products, remove the LOAD commands for those multi-NLM products from AUTOEXEC. Load those NLMs manually after your server has completed its boot procedure. UPGRADING YOUR SERVER --------------------- Step 1. Login to your NGM server as supervisor. Step 2. Verify that your server has at least 8.0 MB of free hard disk space. This is the recommended minimum required to perform this upgrade. Step 3. The contents of the NetWare Global MHS 2.0C for NW 4.01 patch is as follows: a. README.UPG b. PATCH.EXE c. PATCHNGM.BAT d. UPGRD20C.RTP Step 4. Copy the files 'PATCH.EXE', 'PATCHNGM.BAT', and 'UPGRD20C.RTP' to the root NGM directory. The default NetWare Global MHS directory is <Server\Volume:\NGM\>. Sample: COPY PATCH.EXE <drive>:\NGM\PATCH.EXE COPY PATCHNGM.BAT <drive>:\NGM\PATCHNGM.BAT COPY UPGRD20C.RTP <drive>:\NGM\UPGRD20C.RTP If you installed NetWare Global MHS in some other directory, be sure to copy the upgrade files to that directory. For example, if NetWare Global MHS is installed in the directory <Server\Volume:\PUBLIC\MAIL\NGM\>, enter the following: Sample: COPY PATCH.EXE <drive>:\PUBLIC\MAIL\NGM\PATCH.EXE COPY PATCHNGM.BAT <drive>:\PUBLIC\MAIL\NGM\PATCHNGM.BAT COPY UPGRD20C.RTP <drive>:\PUBLIC\MAIL\NGM\UPGRD20C.RTP The patch program searches down through all subdirectories to find the appropriate files to upgrade. Therefore, it is very important to start the upgrade procedure from the correct directory. Step 5. Unload NGM at the server console and make a backup copy of your NetWare Global MHS Directory structure. IMPORTANT: Do not save backup files under the same directory structure in which you installed NetWare Global MHS. The upgrade procedure will update the first file within the directory structure. If this first file happens to be a backup file, then the correct system file may not be upgraded. Step 6. Change to the root NGM directory (where you copied the upgrade files). Enter: PATCHNGM The patch program upgrades all appropriate files. The patch program also retains a log of the results in a file called 'RESULTS.TXT'. To verify your upgrade installation, view the contents of 'RESULTS.TXT' after the upgrade is complete. Step 7. During the patch process a BACKUP directory is created under the directory from which you ran 'PATCHNGM'. The BACKUP directory contains all files that were changed and a file called 'UNPATCH.BAK'. After the patch process has completed do NOT delete the BACKUP directory until you are satisfied that the upgrade procedure was successful. If you want to undo your upgrade and return your installation to its previous state, perform the following procedure. o To restore your system, change to the BACKUP directory, copy 'UNPATCH.BAK' to 'UNPATCH.BAT', and type "UNPATCH". This file will delete all new files in the appropriate directories and replace them with the files which originally existed. o Verify the original files have been correctly re-installed. o In order to re-run the patch process, or add additional patches, you MUST delete or rename the BACKUP directory first. Otherwise, the patch procedure will be unable to create an accurate BACKUP of the changes being made during the subsequent upgrade. ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ DISCLAIMER │ │ │ │ Novell, Inc. makes no representations or warranties with respect │ │ to this software patch, and specifically disclaims any express │ │ or implied warranties of merchantability, title, or fitness for │ │ a particular purpose. │ │ │ │ Novell's intentions for this software patch is to provide a temporary │ │ work-around to the anomalies described in this file. Such │ │ work-arounds are typically addressed in future releases of │ │ NetWare Global MHS. │ │ │ │ Distribution of this patch is forbidden without the express written │ │ consent of Novell, Inc. Novell reserves the right to discontinue │ │ distribution of this software patch. │ │ │ │ Novell will not be responsible for any data loss that may result from │ │ implementing this patch. Novell strongly recommends a backup be made │ │ before any patch is applied. Technical support for this patch is │ │ provided at the discretion of Novell. │ │ │ └────────────────────────────────────────────────────────────────────────┘