Frustration with Support model/RPM versioning of updates

Latest response

[N.B.: My name isn't 'William Stromberg'. 3 of us share this account; he is the Contracts contact person, so his name is on it.]

I work at a U.S. Government facility that requires us to lock down and "freeze" some of our Linux environments.

As a result, right now we are a shop that is mostly RHEL 5.4, a few RHEL 5.10, a few RHEL 6.3 and some RHEL 6.5 systems (plus a couple of RHEL 7.0 sandboxes).
We are constrained to these choices and upgrading to 5.11 or 6.6 is not an option for us.

I was tasked with upgrading Java in our environment by adding Java 1.7.

(We also have Solaris 10 systems and we'd like to have matching versions if possible.)

I discovered that there are the separate "Thirdparty Oracle Java" RHN channels available so I added them.

When I looked to see what was available for, say, 32-bit RHEL 6.3 and 6.5, I'm presented with these choices:

java-1.7.0-oracle-1.7.0.15-1jpp.1.el6_3:1.i686 Oracle Java Runtime Environment

java-1.7.0-oracle-1.7.0.17-1jpp.1.el6_4:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.21-1jpp.1.el6:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.25-1jpp.2.el6_4:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.45-1jpp.2.el6_4:1.i686 Oracle Java Runtime Environment

java-1.7.0-oracle-1.7.0.51-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.55-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.65-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment

java-1.7.0-oracle-1.7.0.72-1jpp.2.el6:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.75-1jpp.1.el6:1.i686 Oracle Java Runtime Environment

This underlines something that really bothers me about the current Red Hat support model.

It seems like in general, RPM updates are only produced for the current OS release that is out at the time.

That pretty much screws those of us who can't run 5.11 or 6.6 or 7.0.

Yet there are a few cases - like with 1.7.0_21, 1.7.0_72 and 1.7.0_75 here - where it looks like that 'policy' isn't the case.

Those 3 RPM names are 'generic' and don't indicate what OS they were built on. I presume it's an older version than the current one.

(I don't understand why this policy isn't consistent. Why not always put the OS version into the RPM name, or else why not build all versions against an older revision? Pick one, please.)

So if I'm sitting here wanting to upgrade Oracle Java on one of my 6.3 systems, which version do I choose?

Do I choose 1.7.0_15, because I know it was built on RHEL 6.3?

Or do I choose 1.7.0_75, because the RPM name says "el6" and not "el6_6", so maybe it was built against an older version like 6.3 - or even earlier?

Similarly for RHEL 5.x. The 1.7.0_72 and 1.7.0_75 RPMs were built on RHEL 5.11. Do I dare install 1.7.0_75 on 5.10 and pray it doesn't break? What about on RHEL 5.4?

Or do I fall back to the 'safe' 1.7.0_65 that I know was built on 5.10 and will be compatible with it? Similarly for 5.4 - do I use the 'safe' 1.7.0_21?

Before someone says "Oh, you can install any of these on any RHEL 5/6.x machine!", I don't believe it.

Why? Because I took the most recent "Critical" Firefox 31.5.0 release - built on 5.11 - and rebuilt the SRPM on 5.10. That worked.

But when I tried to rebuild the exact same SRPM on 5.4, it failed in at least 3 places. So what will happen when the compiled 5.11 binaries run those same bits of code on 5.4 that builds on 5.10 and 5.11, but does not build on 5.4? I'd expect "undefined behavior" at best, and a crash at worst.

I never assume backwards compatibility with binaries. So I would not install a RHEL 5.11-built RPM on a 5.4 system, much less a 5.1.

I would really appreciate someone (preferably from Redhat) straightening this out for me.

Thanks in advance,

Greg

WS
Log in to join the conversation

Responses

Radek Bíba's picture Red Hat Guru 1517 points
9 March 2015 1:26 PM

Greg,

The package NVRs don't contain the RHEL X.Y version that they were built on for two reasons:

1 - The packages aren't really built by Red Hat. The binaries are complied by Oracle, and Red Hat only does the packaging part. If you had the spec file, you would see that it just instructs rpmbuild to extract the upstream tarball and distribute the files across the file system appropriately.
2 - You can install and run the JDK on any RHEL version. Oracle links the binaries with libraries that are generally present everywhere.

In conclusion, you can safely assume backwards compatibility. If you cannot install the packages because yum/rpm complains about missing dependencies, or if you can install them but the binaries won't run due to missing library symbols, let me know and I'll try to figure out where the problem might be.

Radek

WS Active Contributor 119 points
9 March 2015 1:44 PM

Thank you Radek!!! That is a big help. I am being pressured to make a decision very quickly here.

If I may, can I ask if you know anything more about the "%dist" value issue I brought up in these RPMs?

I cannot understand why the 2 most recent versions are ".el6" on RHEL 6 but they are ".el5_11" on RHEL 5:

java-1.7.0-oracle-1.7.0.75-1jpp.1.el6:1.{i686,x86_64}.rpm

java-1.7.0-oracle-1.7.0.75-1jpp.1.el5_11.{i586,x86_64}.rpm

This is something that just confuses me in general (not just for Java), as I stated in my OP.

I realize from what you are saying that this is a special case, i.e. that you are just re-packaging Oracle's binaries. But if that is the case, then why wouldn't all of the Java RPMs released up to date (since the first 1.7.0_N versions) just be using "el5" or "el6" for %dist", rather than the OS revision-specific tags like "el5_11" or "el6_6"?

Radek Bíba's picture Red Hat Guru 1517 points
9 March 2015 4:22 PM

You're welcome. The dist tag isn't used very consistently with these package, which is something for our packagers to think about, but in general it can be ignored. The original intention was to ensure a correct upgrade path from RHEL X.Y Extended Update Support to Y+1 even in the cases where the version and release don't change, but that's not applicable here. Feel free to use the latest available build of java-1.7.0-oracle, and if you want, file a bug against the package for the inconsistent values of %dist.

WS Active Contributor 119 points
9 March 2015 7:25 PM

Thanks. Can you clarify "but in general it can be ignored" - do you mean specifically for these Oracle Java packages, or in general? Because I have tried to (as I said in my OP) (re)build SRPMs with "el5_11" or "el6_6" %dist tags on 5.4 or 6.3 systems and they've failed.

BTW, I tried the Java 1.7.0_75 RPMs on RHEL 5.4, and at first they demanded unixODBC-devel and unixODBC-libs; since the -libs didn't exist until RHEL 5.8 it wanted to update unixODBC and unixODBC-kde to the latest versions.

Instead I installed the same version of unixODBC-devel as the 5.4 unixODBC base RPM and once I did that, the dependency upon unixODBC-libs magically disappeared. So I was happy with that outcome :)

--

One last side-issue: how to I download the RHEL 7 versions? We have 4 test sandbox RHEL 7 systems; it seems like all of them got Subscription Manager enabled by default. (We do Kickstart installs and we like to have the most important stuff in our own local yum repo available at install time - we can't depend on the system being registered and having RHN available during installs.)

With my RHEL 5 & 6 systems I can just come here to RHN, go to Downloads and do a Package Search and find them easily - but the RHEL 7 versions never come up, despite having the channel (rhel-7-workstation-thirdparty-oracle-java-rpms) enabled on the RHEL 7 systems.

Radek Bíba's picture Red Hat Guru 1517 points
10 March 2015 8:56 AM

The dist tag can be ignored in the case of the Oracle Java package because there are no separate (and different) builds for the individual Y-streams. Otherwise, it's another string in the Release field and RPM does not ignore it.

AFAIK, none of the java-1.7.0-oracle (sub)packages requires unixODBC-libs, and they should all be installable on older Y-stream versions of RHEL 5. I don't have RHEL 5.4 here because it's no longer supported, but I have 5.6 "Long Life", and RPM seems happy with java-1.7.0-oracle-1.7.0.75-1jpp.1.el5_11.x86_64.rpm and its subpackages.

It's strange that the packages for RHEL 7 can't be found in the web UI. That looks like a bug. Anyway, you can still use "yumdownloader java-1.7.0-oracle" on the systems to get the package, right?

WS Active Contributor 119 points
10 March 2015 4:25 PM

Radek,

It's "java-1.7.0-oracle-jdbc" that requires unixODBC. I can't tell you why it wanted unixODBC-libs. It wanted to update unixODBC-2.2.11-7 to unixODBC-2.2.11-10 across the board for all 4 of the unixODBC-related RPMs.

Also, I just realized this - Oracle makes 'generic' RPMs for Java 1.7 and Java 1.8; but Red Hat only offers 1.8 for RHEL 6 (and, presumably, RHEL 7) in the rhel-${ARCH}-client-${OS}-thirdparty-oracle-java channel.

Is there a reason why there are no RHEL 5 versions of Java 1.8? My Systems Engineer is clamoring for me to install the generic Oracle version now, because 5.10 is now our new baseline and he wants to do development work with Java 1.8. The Oracle versions don't play nice with the "alternatives" stuff, and it's more work for me to figure out how to get them to work with that system ...

Thanks for the tip about "yumdownloader" - I've never used it before, so I'd forgotten it existed!

Radek Bíba's picture Red Hat Guru 1517 points
10 March 2015 4:52 PM

The unixODBC package was split into the main package and -libs in RHEL 5.8, yes. So if your system is missing unixODBC completely and tries to install the latest version, or if it sees the new version-release as an update, it will try to pull in the -libs subpackage. Anyway, an older version should be fine.

I don't know why there's no custom java-1.8.0-oracle package for RHEL 5. That would be a question for product management. Technically, however, it is possible that the binaries in the upstream tarball are too new. This is what I got when I tried to install the RHEL-6 package on a RHEL-5 system, in addition to unsatisfied requirements of a newer RPM:

libgio-2.0.so.0()(64bit) is needed by java-1.8.0-oracle-1.8.0.31-1jpp.1.el6.x86_64
libc.so.6(GLIBC_2.11)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libc.so.6(GLIBC_2.7)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libc.so.6(GLIBC_2.8)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libgio-2.0.so.0()(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libstdc++.so.6(GLIBCXX_3.4.11)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libstdc++.so.6(GLIBCXX_3.4.9)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxml2.so.2(LIBXML2_2.4.30)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxml2.so.2(LIBXML2_2.6.0)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxml2.so.2(LIBXML2_2.6.6)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxslt.so.1(LIBXML2_1.0.11)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxslt.so.1(LIBXML2_1.0.22)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxslt.so.1(LIBXML2_1.0.24)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
libxslt.so.1(LIBXML2_1.1.9)(64bit) is needed by java-1.8.0-oracle-javafx-1.8.0.31-1jpp.1.el6.x86_64
WS Active Contributor 119 points
10 March 2015 5:49 PM

That's very interesting. Why do you think that is? Have you looked at the Oracle RPMs themselves? One thing that fascinated me was how they distribute RPMs that are only differentiated by architecture (and version as in 1.7/1.8), not by OS.

My first thought - before Red Hat galloped in to save me - was "How am I going to be able to install the same set of RPMs on RHEL 5/6/7? How can they work on 3 different OSes?".

So I installed the Oracle 1.8 on a 5.4 machine and the Red Hat Oracle 1.8 on a 6.5 machine, and looked at the two biggest binaries ("javaws" and "jmc"):

[root@rh54x32 RPMS]# ls -l /usr/java/jdk1.8.0_31/bin/{javaws,jmc}
-rwxr-xr-x 1 root root 108381 Dec 17 21:11 /usr/java/jdk1.8.0_31/bin/javaws
-rwxr-xr-x 1 root root  20873 Dec 17 21:11 /usr/java/jdk1.8.0_31/bin/jmc

[root@rh65x32 RPMS]# ls -l /usr/lib/jvm/java-1.8.0/bin/{javaws,jmc}
-rwxr-xr-x 1 root root 109083 Dec 17 21:05 /usr/lib/jvm/java-1.8.0/bin/javaws
-rwxr-xr-x 1 root root  63050 Jul  8  2014 /usr/lib/jvm/java-1.8.0/bin/jmc

If it's just a simple RPM repackaging, why are the binaries different?

Next I did an "ldd" on "javaws"; the Oracle binary depends on "libXdmcp.so.6" whereas the Red Hat Oracle binary depends on "libxcb.so.1". (All other library dependencies are the same.) I can't explain that one. Maybe an inferred dependency? (No libxcb in RHEL 5)

Last but not least, I did a "strings" on each "javaws" binary. The generic Oracle binary is first; the Red Hat Oracle binary is second:

[root@miplvm-rh65x32 tmp]# diff -rC 0 javaws_strings_RHEL5+Oracle+Java1.8.txt javaws_strings_RHEL6+Java1.8.txt 
*** javaws_strings_RHEL5+Oracle+Java1.8.txt  2015-03-10 10:45:13 -0700
--- javaws_strings_RHEL6+Java1.8.txt    2015-03-10 10:44:46 -0700
***************
*** 32 ****
--- 33 ----
+ applicationIcon.c
***************
*** 44 ****
--- 46 ----
+ base64.c
***************
*** 86 ****
--- 89,90 ----
+ configcache_pd.c
+ configurationFile.c
***************
*** 98 ****
--- 103 ----
+ crtstuff.c
***************
*** 149 ****
--- 155 ----
+ dialogutils.c
***************
*** 269 ****
--- 276 ----
+ expirationdialog.c
***************
*** 606 ****
--- 614,615 ----
+ jfx_runtime.c
+ jfx_runtime_md.c
***************
*** 626 ****
--- 636,637 ----
+ launcher.c
+ launcher_md.c
***************
*** 627 ****
--- 639 ----
+ launchFile.c
***************
*** 684 ****
--- 697 ----
+ msgString.c
***************
*** 759 ****
--- 773 ----
+ propertyParser.c
***************
*** 814 ****
--- 829 ----
+ secureArgs.c
***************
*** 879 ****
--- 895 ----
+ splashFile.c
***************
*** 882 ****
--- 899 ----
+ splash_md.c
***************
*** 1015 ****
--- 1033 ----
+ system.c
***************
*** 1016 ****
--- 1035 ----
+ system_md.c
***************
*** 1121 ****
--- 1141 ----
+ util.c
***************
*** 1130 ****
--- 1151 ----
+ versionId.c
***************
*** 1141 ****
--- 1163 ----
+ webstartblockdialog.c
***************
*** 1153 ****
--- 1176 ----
+ xmlparser.c

Where are these extra file references coming from, in the Red Hat version?

Radek Bíba's picture Red Hat Guru 1517 points
11 March 2015 9:18 AM

Which JDK version do you have? I was looking at 1.8.0_31 as we have in RHEL 6. Oracle now has 8u40, and I'm not sure where to get 31 from (or why we haven't updated the packages to 40 yet), so I can't really compare the binaries. Anyway, there's a difference between the way Oracle and Red Hat creates the RPM packages. Although the tarball is the same, our packages contain real dependencies of all the binaries and shared objects. So, although it is possible to install the upstream RPM on RHEL 5, I'm afraid some parts of the JDK won't run. Here's an example:

ldd /usr/java/jdk1.8.0_40/jre/lib/amd64/libglass.so
...
libgio-2.0.so.0 => not found

(In RHEL 6, libgio-2.0.so.0 is part of glib2 2.28.) Or:

ldd /usr/java/jdk1.8.0_40/jre/lib/amd64/libjfxwebkit.so
/usr/java/jdk1.8.0_40/jre/lib/amd64/libjfxwebkit.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/java/jdk1.8.0_40/jre/lib/amd64/libjfxwebkit.so)

Radek Bíba's picture Red Hat Guru 1517 points
11 March 2015 3:52 PM

As for the differences, could it be prelink? Here's what I got:

]# ll javaws.*
-rwxr-xr-x 1 uucp 143 109083 Dec 18 00:05 javaws.ora
-rwxr-xr-x 1 root root 110855 Mar 11 11:45 javaws.rh
]# prelink javaws.ora
]# ll javaws.*
-rwxr-xr-x 1 uucp 143 110855 Dec 18 00:05 javaws.ora
-rwxr-xr-x 1 root root 110855 Mar 11 11:45 javaws.rh

