I'm helping a developer setup a RHEL 6.4 system for an application that he is building.

Unfortunately in order to get this app to work correctly, it needs a number of packages that are newer then what comes with the install ISO.

My original plan was to create a local repo and install those packages, however that won't work.

I'm not sure what the best solution would be for this? Would setting up a Container with a RHEL OS that has the correct packages, which would get build in production, however we want to do all of this testing in development, in order to get this back in production.

Would this be the correct use of a Container in this situation?

Hopefully what I'm asking makes sense.

I have used OpenVZ containers (host at RHEL-6 with guest container CentOS-7) for this kind of development. An LXC container should work just as well and does not require changing to OpenVZ (as LXC support is in the kernel upstream). If you mean a KVM container, while heavier and less efficient that should serve just as well. Even VirtualBox or VMWARE (although quite slow ) would work for this.

You have, in fact, MANY solutions that do not require messing with your RHEL-6 supported packages and putting your server into an unsupported state.

I would create a CentOS-7 development container to compile your packages, and test there first. Static compile might be advisable if the package must work on multiple versions/releases. (Note the advantages and disadvantages, and perhpas leave that to your developers judgment.)
Then migrate it to the test server and hammer it there before migrating it to production.

Just my $0.02 UDS worth.

3 members found this post helpful.

You migth also want to consider docker.

You've been given good advice here by wpeckham, and I concur totally with it.

RHEL 6.4 is old..the latest is 7.x, so if this is, as you say, a new RHEL system for developing an application, why on earth would you start with an old OS with old packages? And unless you're paying for RHEL, you are in for problems too. You won't get any updates/patches/bug fixes/security fixes unless you do purchase a subscription. And for development...CentOS is totally free, and IDENTICAL to RHEL, so there's no benefit to using RHEL without paying.

You could 'container' this app, sure...but then you're only going to be asking any potential end-user to install the container apps/libraries to get things to work, as opposed to just saying "here's a list of supported OS versions". Installing your package after that with any package manager (zypper, yum, apt-get), will then also shove on any missing packages from the native repositories.

Just my $0.02 worth...better to build it right to start with, than to try to shoehorn it in with 'workarounds'.

2 members found this post helpful.

The app currently works with RHEL 6.4. However we are testing it along with other Python 2.7 packages/libraries so that it will work a newer version of RHEL6. We have to work with the vendor on this. However I'm trying to speed up the deployment of this along with learning about Containers and what my options are for this.

RHEL 6.4 is supported till 2020 and we have a current subscription with Red hat.

Thank you, I do appreciate when someone knowledgeable supports my advice.I was not talking about developing his app as a container, but compiling it for RHEL7/CentOS7 IN a container. Not an app container, but a full distro container. This can be easily done using LXC and its tools, or OpenVZ and its tools, and is easier and lighter than using a full virtual using XEN, VMWARE, KVM, or Virtualbox and results in executables that will run on any RHEL7 compatible system: physical or virtual.

I apologize for not making that clear in the earlier post.

1 members found this post helpful.

No worries, you were clear, but the OP originally mentioned a container at the start. Wasn't sure which kind (VM or something like Docker) they meant.

RHEL 6.4 is not supported til 2020. The EUS (Extended Update Support) for RHEL 6.4 ended in March, 2015.

A standard subscription entitles you to updates for the current update level. It doesn't allow you to stay on a specific update unless you purchase an EUS as an add-on. A premium subscription includes EUS, but it doesn't extend the support time frame for an EUS.

So, unless you have a special contract with Red Hat for support well beyond the EUS date, you don't have a support for that version.