Legacy Packages in current RHEL 7.5

Latest response

Hello Community,

i am new to RHEL and apologize in advance for my lack of knowledge of the ecosystem.

is it possible or at all supported to use RPMs of earlier Versions of RHEL?

i.e. for a reimplementation i need apache/httpd 2.2 - from https://access.redhat.com/solutions/445713 i can see it is available in RHEL 5, which itself is already in ELP
https://access.redhat.com/support/policy/updates/errata/

is there a different generic best practice for legacy-package-requirements without also forcing legacy RHEL i am missing?

Cheers,
David

Responses

Hi David,

First of all, there's no reason to apologize, everyone (including me) was a "newbie" when starting with something new. :)
Now to your question : Generally it is possible to install older RPM packages manually on newer Red Hat based systems.
Now the but : If it works properly or not depends on whether the package meets all requirements (called dependencies).

Red Hat also provides the possibility to use "Software Collections", where you can use application versions side-by-side.
My personal recommendation is to not downgrade packages, because it may break other parts of the operating system.
Best would be, you read some documentation, search through knowledgebase articles, and then start to try things out.

Regards,
Christian

Completely agree with Christian.

David, what is it that causes you to wish to have a degraded version of httpd? Is there some reason why you can't configure a current version of httpd to support your needs? Are you chained to some software version due to some 3rd party or a vendor who is providing support?

Please give us more details (if possible, if you are not restricted from doing so) regarding the basis for you seeking a degraded version. Perhaps we can help you with configurations etc with more specifics.

Added, you will be inheriting possibly insufferable security risks with some older versions of httpd, by the way.

Regards,

-RJ

Thanks for adding the (extremely important) security aspect, RJ ... I forgot to mention it in my response. :)

Regards,
Christian

Hello and thanks to you both for your prompt responses,

as you may suspect, i would like to spare you, me, and a public forum as many unnecessary details as possible. suffice it to say all the classical preconditions leading to such a scenario apply. the primary goal is a "functional" re-implementation of a legacy LAMP (rehl5.?,apache2.2.?,mysql5.5,php5.4/5.3) for "some" version of typo3.

the basic idea is to re-implement as is - as a "last known good", and again with what should be serviceable, compare differences and either go with serviceable, or try known upgrade-paths to get as close as possible within the given time frame.

if possible i would like to try and cut out the OS (or at least try to reduce the probability of interference, if i only resolve the packages dependency-chains) as part of that process to reduce variance and time hence my question.

thank you for pointing out the security-aspect, naturally its low priority relative to a functional solution is part of the "classical" scenario mentioned above.

Thank you for your time,

Cheers, David

Hi Team

I have some queries 1-Still, why we're using LEGACY for RHEL, If it runs with UEFI what will be the problem 2-Why we're disabling secure boot while using RHEL,

Fazil-- your questions are completely unrelated to this 2-year old topic about 'glibc', so you should start a new topic in the discussion groups for best results.

That said, there is no reason not to use UEFI booting if your hardware supports it and you want to. We have both laptop machines and production data center server hardware booting RHEL 7.x and 8.x in UEFI mode.

I have no experience with secure boot mode; we do not have a requirement for it, so we have generally left it at the hardware & software defaults (off).