(javaws.ora was taken from jdk-8u31-linux-i586.tar.gz)

WS Active Contributor 119 points
17 April 2015 6:28 PM

Radek,

A followup post: today we got an Errata pushing out 1.8.0_45:

RHSA-2015:0854 Critical: java-1.8.0-oracle security update

The RPMs are named

java-1.8.0-oracle-1.8.0.45-1jpp.2.el6_6.i686.rpm
java-1.8.0-oracle-1.8.0.45-1jpp.2.el6_6.x86_64.rpm

So, while I still hate these "OS-specific" %dist things (i.e. ".el6_6"), at least now they're the same :-)

Radek Bíba's picture Red Hat Guru 1517 points
20 April 2015 6:34 AM

Yeah, now it looks consistent. Thanks for sharing the update.

WS Active Contributor 119 points
20 April 2015 8:48 AM

Consistency is a good first step. Now if only those "_6"'s would disappear ;-)

PS Guru 6494 points
20 April 2015 11:23 PM

I have a similar complaint regarding the RHEL version suffix on packages, namely sssd. If you look at the SSSD changelog, the changelog version doesn't match the package name version because the RHEL version is being added (inserted) to the package name... why is this?

eg.

Package: sssd-1.11.6-30.el6_6.4.x86_64.rpm
Changelog: 1.11.6-30.4

Why is this not expressed in the following way if Red Hat are appending RHEL version numbers (ie. why is the revision not appended to the version rather than after el6_6?

sssd-1.11.6-30.4.el6_6.x86_64.rpm
Radek Bíba's picture Red Hat Guru 1517 points
21 April 2015 6:52 AM

You're right that the NVR in the changelog rarely matches the actual package NVR with the dist tag. I've noticed that some package maintainers use it in the changelog, but most don't. Here's an exception (libcurl):

* Thu Jan 15 2015 Kamil Dudka <kdudka@redhat.com> 7.19.7-40.el6_6.4
- do not crash if MD5 fingerprint is not provided by libssh2 (#1008178)

* Mon Dec 01 2014 Kamil Dudka <kdudka@redhat.com> 7.19.7-40.el6_6.3
- fix occasional SIGSEGV during SSL handshake (#1169357)

I guess the reason is, in theory, you can have a single source RPM (with a hardcoded changelog) and build it for multiple EUS/Z streams. Then the only difference is the dist tag in the "release" part of the NVR. So if the changlog contained a particular unconditional dist tag, it would then be the same in all those EUS/Z streams, which would be wrong. Or worse, if the dist tag was written conditionally, it would change with every rebuild; IOW, when we move to the next stream, historical records in the changelog would change.

PS Guru 6494 points
22 April 2015 12:56 AM

Thanks for the response Radek,

Changelog aside, why is the ".4" in the example put after the RHEL release (6_6).
ie. why is it:
sssd-1.11.6-30.el6_6.4.x86_64.rpm

and not (notice .4 is placed after 30, which is where it should be to make up the version number)
sssd-1.11.6-30.4.el6_6.x86_64.rpm

When moved, the version matches the changelog version. The RHEL release (if added at all) should be a suffix that is added after the version and before the arch. As it stands, it appears to be wedged into the version/release.

Radek Bíba's picture Red Hat Guru 1517 points
22 April 2015 7:52 AM

You're welcome. The number behind the dist tag differs if it's a subsequent build for the same version-release.zstream. So instead of increasing 30 to 31, we bump the very last suffix. This makes sure the NVR is higher in this Y-Stream (6.6) while remaining lower than a potential next Y-Stream update with its own Release: number.

ir. Jan Gerrit Kootstra's picture Guru 6222 points
9 March 2015 7:43 PM

Hello Greg,

If you need RHEL 5.4, RHEL 6.5 or any non current minor release specific rpms you need ELS or EUS support.
These are extra subscriptions.

Most Red Hat maintained products are supported under ELS and EUS. I do not know about the Oracle third party java rpms.

Contact your Red Hat reseller, Red Hat distributor or Red Hat sales (which apply) about ELS or EUS subscriptions and the support for Oracle/Sun java..

So updating to the current minor release or Red Hat Enterprise Linux is not always needed.

Kind regarsds,

Jan Gerrit Kootstra

WS Active Contributor 119 points
9 March 2015 8:27 PM

Hoi Jan,

What is the difference, in practice, between ELS and EUS? (Yes I know it's Lifetime vs. Update)

Are those the products that I recently saw where it claimed that support was being dropped in 6 months?

"In accordance with the Red Hat Enterprise Linux Errata Support Policy, Extended Update Support for Red Hat Enterprise Linux 6.3 will be retired as of June 30, 2014". That doesn't sound very "Extended" to me.

The announcement also urges EUS customers to upgrade to a newer 5.x or 6.x release, according to the "Red Hat Enterprise Linux Errata Support Policy". (Whoever wrote that 'policy' has never dealt with the U.S. Space Program. It's a Bizarro World with words like "freeze" and "multi-year missions". We serve multiple masters and can only move forward to match the slowest foot-dragger. The MER project - the 2 Mars Exploration Rovers - only upgraded and baselined on RHEL 5.7 in the last year!)

Also, we run some 6.3 and some 6.5 machines. EUS for 6.3 is already expired!

The last (most recent) EUS for RHEL 5 is based on RHEL 5.9. We run 5.4 and 5.10. We don't have a say in this. Again EUS is useless in this instance.

If security bugfixes come out for perennial problem children like OpenSSL or PHP or Apache, I need a version that will run on 5.4 (actually, we're finally starting our 5.4 -> 5.10 upgrade cycle, so mercifully this will be short-lived - but I've been dealing with this for a few years now). I end up trying to rebuild the latest SRPM and praying it will compile and work.

Also, when we first installed these OSes I 'm not sure these "Extended" products existed (for that particular release). In other words I don't know how to handle this sort of scenario:

We are running on some version of RHEL N. Then RHEL N+1 comes out, and eventually (possibly up to 2 years later!) our customers finally say "We need it" and then they baseline (and freeze) on version RHEL N+1.X.

So we install RHEL N+1.X on all of these machines, they stay there and eventually, RHEL N+1.X is ancient history and it seems we should have been using RHEL ELS/EUS all along, except that back when we installed RHEL N+1.X, it was just using our normal RHEL Workstation licenses and ELS/EUS probably wasn't relevant at the time.

Is the solution to inquire about adding ELS/EUS on as soon as a machine is upgraded? (I hope certain dot-dot releases aren't skipped, like EUS did during RHEL 5.x.)

Not to go too far off-topic, but I find this whole thing VERY confusing. Far too many offerings and variants to understand :(

ir. Jan Gerrit Kootstra's picture Guru 6222 points
9 March 2015 10:42 PM

Hoi Greg,

EUS => Extends a minor release. 5.x, 6.x
ELS => Extend the last minor release after the "version" is out of support, like 4.9 since the end of support of RHEL 4.

I understand your feeling about the time period that a EUS support is usable for a minor release.
I cannot do anything about that.

I work for an advanced partner in Europe, not for Red Hat.

If you have a Satellite server, EUS appears as a couple of RHEL ... 6.x.z base channel after you update the Satellite certificate.

here a snippet from my satellite-sync -l output


17:37:06 . rhel-x86_64-server-6.0.z 4151
17:37:06 . rhel-x86_64-server-6.1.z 5819
17:37:06 . rhel-x86_64-server-6.2.z 7545
17:37:06 . rhel-x86_64-server-6.3.z 9198
17:37:06 . rhel-x86_64-server-6.4.z 11447
17:37:06 . rhel-x86_64-server-6.5.z 13151
17:37:06 . rhel-x86_64-server-6.6.z 14622

and a list of RHEL 6.6.z subchannels will look like this:

17:37:09 rhel-x86_64-server-6.6.z:
17:37:09 . rhel-x86_64-server-6.6.z-debuginfo 5920
17:37:09 . rhel-x86_64-server-6.6.z-thirdparty-oracle-java 257
17:37:09 . rhel-x86_64-server-dts2-6.6.z 469
17:37:09 . rhel-x86_64-server-dts2-6.6.z-debuginfo 37
17:37:09 . rhel-x86_64-server-ha-6.6.z 454
17:37:09 . rhel-x86_64-server-ha-6.6.z-debuginfo 198
17:37:09 . rhel-x86_64-server-lb-6.6.z 48
17:37:09 . rhel-x86_64-server-lb-6.6.z-debuginfo 27
17:37:09 . rhel-x86_64-server-optional-6.6.z 8673
17:37:09 . rhel-x86_64-server-optional-6.6.z-debuginfo 3621
17:37:09 . rhel-x86_64-server-rs-6.6.z 482
17:37:09 . rhel-x86_64-server-rs-6.6.z-debuginfo 214
17:37:09 . rhel-x86_64-server-sfs-6.6.z 46
17:37:09 . rhel-x86_64-server-sfs-6.6.z-debuginfo 18
17:37:09 . rhel-x86_64-server-sjis-6.6.z 6
17:37:09 . rhel-x86_64-server-sjis-6.6.z-debuginfo 4
17:37:09 . rhel-x86_64-server-supplementary-6.6.z 480
17:37:09 . rhel-x86_64-server-supplementary-6.6.z-debuginfo 18
17:37:09 . rhn-tools-rhel-x86_64-server-6.6.z 170
17:37:09 . rhn-tools-rhel-x86_64-server-6.6.z-debuginfo 4

be aware end of support does not mean, end of availability.
and critical CVE' vulnerabilities may still be patched. Like some patches for RHEL 4.9 this quarter.

Kind regards,

Jan Gerrit

WS Active Contributor 119 points
9 March 2015 10:49 PM

Thanks Jan. That is helpful information to know. We have our own custom local yum repo but the more I see things that don't work too well, the more I am thinking maybe we need to run our own Satellite. I don't know how much that costs, however.

WS Active Contributor 119 points
9 March 2015 10:51 PM

Oh, a question for you - I see you are running Server. We are running Workstation. Do you think all the same 6.n.z sub-channels have an equivalent Workstation version?

ir. Jan Gerrit Kootstra's picture Guru 6222 points
10 March 2015 12:08 AM

Greg,

As our customers do not use Workstation I did not order the EUS and/or ELS channels for our test and production Satellite.

Do not ask me for prices, please for Government agencies in the US can get special offers from Red Hat sales or their Red Hat partner. The prices on shop.redhat.com might cause confusion.

We are an European Datacenter specialized Partner so we use a sales model that does not apply to you.

Kind regards,

Jan Gerrit Kootstra

ir. Jan Gerrit Kootstra's picture Guru 6222 points
10 March 2015 12:28 AM

If you have not got a Red Hat partner yet, http://redhat.force.com/finder/ can be used to find one.

WS Active Contributor 119 points
10 March 2015 4:27 PM

Jan,

We have a Red Hat partner, En Pointe Technologies Sales, they handle all our current licenses :)

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.