When installing Grid Control agents on a Linux or Unix platform, a recommended practice is to install as a user that doesn't own the ORACLE_HOMEs to be monitored. This poses a challenge when configuring monitoring for some targets, particularly those based on Oracle Application Server 10g. For security purposes, file and directory permissions on some ORACLE_HOMEs are fairly restrictive, and the Grid Control agent can't read all of the files necessary for target discovery and metric collection. The Grid Control release notes mention this complication, and Metalink Note 437078.1 provides additional suggestions for resolving discovery and metric collection errors related to file permission restrictions on a target ORACLE_HOME. I can't reveal the content of the Metalink My Oracle Support Note, and the information in the publicly-available Release Notes provides inadequate coverage, but the overall problem-solving method reduces to:
- Make sure that the owner of the agent software is in the same group as the owner of the monitored target software
- Check the agent log files for file permission errors, and fix them.
My experience so far indicates that fixing some errors tends to reveal others. Who doesn't love a rousing game of log file whack-a-mole? In the interest of saving others a few rounds of this, I'm offering up a few additional permission change steps that could make your lives easier. For ease of navigation, I've broken things into the following sections:
- Oracle Application Server
- Database targets
- Oracle Collaboration Suite Calendar Server
- E-Business Suite
Disclaimer: When considering making the changes I describe below, please consider the trade-off you are making: more robust monitoring at the expense of some level of security. The perceived degree of sacrifice will vary from person to person and organization to organization. I would argue that the benefits outweigh the risks, and since Oracle itself suggests similar changes, this is clearly not a cut-and-dried issue. Hey, if doing the right thing were always easy, this job wouldn't be any fun, right? 
Please feel free to leave any similar tips (or links to your own posts about this topic) in the comments.
Oracle Application Server
Note 437078.1 is a good start, but there are a few additional items I found to ease metric collection and discovery errors for Oracle 10g App Server. ORACLE_HOME refers to the location of the 10gAS software. Depending on the application server components installed on your system, you may need to change more or fewer permissions.
chmod g+rx $ORACLE_HOME/webcache chmod g+r $ORACLE_HOME/webcache/*.xml chmod g+rx $ORACLE_HOME/portal chmod g+rx $ORACLE_HOME/portal/conf chmod g+rx $ORACLE_HOME/discoverer chmod g+rx $ORACLE_HOME/discoverer/config chmod g+rx $ORACLE_HOME/forms chmod g+rx $ORACLE_HOME/forms/server chmod g+rx $ORACLE_HOME/ldap chmod g+rx $ORACLE_HOME/ldap/das chmod g+rx $ORACLE_HOME/uix chmod g+rx $ORACLE_HOME/ultrasearch chmod g+rx $ORACLE_HOME/ultrasearch/webapp chmod g+rx $ORACLE_HOME/ultrasearch/webapp/config chmod g+rx $ORACLE_HOME/jpi chmod g+rx $ORACLE_HOME/jpi/doc chmod g+rx $ORACLE_HOME/Apache/oradav chmod g+rx $ORACLE_HOME/Apache/oradav/conf chmod g+rx $ORACLE_HOME/Apache/jsp chmod g+rx $ORACLE_HOME/Apache/jsp/conf chmod g+rx $ORACLE_HOME/Apache/modplsql chmod g+rx $ORACLE_HOME/Apache/modplsql/conf chmod g+rx $ORACLE_HOME/sso chmod g+rx $ORACLE_HOME/sso/conf
Database targets
Some environments (for example, the 10gAS infrastructure database) will require permission changes to effectively monitor database and listener targets. You may find the scope of these changes to be a bit broad; at some point I got tired of chasing down individual files and just hit them all with the same hammer. 
In this case, ORACLE_HOME refers to the ORACLE_HOME of the RDBMS software.
find $ORACLE_HOME/admin -type d -exec chmod g+rx {} \;
find $ORACLE_HOME/admin -type f -exec chmod g+r {} \;
find $ORACLE_HOME/network -type d -exec chmod g+rx {} \;
find $ORACLE_HOME/network -type f -exec chmod g+r {} \;
find $ORACLE_HOME/rdbms -type d -exec chmod g+rx {} \;
find $ORACLE_HOME/rdbms -type f -exec chmod g+r {} \;
## The following are needed for database health checks to work properly...
chmod g+rx $ORACLE_HOME/dbs
chmod g+rw $ORACLE_HOME/dbs/hc*
Another general configuration note for the database listener, which I stumbled upon when setting up monitoring for a Secure Enterprise Search repository database: If sqlnet.ora is configured with TCP.VALIDNODE_CHECKING=yes, then the server that hosts the Grid Control OMS needs to be added to the list of hosts defined by TCP.INVITED_NODES. Otherwise, you'll get messages like this when attempting to add the database target, even if all monitoring credentials are correct:
Failed to connect to the database: Io exception: Got minus one from a read call The Connect Descriptor was (description=(address=(host=ses.myorg.com)(protocol=tcp)(port=xxxx)) (connect_data=(service_name=SESdb)(instance_name=SESdb)(UR=A)))</pre> And corresponding messages in the listener log: <pre>TNS-12546: TNS:permission denied TNS-12560: TNS:protocol adapter error TNS-00516: Permission denied
Of course, after adding the OMS host to TCP.INVITED_NODES in sqlnet.ora, you need to tell the listener that you've made a change before the OMS will be able to connect to the database and add it as a target:
oracle@ses:~> lsnrctl reload LSNRCTL for Linux: Version 10.1.0.5.0 - Production on 05-DEC-2008 10:58:45 Copyright (c) 1991, 2004, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ses.myorg.com)(PORT=xxxx))) The command completed successfully
Oracle Collaboration Suite Calendar Server
These commands will resolve some issues with metric collection for OCS Calendar Server. I suspect that the intersection of Collaboration Suite administrators (a small set) and readers of this blog (a vanishingly small set) is probably zero, but Google works in mysterious ways. ORACLE_HOME refers to the OCS software location, not the Grid Control agent home.
chmod g+rx $ORACLE_HOME/ocal/bin
chmod g+rx $ORACLE_HOME/ocal/bin/uniwho
chmod g+rx $ORACLE_HOME/ocal/bin/unireqdump
chmod g+rx $ORACLE_HOME/ocal/bin/uniping
chmod g+rx $ORACLE_HOME/ocal/bin/unistatus
chmod g+rx $ORACLE_HOME/ocal/sbin
chmod g+rx $ORACLE_HOME/ocal/sbin/who
chmod g+rx $ORACLE_HOME/ocal/sbin/reqdump
chmod g+rx $ORACLE_HOME/ocal/sbin/ping
chmod g+rx $ORACLE_HOME/ocal/sbin/status
chmod g+rx $ORACLE_HOME/ocal/oem
chmod g+rx $ORACLE_HOME/ocal/oem/scripts
chmod g+rx $ORACLE_HOME/ocal/oem/scripts/ocal_ps.pl
chmod g+rx $ORACLE_HOME/ocal/oem/scripts/ocal_dbsize.pl
chmod g+rx $ORACLE_HOME/ocas
chmod g+rx $ORACLE_HOME/ocas/linkdb
chmod g+rx $ORACLE_HOME/ocas/sessiondb
chmod g+rx $ORACLE_HOME/lib
chmod g+rx $ORACLE_HOME/ocal/lib
chmod g+r $ORACLE_HOME/ocal/lib/*.so
chmod g+rx $ORACLE_HOME/ocal/db
chmod g+rx $ORACLE_HOME/ocal/db/nodes
find $ORACLE_HOME/ocal/db/nodes -type d -exec chmod g+rx {} \;
find $ORACLE_HOME/ocal/db/nodes -type f -exec chmod g+r {} \;
E-Business Suite
Setting these permissions in an E-Business Suite R12 instance resolved some metric collection errors of the form
Couldn't open INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/oafm/orion-application.xml: Permission denied at AGENT_HOME/sysman/admin/scripts/ias/simpleXPath.pm line 116
These errors may not manifest in 11i, since that version's tech stack is not based on 10gAS. INST_TOP is the "Instance TOP" environment variable for the R12 Apps installation, and serves as a reminder to connect as the Apps owner (not database software owner) to run these commands.
chmod g+r $INST_TOP/ora/10.1.3/j2ee/forms/config/jms.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/forms/application-deployments/forms/orion-application.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/forms/application-deployments/forms/formsweb/orion-web.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oacore/config/jms.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/orion-application.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orion-web.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/config/jms.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/oafm/orion-application.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/oafm/webservices/orion-web.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/mapviewer/orion-application.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/mapviewer/web/orion-web.xml chmod g+r $INST_TOP/ora/10.1.3/j2ee/oafm/application-deployments/ascontrol/orion-application.xml
3 Comments
Hi John,
Very nice article, do we have something similar for 11g. I need to give access to other users (ORACLE_HOME - Fusion Middleware 11g) to be able to compile forms using the frmcmp script. I just need proper permissions for 11g as we had for 10g (437078.1).
Regards,
Philani
Hi Philani,
Your situation sounds different than the problem that I'm trying to solve with this post, but it should hopefully be less complicated. Since you are considering granting execute access on frmcmp to a broader group of users, however, it is worthwhile to consult with Oracle Support to make sure that you aren't violating a recommended security practice.
Regards,
John P.
Hi John,
Metalink note 437078.1 worked very well for OAS 10.1.2.x. I did log an SR with Oracle; they suggested using the sudo utility for Forms 11g. The problem with using sudo is; frmcmp script calls hundreds of scripts/modules/libraries inside the ORACLE_HOME which defeats the purpose of protecting ORACLE_HOME. We would end up granting execute privs to all the files inside the ORACLE_HOME.
Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer 11g Release 1 (11.1.1)" --> "2.3.2 Installing as a Non-Default User":
http://download.oracle.com/docs/cd/E17904_01/install.1111/e10421/install.htm#CHDBFCBC
On UNIX operating systems, the installation of Fusion Middleware products is owned and controlled as a known user (for example, "oracle"). The file
permissions associated with this installation are configured to ensure the highest level of security possible, which by default are 700 (meaning all files are owned and accessible by the owner only).
Changing the default permissions settings will reduce the security of the installation and possibly your system. Therefore, making such a change is not
recommended. If access to particular files or executables is required by other users, the UNIX sudo command (or other similar command) should be
considered in lieu of changing file permissions..."
Regards,
Philani
One Trackback
[...] When an E-Business Suite system is behaving in a way that suggests one or two mangled (some say "corrupt," but I try not to be judgmental) configuration files, a common first response is to run Autoconfig to see if the system can sort itself out. Running Autoconfig is also frequently necessary during the course of normal maintenance, e.g. during some patching, or when renaming/relocating Oracle Apps nodes. This weekend, I was reminded of an interesting side effect of running Autoconfig. After the process was complete, Grid Control started reporting metric collection errors and "Unknown" status for some components on the application tier nodes. In this case, Autoconfig was just doing its job, generating new versions of configuration files for the apps tier, complete with their original file permissions, which overwrote the permission changes I had made to enable the Grid Control agent to monitor some of the OC4J components. Good thing I keep that list of chmod commands in an easy-to-find reference location. [...]