Issues with RPM installs/upgrades

Latest response

Hello red Hat SME's... I am at the end of my rope and looking for some assistance. I'm working on some prm upgrades and installs for a DISCONNECTED system and so i have to manually copy the rpm's over as needed.

Certain packages (dhclient, dhcp-common, dhcp-libs, bind-export-libs to name a few) (as well as bind, bind-libs, bind-libs-lite, bind-license, bind-utils, bind-export-libs…) are all erroring out for a dependency stating they need libcrypto.so.1.1 (note the '1.1' there) and other .so files that I cannot seem to find. I have libcrypto.so.10 which i got from openssl-libs-1.0.2k-19 but for some reason i cannot find/download the 1.1 version? Can anyone help me find where I can download it or what rpm it might be included with? My searches are coming up empty or unsuccessful and I am at the end of my rope and tired of all these manual transfers only to find it still not working. I've got a bunch of ACAS HIGH findings that are pointing to a need to update some of these RPM's but im just not able to do so until I locate that dependency.

thanks in advance

Responses

Where are you getting your packages from? The standard dhcp packages for RHEL7 (eg. dhcp-libs-4.2.5-77.el7.x86_64) are linked against /lib64/libcrypto.so.10 so you may be trying to install dhcp packages that aren't compatible with RHEL7

hi thanks! ive either downloaded them the long way from the rpm package search page or we have one connected repo server that talks directly to rh and I just yum install --downloadonly and grab them that way. Note I also edited my above post I am trying to install a number of bind related packages as well that are all bombinb out looking for various .so files

Could you give the full file name from one of the rpms you are trying to install, eg. for dhcp-libs?

bind-9.9.4-74.el7_6.1 bind-libs-9.9.4-74.el7_6.1 bind-utils-9.9.4-74.el7_6.1 dhclient-4.2.5-77.el7 dhcp-libs-4.2.5-77.el7

You are mixing RHEL 7.6 and RHEL 7.7 packages but that isn't necessarily bad. Could you post the full error message?

so unfortunately wit) this being a closed system i cant get the exact errors off due to them bring just way too long to manually reproduce which i realize complicates this

basically at this point ive got 2 ACAS findings that I am trying to remediate. One is for BIND (Rhel 7: BIND (RHSA-2019:1294)(125590). The other is for DHCP (RHEL 7 DHCP (RHSA-2018:1465)(109842)

so ok so ACAS says I am running version 9.9.4-38.el7_3.2 but should be running 9.9.4-74.el7_6.1. SO ok i try to yum install that version that it wants and i get a laundry list of dependency errors. Says it needs bind-libs-9.9.4-74.el7_6.1 which i do in fact have in my repo ironically nut also a list of .so files (liblwres.so.90, libisc.so, libisc.so....) So i go in and try to yum install bind-libs first and it says a number of things will or should be updated like bind-libs, bind-libs-lite, dhclient, bind-export-libs, dhcp-common, dhcp-libs etc which leads me to believe a lot of these are intertwined here. also says bind-export-libs requires libcrypto.so.1.1 and libcrypto.so.1.1(openssl_1_1_)…

long story short i have no idea what to do to get these packages installed and get past these errors and ive been fighting with it for days on end now....

the biggest kicker is i don't even think we have/use/need bind or dhcp on the servers that ACAS is complaining about... not 100% sure on that but that's my guess

Brian-- This presents quite a challenge (as network-disconnected systems often do). Fundamentally, you are going to have a difficult time dealing with dependency resolution unless you can find a way to make the entire "current" RHEL 7 (7.7 as of today, maybe 7.6 EUS if you need to hold the system in question back to the older release?) repository available to the disconnected server(s). Depending on the size of your environment, a disconnected Satellite server might work. Or you could simply 'reposync' the entire current RHEL 7 (-server, -optional, -extras) repo set onto a USB hard drive & sneakernet it to the isolated systems.

Another option might be to simply remove the 'bind' package from the system in question - then, presumably it won't show a vulnerability to DDoS attacks on the 'named' process, since /usr/bin/named won't exist. bind-libs will still be present, as it is required by dhclient (and you may not be able to remove dhclient due to other dependencies) - but getting rid of 'bind' and any other non-essential packages will reduce the number of packages you need to juggle to patch security issues.

A final option might be to argue with the security folks that the particular vulnerability fixed in the bind-9.9.4-74.el7_6.1 package doesn't apply to a system that cannot be attached to the internet (probably won't fly, but you might be able to get an exemption for it).