[SOLVED] Install older packages side by side newer

Hello all. I have been thrown into some linux work and am struggling with some, what I presume to be, fairly simple administrative tasks on Oracle Enterprise Linux. I am posting here as I think RHEL is as close to OEL as is offered here.



I am configuring a new server for some devs and they have requested a list of packages for the Oracle 12.1.0.2 client. All of the packages for that client were present in the standard repo and I was able to install using YUM.



However they have requested to also install the version 11 Oracle client which requires some of the same packages (older versions) to be installed side by side with the newer versions.



I have 2 questions:

1) how do I install packages that are not in the standard repo

2) are there any traps or gotchas for installing 2 versions of the same package on a box?



Some example packages required (these are installed):
Oracle 12 client:
libstdc++-4.8.2-3.el7
glibc-2.17-36.el7
libaio-devel-0.3.109-9.el7



Some example version 11 packages (not installed, not in YUM list):
libstdc++-3.4.6
glibc-2.3.4-2.41
libaio-devel-0.3.105



On the old server it looks like these same libraries are installed at /opt/omni and organized very cleanly but I don't know how to replicate that on this new server.

Any help is greatly appreciated.

edit: added the oracle client 12 package version numbers

First - what version of OEL are you running on the "new" and the "old" machines? On RHEL you'd be able to tell by looking at /etc/redhat-release. I'm not sure if OEL uses that or a similarly named file.

OEL is a fork of RHEL so you're correct that a lot is similar.

In your new packages you have suffix as x86_64 which is not the version of the package but rather the architecture. In your old you're listing the version. You can get full info on what is installed with "rpm -qa". Note that it is possible to have both 32 bit and 64 bit packages of the same name (but different architecture) on the same server and often if what you're running for application is a 32 bit it requires the 32 bit libraries be added even though the system may already have 64 bit libraries.

If your "old" system is OEL5 but your new system is OEL6 (or old is OEL6 and new is OEL7) you can't just install the older OS packages onto the newer system. Specifically things like glibc you can't have older version because the OS itself relies on the newer version. What you CAN do often is make links from new library names to old names so your older application can find things.
e.g. If your app is looking for libbillybob.so.2 but your OS has libbillybob.so.3 you can often solve the issue by doing:
ln -s libbillybob.so.3 libbillybon.so.2

Most Oracle applications will give you error messages you can review to solve issues. Recently we were installing Oracle designed for RHEL5 on RHEL6 and had to solve various problems most of which were obvious either by the actual message seen in the log or by researching the oracle message ID it gave us.

Thanks for your reply!

The new server is OEL 7.3, the old is RHEL 5.11

As for the package architecture, I was having a blonde moment and not including the versions. I have edited the original post. But my concern was making the older packages available for the older Oracle client. I think I see what you mean though as I look at the /opt/omni directory on the old server I see a link that may refer to what you were saying about linking so the installer can find the package (though this is the only one).

lrwxrwxrwx 1 root root 19 Mar 31 2015 libstdc++.so.6 -> libstdc++.so.6.0.14

I think I will work with the dev and see what errors pop up and see if those can be resolved by linking to the new locations.

On a side note, since we have this /opt/omni directory with all these libraries installed, does this mean the previous admin installed them here from source? Because installing from the repo would place them in /usr/bin like it has on my new OEL server? For the record they exist in both places on the old server from what I can tell.

/opt/omni/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6

Though I think the only reference to libstdc++.so.6.0.14 is the link I mention above.

FYI: RHEL5 & 6 (and OEL5 & 6) used a 2.6.x kernel so it was relatively easy for us to get Oracle products from 5 to work on 6 doing what I mentioned in previous post. RHEL7 (and OEL7) is based on a 3.x kernel and relies upon systemd rather than init so is quite different. Not saying you can't get it working but it will likely be harder which is why we didn't try to go to 7 with our older Oracle application/DB migration.

/opt/omni is not a standard system directory so it is likely your previous admin added it.

The link you show:
libstdc++.so.6 -> libstdc++.so.6.0.14
Has no path on the right side of the arrow so it means it links to a file in the same directory (presumably /usr/lib based on the rest of your post).

If the /opt/omni/lib64/libstdc++.so.6 is not showing as a link as well then I'd say it was installed in /opt/omni (or copied). You could run cksum on that and the /usr/lib/libstdc++.so.6.0.14 to see if they're the same (i.e. copies of each other). Copying a symbolic link by default creates a hard file rather than another link.

Originally Posted by MensaWater FYI: RHEL5 & 6 (and OEL5 & 6) used a 2.6.x kernel so it was relatively easy for us to get Oracle products from 5 to work on 6 doing what I mentioned in previous post. RHEL7 (and OEL7) is based on a 3.x kernel and relies upon systemd rather than init so is quite different. Not saying you can't get it working but it will likely be harder which is why we didn't try to go to 7 with our older Oracle application/DB migration. /opt/omni is not a standard system directory so it is likely your previous admin added it. The link you show: libstdc++.so.6 -> libstdc++.so.6.0.14 Has no path on the right side of the arrow so it means it links to a file in the same directory (presumably /usr/lib based on the rest of your post). If the /opt/omni/lib64/libstdc++.so.6 is not showing as a link as well then I'd say it was installed in /opt/omni (or copied). You could run cksum on that and the /usr/lib/libstdc++.so.6.0.14 to see if they're the same (i.e. copies of each other). Copying a symbolic link by default creates a hard file rather than another link.

This was solved with the soft links I created. Thanks again for your help. The funny thing is oracle documentation says the older client supports newer packages but the install scripts have the library version hard coded...

Originally Posted by toledotown The funny thing is oracle documentation

Don't get me started on Oracle documentation.

One of my favorite things about their documentation is that it will give you OS tuning parameters (based on the system they did their test install upon rather than any rational equation of data to parameter sizing). You dutifully set the values they provide in the document then during the install the OUI tells you that those parameters are wrong and gives you completely different values than the document.

Even worse is I've found one parameter that they apparently change when they start the software after initial install and of course that new value is completely different than the documentation AND the OUI.

On the plus side their error codes usually lead to easy searching for others who have found and fixed similar issues.