Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Bug in VCS's Oracle agent Health check Monitoring scripts?

Created: 19 Nov 2013 • Updated: 29 Jul 2014 | 4 comments
This issue has been solved. See solution.

Has anyone hit a bug when using VCS's Oracle agent in "Health Check Honitoring" mode (MonitorOption=1)? I've recently tested this with VCS 6.0.1 on Solaris10 x64, and discovered that the agent attempts to run scripts called "oraapi_32", "oraapi_3211g", "oraapi_64" or "oraapi_6411g" in the agent's directory "/opt/VRTSagents/ha/bin/Oracle". However, this fails because the standard installation doesn't give these scripts execute permission for non-root users, yet it's the (non-root) Oracle user that needs to run these scripts.

I added global execute permission to these scripts in my test environment, and this allowed Health Check Honitoring to work OK. Has anyone else hit this problem? Is there an official workaround or solution?

Best Regards, Alistair.

Operating Systems:

Comments 4 CommentsJump to latest comment

hafiz_rehman's picture

Hi Alistair,

I have just tested this with VRTSvcsea package version 6.0.100.000-GA-2012-07-20-16.30.01 and i see the following permissions for the oracle libs, which are set to 755 . Did you install any patch on top of it also at the same time, so i can test that ? 

-rwxr-xr-x   1 65530    119      2761412 Jul 21  2012 oraapi_32

-rwxr-xr-x   1 65530    119      1628188 Nov 12  2008 oraapi_3211g

-rwxr-xr-x   1 65530    119      3081224 Jul 21  2012 oraapi_64

-rwxr-xr-x   1 65530    119      2234248 Feb 15  2010 oraapi_6411g

Regards

Hafiz 

Alistair J Veitch's picture

Hi Hafiz,

Apologies, I think the problem I had on Solaris was due to a non-standard installation procedure. Please ignore the problem on Solaris.

However, on RHEL, the problem appears to be genuine, for example:

[root@rhel64-2 ~]# uname -a
Linux rhel64-2 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

[root@rhel64-2 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
 

[root@rhel64-2 ~]# rpm -qa | grep VRTSvcsea
VRTSvcsea-6.0.300.000-GA_RHEL6.i686
 

[root@rhel64-2 ~]# umask
0022
 

[root@rhel64-2 ~]# ls -l /opt/VRTSagents/ha/bin/Oracle | grep oraapi_
-rwxr--r--. 1 root root 1369174 Jan 11  2013 oraapi_32
-rwxr--r--. 1 root root 1563240 Jan 11  2013 oraapi_3211g
-rwxr--r--. 1 root root 1091541 Jan 11  2013 oraapi_64
-rwxr--r--. 1 root root 1998392 Jan 11  2013 oraapi_6411g
 

Could you take a look at this problem on RHEL6.4?

Thanks, Alistair.

hafiz_rehman's picture

Hi Alistair,

Yes I agree that VCS 6.0.3 on RHEL have this behaviour and as per of internal audit it was decided to change them from 755 to 744 as it might not be desirable to have world wide execute permissions, it will also be changed for other versions of VCS in future.

I will work with internal team to get documentations updated for Oracle Agent to to make sure a note is added in health check configuration to set appropriate permissions.

Regards,

Hafiz 

hafiz_rehman's picture

Hi Alistair,

We no longer ship health check API from recently launched version of SFHA 6.1, From this release a script build_oraapi.sh is included which should be used to build health check API and it should set the correct permissions on built binaries. For further details please check 

https://sort.symantec.com/public/documents/sfha/6....

For customers who are using 6.0 version of the product we are planning to introduce the same script in next version of Maintenence release and currently workaround is to set the correct permissions of 755 manually for required binary. 

Regards,

Hafiz 

SOLUTION