3.9 Caveats to Consider Before You Install

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:

3.9.1 Adding a Linux Node to a Cluster Ends Adding More NetWare Nodes

After you add a Linux node to a cluster, you cannot add more NetWare nodes. For more information, see the OES 11 SP2: Novell Cluster Services NetWare to Linux Conversion Guide.

3.9.2 Always Double-Check Service Configurations Before Installing

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 3.9.3, Back Button Doesn’t Reset Configuration Settings.

3.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 eDirectory 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.

3.9.4 Cluster Upgrades Must Be Planned Before Installing OES

Because of differences between Novell Cluster Services on NetWare 6.5 SP8 and OES, there are important issues to consider before combining them into a mixed node cluster, as explained in the following sections.

Service Failover in a Mixed Cluster

The only cluster-enabled service that can fail over cross-platform (run on either OES 11 SP2 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 11 SP2 server can fail over to another OES 11 SP2 server in the cluster, but the service cannot fail over to a NetWare 6.5 SP8 server.

3.9.5 Common Proxy Password Policy Should Be Assigned

When you install a Common Proxy user, it is possible to deselect the Assign Common Proxy Password Policy to Proxy User checkbox. This is not recommended because then the user inherits the password policies of the container where it is installed, and that can lead to service failures.

3.9.6 Cross-Protocol File Locking Might Need To Be Reconfigured if AFP or CIFS Is Functioning on an NCP Server

Cross-protocol file locking (CPL) default behavior works as follows:

  • All new servers with NCP installed have CPL turned on.

  • If an upgraded server was not configured for CPL prior to the upgrade, CPL will be turned on.

  • If an upgraded server was configured for CPL prior to the upgrade, the CPL setting immediately preceding the upgrade is retained.

If a server is only accessed through NCP (AFP and CIFS are not installed), you can achieve an NCP performance gain of about 10% by disabling CPL. However, there is a critical caveat. If you later install AFP or CIFS and you forget to re-enable CPL, data corruption can occur.

There are also obvious implications for clustering. The CPL settings for clustered nodes must match.

For more information about cross-protocol locking, see Configuring Cross-Protocol File Locks for NCP Server in the OES 11 SP2: NCP Server for Linux Administration Guide.

3.9.7 Do Not Create Local (POSIX) Users

During the OES 11 SP2 install you are prompted by the SLES portion of the install to create at least one local user besides root, and you are warned if you bypass the prompt.

Creating local users is not recommended on OES servers because user management in OES 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 to servers through the Linux User Management (LUM) technology installed by default on every OES 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 servers just as they do on NetWare without any additional configuration.

For more information about this topic, see Section 15.2, Linux User Management: Access to Linux for eDirectory Users.

3.9.8 Do Not Upgrade to eDirectory 8.8 Separately

If you are running OES 1 SP2, do not upgrade to eDirectory 8.8 independently of upgrading to OES 11 SP2.

For example, do not upgrade from eDirectory 8.7.3 to eDirectory 8.8.6 through the oes-edir88 patch channel prior to upgrading to OES 11 SP2. Doing so causes configuration problems that the OES 11 SP2 install is not designed to handle.

3.9.9 Follow the Instructions for Your Chosen Platforms

Although installing Novell services on Linux or NetWare is a straightforward process, the installation processes are platform-specific, requiring different sets of media and different installation programs.

3.9.10 If You’ve Ever Had OES 1 Servers with LUM and NSS Installed

Having NSS volumes on OES servers requires certain system-level modifications, most of which are automatic. For more information, see Section H.0, System User and Group Management in OES 11 SP2.

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 server with both LUM and NSS installed.

NetStorage, XTier, and Their System Users

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).

An NSS Complication

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.

eDirectory Solves the Basic Problem

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 15.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.

ID Mismatches on OES 1

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 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.

The OES 1 Solution: The nssid.sh Script

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.

OES 2 SP1 or Later Requires a New Approach

IMPORTANT:The following processes described in the next section (The Solution: Standardizing the UIDs on all OES servers) only need to be done once per eDirectory tree.

Unfortunately, system-level changes in SUSE Linux Enterprise Server 10 SP2 invalidated the nssid.sh script solution for OES 2 SP1 and later. Synchronizing the XTier IDs with an OES 1 installation can cause instability in other non-OES components. Therefore, if you have not already done so, you should standardize all XTier IDs on existing servers before installing a new OES 11 SP2 server with XTier-dependent services.

The Solution: Standardizing the UIDs on all OES servers

If your eDirectory tree has ever contained an OES 1 server with NSS and LUM installed, and if you have not already standardized the UIDs for a prior OES 2 SP1 or later release, do the following on each server that has NSS and LUM installed:

  1. 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.

  2. (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)
    

  3. (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.

  4. Download the following script file:

  5. 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

  6. 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 affects the entire file system, and some files are locked because the system is running.

  7. Repeat from Step 1 for each of the other servers in the same context.

3.9.11 iFolder 3.9.2 Considerations

For best results, be sure you read and carefully follow the instructions in the .Novell iFolder 3.9.2 Administration Guide and the Novell iFolder 3.9.2 Deployment Guide. This is especially critical if you plan to use NSS for your iFolder 3.9.2 data volume.

3.9.12 Incompatible TLS Configurations Give No Warning

When you install a new eDirectory tree, the eDirectory Configuration - New or Existing Tree screen has the Require TLS for Simple Binds with Password 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 Use secure channel for configuration 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.

3.9.13 Installing into an Existing eDirectory Tree

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:

Consider Coexistence and Migration Issues

If you are installing a new OES 11 SP2 server into an existing eDirectory tree, be sure to read and follow the instructions in Preparing eDirectory for OES 11 SP2 in the OES 11 SP2: Installation Guide.

Do Not Add OES to a Server That Is Already Running eDirectory

Although you can add OES to an existing SLES 11 server if needed, you cannot install OES on a SLES 11 server that is already running eDirectory.

eDirectory must be installed in conjunction with the installation of OES services.

Be Sure That eDirectory Is Healthy

Review and follow the guidelines in Keeping eDirectory Healthy in the NetIQ eDirectory 8.8 SP8 Administration Guide.

Be Sure That Network Time Is Synchronized

OES 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 11 SP2 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 12.3, Time Services.

Be Sure that OpenSLP on OES Is Configured Properly

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 12.5, SLP.

3.9.14 NetStorage Caveats

NetStorage Access to a Cluster Resource Fails When the Resource Comes Online from a Comatose State

To restore access to the storage object, restart the novell-xsrvd process by running the following command:

/etc/init.d/novell-xsrvd restart

Unable to Use a Common Proxy if ZENworks and NetStorage Are Installed on the Same System

If you are using ZENworks along with NetStorage on the same OES server, you must not use a common proxy user.

Common Proxy Password Cannot Exceed 20 Characters

If a common proxy user used by NetStorage is assigned a password policy, you must ensure that the password size specified in the policy does not exceed 20 characters.

NetStorage Purge and Salvage Options Do Not Work on Macintosh with Safari 4.0.x

If you are using Safari 4.0.x with Macintosh, the Salvage and Purge options do not work.

3.9.15 NetWare Caveats

NetWare Licenses and OES Trees

OES doesn’t use Novell Licensing Services (Section 4.6, Licensing). As a result, OES servers don’t need a license container in eDirectory as part of the server installation.

In a mixed OES 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:

  1. 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 NetIQ® iManager Installation Guide.

  2. Add a Read/Write replica to the server as described in Adding a Replica in the NetIQ eDirectory 8.8 SP8 Administration Guide.

  3. 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 NetIQ® iManager Installation Guide.

NetWare 6.5 Servers Must Be Running SP3 or Later

If you are installing OES 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:

  • SLP Directory Agents: If the SLP Directory Agents on your network are not running NetWare 6.5 SP3 or later, installing an OES 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.

3.9.16 Novell Distributed Print Services Cannot Migrate to Linux

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.

3.9.17 NSS Caveats

About New Media Support and Clusters

The new media support for hard links on OES 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 a later version of OES.

Removable Media Cannot Be Mounted on OES

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 11 SP2: NSS File System Administration Guide for Linux.

3.9.18 Plan eDirectory Before You Install

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 11 Services in the OES 11 SP2: Installation Guide.

3.9.19 Samba Enabling Disables SSH Access

Enabling users for Samba automatically disables SSH access for them. However, this default configuration can be changed. For more information, see Section 11.5, SSH Services on OES 11 SP2.

3.9.20 Unsupported Service Combinations

Do not install any of the following service combinations on the same server. Although not all of the combinations shown in Table 3-2 cause pattern conflict warnings, Novell does not support any of them.

Table 3-2 Unsupported Service Combinations

Service

Unsupported on the Same Server

Novell AFP

    • File Server (Samba)
  • Netatalk

  • Novell Domain Services for Windows

  • Novell Samba

  • Xen Virtual Machine Host Server

Novell Archive and Version Services

  • Novell Domain Services for Windows (DSfW)

  • Xen Virtual Machine Host Server

Novell Backup / Storage Management Services

No restrictions

Novell CIFS

  • File Server (Samba)

  • Novell Domain Services for Windows

  • Novell Samba

  • Xen Virtual Machine Host Server

Novell Cluster Services (NCS)

  • High Availability

  • Novell Domain Services for Windows

    DSfW can actually be installed and run on the same server as NCS, but DSfW cannot run as a clustered service.

Novell DHCP

  • Xen Virtual Machine Host Server

Novell DNS

  • Xen Virtual Machine Host Server

Novell Domain Services for Windows

  • File Server (Samba)

  • Novell AFP

  • Novell Archive and Version Services

  • Novell CIFS

  • Novell Cluster Services (NCS)

    • NCS can actually be installed and run on the server, but DSfW cannot run as a clustered service.
  • Novell FTP

  • Novell iFolder

  • Novell NetStorage

  • Novell Pre-Migration Server

  • Novell QuickFinder

  • Novell Samba

  • Xen Virtual Machine Host Server

NetIQ eDirectory

  • Directory Server (LDAP)

  • Xen Virtual Machine Host Server

Novell FTP

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell iFolder

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell iManager

  • Xen Virtual Machine Host Server

Novell iPrint

Novell Linux User Management (LUM)

No restrictions

Novell NCP Server / Dynamic Storage Technology

  • Xen Virtual Machine Host Server

Novell NetStorage

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell Pre-Migration Server

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell QuickFinder

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell Remote Manager (NRM)

  • Xen Virtual Machine Host Server

Novell Samba

  • File Server (Samba)

  • Novell CIFS

  • Novell Domain Services for Windows

  • Xen Virtual Machine Host Server

Novell Storage Services (NSS)

  • Xen Virtual Machine Host Server

Xen Virtual Machine Host Server

  • File Server (Samba)

  • Novell AFP

  • Novell Archive and Version Services

  • Novell CIFS

  • Novell DHCP

  • Novell DNS

  • Novell Domain Services for Windows

  • NetIQ eDirectory

  • Novell FTP

  • Novell iFolder

  • Novell iManager

  • Novell iPrint

  • Novell NCP Server / Dynamic Storage Technology

  • Novell NetStorage

  • Novell Pre-Migration Server

  • Novell QuickFinder

  • Novell Remote Manager (NRM)

  • Novell Samba

  • Novell Storage Services

  • Print Server (CUPS)

3.9.21 VNC Install Fails to Set the IP Address in /etc/hosts

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.