This is the only reasonable policy, because all OS commands would necessarily execute on the server side. Developers, generally speaking, do not have access to the database server, so I don't see much use for that. If the idea is to spawn a command on the developer's workstation by using "rsh" or "remsh" (HP-UX), then it would require a great multitude of ".rhosts" files, which would render the whole network insecure. I did, however, see a reasonable application of external procedures. Database server was on the same machine as a scanner. External procedure made it possible for the operator to scan a form, OCR it, and store it as "BFILE", all from Oracle*Forms on a client. Essentially, external procedure controlled the scanner and invoked OCR. Both scanner and PC were out of the computer room, so operator did not need access to the sensitive facilities.
On 01/09/2004 11:44:26 AM, "Goulet, Dick" wrote: > HUMM, I've taken a pretty tight stand against open ended external procedures and > Java Stored Procedures. Thankfully the developers here agree. Basically I've told > them that can't have an external or java procedure that executes a command send into > it. That being the case rsh or sh command processors are verboten. > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > > -----Original Message----- > Sent: Friday, January 09, 2004 5:29 AM > To: Multiple recipients of list ORACLE-L > > > Dick/John > > Thanks for all your input. I conclude from this discussion that it is not > possible to have different, seperate external procedure listeners for > different SIDs in the same instance at least not in 8.1.7. > > Incidentially, I have been having an issue with running an rsh command via > an external procedure. The external procedure is a C .so which uses the C > system command to run a Unix command. Sometimes the Unix command is an rsh. > What I find is that sometimes the rsh command causes the "ORA-28576 lost RPC > connection to external procedure agent". However if I make the external > procedure listener seperate and start it off as follows from the root > crontab or inittab > > /usr/bin/su - oracle -c /u01/app/oracle/product/8.1.7/bin/lsnrctl start > listener_ext > > Then I never get the error. > > Just wondered if anyone had any thoughts as to why starting the external > procedure listener in this way seems to resolve the ORA-28576 error with rsh > commands. > > John > > > > -----Original Message----- > Sent: 08 January 2004 15:59 > To: Multiple recipients of list ORACLE-L > > > John, > > I agree if you have multiple databases under the same home all is > well, one extproc sid will do. But if you have several different Oracle > homes, with different versions of Oracle then each needs it's own extproc > sid. Tried using the latest listener and/or extproc combinations, didn't > work. > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > > -----Original Message----- > Sent: Thursday, January 08, 2004 10:44 AM > To: Multiple recipients of list ORACLE-L > > > Thanks - I wasn't sure if each session got its own instance of extproc. The > SID associated with an EXTPROC is not the same as a SID associated with a > database. I have several databases running under the same Oracle Home, and > they are sharing the same external procedure listener - which references > that Oracle Home. If you are running databases under several versions of > Oracle, you may be able to use the listener for the latest version of Oracle > you have to listen for all of them, and use its extproc. But it is probably > a better idea to run separate listeners for databases and external > procedures, each with its own LISTENER.ORA and TNSNAMES.ORA under its own > Oracle Home. Just be careful about how the TNS administration directory is > set. > > -----Original Message----- > Sent: Thursday, January 08, 2004 9:54 AM > To: Multiple recipients of list ORACLE-L > > > John, > > On the contrary. You do need to associate an EXTPROC with a > particular SID otherwise running different versions of Oracle on the same > box blows the EXTPROC to hell. You'll notice that in listener.ora there > needs to be a line "SID_NAME=" and in TNSNAMES.ora there is a "Connect_data > = (sid = " as well. Now a particular database instance/version can only > have one extproc_connect_data entry, but with multiple versions each has > it's own, and sure enough each has to have a particular sid otherwise they > mess each other up. > > BTW: Your description of the process is dead on, with one exception. > An instance of extproc is connected to one and only one session in the > calling database. If two sessions each need to call an external procedure > then each gets it's own instance of extproc. Also if you need to update the > dll or so file you have to get everyone to let go of extproc, namely by > disconnecting from the database. Although it's like a database link, > closing the links does not release extproc. Also using TCP to connect to > extproc is not an Oracle recommended method, opens a door to hackers. > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: John Flack > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Goulet, Dick > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: John Dunn > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Goulet, Dick > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
