README VERSION : 1.1 README CREATION DATE : 2012-09-20 PATCH-ID : PVCO_03959 PATCH NAME : VRTSvcsag 5.1 SP1RP2 BASE PACKAGE NAME : Veritas Cluster Server Bundled Agents by Symantec BASE PACKAGE VERSION : VRTSvcsag 5.1SP1 SUPERSEDED PATCHES : NONE REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : hpux1131 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : OTHER PATCH CRITICALITY : OPTIONAL HAS KERNEL COMPONENT : NO ID : NONE REBOOT REQUIRED : NO PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer the release notes for installation instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer the release notes for un-installation instructions. SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- 1787018 (1919382) Mount agent fails to detect the mounted file system with trailing "/". 2586230 (2528470) Preonline trigger not supported for IPMultiNIC, and IPMultiNICB agents. 2619254 (2593173) DiskGroup agent do not detect serial split-brain situation. 2728805 (2728802) Apache agent should work correctly even if Mountpoint for httpd directory is not present on the failover node. 2788082 (2788059) System did not panic when "PanicSystemOnDGLoss" is set. 2818051 (2731133) When NFSRestart resource is brought offline, it forcefully stops automountd process. SUMMARY OF KNOWN ISSUES: ----------------------------------------- KNOWN ISSUES : -------------- FIXED INCIDENTS: ---------------- PATCH ID:PVCO_03959 * INCIDENT NO:1787018 TRACKING ID:1919382 SYMPTOM: The Mount agent fails to detect the mounted file system if either the BlockDevice or MountPoint attribute contains a trailing forward slash ("/"). DESCRIPTION: If the value configured in either the BlockDevice or MountPoint attribute contains a trailing forward slash, the Mount agent online entry point does not remove it. The monitor entry point fails to record the entry in the mount table because the monitor entry point removes the trailing forward slash before searching the mount table. RESOLUTION: Symantec has modified the Mount agent code to remove the trailing forward slash while mounting the file system. * INCIDENT NO:2586230 TRACKING ID:2528470 SYMPTOM: The preonline_ipc trigger functionality of VCS, that performs certain checks before bringing a group online, does not work for resources other than IP resources. DESCRIPTION: This is a known limitation. There is an enhancement requirement to extend preonline_ipc trigger support to other resources types. RESOLUTION: Symantec has enhanced the preonline_ipc trigger to support the following types of resources on a system: IP, IPMultiNIC, and IPMultiNICB. * INCIDENT NO:2619254 TRACKING ID:2593173 SYMPTOM: Online entry point of DiskGroup agent do not detect the serial split-brain situation and fail to log warning about it. DESCRIPTION: Diskgroup agent check for incorrect return code of the vxdg import command expected during serial split-brain situation and thus do not recognize the serial split-brain situation. RESOLUTION: Symantec has now modified the DiskGroup agent to look for correct return code of vxdg import command during serial split-brain situation. * INCIDENT NO:2728805 TRACKING ID:2728802 SYMPTOM: If the directory or filename specified as part of 'httpdDir' attribute does not exist on the cluster node, the Apache agent cannot monitor the HTTP server correctly. And Apache agent logs error with following message id V-16-10061-20495. DESCRIPTION: As part of validations Apache agent checks existence of file or directory specified as part of 'httpdDir' attribute. However on a node where apache resource is offline, it is possible that even the mountpoint for httpd directory may not be present, in such a case Apache agent should report the resource state as offline instead of logging an error message. RESOLUTION: Symantec has update the Apache agent to report the resource state as offline when the directory or file specified as part of 'httpdDir' attribute is not present on the system. In such an event, during process level monitoring agent looks for the Apache processes assuming the value specified as part of 'httpdDir' attribute in following ways: 1 A directory name containing 'httpd' binary 2 Complete path to the binary name itself * INCIDENT NO:2788082 TRACKING ID:2788059 SYMPTOM: System did not panic on loss of storage connectivity, even after the PanicSystemOnDGLoss attribute of DiskGroup resource is set to 1. DESCRIPTION: If a resource other than DiskGroup in a service group detects loss of storage connectivity, then that resource faults and the DiskGroup resource is brought offline. The offline entry point of DiskGroup agent does not check the state of the underlying disk group before deporting it. RESOLUTION: Symantec has modified the DiskGroup agent code to check the state of the underlying disk group before deporting. This ensures that if the offline entry point is called for DiskGroup resource due to loss of storage connectivity and PanicSystemOnDGLoss attribute of DiskGroup resource is set to 1, then the system will panic. * INCIDENT NO:2818051 TRACKING ID:2731133 SYMPTOM: When NFSRestart resource is brought offline, it forcefully stops automountd process. DESCRIPTION: When NFSRestart resource is brought offline, it terminates NFS daemons. It looks for 'mountd' daemon in running processes and stops the matching ones. It also matches 'automountd' process and subsequently forcefully stops it. RESOLUTION: The NFSRestart Agent behaviour is updated in VCS to do a strict matching for process name, which means only stop 'mountd' process. INCIDENTS FROM OLD PATCHES: --------------------------- Patch Id::PVCO_03933 * Incident no::2253349 Tracking ID ::2253345 Symptom::The IP agent fails to go offline when NetMask is changed outside of VCS control for an online VCS IP resource. Description::The IP agent makes use of IP address and Netmask value pair to perform online and offline operations. When the Netmask value on the interface is changed outside of VCS control, the VCS expected value of Netmask mismatches with the netmask value present on the device and hence offline operation fails. Resolution::Symantec has modified the VCS IP agent to log a warning which prompts to update the NetMask attribute value if the Netmask value is changed outside of VCS control. * Incident no::2330045 Tracking ID ::2195569 Symptom::If you set the ControlMode attribute of a RemoteGroup resource to OnlineOnly or MonitorOnly, then the resource fails to go offline when it loses connectivity with the remote cluster. Description::The RemoteGroup resource tries to connect to the remote cluster even after the agent has invoked its offline entry point. If the connection to the remote cluster is not available, the resource goes into the UNKNOWN state and prevents the service group from going offline. Resolution::Symantec has modified the RemoteGroup resource to check for the remote cluster connection only when the resource is ONLINE. This fix is valid only if you set the ControlMode attribute of a RemoteGroup resource to OnlineOnly or MonitorOnly. * Incident no::2366701 Tracking ID ::2371667 Symptom::1. If you store the Monitor program on a shared disk and a VCS node is unable to access the shared disk, then: a) The Application agent cannot monitor an application on the node. b) VCS cannot fail over applications on such a node. 2. If the Monitor program returns UNIX style return values (0 for success and 1 for failure), the application agent reports the state of application as UNKNOWN. AIX- Description::1. The application agent checks for the existence of the Monitor program on a node. On nodes that cannot access the shared disk, this check fails. As a result, the agent marks the status of the application as UNKNOWN on such nodes. Further, if an application goes down on an active node, then the application cannot fail over to nodes where the status of the application is UNKNOWN. 2. The Application agent can handle only the following set of values returned by the monitor program: 100 --> OFFLINE 101 to 110 --> ONLINE Any other value --> UNKNOWN. If the monitor program returns "0" as success and "1" as failure, the Application agent reports the state of application as UNKNOWN. AIX- Resolution::1. Symantec has modified the Application agent to check for the existence of the Monitor program, instead of checking whether the Monitor program has executable permissions. As a result, for nodes that cannot access the shared disks, the agent now reports the application as OFFLINE, only if the previous state of the application was OFFLINE, and the application was not waiting for a state change. In all other cases, for nodes that cannot access the shared disks, the agent reports the state of the application as UNKNOWN. 2. The Application agent handles the standard UNIX style return values, that is, "0" for success and "1" for failure, and now reports the resource state based on following set of values: 100 or 1 --> OFFLINE 101 to 110 or 0 --> ONLINE Any other value --> UNKNOWN. LINUX-SYMPTOM: 1. The Application agent returns the resource state as UNKNOWN if: a. You store the Monitor program on shared disks and a VCS node is unable to access the shared disks, then the Application agent cannot monitor an application on that node. Moreover, VCS cannot fail-over applications on such a node. b. The Monitor program returns UNIX style values, that is, "0" in case of success and "1" in case of failure. The Application agent does not handle these values. 2. The Application agent does not validate the user. If a configured user is not present on the system, the Application agent does not work properly. 3. The Application agent does not check whether the home directory for a configured user is set or not. LINUX-DESCRIPTION: 1. The Application agent checks for the existence of the Monitor program on a node. On nodes that cannot access the shared disk, this check fails. As a result, the agent marks the status of the application as UNKNOWN, on such nodes. Moreover, if an application goes down on an active node, then the application cannot fail over to nodes where the status of the application is UNKNOWN. 2. The Application agent can handle only the following set of values returned by the monitor program: 100 --> OFFLINE 101 to 110 --> ONLINE Any other value --> UNKNOWN. If a monitor program returns "0" as success and "1" as failure, the Application agent returns the resource state as UNKNOWN. 3. If an invalid user is configured in the "User" attribute of an application resource (that is, the user is not present on the system), the Application agent fails to handle such a user, and may terminate abruptly. 4. Linux does not allow a user to be created without specifying the home directory. The Application agent does not validate such a user for the home directory. If any such user is configured as the "User" attribute for an application resource, the Application agent fails to monitor the configured application. LINUX-RESOLUTION: Symantec has done following modifications in the Application agent: 1. Instead of checking for the existence of the Monitor program, the Application agent checks for non-null values of the attributes associated with the Start/Stop/Monitor programs. As a result, for nodes that cannot access the shared disks, the agent now reports the application as OFFLINE, only if the previous state of the application was OFFLINE, and the application was not waiting for a state change. In all other cases, for nodes that cannot access the shared disks, the agent reports the state of the application as UNKNOWN. 2. The Application agent validates the user for their existence and the home directory. If the configured user is not valid, or the home directory is not set for a user, the Application agent reports the resource state as UNKNOWN. 3. The Application agent handles the standard UNIX style return values, that is, "0" for success and "1" for failure, and now reports the resource state based on the following set of values: 100 or 1 --> OFFLINE 101 to 110 or 0 --> ONLINE Any other value --> UNKNOWN. SOL-SYMPTOM: a. If you store the Start/Stop/Monitor programs on shared disks, and a VCS node is unable to access the shared disks, then the Application agent cannot monitor an application on the node. Further, VCS cannot fail over applications on such a node. b. The Monitor program returns UNIX style values, that is, "0" in case of success and "1" In case of failure. The Application Agent does not handle these values. SOL-DESCRIPTION: a. The Application agent checks for the existence of the Start/Stop/Monitor programs on a node. On nodes that cannot access the shared disk, this check fails. As a result, on such nodes, the agent marks the status of the application as Unknown. Further, if an application goes down on an active node, then the application cannot fail over to nodes where the status of the application is Unknown. b. The Application agent can handle only the following set of values returned by the monitor program: 100 --> OFFLINE 101 to 110 --> ONLINE Any other value --> UNKNOWN. If a monitor program returns "0" as success and "1" as failure, the Application agent returns the resource state as UNKNOWN. SOL-RESOLUTION: a. Symantec has modified the Application agent to check for non-null values of the attributes associated with the Start/Stop/Monitor programs, instead of checking for the existence of the programs. As a result, for nodes that cannot access the shared disks, the agent now reports the application as OFFLINE, only if the previous state of the application was OFFLINE, and the application was not waiting for a state change. In all other cases, for nodes that cannot access the shared disks, the agent reports the state of the application as UNKNOWN. b. The Application agent handles the standard UNIX style return values, that is, "0" for success and "1" for failure, and now reports the resource state based on following set of values: 100 or 1 --> OFFLINE 101 to 110 or 0 --> ONLINE Any other value --> UNKNOWN. * Incident no::2423990 Tracking ID ::2423984 Symptom::If you configure an invalid value for the User attribute, the Application agent logs the following messages in the engine log: ============================================== Use of uninitialized value $uid in numeric eq (==) at /opt/VRTSvcs/bin/Application/online line 102. Use of uninitialized value $usershell in pattern match (m//) at /opt/VRTSvcs/bin/Application/online line 116. Use of uninitialized value $home in concatenation (.) or string at /opt/VRTSvcs/bin/Application/online line 138. ============================================== SOL- Description::When you configure the User attribute, if you specify a user name that does not exist on a system, then the 'getpwnam' command fails during online/offline entry points. As a result, the agent logs the above messages in the engine log. SOL- Resolution::Symantec has made the following changes in Application agent to handle the user configuration. For the configured user, if the Application agent is unable to retrieve the UID through the 'getpwnam' command, then the online/offline entry points must bail out, and log the error message in the engine log. If the Home directory returned by the 'getpwnam' command does not exist, and the UseSuDash attribute is set to 1, then the online/offline entry points must bail out, and log the error message in the engine log. The monitor entry point detects the accessibility of the Home directory only if you set the UseSuDash to 1, and the Home directory field in '/etc/passwd' is non-empty. * Incident no::2438621 Tracking ID ::2427433 Symptom::In an IPv6 setup, the MultiNICB agent incorrectly reports the state of a MultiNICB resource as UNKNOWN, if the following condition occurs: - Interfaces that are under MultiNICB control are on a subnet other than the subnet of interfaces that are not under MultiNICB Agent control Description::The MultiNICB agent compares the subnets of all the interfaces on a system, and in the above case, reports an incorrect resource state. Resolution::Symantec has modified the MultiNICB agent to skip the check for the subnet of IPv6 interfaces. * Incident no::2491635 Tracking ID ::2491627 Symptom::On Solaris systems when VxVM version 5.1 is installed with VCS version 5.1SP1, online entry point of DiskGroup resource logs the following error message "ERROR: vxdefault list autostartvolumes command failed". Description::VxVM introduced autostartvolumes feature in 5.1SP1 release. The DiskGroup agent online entry point in VCS 5.1SP1 fails to correctly verify the VxVM version to check the availability of autostartvolumes feature. Resolution::Symantec has modified the online entry point of DiskGroup agent to directly verify the availability of autostartvolumes feature in VxVM. * Incident no::2417840 Tracking ID ::2205553 Symptom::The offline entry point of DNS agent failed to remove all configured resource records when OffDelRR attribute is set to 1 and multi-home resource records are configured in ResRecord attribute. Description::The offline entry points must delete all configured resource records for multi-home ResRecord attribute values if OffDelRR attribute is set to 1. This functionality failed to work properly and removed only some of the resource records during offline operation. Resolution::Symantec has modified the offline entry point to delete all configured resource records for multi-home records if OffDelRR attribute value is set to 1. * Incident no::2417841 Tracking ID ::2205558 Symptom::The clean entry point of DNS agent failed to remove the configured resource records when OffDelRR attribute is set to 1. Description::The clean entry points must delete the resource records configured in ResRecord attribute of DNS type resource if OffDelRR attribute is set to 1. This functionality failed to work. It is required at the time of execution of clean entry point when some configured resource records are present at the DNS server and are required to be deleted. Resolution::Symantec has modified the clean entry point to delete any configured resource records if OffDelRR attribute is set to 1. * Incident no::2417843 Tracking ID ::2205564 Symptom::The master.vfd action entry point of DNS agent failed to check if the DNS server is able to reply to SOA query for configured domain for valid configurations. Description::The action entry point master.vfd queried the DNS servers without specifying the Domain name in the dig command. Therefore, it failed to query SOA record for the configured domain. Resolution::Symantec has modified the DNS agent's master.vfd action entry point to query the DNS servers for SOA record by specifying the domain name in dig command.