You would have oracle's cron to execute something like this regularly:

#!/bin/sh md5sum /some/secure/oracle/path/filename > /var/tmp/filename.md5

Then have hobbit's cron run something like:

#!/bin/sh $HOME/server/bin/bbcmd $HOME/server/ext/oracle-md5-checker.sh

You could use Hobbit's launcher, but I always found it easier to use cron to spread scheduled jobs over time.

The oracle-md5-checker.sh script would start up with all the Hobbit environment, grab the md5 checksum from the file, check it against the proper value, then report red/green. I think I would then have it delete the md5 file - that might require parking the file somewhere other than /var/tmp, which would be a good idea anyway... Deleting the file means that next time the hobbit script runs, it can validate that the oracle cron job ran, rather than just blindly re-reading the same file. That's probably simpler than comparing the file-last-changed timestamp to realtime.

Ralph Mitchell

On Tue, Jan 13, 2009 at 1:45 PM, chris <chris at spw.info> wrote:

Thanks for your suggestions.

Adding the hobbit user to the oracle group is unfortunately not an option, as the permissions do not even give the group permission to the directory, but only the owner itself.

When you suggest running a script as oracle from cron, I presume that we are talking outside of the hobbit environment, or is there still a way to keep server side configuration, etc?

---

*From:* Ralph Mitchell [mailto:ralphmitchell at gmail.com] *Sent:* Sonntag, 11. Jänner 2009 20:27 *To:* hobbit at hswn.dk *Subject:* Re: [hobbit] file monitoring permission problems

On Sun, Jan 11, 2009 at 1:05 PM, L.M.J <linuxmasterjedi at free.fr> wrote:

Le Sun, 11 Jan 2009 13:12:20 +0100, "Chris" <chris at spw.info> a écrit :

...

This is confirmed when looking into the client data sent to the server:

[file:/opt/oracle/product/j2ee/applications/appl.ear] ERROR: Permission denied

Is there an easy workaround without having to change file permissions, eg. running the file tests with sudo?

You can add the user "hobbit" to the oracle unix group. I think it's the fastest and simplest way to fix your issue.

That also reduces your database security, and I'll bet your DBAs wouldn't allow it. Better to have the oracle account run the script from cron and pick up the output from a neutral location.

Ralph Mitchell