Re: Oracle and SCO NIS: A Big No-No??

chriseli,

I'd be more concerned that their installing a non-Y2K version of Oracle at this present time !

Chris

chriseli_at_my-deja.com wrote:
>
> I've posted this problem on the SCO newgroup and I will post it here as
> well because it involves Oracle. I also am not familiar on how Oracle
> works. Now here's the problem:
>
> We've got a SCO OpenServer 5.0.5 box acting as a NIS Client to a Red Hat
> Linux 6.0 box NIS Server. Everything is working nicely with regards to
> the NIS workings. Now, this company we've commissioned to program our
> new Accounting Software have been giving us a hard time. They're
> installing/configuring their accounting program that uses Oracle 7.2.2.3
> on the SCO box and it's taking them forever. Their reason now is that
> Oracle doesn't work propery with SCO systems configured as NIS Clients.
> Here's what they said:
>
> "We've hit a problem with the NIS system you are using for user
> authentication. It appears Oracle Forms and Oracle Menu cannot
> resolve user id's using NIS on SCO. From talking to Oracle support and
> through my own research it looks like SCO's implementation of NIS has
> several bugs in it that causes problems with Oracle. Right now it looks
> like the only solution is to disable NIS on maple [the SCO box] and
> store the user id's and passwords directly on the system. We need to do
> this asap."
>
> i've asked them for a more thorough explanation and here's what i got
> this morning:
>
> "Here is the issue with NIS. There are some bugs in SCO's NIS
> implementation that affects Oracle. When a user try's to log into the
> Plus system it verifies the user ID against the unix userid. In order
> for this to work the userid's and passwords need to be on the same
> system that Oracle is running on. They cannot be stored on another
> server. What this means for your setup is NIS has to be disabled on
> maple only and the userid's on the central NIS server need to be
> duplicated on maple. This will not affect any of your other systems. All
> it means is you are maintaining users in 2 different locations. As long
> as the entries are identical between the 2 systems everything is OK. The
> users and groups must have the same names and id numbers and the same
> home directory path. It will require some more work initially, but
> unfortunately this is the only work around for this problem."
>
> what do you think about this? is this true?
>
> thanks a million for your inputs!
>
> chriseli
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Sun Dec 19 1999 - 17:40:02 CST