11-19-2013 05:13 AM
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.
Solved! Go to Solution.
12-06-2013 01:04 AM
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.1/linux/productguides/html/vcs_oracle_agent/ch01s02.htm
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
12-02-2013 08:39 AM
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
12-02-2013 10:24 AM
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.
12-02-2013 10:49 AM
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
12-06-2013 01:04 AM
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.1/linux/productguides/html/vcs_oracle_agent/ch01s02.htm
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