Creating unprivileged container for outdated centos 7 distribution

1

I need to get my hands on an unprivileged container of an outdated centos 7 distribution. I’m wondering what would be the best/simplest/most clever/efficient way to achieve that. It does not show up on the list of currently available images so I am prepared to be doing it by myself.
My thougths/understanding so far:

  • distrobuilder is probably the tool of choice
  • i will need the installation .iso (no problem, those have been archived and are available)
  • I will probably need something else (yaml file?)

I’d like to get some hints or pointers/opinions on what ‘tech’ to aim for:

  • should I use LXC?
  • or incus?
  • or docker? (I know that’s the other camp…)
  • something else?

Is there something in particular I should be aware of? Where to get those yaml-files?

Thanks in advance.

2

So you just need to find a container image of Centos 7.

The best that https://images.linuxcontainers.org/ can do, is Centos 9-Stream.

However, the distrobuilder configuration file for Centos can be found here, and if you go back in history, you can checkout a version of that file that produces a Centos 7 image. Here you go, History for images/centos.yaml - lxc/lxc-ci · GitHub

You can generate container images for both Incus and LXC, including VM images. Obviously you may need to adapt URLs that point to legacy Centos versions.

3

To run CentOS 7 CTs on Incus your host node needs to use CGroups v1, whereas most OS’s have since long switched to CGroups v2.

Trying to run CentOS 7 CTs via Incus on modern host nodes is possible (if you switch them to us CGroups v1), it is really a step backwards that cause issues with modern CTs you might want to run, too. Because you can only have one or the other.

Using a VM instead will be a lot less involved. Something like this may perhaps work:

incus create centos7vm -c limits.cpu=4 -c limits.memory=4GiB -c security.secureboot=false -d root,size=50GiB --empty --vm
incus config device add centos7vm vtpm tpm
incus config device add centos7vm install disk source=/path/to/CentOS-7-Minimal.iso boot.priority=10
incus start centos7vm
sleep 5s
incus console centos7vm --type=vga
1 Like
4

Does this hold true for lxc as well?

5

Yes, it’s not related to the container runtime.

6

I used to be running CentOS 7 on lxc on a CGroups v2 host only in the past, though in a degraded mode(which would still be fine with me). While systemd(1) was running, pretty much all of the rest of systemd like systemctl, Dbus,… was not. However this still used to do the trick for me. The proprietary cs app I need to use requires CentOS 7(libs, tools,… at a particular version) but does not seem to care about systemd being operational.

So I would like to recreate that state from a fresh start - with incus or lxc. I believe CentOS provides archives with their discontinued os versions.

Unfortunately a vm is no option at the moment due to severely restricted memory and storage constrains. I still appreciate your hint on this as it might become useful in the future.

On a second thought: I don’t really need systemd to be running(or do I?). What I need is:

  • provide a CentOS 7 environment for my cs app
  • have the CentOS 7 package management system (yum/dnf in this case) functional
  • grant access to it to some distinct folders in the file system
  • isolate it from the host’s network

If running my app in such an environment could work without systemd, I don’t need it.

7

CentOS 7 simply has no future. It’s dead and buried and should be left to rot. I did have a few CentOS 7 still running in our org until three months ago due to an oversight. Until one of them got thoroughly rooted by not just one, but two vulnerabilities in its included OpenSSH (password auth was off, key based auth on).

I’d rather suggest to explore alternatives. Like how to run your application on something else hat still has some life left. Or adapting the application to run in a more modern environment. Or make ends meet in the middle and you use a still supported OS and bend the environment into shape to run the older stuff you need.

For example: Our webhosting control panel for EL8 and EL9 has every PHP version from PHP-5.6 up to the latest PHP-8.4 covered. Users can pick pick the poison that suits their needs. There is always the odd website that refuses to run on something modern and it would be inconvenient or too much hassle to bring it forward. On EL10 we currently cover PHP-7.3 all the way up to the latest PHP-8.4. This is done by installing older libraries (OpenSSL, libxml, libzip, libiconv and a few other odds and sods) out of the way of the OS provided versions and linking the ancient software we need against those older libraries.

While it is not exactly wise or risk free to side-load a modern OS with outdated software for specific legacy tasks? It is perhaps a better alternative than trying to drag the corpse of an EOL OS way past the finishing line.

Sure, what I suggested above requires some effort. But right now you’re also looking at pushing a square peg into a round hole by trying to bend an Incus node so out of shape that it can do what you want.

Just my view of things. YMMV.

And yes: Sometime early last year I also got as far with CentOS 7 on Incus that Init would fire up - but not much else. That’s when I dug into the Cgroup issue. And decided (just for myself) that it wasn’t worth it to cripple a node by switching it to Cgroups v1 just to be able to run legacy OS’s in CTs.

8

I appreciate your input and I agree about pretty much everything you pointed out. However that is not the point.

The point is that I have that one old close source app (that I bought a license for a long time ago) and I need it to get running. It has been compiled for Centos 7 (well RedHat do be precise) and it has a lot (in the hundreds at least) dependencies on several (many) libs and tools with particular and very specific versions. (I tried to inject those libs/tools into a modern distribution. After the 50th lib done and getting another weird error about unmet dependencies, I gave up and decided to follow a different path.)

CentOS 8 or 9 do not meet those specific version requirements. It needs (the app requires it) to be specifically CentOS 7.
I don’t need it to be future proof. It won’t be used to run or develop anything current or new. It does not need to be fully functional, no need for ssh, syslog, systemctl, d-bus,… As long as that one da** app runs, I’m fine.
A vm would certainly do the trick, as suggested above, but memory and storage are scarce on that particular host machine I need it to run.

So yes, it is a special and probably rare use case. The requirements are rather specific, I know. But future proofness and security are not among them (it does not need to and won’t be exposed to any kind of networking, just local file access).

Kay