Fix (APAR): PK50965 Status: Fix Release: 6.1.0.5, 6.1.0.7, 6.1.0.9, 6.1.0.11, 6.1.0.13 Operating System: AIX,HP-UX,i5/OS,Linux,Linux pSeries,Linux zSeries,OS/400,Solaris,Windows Supersedes Fixes: CMVC Defect: PK50965 Byte size of APAR: 14054 Date: 2007-10-10 Abstract: With global security enabled, a CORBA.NO_PERMISSION occurs during application server re-registration when a nodeagent is restarted and the application server(s) are not. Description/symptom of problem: PK50965 resolves the following problem: ERROR DESCRIPTION: Under WebSphere Application Server environment with global security enabled and Application Server Clusters running, CORBA.NO_PERMISSION error occurs when only nodeagent is restarted and the application servers are not. The specific error is: CORBA.NO_PERMISSION: Failed to verify caller subject vmcid: 0x49424000 minor code: 303 completed: No LOCAL FIX: None. PROBLEM SUMMARY USERS AFFECTED: Users of IBM WebSphere Application Server versions 6.0.2 and 6.1. PROBLEM DESCRIPTION: With global security enabled, a CORBA.NO_PERMISSION occurs during application server re-registration when a nodeagent is restarted and the application server(s) are not. RECOMMENDATION: There is a workaround for this issue, which is to ensure that whenever a nodeagent is recycled, that all the application servers on that node (assuming there are managed servers) be recycled as well. When a nodeagent is restarted, the application server(s) needs to re-register (assuming there are managed servers) with the nodeagent. The CORBA.NO_PERMISSION error occurs when the application server(s) re-register with the nodeagent. This exception occures when global security is enabled due to a missing security context during the re-register request to the nodeagent. This is not hit during the application server startup, rather is only hit when the nodeagent is restarted and requests that all application servers re-register with the nodeagent. During appserver startup, the main startup thread has already obtained the server subject and has established a security context when it issues the register request to the nodeagent. However, after a nodeagent is restarted (and the application servers aren't), when a re-registration is issued from the nodeagent to the application server(s), the thread that then issues the re-register back to the nodeagent is a generic ORB worker thread which does not have any established security context and credentials, thus resulting in a CORBA.NO_PERMISSIONS exception. PROBLEM CONCLUSION: With this fix, when the application server re-registers with the nodeagent, the correct security context and credentials will be associated with the thread performing the re-register. The fix for this APAR is currently targeted for inclusion in fixpacks 6.0.2.25 and 6.1.0.15. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980 Directions to apply fix: NOTE: Choose the: 1) Release the fix applies to 2) The Editions that apply 3) Delete the Editions & Methods that do not apply and this Note Fix applies to Editions: Release 6.0 _X_ Application Server (Express or BASE) _X_ Network Deployment (ND) Install Fix to: Method: __ Application Server Nodes __ Deployment Manager Nodes _X_ Both NOTE: The user must: * Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 For detailed instructions to Extract the Update Installer see the following Technote: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21205400 1) Copy 6.1.0.5-WS-WAS-IFPK50965.pak file directly to the maintenance directory 2) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Select the "Install maintenance package" operation. 6) Enter the file name of the maintenance package to install (6.1.0.5-WS-WAS-IFPK50965.pak file which was copied in the maintenance directory). 7) Install the maintenance package. 8) Restart WebSphere Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (6.1.0.5-WS-WAS-IFPK50965.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere. Additional Information: