IMPORTANT:As support packs are released, there are sometimes new caveats identified. Be sure to always check the OES Readme for items specific to each support pack.
This section discusses the following installation/migration caveats:
Section 4.9.1, Adding a Linux Node to a Cluster Ends Adding More NetWare Nodes
Section 4.9.2, Always Double-Check Service Configurations Before Installing
Section 4.9.3, Back Button Doesn’t Reset Configuration Settings
Section 4.9.4, Cluster Upgrades Must Be Planned Before Installing OES 2
Section 4.9.8, Follow the Instructions for Your Chosen Platforms
Section 4.9.9, If You’ve Ever Had OES 1 Linux Servers with LUM and NSS Installed
Section 4.9.11, Incompatible TLS Configurations Give No Warning
Section 4.9.14, Novell Distributed Print Services Cannot Migrate to Linux
Section 4.9.19, VNC Install Fails to Set the IP Address in /etc/hosts
After you add a Linux node to a cluster, you cannot add more NetWare nodes. For more information, see the OES 2 SP3: Novell Cluster Services NetWare to Linux Conversion Guide.
It is critical and you double-check your service configurations on the Novell Open Enterprise Server Configuration summary page before proceeding with an installation. One reason for this is explained in Section 4.9.3, Back Button Doesn’t Reset Configuration Settings.
During an installation, after you configure eDirectory and reach the Novell Open Enterprise Server Configuration summary screen, service configuration settings have been “seeded” from the eDirectory configuration.
If you discover at that point that something in the eDirectory configuration needs to change, you can change the settings by clicking the link on the summary page or by clicking the Back button.
In both cases when you return to the summary page, the eDirectory configuration has changed, but the individual service configurations have the same eDirectory settings you originally entered. These must each be changed manually.
For example, if you specified the wrong server context while initially configuring eDirectory, the NSS and LUM configurations still have the wrong context. You must select each service individually and change the server context in them.
Unless you manually change the services affected by changes to eDirectory, your services will at best not work as expected and at worst completely fail.
Because of differences between Novell Cluster Services on NetWare 6.5 SP8 and OES 2, there are important issues to consider before combining them into a mixed node cluster, as explained in the following sections.
The only cluster-enabled service that can fail over cross-platform (run on either OES 2 or NetWare 6.5 SP8) is cluster-enabled NSS pools. All other services (iPrint, iFolder, etc.) can only fail over between servers that are the same platform. For example, an iPrint service that is running on an OES 2 server can fail over to another OES 2 server in the cluster, but the service cannot fail over to an NetWare 6.5 SP8 server.
The following points apply to working with mixed NetWare and OES clusters:
You cannot uses EVMSGUI to create a Linux POSIX file system as a cluster resource until the entire cluster is migrated to Linux.
You cannot migrate or fail over a Linux POSIX file system cluster resource to a NetWare cluster node.
Only NSS pool cluster resources that are created on a NetWare cluster node can be failed over between Linux and NetWare nodes.
NetWare NSS to Linux NSS 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.
The new NSS media format in OES 2 is not available for OES 1 SP2 Linux and earlier. After a volume has been upgraded to the new media format, you cannot fail it over to a node that is running OES 1 SP2 Linux or earlier.
If you plan to use Novell CIFS, Novell AFP and/or NCP file services in combination with each other, be sure to read Section 1.5.5, Cross-Protocol File Locking Change.
During the OES 2 install you are prompted by the SLES portion of the install to create at least one user besides root and you are warned if you bypass the prompt.
Creating local users is not recommended on OES 2 servers because user management in OES 2 is managed entirely in eDirectory. The only local user you need on the server is the root user. Creating other local users can, in fact, cause unnecessary confusion and result in service-access problems that are difficult to troubleshoot.
eDirectory users are enabled for POSIX access through the Linux User Management (LUM) technology installed by default on every OES 2 server.
Also be aware that not all OES services require that users are LUM-enabled. Novell Client users, for example, can access NCP and NSS volumes on OES 2 servers just as they do on NetWare without any additional configuration.
For more information about this topic, see Section 16.2, Linux User Management: Access to Linux for eDirectory Users.
If you are running OES 1 SP2, do not upgrade to eDirectory 8.8 independently of upgrading to OES 2 SP3.
For example, do not upgrade from eDirectory 8.7.3 to eDirectory 8.8.2 through the oes-edir88 patch channel prior to upgrading to OES 2 SP3. Doing so causes configuration problems that the OES 2 SP3 install is not designed to handle.
Although installing OES 2 services on Linux or NetWare is a straightforward process, the installation processes are platform-specific, requiring different sets of media and different installation programs.
Having NSS volumes on OES servers requires certain system-level modifications, most of which are automatic. For more information, see Section I.0, System User and Group Management in OES 2 SP3.
However, as OES has evolved, some initially defined conventions regarding system Users have needed adjustment. Be sure to read the information and follow the instructions in this section if your network has ever included an OES 1 Linux server with both LUM and NSS installed.
By default, certain OES services, such as NetStorage, rely on a background Novell service named XTier.
To run on an OES server, XTier requires two system-created users (named novlxsrvd and novlxregd) and one system-created group that the users belong to (named novlxtier).
The two system users and their group are created on the local system when XTier is installed. For example, they are created when you install NetStorage, and their respective UIDs and GID are used to establish ownership of the service’s directories and files.
For NetStorage to run, these XTier users and group must be able to read data on all volume types that exist on the OES server.
As long as the server only has Linux traditional file systems, such as Ext3, Reiser, or XFS, NetStorage runs without difficulties.
However, if the server has NSS volumes, an additional requirement is introduced. NSS data can only be accessed by eDirectory users. Consequently, the local XTier users can’t access NSS data, and NetStorage can’t run properly.
Therefore, when NSS volumes are created on the server, the XTier users are moved to eDirectory and enabled for Linux User Management (LUM). See Section 16.2, Linux User Management: Access to Linux for eDirectory Users.
After the move to eDirectory, they can function as both eDirectory and POSIX users, and they no longer exist on the local system.
Problems with OES 1 occurred when additional OES NetStorage servers with NSS volumes were installed in the same eDirectory container. Because the UIDs and GID were assigned by the Linux system, unless the installation process was exactly the same for each OES 1 Linux server, the UIDs and GID didn’t match server-to-server.
When the local XTier UIDs and GID on subsequently installed servers didn’t match the XTier UIDs and GID in eDirectory, NetStorage couldn’t access the NSS volumes on the server.
To solve this problem, the OES 1 installation program looked for XTier ID conflicts, and if the IDs on a newly installed server didn’t match the IDs in eDirectory, the program generated a script file named nssid.sh. The documentation instructed installers to always check for an nssid.sh file on a newly installed server, and if the file was found, to run it. The nssid.sh script synchronized all of the XTier IDs with those that had already been stored in eDirectory.
This solution remained viable through the first release of OES 2.
Unfortunately, system-level changes in SUSE Linux Enterprise Server 10 SP2 invalidated the nssid.sh script solution for OES 2 SP1. Synchronizing the XTier IDs with an OES 1 installation can now cause instability in other non-OES components. Therefore, starting with OES 2 SP1, you should standardize all XTier IDs on existing servers before installing a new OES 2 server with XTier-dependent services.
If your eDirectory tree has ever contained an OES 1 Linux server with NSS and LUM installed, do the following on each server (including OES 2) that has NSS and LUM installed:
Log in as root and open a terminal prompt. Then enter the following commands:
id novlxregd
id novlxsrvd
The standardized XTier IDs are UID 81 for novlxregd, UID 82 for novlxsrvd, and GID 81 for novlxtier.
(Conditional) If you see the following ID information, the XTier IDs are standardized and you can start over with Step 1 for the next server:
uid=81(novlxregd) gid=81(novlxtier) groups=81(novlxtier) uid=82(novlxsrvd) gid=81(novlxtier) groups=81(novlxtier),8(www)
(Conditional) If you see different IDs than those listed above, such as 101, 102, 103, etc., record the numbers for both XTier users and the novlxtier group, then continue with Step 4.
You need these numbers to standardize the IDs on the server.
Download the following script file:
Customize the template file by replacing the variables marked with angle brackets (<>) as follows:
<server_name>: The name of the server object in eDirectory.
This variable is listed on line 38 in the file. Replace it with the server name.
For example, if the server name is myserver, replace <server_name> with myserver so that the line in the settings section of the script reads
server=myserver
<context>: This is the context of the XTier user and group objects.
Replace this variable with the fully distinguished name of the context where the objects reside.
For example, if the objects are an Organizational Unit object named servers, replace ou=servers,o=company with the fully distinguished name.
<admin fdn>: The full context of an eDirectory admin user, such as the Tree Admin, who has rights to modify the XTier user and group objects.
Replace this variable with the admin name and context, specified with comma-delimited syntax.
For example, if the tree admin is in an Organization container named company, the full context is cn=admin,o=company and the line in the settings section of the script reads
admin_fdn=”cn=admin,o=company”
<novlxregd_uid>: This is the UID that the system assigned to the local novlxregd user. It might or might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the UID reported for the novlxregd user on this server as listed in Step 1.
For example, if the UID for the novlxregd user is 101, change the line to read
novlxregd_uid=101
<novlxsrvd_uid>: This is the UID that the system assigned to the local novlxsrvd user. It might or might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the UID reported for the novlxsrvd user on this server as listed when you ran the commands in Step 1.
For example, if the UID for novlxsrvd_uid is 102, change the line to read
novlxsrvd_uid=102
<novlxtier_gid>: This is the GID that the system assigned to the local novlxtier group. It might or might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the GID reported for the novlxtier group on this server as listed when you ran the commands in Step 1.
For example, if the GID for novlxtier_gid is 101, change the line to read
novlxtier_gid=101
Make the script executable and then run it on the server.
IMPORTANT:Changes to the XTier files are not reported on the terminal.
Error messages are reported, but you can safely ignore them. The script the entire file system, and some files are locked because the system is running.
Repeat from Step 1 for each of the other servers in the same context.
For best results, be sure you read and carefully follow the instructions in the Novell iFolder 3.8.4 Administration Guide, and especially Deploying iFolder Server .
This is especially critical if you plan to use NSS for your iFolder 3.8 data volume.
When you install a new eDirectory tree, the eDirectory Configuration - New or Existing Tree screen has the option selected by default. If you keep this configuration setting, the eDirectory LDAP server requires that all communications come through the secure LDAP port that you specified on the eDirectory Configuration - Local Server Configuration screen. By default, this is port 636.
Unfortunately, the OES install doesn’t display a warning if you subsequently configure OES services to use non-TLS (non-secure) LDAP communications (port 389). The installation proceeds normally but the service configuration fails.
For example, if you accept the TLS default, then configure Novell DHCP to use non-secure communications (by deselecting the option), the OES install doesn't warn that you have created an incompatible configuration.
After eDirectory and the iManager plug-ins install successfully, the Novell DHCP configuration fails. You must then use iManager to change either the LDAP server configuration or the Novell DHCP configuration to support your preferred communication protocol.
Simply enabling non-TLS LDAP communications doesn’t disable TLS. It merely adds support for non-secure communications with the LDAP server.
Novell Support has reported a significant number of installation incidents related to eDirectory health and time synchronization. To avoid such problems, do the following prior to installing OES:
If you are installing a new OES 2 server into an existing eDirectory tree, be sure to read and follow the instructions in Preparing eDirectory for OES 2 SP3
in the OES 2 SP3: Installation Guide.
Although you can add OES to an existing SLES 10 server if needed, you cannot install OES on a SLES 10 server that is already running eDirectory.
eDirectory must be installed in conjunction with the installation of OES services.
Review and follow the guidelines in Keeping eDirectory Healthy
in the Novell eDirectory 8.8 SP7 Administration Guide.
OES2 Linux and NetWare 6.5 SP8 servers can receive network time from either an existing eDirectory server or from an NTP time source. The critical point is that the entire tree must be synchronized to the same time source. For example, do not set your new OES 2 server to receive time from an NTP source unless the whole tree is synchronized to the same NTP source.
For an in-depth explanation of OES time synchronization, see Section 13.3, Time Services.
Novell SLP (NetWare) and OpenSLP (Linux) can coexist, but there are differences between the services that you should understand before deciding which to use or before changing your existing SLP service configuration. For more information, see Section 13.5, SLP.
OES doesn’t use Novell Licensing Services (Section 5.5, Licensing). As a result, OES servers don’t need a license container in eDirectory as part of the server installation.
In a mixed OES 2 and NetWare eDirectory tree, at least one NetWare server must hold a replica for each partition where there is a NetWare server object. Without this configuration, It is impossible to install licenses or to service requests from NetWare servers to consume those licenses.
If you need to install a NetWare server in an OES tree, you must do the following after installing the first NetWare server in a partition:
Install iManager on the NetWare server, or use iManager Workstation.
You can do this during initial installation or later as described in Installing iManager
in the Novell iManager 2.7.6 Installation Guide.
Add a Read/Write replica to the server as described in Adding a Replica
in the Novell eDirectory 8.8 SP7 Administration Guide.
Install the NetWare license as described in Installing and Removing License Certificates
in the NW 6.5 SP8: Licensing Services Administration Guide.
The iManager Licensing plug-in is not installed on OES servers. If you have configured Role-Based Services, you need to make sure the licensing plug-in is installed and added to the RBS collection. For more information, see Upgrading iManager
in the Novell iManager 2.7.6 Installation Guide.
If you are installing OES 2 servers into a tree containing NetWare 6.5 servers, be sure that the following server types have been updated to SP3 or later prior to installing OES 2:
SLP Directory Agents: If the SLP Directory Agents on your network are not running NetWare 6.5 SP3 or later, installing an OES 2 server into the tree can cause the DA servers to abend.
LDAP Servers: If the LDAP servers referenced in your installation are not running NetWare 6.5 SP3 or later, the servers might abend during a schema extension operation.
NDPS clients are not supported on OES. You must therefore migrate any NDPS clients to iPrint before you migrate your print services to OES. For more information, see Migrating NDPS Printers to iPrint
in the NW 6.5 SP8: iPrint Administration Guide.
The new media support for hard links on OES 2 NSS volumes was not available for OES 1 SP2 Linux and earlier, but it was available for NetWare 6.5 SP4 and later.
If you've already upgraded the media format of the volume, you cannot fail over to a node that is running OES 1 SP2 until you have upgraded the node to OES 2.
CD and DVD media and image files cannot be mounted as NSS volumes on OES; instead, they are mounted as Linux POSIX file systems.
For more details about NSS compatibility, see Cross-Platform Issues for NSS Volumes
in the OES 2 SP3: NSS File System Administration Guide for Linux.
Although the default eDirectory settings work for simple trees, they are not usually practical for a production implementation. For example, by default the tree Admin user and the server are installed in the same context.
Some administrators, when they discover that the tree structure doesn't meet their needs, assume they can rectify the situation by uninstalling and then reinstalling eDirectory. This simply cannot be done.
In fact, OES services cannot be uninstalled. For more information, see Disabling OES 2 Services
in the OES 2 SP3: Installation Guide.
Enabling users for Samba automatically disables SSH access for them. However, this default configuration can be changed. For more information, see Section 12.4, SSH Services on OES 2.
Do not install any of the following service combinations on the same server. Although not all of the combinations shown in Table 4-2 cause pattern conflict warnings, Novell does not support any of them.
Table 4-2 Unsupported Service Combinations
|
Service |
Unsupported on the Same Server |
|---|---|
|
Novell AFP |
|
|
Novell Archive and Version Services |
|
|
Novell Backup / Storage Management Services |
No restrictions |
|
Novell CIFS |
|
|
Novell Cluster Services (NCS) |
|
|
Novell DHCP |
|
|
Novell DNS |
|
|
Novell Domain Services for Windows |
|
|
Novell eDirectory |
|
|
Novell FTP |
|
|
Novell iFolder |
|
|
Novell iManager |
|
|
Novell iPrint |
|
|
Novell Linux User Management (LUM) |
No restrictions |
|
Novell NCP Server / Dynamic Storage Technology |
|
|
Novell NetStorage |
|
|
Novell Pre-Migration Server |
|
|
Novell QuickFinder |
|
|
Novell Remote Manager (NRM) |
|
|
Novell Samba |
|
|
Novell Storage Services (NSS) |
|
|
Xen Virtual Machine Host Server |
|
If you install through a VNC connection, the /etc/hosts file is configured with a loop back address assigned to the hostname. This can cause problems with services.
Using a text editor, modify /etc/hosts so that the hostname is associated with its actual IP address.