Sharing log files with users who are not in the oinstall group

Sometimes a client wants to be able for a user to view log files for an Oracle application.  There are many ways to do this:

1. Give the user sudo rights to the oracle user.
2. Put the user in the oinstall group (assuming that was the default group used in the installation for the oracle user)
3. Open up the umask to 0022 so that any user can read the files.
4. Do the following:

First, you need to give read access to all of the folders in the chain.  Let's say you have a middleware home of:

/u01/oracle/products/middleware

and in there you have a domain home of

$MW_HOME/user_projects/domains/oim_domain

and in there you have a server

$DOMAIN_HOME/servers/oim_server1

In this case every folder between /u01 and oim_server1 would have to be granted 755 privileges.  It is easy enough to just go through and chmod each folder in order and then check from a user who has not been granted any of 1-3.

Next, the umask in the .bash_profile does have to be 0027 or better for people to read the files if they are in the correct group.

To make this work here is what needs to happen:

As root, execute the command:
# groupadd oshare
(I made up that group name oshare but you can call it whatever you want).
# usermod -a -G oshare oracle
# usermod -a -G oshare username
(username is the user you want to share files with)
# cd <that oim_server1 folder>
# chown -R oracle:oshare logs
# chmod -R 2755 logs

That should do it.  I have not tested this.

To reverse this go back and perform:
# chown -R oracle:oinstall logs

If you want the user to be able to delete files and not just read them, change the 2755 above to 2775.
You will have to do this in any log folder you want to share.  I would not advise sharing any other folder.  This does include the ADR folders.

Oracle Diagnostic Logging - getting deeper into OIM11gR2

Going deeper into OIM is a little different using ODL instead of the old log4j.properties file in OIM 9.1.0.2

If you have read my previous post on how to set up and hand modify the ODL files for your server, you will be able to perform these tasks.

Here are some interesting logging points I have tried:

  <logger name='oracle.iam.provisioning' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='oracle.iam.identity' level='TRACE:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='Thor.API.Operations' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.DATABASE' level='NOTIFICATION:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SERVER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SCHEDULER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
 
The handler name was changed back to odl-handler, but I use my own handler that segregates the parts I am interested in.  I put all of the parts I am interested in, into a handler I call edu-handler, so in my logging.xml file, all of the above odl-handler references actually are edu-handler.  I just want someone who wants to copy/paste to not have a failure because they haven't defined an edu-handler.

Oracle Diagnostic Logging on Weblogic - Manual Modifications

My last post on this subject involved setup.  If you are a situation where you have classes in packages such as com.mycompany.subject.specificarea and you log into the ODL logging area, you can't easily search on com.  This is why I suggested your class packages are something more like mycompany.subject.specificarea leaving off the com part.

You can search on you mycompany name in the ODL log configuration page, but you won't get the high level box like if you search on com.  And so you have to change the logging level of each individual class, and if the class you are developing has never been called, it will not be in the list.  How to fix?

Start by setting a persistent log level for one of the classes in your package structure.  Don't do it for a second or more, that's overkill.  Next, save and log out of EM.

Next, log into your server and navigate to the domain for your admin server.  Then navigate to config/fmwconfig/servers/oim_server1 (or whatever your server name is) and then edit logging.xml

Find the section which contains your class name that you just modified.  Trim back the name as far back as you desire.  Generally I leave the com.mycompany

Log levels in this file are:

INCIDENT_ERROR:1 (SEVERE+100)

ERROR:1 (SEVERE)
WARNING:1 (WARN)
WARNING:32
NOTIFICATION:1 (INFO)
NOTIFICATION:16 (CONFIG)
NOTIFICATION:32
TRACE:1 (FINE)
TRACE:16 (FINER)
TRACE:32 (FINEST)

Restart the managed server.

Working with the Oracle Diagnostic Logging on Weblogic

How to use the ODL effectively in the following:

Event Handlers
Scheduled Tasks
ICF Connectors

First, use the following classes in your code:
java.util.logging.Logger
java.util.logging.Level

You do not have to use log4j-xxx.jar it is not needed.

Second, and this is very important, if you CAN, do not begin your package name with com, rather use something unique like edu for colleges or your company abbreviation.  This will make it easier to do the configuration in the Enterprise Manager.

Next, in your code, use the following techniques:
1) In your class definition, create a private static final Logger called logger and initialize it with the class like this:
private static final Logger logger = Logger.getLogger(MyClass.class.getName());

2) In each method specify a String with the method name such as:
String methodName="execute";

3) At the beginning of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Entering");

4) Optionally, at the end of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Exiting");


5) For the rest of your output statements, use:
logger.logp(Level.FINE, getClass().getName(), methodName,
   "whatever you want to say in your message");

For these types of statements the following are available:
Level.SEVERE         Level.WARNING      Level.INFO
Level.FINE               Level.FINER             Level.FINEST

That's it for the code.

In Weblogic's Enterprise Manager, open the deployment where you have placed your code, Nav to this with WebLogic Domain -> domain name and select the managed server.

You will see the managed server name (it needs to be up with the green up arrow) and below that will read WebLogic Server and show a down arrow.  Select the down arrow and nav to Logs -> Log Configuration.

In here you see 3 tabs, Log Levels, Log Files, and QuickTrace.  Select Log Levels, View Runtime Loggers, and search on your class name.

Find your class name.  The default log level is normally WARNING.  Choose wisely the class or package you want to modify, and set the level to the highest level you wish to see.  Scroll to the bottom of the screen and check the "Persist log level state across component restarts" and then click "Apply".  Your logger is now set to go to the diagnostic.log file.

If you want to have your data go to a separate set of log files, go to the Log Files tab and select the odl-handler Handler Name, then click on "Create Like...", and create a new Handler.  Give it a cool name and change the configuration to use a different file name pattern than -diagnostic.  Save this and then assign your classes to it.  Done.