This chapter describes Sun N1 Service Provisioning System 5.1 issues that are known to be problems.
This section describes known issues with uninstallation.
When you are performing a side-by-side upgrade of a Windows Master Server, immediate uninstallation fails. Uninstallation might require manual intervention and reboot to complete.
Workaround: Stop the Master Server service from the Services application in the Windows Control Panel before running the Master Server uninstallation. After the uninstallation completes, the Master Server services are still present. Reboot the machine to remove the Master Server services entries in the Services application in the Windows Control Panel.
After upgrading a Sun N1 Service Provisioning System Windows version of the Local Distributor or Remote Agent to the next version, if you uninstall that Local Distributor or Remote Agent, the title of the uninstallation window displays the previous version.
Workaround: The uninstallation program proceeds properly. Ignore the erroneous title.
This section describes known runtime issues.
When executing an execNative step with the background option specified, the command might take more than ten minutes to start instead of starting immediately.
This issue occurs on IBM AIX systems that have the number of open file descriptors set to a value in excess of a million or unlimited. Unlimited equates to approximately two billion. You can determine the current soft limit on the maximum number of open file descriptors by executing the ulimit -n command.
Workaround: Set the value of the nofiles parameter to 2000 in the /etc/security/limits file for either the user that is running the agent process or all users. Following a reboot, this value persists and affects all users on the machine.
The value of the nofiles parameter must not exceed 100,000.
For more information about the /etc/security/limits file, perform the following steps:
Go to the IBM AIX Information Center at http://publib.boulder.ibm.com/infocenter/pseries/index.jsp.
Type limits file in the Search text field.
Click the GO button.
Click the limits File link in the search results.
After installing the Remote Agent on a system running SUSE Linux 9 which has the setuid bit set to yes, the permissions are incorrect for the /protect/jexec file.
The permissions are:
---x--x--- 1 root other 21864 2005-08-15 03:16 jexec |
The permissions should be:
---s--x--- 1 root other 21864 2005-08-15 03:16 jexec |
Workaround: Manually correct the file permissions after the installation completes by using the following command:
% chmod 4110 $BASEDIR/agent/bin/protect/jexec |
$BASEDIR is the installation directory.
You might not be able to delete a component when different versions of the component have had direct-run component procedures run.
This situation arises if a particular direct-run component procedure was first run on a version other than 1.0 of the component and then the same direct-run component procedure was later run on version 1.0 of the component.
You will not be able to delete the 1.0 version of the component or the first direct-run component procedure that you ran. Neither direct delete of one version nor bulk delete of both versions will be possible.
As an alternative to delete, it is possible to hide the components in question to remove them from view.
Workaround: Avoid the problem by using one of the following methods:
Always run direct-run component procedures on the 1.0 version of the component first.
Do not run direct-run component procedures on the root component once the direct-run component procedure has been run on other versions.
When running a plan on a Solaris Remote Agent with the Detailed Preflight option selected, the plan fails during preflight and displays the following error messages:
The system was unable to create VirtualAgent for host xxx. (017009) Unable to connect to agent at host xxx. (026000) Unable to create an internal representation of host xxx. (017030) Unexpected exception thrown on the server-side. (022046) readdir_r() on "/" failed: "Unknown error [-1]". (025006) |
Workaround: Do not select the Detailed Preflight option when running a plan.
The Check In Current operation enables you to ensure that the version of a component in the Master Server repository is the most recent. The Master Server checks its version of the component against the version on the source host. The check is based on metadata regarding the location of the component that was gathered at the time of previous check in.
You cannot perform the Check In Current operation on all component types. Typically, component types that can be browsed using the browser interface are eligible for the Check In Current operation.
When performing a bulk Check In Current operation, if you select a component type that does not support the Check In Current operation, the operation completes with no errors. The results displayed in the Progress dialog box for component types that are not supported might be empty or might represent historical data.
Workaround: No workaround is available.
If you are running the Sun N1 Service Provisioning System on Red Hat Linux Advanced Server 3.0, the system might hang when using Secure Socket Layer (SSL) connections.
SSL uses SecureRandom which uses /dev/random to generate random numbers. Red Hat Linux Advanced Server 3.0 includes a bug that causes /dev/random not to collect entropy. Since /dev/random does not generate numbers unless sufficient entropy is collected, applications hang when attempting to read random data from /dev/random.
Workaround: Choose one of the following workarounds:
Red Hat plans to include a patch in Update 3 to correct the problem. Apply the patch from Red Hat to your system when the patch is available. For more information about the Red Hat patch, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117218.
Do not use SSL as a connection type. Choose TCP/IP or SSH.
Remove /dev/random and replace it with a symbolic link to /dev/urandom. /dev/urandom is less secure than /dev/random but the system does not hang when the provisioning system attempts an SSL connection on Red Hat Linux Advanced Server 3.0.
If you create a notification rule that has few criteria or no criteria, plans might appear to run slowly. The plan does not complete slowly, but the display of the plan results might be delayed.
Workaround: When creating a notification rule, use as many criteria as possible. More criteria for a notification rule decreases the number of notification emails the provisioning system sends across the network. A lower number of notification emails is less likely to interfere with the display of plan results.
This section describes known issues with the Windows 2000 plug-in.
You can create a component with a single resource of type registry key where the entry you capture is a single default value. However, without the accompanying registry key, you can deploy that value but you cannot uninstall it or delete it. A message indicating an invalid path appears.
Workaround: Ensure that registry keys that you capture include more than just a single default value. For example, include the key and the default value.
When performing model to install comparisons that include snapshots of IIS settings, if an IIS setting is changed and then changed back to its original value on the target server, comparison results might indicate differences when no difference exists. In particular, IIS metabase properties that are inherited from parent nodes, such as read/write web site permissions or default document settings, are prone to this behavior.
Workaround: Ignore the differences that are found in these cases.
When you uninstall a Windows IIS Application, the Master Server browser interface displays that the uninstallation was successful. However, the COM+ applications are not completely removed. The COM+ applications remain in the Add/Remove Software Programs in the Control Panel.
Workaround: Manually remove the remaining COM+ applications.
To prevent this problem, when you install the application, increase the value of the shutdownDelaySecs variable.
This section describes known issues with the WebLogic plug-in.
If you run the default uninstall procedure for an EJB component that was deployed to more than one virtual WebLogic managed server and select only one of the managed servers to be uninstalled, the EJB component does not appear to be uninstalled from the managed server.
After the uninstall, if you click the tab on the WebLogic console for the managed server from which you uninstalled the EJB, the console correctly reports that the EJB is no longer deployed. Also, when you click the EJB tab, the console reports that the EJB is no longer targeted at the managed server from which it was uninstalled.
However, on the EJB tab, the console reports that the EJB is deployed on the managed server.
If you uninstall the EJB from all managed servers, the EJB is removed from the WebLogic console correctly.
Workaround: The WebLogic Plug-In is uninstalled correctly. Ignore the erroneous display.
If you deploy a WebLogic web application that contains a web application container with a WAR file and web application settings and include a snapshot and then delete the web application from the WebLogic Console, the following error displays if you run a model to install comparison on the web application component:
Could not complete operation on webapp domain. No such webapp exists on domain /domain/. (310101) |
The comparison should report a difference between the model and what is installed on the server. However, the comparison fails.
Workaround: No workaround is available.
If you use the WebLogic Console to undeploy a WebLogic WAR or EJB component from a managed server or cluster, the WebLogic Console reports that the WAR or EJB component is still targeted to that managed server or cluster. Consequently, if you run a model to install comparison on the managed server or cluster, the comparison reports no differences. The model to install comparison checks the WebLogic Console and reports targeted applications as deployed.
Workaround: No workaround is available.
If a WebLogic application is installed using the Sun N1 Service Provisioning System 5.1 and then content changes are made to the on disk WAR archive on the administration server, the changes are not reported in comparison results. The problem does not occur when configuration changes are made.
Workaround: Comparisons can be customized using the generate and prepare extensions with more capabilities to preprocess the on disk representation prior to running the comparison. This type of customization might require some advanced scripting.
When setting up a WebLogic administration server in the Sun N1 Service Provisioning System 5.1, clicking the Secure checkbox will attempt to set up connectivity using SSL. This selection causes an error when attempting to perform actions that require access to the WebLogic administration server.
Workaround: Always setup WebLogic administration server connections with requiring SSL connectivity. Do not select the Secure checkbox.
This section describes issues encountered when using the Sun N1 Service Provisioning System 5.1 in locales other than the English locale.
In the Latin-1 locale environment, non-ASCII characters should not be used in the search pattern. For example, umlauts in German and accents in French. The desired match might not be in the returned set when the find operation is executed.
Workaround: Latin-1 locale users should not use non-ASCII characters as the input to the find command. Using non-ASCII characters might not return the desired result. Use only ASCII characters in these locales.
String–based data within the Sun N1 Service Provisioning System is sorted using the standard dictionary lexicon. Locale-specific collation is not performed. Consequently, accented versions of characters appear in a different position than the same unaccented characters.