Section 10.3.3, Blank Error String iManager Error Appears While Bringing a Resource Online
Section 10.3.4, Clustered Pool Is Stuck in an eDirectory Synchronization State
Section 10.3.5, Mapping Drives in Login Scripts Does Not Work
Section 10.3.6, Mapping Drives to Home Directories by Using the %HOME_DIRECTORY Variable
Section 10.3.7, Resource Script Search-and-Replace Functions Do Not Work
Section 10.3.8, Virtual NCP Server IP Addresses Won’t Change
If you cannot bring a BCC-enabled resource online, the resource might be set as secondary. If the NCS:BCC State attribute is equal to 1, the resource is set to secondary and cannot be brought online.
On the resource object, change the NCS:BCC State attribute to 0. This sets the resource to the primary state. Also, increment the NCS:Revision attribute one number so that Novell Cluster Services recognizes that the resource properties have been updated. See Step 1 for an example of how to modify object attributes.
If you cannot migrate a resource from one cluster to a peer cluster, the problem might be caused by one of the following conditions:
The resource has not been BCC-enabled.
Remote clusters cannot communicate.
See Section 10.2.3, Peer Cluster Communication Is Not Working.
Perl script errors.
Special characters must be escaped in scripts. For example, the script might have a single % character in it that needs to be an escape (%% instead of %). Also, hashes in Perl need to have escape characters.
If you get an error in iManager with a blank error string (no text appears with the error message) while attempting to bring a resource online, it is possible that Novell Cluster Services views the resource as secondary even though BCC has changed the resource to primary and iManager shows the resource as primary.
To resolve this problem, make a change to the cluster properties to cause the NCS:Revision attribute to increment. You could add a comment to the resource load script to cause this to happen.
Pools might get stuck in an eDirectory synchronization state if all of the volumes in that pool are not active and mounted.
To resolve this problem:
In NSSMU or iManager, activate and mount the deactive volumes.
In iManager, click Clusters, then select the cluster resource for the clustered pool.
Click Offline to dismount the pool’s volumes and deactivate the pool.
Wait until the resources are successfully offline before continuing.
Click Online to bring the resource back online.
Consider the following when mapping drives in login scripts in a BCC:
Using a fully distinguished name for cluster-enabled volume (such as map s:=BCCP_Cluster_HOMES.servers.:shared) has been tested and does not work.
When the resource fails over to the secondary cluster, the DN does not resolve to a server/volume that is online. This causes the map command to fail.
Using the Server short Name/VOL:shared syntax has been tested and works.
Server Short Name is the name being advertised in SLP as specified in the resource load script. This method requires a client reboot.
Consider the following when mapping drives to home directories in login scripts in a BCC:
Using the %HOME_DIRECTORY variable (such as map u:=%HOME_DIRECTORY) has been tested and does not work.
When the resource fails over to the secondary cluster, the %HOME_DIRECTORY variable still resolves to the old volume object, and the map command fails.
Using a temporary environment variable has been tested and does not work.
For example:
set FOO=%HOME_DIRECTORY
MAP u:=%FOO
Using a false volume object along with ICE and LDIF has been tested and works.
Create a new volume object that references the real volume object.
The Host Server attribute must point to the virtual NCP server in the primary cluster, and the Host Resource Name attribute must specify the name of the volume. This new volume object can be referred to as a volume reference.
All User objects must be modified to have their Home Directory attribute reference the new volume object (volume reference).
Use LDIF and ICE in the NSMI script (SAN Array Mapping Information) area.
This script modifies the new volume reference object and updates the Host Server attribute to point to the virtual NCP server in the secondary cluster.
NOTE:Using LDIF/ICE prevents you from using the NSMI script to control the SAN. If you want to use LDIF/ICE and the NSMI script, you must have two NCF files: one for the SAN, and one for LDIF/ICE. The NSMI script must then call each NCF file separately.
See TID 10057730 for information on modifying the Server Cache Timeout value on the Client for Open Enterprise Server.
A sample NSMI script is included below:
#!ICE -b -D LDAP -d cn=root,ou=servers,o=lab -w novell -S LDIF -f #@ -s0 -w20 version: 1 dn: cn=HOMES_REF, ou=servers,o=lab changetype: modify replace: hostServer hostServer: cn=BCC-CLUSTER-HOMES-SERVER,ou=From_BCCP,ou=servers,o=lab
The first line in the sample script instructs NSMI to run the ICE utility.
The -b parameter automatically closes the ICE window.
The -d parameter is the administrator DN that is used to modify eDirectory.
The -w parameter is the password.
There must be a trailing space after the -f parameter.
The second line in the sample script includes NSMI-specific options.
-s0 causes NSMI to not wait for a signal file.
-w20 causes NSMI to wait 20 seconds before proceeding.
Failure to add the wait causes the temporary LDIF file to be deleted before ICE can read it. This causes ICE to fail.
If resource script search-and-replace functions are not working, the problem might be caused by one of the following conditions:
You did not click the Apply button on the Properties page. Clicking OK when entering the scripts does not apply the changes to the directory.
You added the search-and-replace values to the resource instead of to the cluster.
The search-and-replace values apply to a specific resource instead of all resources in the cluster.
If you are testing search-and-replace functionality, you might have made the changes too rapidly.
Identity Manager merges all changes into one, so if you quickly add a change and then delete it, Identity Manager might view it as no change. You should make a change and then verify that the change has synchronized with the other cluster before deleting it.
If the IP address for a virtual (NCP) server does not change properly, the problem might be caused by one of the following conditions:
The IP address has been changed on the load, unload, and monitor script pages.
For information, see Moving a Cluster, or Changing the Node IP Addresses, LDAP Servers, or Administrator Credentials for a Cluster
in the OES 2023: OES Cluster Services for Linux Administration Guide.
The virtual server has an extra IP address.
IP address changes should always be made on the Protocols page of the iManager cluster plug-in, and not in load and unload scripts.
This is the only way to change the IP address on the virtual NCP server object in eDirectory.
You might see a DSML read error if you select properties for a Cluster object and then click the Business Continuity tab.
The eDirectory pointers for the cluster resource are missing or are invalid. The following shows the required attributes and the format: