Has anyone used Command line RUNUBE on Unix?

Dave Harker

Dave Harker

Member
We are trying to automate running batch reports under UNIX (Solaris 10 in particular). We have a number of issues when we try and Oracle have come back saying only the user who started JDE services on the box is able to run under an SSH session, and that they must also be the owner of IPC services. They suggest there is no known workaround which seems bad. Having to run batch reports from a system account just doesn't make any sense! Is there anyone out there thats been able to run RUNUBE from a command line?

Thanks

Dave
 
Yes (HP-UX and AIX). Yes there is a workaround, but the workaround works on HP-UX but not AIX. Perhaps it will work on Solaris. I don't have a box available to test, but if you 'chmod 4755 runube' as the system owner, it should set 'setuid' permissions on runube such that the program can be executed by any user and 'run as' the system owner.

The whole thing about IPC services and "no known workaround" is an excuse or the person who told you that doesn't know the story. What happened is that it used to work for all users, but some customer had the requirement that no user other than the system owner should be able to attach to the shared memory of the IPC's owned by the system owner for security purposes. As a result, the JDE developers changed the default IPC permissions such that it no longer works for any user besides the system owner. I complained about it loudly a few years ago, but was shut down. I never bothered to go back and complain again.
 
[ QUOTE ]
As a result, the JDE developers changed the default IPC permissions such that it no longer works for any user besides the system owner.

[/ QUOTE ]

Can ANYONE explain why JDE does this ?

I mean, it doesn't really take much to have a routine that checks to see if the JDE.INI file has a value or not, and changes the way the system works based on that value.

It happens way too often. One (large) customer screams loudly, and the developers jump. When many (usually smaller) customers then point out the folly of the development teams changes, nothing gets done to rectify the situation.

Developers should use the JDE.INI more often.
 
I don't agree with the change, but in reality what they did *is* good security practice. However, they should have come up with another way to accomplish the same task.

Setting a JDE.INI parameter is a great idea, but of course it could easily be defeated. After all, a developer could edit the INI with a crafty piece of code, provided they could get the code built and deployed to the enterprise server. To do that, just check it in to DV and wait until the next full build. LOL. All the more reason to have separate physical servers or multifoundation and of course the requisite code reviews for promoted objects.
 
Dave,

We use runube on a Sun/Solarus box. The master user JDE is set up so that it cannot be used to log on to the box directly. A limited number of users have authority to "switch user" to the user id JDE. We also use runube in a number of scripts which are set up as a cron job and run as the master JDE user.
 
[ QUOTE ]

It happens way too often. One (large) customer screams loudly, and the developers jump.

[/ QUOTE ]

Come on, you've been around long enough to know how it really works. What you meant was that the management jumps and tells the developers to change stuff....
 
Back
Top