'External Connections" on different Oracle versions.
Jeff
heres another try.
I want to do an 'external connection' (i.e., No user or password
supplied in DBI->connect ) from a single script to multiple versions of
Oracle ( Oracle 8 & 10 ).
What I have found so far is that Oracle.pm built againt the 10 client
works great with the wallet (No user or password supplied in
DBI->connect ) but will not connect to 8 without a username/password.
Oracle.pm built against 8 works great with Oracle 8 when doing an
'external connection' (i.e., No user or password supplied in
DBI->connect ) but will not connect to 10 without a username/password.
Each version of Oracle uses a different mechanism to do an 'external
connect' and they seem to have opted for NO backward compatibility in
this regard.
Anyone solved this ?
Thanks.
Jeff
SQL> show parameter os_authent_prefix;
NAME TYPE VALUE
------------------------------------ ------- ---
os_authent_prefix string
Notice no value just to complicate it more :-)
SQL> select USERNAME,PASSWORD from dba_users;
OW_ADMIN_UTILS 26749C6AA7E5A212
MYUSER EXTERNAL
OWPROJECT F068F107BFFB41DD
Charles Jardine
Executive summary: It can't be done in this way at all.
You have to user two different processes. Try DBD::Gofer.
Longer explanation:
The connection between an Oracle client and an Oracle server is
via an 'adapter'. Most adapters are network based. One, in
particular, is not. It is called the 'bequeather', or BEQ.
The bequeather can be used only when the client is on the same
computer as the server. To use the bequeather, set ORACLE_SID
and ORACLE_HOME, unset TWO_TASK, and do not pass a connect
string with the login credentials.
The bequeather is only designed to work when the client and server
are using the *same* ORACLE_HOME. It is not a matter of versions.
Even if you have two ORACLE_HOMEs of the same version, you have
to use the one which the server runs from.
External authentication can be used only in conjunction with
bequeather connections. An 'identified externally' user can
log in without providing either a username or a password, provided
the Oracle username is equal to the concatenation of the
os_authent_prefix parameter and the OS username. In your
case, where the os_authent_prefix is null this means
the two usernames must be equal.
Users 'identified externally' do not have passwords, and
can this only log in from the same computer as the server.
This is all very convenient until you want to use databases
of different versions at once
Is simply isn't possible to user two ORACLE_HOMEs at once
in a single process. Clashing linker names in the libraries
will cause segfaults etc..
You have to find a way of establishing your two connections
in different processes.
--
Charles Jardine - Computing Service, University of Cambridge
cj...@cam.ac.uk Tel: +44 1223 334506, Fax: +44 1223 334679
Jeff
DBD::ProxyServer, but I want to add some interesting observations:
External connections Orcale 8:
If the remoter server has a username that matches the username of the
remote client it will still authenticate. This work in our setup. You
don't necessarily have to be local.
>From what I have seen Oracle.pm & Oracle.so will search LD_LIBRARY_PATH
for the appropriate libclntsh.so that they were built with. Both builds
will load happily if I have both versions of libclntsh.so in the path.
If I take one away the corresponding Oracle.pm will complain on
bootstrap and die.
In fact, as I stated, using 2 Oracle.pms ( one hacked and built with 8 &
the other NOT hacked and built with 10 ) --> if the Oracle8 connection
is made first ( no username/password given & set up with external
connections on a remote server) and then the Oracle10 connection ( again
no username/password given & using the wallet ) - both connection are
happy ........ until cleanup time on exit.
Therefore if seemed to me that the only major thing ORACLE_HOME is being
used for is tnsnames.ora
Charles Jardine
> External connections Orcale 8:
> If the remoter server has a username that matches the username of the
> remote client it will still authenticate. This work in our setup. You
> don't necessarily have to be local.
This is so only if some idiot has set the parameter remnote_os_authent = true.
It is false by default, and the description points to a warning in the
Advanced Security Guide which explains why you should not set it true.
The same parameter, with the same warning, still exists in 9, 10 and 11.
At last, in 11, it is said to be deprecated.
> Therefore if seemed to me that the only major thing ORACLE_HOME is being
> used for is tnsnames.ora.
tnsnales.ora is not used for a bequeather connection. In this case the
client's ORACLE_HOME is used in the ways that server-site ORACLE_HOME
is used by the listener for a network connection. In perticular it is
usne to find the server instance.
Charles Jardine
Please post you replies to the list, not just to me.
> Its a closed system. No outside access.
In that case, set remote_os_authent = true on all the servers,
use the Oracle 10 client, an make all the connections using
a network connections, i.e. not setting ORACLE_SID and using
a tns alias.
Jeff
Can't, privileges do vary from SID to SID so need user's real access.
DBI::Proxyserver for one or the other is a winner I think.
On Mon, 2009-11-02 at 09:10 -0700, Bruce Johnson wrote:
> On Oct 29, 2009, at 2:15 AM, jeff wrote:
>
> > Oracle.pm built against 8 works great with Oracle 8 when doing an
> > 'external connection' (i.e., No user or password supplied in
> > DBI->connect ) but will not connect to 10 without a username/password.
> >
> > Each version of Oracle uses a different mechanism to do an 'external
> > connect' and they seem to have opted for NO backward compatibility in
> > this regard.
>
> How a bout going low and sneaky, and providing a username and password
> with appropriate privs for one or the other hardcoded into the app?
>
Bruce Johnson
On Oct 29, 2009, at 2:15 AM, jeff wrote:
> Oracle.pm built against 8 works great with Oracle 8 when doing an
> 'external connection' (i.e., No user or password supplied in
> DBI->connect ) but will not connect to 10 without a username/password.
>
> Each version of Oracle uses a different mechanism to do an 'external
> connect' and they seem to have opted for NO backward compatibility in
> this regard.
How a bout going low and sneaky, and providing a username and password
with appropriate privs for one or the other hardcoded into the app?
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs