The following documentation is available for this release:
Readme: This Readme highlights installation and configuration information as well as issues specific to this release for Open Enterprise Server (OES) 2.
iFolder 3.6 Documentation: The Novell® iFolder® Documentation Web site contains the iFolder Readme and administration guides.
iManager 2.7 Readme: The iManager Readme contains information about enhancements and known issues for this management tool.
Novell Client for Linux, Novell Client 4.91™ for Windows* XP/2003 and the Novell Client for Windows Vista*: The Novell Client Documentation Web site contains the client Readmes and administration guides.
Product Documentation: Most documentation has been updated for this release.
For instructions on installing Open Enterprise Server for Linux, see the OES 2: Linux Installation Guide.
You should also review caveats about upgrading, migrating, and installing OES 2 in Caveats to Consider Before You Install
. For caveats for OES 2 services, see Caveats for Implementing OES 2 Services
.
In OES 2, new physical NetWare® installations are performed using the same install procedure as in previous versions of OES NetWare.
For OES 2 NetWare, in-place and remote upgrades are no longer supported. If you want to upgrade an existing NetWare 6.5 SP6 server to OES 2 NetWare, you must use the Support Pack update method.
For complete instructions on installing and upgrading to OES 2 NetWare, see the OES 2: NetWare Installation GuideOr, to apply just the Support Pack, see the Readme at the root of the Support Pack.
You should also review caveats about upgrading, migrating, and installing OES 2 in Caveats to Consider Before You Install
. For caveats for OES 2 services, see Caveats for Implementing OES 2 Services
.
To install OES Linux or NetWare as a virtual machine, see following documentation:
This section contains issues for OES 2 Linux.
NSS requires EVMS 2.5.5-24.54.5 or later. For EVMS patches .46, .49, and .52, data corruption can occur if NSS pools and volumes are active during an EVMS update. Patch .54.5 resolves this problem, and it can be installed without deactivating NSS pools and volumes. For information, see Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes. For clustered pools, see also Section 2.12.1, Installing EVMS Updates in a Cluster to Prevent Data Corruption of Clustered NSS Resources.
When you install NSS on a new OES 2 Linux server, make sure to install all EVMS updates (version .54-5 or later) that are available in the patch channel before you create new NSS pools or mount existing NSS pools.
When you upgrade a server from OES 1 Linux server to OES 2 Linux, and NSS is already installed, make sure that you have the latest versions of OES 2 Linux and SLES 10 SP1 downloaded from Novell.
Before you install NSS on an existing OES 2 Linux server, make sure to install all EVMS updates (.54-5 or later) that are available in the channel.
After you have installed version 54.5 or later, precautions must be taken if you need to revert to a version of EVMS prior to 54.5. Use only versions .52 or .41, and avoid using versions .46 and .49.
WARNING:For instructions on how to avoid data corruption when you revert to an earlier version, see Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes. For clustered pools, see also Section 2.12.1, Installing EVMS Updates in a Cluster to Prevent Data Corruption of Clustered NSS Resources.
Before you can upgrade an OES 1 server to OES 2, ensure that you have patched the OES 1 server to the latest patch level and that the server and OES services are still running as desired. You should also ensure that you meet the other upgrade requirements. For more information, see Updating an OES 2 Linux Server
in the OES 2: Linux Installation Guide.
IMPORTANT:Other Novell products, such as GroupWise®, and third-party applications you have installed on an OES 1 server, are deleted by default during an upgrade. To learn more and for instructions on manually retaining installed packages, see Planning for the Upgrade to OES 2
in the OES 2: Linux Installation Guide.
When installing OES 2 Linux using an AutoYaST file that has Novell Cluster Services™ configured, the installation fails with the following error:
Error configuring and starting SLP
This failure occurs only when installing remotely using VNC or SSH.
NOTE:This issue has been resolved with Archive Server Patch ID: 15269.
Archive and Versioning Services on OES 2 Linux fails to version files stored on remote NSS volumes of NetWare servers.
If renaming an NSS volume does not update the VLDB with the new volume name, you must manually rename the volume again to fix the problem.
You can check to see if the name has been updated correctly by using the following command from an OES 2 Linux server that is a replica site for that management context:
vldb list
An error occurs when you attempt to add an OES 2 Linux server as a replica site using the Distributed File Services plug-in to iManager 2.5, which was available in NetWare 6.5 SP6. You must use the Distributed File Services plug-in for iManager 2.7 in OES 2 in order to create and manage replica sites on OES 2 Linux servers.
Random failures might occur if you attempt to specify two VLDB replica sites when you create the DFS management context. The second replica site fails to be created, causing the DFS creation process to fail.
To avoid or resolve this problem, specify only a single VLDB replica site when you create the DFS management. After the management context has been created successfully, go to > , then click the link to add the second replica site for the management context.
Volumes in Domain containers are not automatically added to the VLDB when you run a VLDB repair from a Linux VLDB replica site. A volume is not added to the VLDB database if it contains a Domain object at any level in its fully distinguished name below the level of the container that is its Management Context. For example, a volume named cn=serverName_VOL,ou=ou1,dc=com is not added into the VLDB. This means that you cannot specify a volume in the Domain container as a junction target volume unless you add the volume to the VLDB.
Volumes in Domain containers can be added manually to a VLDB running on an OES 2 Linux server by using the vldb add command.
If you have a replica site on a NetWare server for the DFS management context, you can run a VLDB repair from the NetWare replica site to automatically add the volumes in Domain containers to the VLDB. Afterwards, the new volume entries are automatically synchronized to the VLDB running on the Linux server.
The vldb help command displays the command options for vldb in uppercase in order to allow characters to be easily distinguished from numbers. On Linux, the vldb command and options are case-sensitive and should be entered in lowercase. If you enter them in uppercase, the following error is returned:
VLDB: Command not found.
To avoid this problem, enter the vldb command and options in lowercase when working on a Linux server.
If you specify two replica sites when you create a DFS management context, it is not possible to specify non-default VLDB paths that are different for each of the replica sites. By default, each replica site uses the default VLDB path appropriate for its platform. If you specify a non-default VLDB path when two sites are selected, that path applies to both selected replica sites.
For example, you typically specify a non-default VLDB path when you are clustering the VLDB service for a replica site so that the VLDB is located on a clustered resource. If you cluster each replica site, the sites might need different non-default paths on their respective servers.
To specify different non-default paths for two replica sites, create the DFS management context with a single replica site, and specify its non-default VLDB path. After the management context is created successfully, use the > task in iManager to add the second replica and specify the non-default VLDB path to use for its VLDB.
When you perform a DFS split volume operation on an NSS volume on Linux, the junction created on the original volume might not be resolved by the Novell Client.
To resolve this problem, unmount and remount the NSS volume on which the junction is created. In some cases, a reboot of the server might be required.
DFS should not be used to move NSS volumes containing hard links. During a move or split using DFS, the hard links on the volume do not move correctly. DFS uses the Storage Management Services (SMS) underneath to back up data from the source location and restore it on the destination volume. SMS does not support backup and restore of hard links for OES 2.
In this release, it is not possible to load DNS Server by using command line options from iManager on Linux.
In this release, it is not possible to load the DHCP server using the command line options from DHCP iManager on Linux
The user should have root privileges to load or unload DHCP server from a remote system.
The NCP volume object created for a cluster enabled on a Reiser volume is not automatically cluster-capable.
Some cluster-enabled shadow volumes aren't appearing in ShadowFS. Adding a delay might help but has not been tested in a cluster load script.
Do not use DST with encrypted NSS volumes. Encrypted volumes hang when you mount them in a shadow relationship, even if you have previously mounted them successfully in NSSMU and provided the password (so that the password is held encrypted in memory until the next reboot). The hangs occur whether you attempt to dismount/remount from Novell Remote Manager where you set up the shadow volume, or from NSSMU.
If you have enabled DST for a pair of encrypted volumes, you must remove the shadow volume relationship in order to allow the volumes to be mounted as individual volumes. To remove a shadow volume, see Removing a DST Shadow Volume
in the OES 2: Novell Dynamic Storage Technology Administration Guide.
Because of changes to class structure and organization, iManager plug-ins must be recompiled to work with iManager 2.7. The iManager 2.7 Web site contains all currently available plug-ins, and is regularly updated with additional plug-ins as they become available. If you add an older plug-in using the link, it does not display an error even though the plug-in is not added. You can view specific error information in the debug log.
Similarly, the OES 2 download includes the currently available iManager 2.7 plug-ins.
The following older plug-ins have not been recompiled and do not work with iManager 2.7:
Novell Audit plug-in
Novell BorderManager® plug-in
WARNING:Do not install older plug-ins from a local drive into iManager 2.7. Although the plug-in might install, it does not run and can be very difficult to remove.
After a system crash or power failure, eDirectory services (ndsd) may not automatically start in some situations.
To start the eDirectory again, delete /var/opt/novell/eDirectory/data/ndsd.pid file, and then enter /etc/init.d/ndsd start at a terminal prompt.
If the NOOP settings in the Linux iSCSI initiator are set, the Netware iSCSI target reports back a SCSI CHECK CONDITION error when it receives the NOOP request during an active iSCSI read or write request sequence. In response, the Linux initiator calls the BUG_ON condition, resulting in a hang. To avoid or resolve this problem, turn off the NOOP settings in the /etc/iscsid.conf file by setting the values to 0. For example:
noop_out_timeout = 0
noop_interval = 0
Afterwards, do a rediscovery in order for the parameters to take effect.
In iManager, you cannot use the Group Access to LUM-Enabled Services control ( > > > > ) to modify the services even though the screen interaction might indicate so. To resolve this, use the namgroupmod command.
In iManager, if you use > to associate a group with a workstation object, the group object does not get associated with the workstation. Instead of using Enable Groups, add and associate the group and workstation by using > > . You could also add the group by modifying the workstation object using > .
If you enable server self-provisioning in an OES 2 eDirectory tree, the PKI Health Check might replace the default certificates every time the PKI Health Check runs. To avoid this, do one of the following:
Finish configuring the CA's CRL capability by creating one or more CRL Distribution Points using iManager's Configure Certificate Authority task.
Delete any CRL Configuration objects (For example,. CN=One - Configuration.CN=CRL Container.CN=Security).
When you use either the Repair Default Certificates or Create Default Certificates task, the task might force the replacement of the default certificates (even if you did not specify a forced replacement). To avoid this you, do one of the following:
Finish configuring the CA's CRL capability by creating one or more CRL Distribution Points using iManager's Configure Certificate Authority task
Delete any CRL Configuration objects (ex. CN=One - Configuration.CN=CRL Container.CN=Security)
NSS requires EVMS 2.5.5-24.54.5 or later. For information, see Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes.
In a Novell Cluster Services environment, you must perform a Cluster leave and Shared pool migrate before you install the EVMS patch on a given node.
WARNING:Data corruption can occur if a cluster resource that contains NSS volumes migrates from a node that has been updated to EVMS 2.5.5-24.54.5 (or later version) to a node that is running a version earlier than EVMS 2.5.5-24.54.5.
It is essential that you upgrade the cluster in a way that avoids the migration of a cluster resource that contains NSS volumes from an updated node to one that has not yet been updated. This can be accomplished in a number of ways. For example, if you have a cluster with four nodes, you can update two nodes (cluster leave, shared pool migrate, install EVMS), then rejoin the cluster and update the remaining nodes (cluster leave, shared pool migrate to updated nodes, install EVMS, and rejoin the cluster).
After you have installed version 54.5 or later, precautions must be taken if you need to revert to a version of EVMS prior to 54.5. Use only versions .52 or .41, and avoid using versions .46 and .49.
WARNING:To avoid data corruption when you revert to an earlier version, make sure to follow a process similar to the one outlined in this section, so that you do not fail over from a 54.5 or later version to a node running an earlier version.
In a mixed cluster of NetWare and OES 1 or 2 Linux nodes, Linux traditional file systems as cluster resources cannot be created using EVMSGUI until the entire cluster is migrated to Linux. Linux traditional file systems as cluster resources cannot be migrated or failed over to NetWare cluster nodes. Only NSS pool cluster resources that are created on a NetWare cluster node can be failed over between Linux and NetWare nodes of a mixed node cluster.
NetWare to Linux failover requires that the Linux node be configured for NSS and that the version of NSS supports the NSS media format and features being used by the NSS pool cluster resource.
If you attempt to delete a cluster resource or clustered pool without first offlining the cluster resource, deletion errors occur, and the data associated with the clustered pool is not recoverable.
To avoid this problem, offline the cluster resource before attempting to delete either the cluster resource or the clustered pool.
NSS requires EVMS 2.5.5-24.54.5 or later. The EVMS patch 54.5 is mandatory for OES 2 Linux servers in order to prevent potential data corruption for NSS pools/volumes. There are no corruption issues with the original shipped EVMS version (.41) for OES 2. The EVMS versions .46, .49, and .52 releases can corrupt pools on the first EVMS open after a pool creation on a device with no previous NetWare partition if NSS pools and volumes are active when the patch is installed. Installing or updating EVMS with the .54.5 or later version addresses the corruption problem, and patch versions .54.5 or later can be installed without deactivating volumes during the patch install.
For information about upgrading EVMS in a Novell Cluster Services environment, see Section 2.12.1, Installing EVMS Updates in a Cluster to Prevent Data Corruption of Clustered NSS Resources.
After you have installed version 54.5 or later, precautions must be taken if you need to revert to a version of EVMS prior to 54.5. Use only versions .52 or .41, and avoid using versions .46 and .49.
Reverting to the .41 and .52 versions can corrupt a pool only if you do not follow the deactivate and reboot instructions outlined in this section. In order to revert to versions .41 or .52 where NSS is installed, a brief file service outage is required to properly align the segment managers for NSS pool partitions.
WARNING:If NSS pools/volumes are mounted during the update process, a segment manager conflict causes data corruption for those mounted pools/volumes.
In order to prevent data corruption during the EVMS reversion process, all NSS pools must be deactivated prior to applying the EVMS version, and must not be reactivated until the install is complete and you have rebooted the server.
In a Novell Cluster Services environment, you must perform a Cluster leave and Shared pool migrate before you install the EVMS patch on a given node. The NSS pools must not be reactivated or migrated back to this node until the install is complete and you have rebooted the node. Update only a single node in the cluster at a time.
For NSS on Linux, snapshot volumes are not automatically mounted on reboot as they were in NetWare. The snapshots are active and performing their snapshot functions, but they are not mounted. If a snapshot was mounted when the server went down and you want the snapshot mounted after reboot, you must mount it manually. Mounting snapshots is necessary only if users require access to the point-in-time version of the data.
In this release, be aware of the following:
Renaming NSS snapshot volumes/pools is not supported.
Mount all the previous snapshots before creating another snapshot for the same origin pool.
In NSSMU, if snapshots are stored in a device, the device fails to reinitialize. To reinitialize the device, delete the snapshots.
If you attempt to delete a cluster resource or clustered pool without first offlining the cluster resource, deletion errors occur, and the data associated with the clustered pool is not recoverable.
To avoid this problem, offline the cluster resource before attempting to delete either the cluster resource or the clustered pool.
If you use NSSMU or iManager to create an NSS pool or volume on Linux, the create time might take longer than expected. Typically, the pool creation takes less than a minute, and the volume creation takes less than 10 seconds. However, if you have a large tree or the server does not hold an eDirectory replica, the create time can take up to 3 minutes.
When mounting a Samba share on an OES 2 Linux server, use
mount -t cifs
Do not use the smbmount command or mount -t smbfs. The smbfs code is no longer being maintained and has been replaced by cifs.
When using OpenOffice 2.0 on a SLED 10 workstation to access files on an NSS volume through a Samba connection, Read/Write access is granted to the SLED workstation even if the file is open on another SLED or Windows workstation. This allows multiple users to have an OpenOffice document open at the same time, each having Write privileges, which could possibly corrupt the file if more than one user makes changes.
This issue has been corrected in OpenOffice 2.1, which ships with SLED 10 SP1. OES 2 customers should update all SLED workstations to SLED 10 SP1 if they plan to access OpenOffice documents on NSS volumes through Samba.
Batch_oplock (opportunistic file locking in batch mode) requests are not handled correctly on an OES 2 Linux server. Programs that request a Batch_Oplock on a Samba share receive no oplock. Requests for Exclusive and Level 2 oplocks are handled correctly.
If you are upgrading to OES 2 and installing Samba on Linux, the default Samba group fails to be created if the uamPosixPAMServiceExcludeList eDirectory attribute is not associated with the uamPosixUser and uamPosixGroup eDirectory classes. The OES2 install sets these on new installs but fails to get this setup on an upgrade. Another symptom is that the Samba iManager plug-in gives an error looking for the default Samba group that was not created.
To resolve this, the uamPosixPAMServiceExcludeList attribute should already exist. Use iManager to associate the attribute with the uamPosixUser and uamPosixGroup. Then do a post-configuration of Samba that creates the default Samba group.
If you see "username: Could not Samba enable the user for group SERVERNAME-W-SambaUserGroup" errors when using the Sambamanagement plug-in for iManager to add users, check the following:- Make sure iManager is installed on a server running a currently supported operating system (OES 1 Linux, OES 2 Linux, or NetWare 6.5 - not NetWare 6.0,NetWare 5.0, or NetWare 4.x).- Add a local replica of the partition containing the Samba user objects to the server that is running the Novell Samba software.- If you have servers running unsupported versions of NetWare in your tree, make sure those servers do not hold a replica of the partition containing theSamba user objects.
Make sure iManager is installed on a server running a currently supported operating system (OES 1 Linux, OES 2 Linux, or NetWare 6.5 - not NetWare 6.0, NetWare 5.0, or NetWare 4.x).
Add a local replica of the partition containing the Samba user objects to the server that is running the Novell Samba software.
If you have servers running unsupported versions of NetWare in your tree, make sure those servers do not hold a replica of the partition containing the Samba user objects.
In the OES Linux Samba install, if you enter a user name and password for a Samba Proxy user that already exists in eDirectory, it creates the user sets the password but fails to set eDirectory rights in NDS®.
To resolve this, try one of the following solutions:
Use the default, which is admin.
If you are installing into an existing tree, create and set the password for the proxy user before installing OES 2. Then use Samba Proxy.
Set the ACLs on the samba proxy user as follows:
ACL: 6#subtree#proxyuser#[All Attributes Rights]
ACL: 3#subtree#proxyuser#[Entry Rights]
ACL: 7#subtree#proxyuser# (All of the following:)
sambaSID
sambaPrimaryGroupSID
sambaAcctFlags
sambaAlgorithmicRidBase
sambaDomainName
sambaLogoffTime
sambaNextUserRid
sambaLogonHours
sambaNextGroupRid
sambaNextRid
sambaBadPasswordCount
sambaBadPasswordTime
sambaLMPassword
sambaHomePath
sambaLogonScript
sambaKickoffTime
sambaHomeDrive
sambaLogonTime
sambaMungedDial
sambaNTPassword
sambaProfilePath
sambaPasswordHistory
sambaPwdCanChange
sambaPwdLastSet
sambaPwdMustChange
sambaUserWorkstations
SBCON does not support failover or failback for OES Linux Cluster resources.
On OES Linux, hard link files are backed up and restored as a normal file type, instead of the hard link file type
On restoring NCP on POSIX file systems, the user must always be LUM-enabled.
On restoring NCP on POSIX file systems, the NSS owner ID is not restored.
In iManager Workstation, the graphical displays of pool and volume usage cannot be rendered and might result in freezing iManager Workstation. This occurs on the tabs for the Pool Properties and Volume Properties pages in the Storage plug-in for iManager. The problem occurs because iManager Workstation uses a newer Java* version that is not compatible with the Java version used to build the graphics applet.
To resolve this, use iManager Server to display the pool and volume usage statistics, not iManager Workstation.
Restoring a single object from a full or subtree backup is not supported in this release.
If you encrypt an attribute of the object, nbackup fails with the following error:
nbackup: Requires password for encryption
nbackup: Failed to read dataset .CN=user-ea.O=novell.T=TREE. for backup
If eDirectory is running on a non-default NCP port (that is, other than 524) tsands does not connect to it.
NOTE:Tsands must be loaded manually by using following command: /opt/novell/sms/bin/smsconfig -l tsands
For further use of tsands, refer to the tsands man page.
This section contains issues for OES 2 NetWare.
The default size of the SYS: volume on NetWare 6.5 servers is 4 GB. However, in NetWare 6.5 SP7, this default size is not large enough to accommodate server installations that include iManager, Apache, and Tomcat. To avoid running out of disk space on the SYS: volume, installers should perform a custom installation and set the size of the SYS: volume to at least 8 GB.
You should not load GroupWise® Agents in protected memory when running GroupWise on virtualized NetWare. GroupWise Agents can still be loaded in protected memory when running NetWare on a physical server.
When backing up a virtual machine running virtualized NetWare, we recommend using a remote backup source rather than a local tape device because of limitations in detecting a local tape device. This limitation might be fixed in a future release.
Currently, the BorderManager 3.8 and 3.9 iManager plug-ins only work with iManager 2.6. When you apply NetWare 6.5 Support Pack 7, iManager is upgraded to 2.7 and the BorderManager plug-ins stop working.
You should apply SP7 to a server running BorderManager only if there is another server in the tree still running iManager 2.7.
If renaming an NSS volume does not update the VLDB with the new volume name, you must manually rename the volume to fix the problem.
You can check to see if the name has been updated correctly by using the command from an OES 2 Linux server that is a replica site for that management context:
An error occurs when you attempt to add an OES 2 Linux server as a replica site by using the Distributed File Services plug-in to iManager 2.5, which was available in NetWare 6.5 SP6. You must use the Distributed File Services plug-in for iManager 2.7 in OES 2 in order to create and manage sites on OES 2 Linux servers.
When VLDB services are clustered on NetWare, the replica site information on the Manage Replica Sites page might list an erroneous name for the replica site instead of the node where VLDB is currently loaded and running. In this case, iManager cannot be used to initiate a VLDB repair.
To repair the VLDB running on a NetWare cluster, issue the vldb repair command at the server console of the cluster node where the VLDB is currently running.
Problems occur when you attempt to start the VLDB service from a Not Loaded state for DFS replica sites running on virtualized NetWare guest servers. If you deselect the option "Run VLDB service on server restarts" for the DFS management context, the VLDB service for the replica site is in a Not Loaded state immediately following a server reboot. If the DFS replica site is a virtualized NetWare guest server, when you start the VLDB service manually by using the Distributed File Services > Manage Replica Sites > Actions > Start option in Novell iManager 2.7, DFS returns an error: "Service is not running."
However, DFS actually loads and activates the service properly. This error message is displayed the first time you attempt to start the VLDB service following a server reboot. Normally, if you stop and start the VLDB, there are no error messages.
Problems occur when configuring two DFS replica sites on virtualized NetWare guest servers, whether they are on the same host or on different hosts.
If you specify two virtual NetWare servers as replica sites when you define the DFS management context, an error occurs that prevents the second replica site from being set up. To avoid or resolve this problem, set up one replica site when you define the DFS management context, then use the Distributed File Services > Manage Replica Sites page in iManager to set up a second replica site on the second virtual NetWare server.
If an existing replica site is configured on a virtual NetWare server, when you set up a second replica site on a another virtual NetWare server, an error occurs when you start the VLDB services on the second site. The process is successful despite the message.
If you specify two replica sites when you create a DFS management context, it is not possible to specify non-default VLDB paths that are different for each of the replica sites. By default, each replica site uses the default VLDB path appropriate for its platform. If you specify a non-default VLDB path when two sites are selected, that path applies to both selected replica sites.
For example, you typically specify a non-default VLDB path when you are clustering the VLDB service for a replica site so that the VLDB is located on a clustered resource. If you cluster each replica site, the sites might need different non-default paths on their respective servers.
To specify different non-default paths for two replica sites, create the DFS management context with a single replica site, and specify its non-default VLDB path. After the management context is created successfully, use the Distributed File Services > Manage Replica Sites task in iManager to add the second replica and specify the non-default VLDB path to use for its VLDB.
When creating a DFS junction on an NSS volume on NetWare that points to a subdirectory on the target volume, if you click Next to set trustees, when the new junction is created, it points to the root of the target volume instead of to the specified subdirectory.
To avoid this problem, select the subdirectory, then click Finish on the Create Junction page instead of clicking Next to set trustees. After the junction is created properly, you can use the Modify Junction task to set trustees for the existing junction.
Before installing the Support Pack, you should back up your eGuide template files located in sys:tomcat\4\webapps\eguide\web-inf\templates\xsl and sys:tomcat\4\webapps\eguide\look because the Support Pack replaces these files and your customizations are lost.
If you chose the Backup option during the Support Pack install, you can retrieve the backed-up files to preserve your customizations.
Because of changes to class structure and organization, iManager plug-ins must be recompiled to work with iManager 2.7. The iManager 2.7 Web site contains all currently available plug-ins, and is regularly updated with additional plug-ins as they become available. If you add an older plug-in by using the link, it does not display an error even though the plug-in is not added. You can view specific error information in the debug log.
Similarly, the OES 2 download includes the currently available iManager 2.7 plug-ins.
The following older plug-ins have not been recompiled and do not work with iManager 2.7:
Novell Audit plug-in
Novell BorderManager plug-in
WARNING:Do not install older plug-ins from a local drive into iManager 2.7. Although the plug-in might install, it does not run and can be very difficult to remove.
NFS on NetWare doesn't support Japanese filenames.
Rcd.nlm is not loaded by default. If you have a script that is loading this file, and you run a Nessus scan on your server, it might abend. To resolve this, do not load rcd.nlm. Rcd on NetWare is not used by any Novell processes.
Name fields should not contain any special characters that could be misinterpreted as separators in paths or URL strings. The characters '/', '\', and ':', are among those that must not be used.
If you attempt to delete a cluster resource or clustered pool without first offlining the cluster resource, deletion errors occur, and the data associated with the clustered pool is not recoverable.
To avoid this problem, offline the cluster resource before attempting to delete either the cluster resource or the clustered pool.
In a mixed cluster of NetWare and OES 1 or 2 Linux nodes, Linux traditional file systems as cluster resources cannot be created using EVMSGUI until the entire cluster is migrated to Linux. Linux traditional file systems as cluster resources cannot be migrated or failed over to NetWare cluster nodes. Only NSS pool cluster resources that are created on a NetWare cluster node can be failed over between Linux and NetWare nodes of a mixed node cluster.
NetWare to Linux failover requires that the Linux node be configured for NSS and that the version of NSS supports the NSS media format and features being used by the NSS pool cluster resource.
This section contains issues for migrating to OES 2.
In tree-to-tree migrations when you are migrating trustees into a new context, user quotas are not restored.
User information is not generated for DFS shares on Windows source servers.
Ownership for files and folders changes after the migration.
The File System Migration tool supports stopping and continuing of migration (migfiles with the -c option) only if the source server is running NetWare 6.5 or OES 1.0 Linux.
The migration summary screen displays only the beginning of the log. To view the full log during and after the migration, the user must scroll down the migration summary screen.
The eDirectory migration utility does not support migration of eDirectory with a Filtered or Read-Only replica in the source NetWare server.
However, it performs migration with NetWare server 6.5 SP7. If you attempt to perform eDirectory migration from any older versions of NetWare, the utility hangs indefinitely.
ACL is migrated in the same tree scenario, not in the different tree scenario.
The content of the Location and Description field for the print manager is not being migrated.
The content of the Location and Description field for the Broker in the source is not migrated to the target.
Do not include white spaces in the name of Print Objects such as Print Managers, Printers, and Driver Store.
iPrint Migration GUI is a mono GUI and cannot be invoked using yast2 novell-migprint-gui command. To invoke the GUI using YaST, click .
iprintmig will not translate the gateway Autoload command correctly when using HP or Axis gateway. The command will display the IP address of the printer as x.x.x.x.
Using iManager, click and select , the feature will not get migrated to the target.
Using iManager, click and select the feature will not get migrated to the target.
This section summarizes the changes made to this readme since the initial release of Novell® Open Enterprise Server 2.
|
Chapter or Section Changed |
Summary of Changes |
|---|---|
|
Added information on how to revert to a version prior to .54.5 of EVMS. |
|
|
Added information on how to revert to a version prior to .54.5 of EVMS. |
|
|
Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes. |
Added information on how to revert to a version prior to .54.5 of EVMS. |
|
Chapter or Section Changed |
Summary of Changes |
|---|---|
|
Removed link to fixes list. The list was inaccurate and can no longer be maintained. |
|
Chapter or Section Changed |
Summary of Changes |
|---|---|
|
EVMS 2.5.5-24.54.5 is required for NSS in order to prevent data corruption. |
|
|
EVMS 2.5.5-24.54.5 is required for NSS in order to prevent data corruption. It is essential that you upgrade the cluster in a way that avoids the migration of a cluster resource that contains NSS volumes from an updated node to one that has not yet been updated. |
|
|
Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes. |
EVMS 2.5.5-24.54.5 is required for NSS in order to prevent data corruption. |
Corrected typographical errors.
|
Chapter or Section Changed |
Summary of Changes |
|---|---|
|
Section 2.13.1, EVMS Updates Are Mandatory to Prevent Data Corruption for NSS Pools and Volumes. |
EVMS patches are mandatory for NSS in order to prevent data corruption. WARNING:Data corruption can occur if you apply an EVMS update while NSS pools/volumes are mounted. See the issue for a workaround to avoid data corruption. |
|
Chapter or Section Changed |
Summary of Changes |
|---|---|
|
Section 2.2, Archive and Versioning Services with Remote NSS Volumes. |
Indicated that issue has been resolved through a server patch. |
|
Corrected typo in Important note to indicate that earlier plug-ins will not run in iManager 2.7. |
Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2002-2008 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page and one or more additional patents or pending patent applications in the U.S. and in other countries.
For a list of Novell trademarks, see the Novell Trademark and Service Mark List at http://www.novell.com/company/legal/trademarks/tmlist.html.