[OLD docker] untergeek/curator `missing signature key` on server

[sastorsl]

Expected Behavior

That docker run untergeek/curator should start curator.

Actual Behavior

On RedHat Enterprise Linux 7 (RHEL7) getting the curator docker image fails:

Command:

docker run --rm untergeek/curator:8.0.3

output:

Unable to find image 'untergeek/curator:8.0.3' locally
Trying to pull repository untergeek/curator ... 
/usr/bin/docker-current: missing signature key.

Running the same on i.e. Ubuntu 22.04 LTS works as expected, so I expect that it is an issue with the version of RHEL7 docker.

Steps to Reproduce the Problem

1. Configure docker on RHEL7
2. Try and start undergeek/docker

Specifications

• Operating system: Red Hat Enterprise Linux Server release 7.9 (Maipo)

Docker version, is the bundled docker version for RHEL7

Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-209.git7d71120.el7_9.x86_64
 Go version:      go1.10.3
 Git commit:      7d71120/1.13.1
 Built:           Fri Jan  7 13:15:46 2022
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-209.git7d71120.el7_9.x86_64
 Go version:      go1.10.3
 Git commit:      7d71120/1.13.1
 Built:           Fri Jan  7 13:15:46 2022
 OS/Arch:         linux/amd64
 Experimental:    false

Context (Environment)

One of our elasticsearch / kibana / logstash (ELK) platforms runs on RHEL7, and we use (used) curator to manage indices.
Since the upgrade to ELK-8 curator has not worked with the old version of curator.

Detailed Description

It would be great if the docker build could support all major versions of the underlying docker client / server versions.

[untergeek]

I can't do that. It's not that I'm being dogmatic about it so much as the requirement to make and release both amd64 and arm64 packages in the same manifest requires me to use much newer versions. My Docker build process won't even build on 20.10.23 (see #1672) leave alone 1.13.1 or I would recommend doing the Docker build yourself and pushing to your own local repository.

I'd be happy to coach you through a few edits to the Dockerfile so you can build your own using 1.13.1 if you like. Even that process is tuned for multi-architecture builds and will not work out of the box with 1.13.1.

[sastorsl]

I understand.

With this issue others can at least find the reason for it, and the decision behind it.

I'll be AFK for a couple of weeks now but I'm very interested in building since we won't be sunsetting that solution anytime soon.

Should we follow up in this issue?

[untergeek]

Indeed. Any solution we can provide here will be of use to anyone else in the same situation.

[sastorsl]

Linking the Dockerfile here: https://github.com/elastic/curator/blob/master/Dockerfile

Would one need to fork your repo with the appropriate changes to Dockerfile, or can one take your image and "re-shape" it in some way?

[untergeek]

I will likely create a gist that you can use as a drop in replacement to start.

[sastorsl]

Did you get around to doing that gist?

[untergeek]

I have been out of office for family matters for most of the time we've been discussing this. I haven't had a chance yet.

[untergeek]

https://gist.github.com/untergeek/00dcb3f64cb0afa2f8fd194e9a5856d2

I can build and run Curator as a Docker image now in RHEL 7.9. I tested against an instance in Elastic Cloud and it works. That said, it is not a painless process, nor a quick fix.

Caveats include:

• A lot of extra work to make a build possible (OpenSSL 1.1.1, Python, etc.). Fully explained in the gist.
• Much larger image size as the concept of builder is not available in 1.13.1 (450MB vs 16.25MB). What this really means is that I have to build Curator and run it from the same Docker image, complete with all of the necessary Python files and dependencies, rather than just the executable and necessary libraries/dependencies. It's not a small difference.
• Requires the use of the --privileged flag to read configuration files
• Could be other things I haven't encountered yet.

[untergeek]

Note that the addition of OpenSSL 1.1.1t will not impact the rest of the system as I chose to install it at /opt/openssl.