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.

Fix to issue of not being able to write Lookup group name

There is a new bug 21171801 that I requested to be created.  This bug has likely been with OIM for some time and is in all versions I can find.

The bug was first reported in 2013.  Here is the issue: when attempting to update the group name of a lookup using the API, the write fails.  Very few people read or write lookups using the API.  I have written a schedule task to back up and restore lookups.

The bug is in the name of the Field lookup called Lookup Definition.Group which translates to LKU_TYPE_GROUP.  If you query the LKU table for the field lookups you will see that each field lookup translates to a table field name in the database.  There is no LKU_TYPE_GROUP in the database, it is called LKU_GROUP.

Field lookups cannot be exported, imported, or modified in the Design Console.  The only fix to this is the following command executed as the OIM schema owner:

SQL> UPDATE LKU SET LKU_FIELD='LKU_GROUP' WHERE 
  2  LKU_TYPE_STRING_KEY='Lookup Definition.Group';
SQL> COMMIT;

I constructed this update query this way to prevent someone from accidentally forgetting the second line.  This change has no effect on imports, exports, or editing of the Lookups including updating the lookup group name of any lookup.  This translation appears to only be used by the API and does not appear to be used by the Design Console or Nexaweb, both of which are supposedly connected via the EJBs directly to the database.

I will update this blog when a patch for this bug is released.