Update Dockerfiles

[jan-cerny]

We have Dockerfiles in this repository to build various containers with OpenSCAP, either packages or from git. They are outdated and very different from what is used in registry.access.redhat.com/rhel7/openscap. I think that for testing and development it would be beneficial to have a Dockerfile that will build an image that is very similar to registry.access.redhat.com/rhel7/openscap, but with fresh OpenSCAP daemon from upstream git.

Maybe we could remove current Dockerfiles.

[shawndwells]

On 6/6/17 7:50 AM, Jan Černý wrote: We have Dockerfiles in this repository to build various containers with OpenSCAP, either packages or from git. They are outdated and very different from what is used in |registry.access.redhat.com/rhel7/openscap|. I think that for testing and development it would be beneficial to have a Dockerfile that will build an image that is very similar to |registry.access.redhat.com/rhel7/openscap|, but with fresh OpenSCAP daemon from upstream git. Maybe we could remove current Dockerfiles.

.... there are OpenSCAP container images in Red Hat's registry?! What are they used for? Better yet.... where is the documentation on what OpenSCAP Daemon is? I know work was happening on GitHub... never heard this was shipping!

[mpreisler]

where is the documentation on what
OpenSCAP Daemon is?

There is https://github.com/OpenSCAP/openscap-daemon/blob/master/README.md

openscap-daemon is used for atomic scan feature. Only a small subset of what openscap-daemon can do is used in production today.

[jan-cerny]

There are multiple solutions:

• Keep the current directory structure in atomic and atomic-git. Update all current Dockerfiles, add all the files. However I'm afraid that there will be a lot of duplicates.
• Remove the atomic and atomic-git. Make a new directory, that would contain Dockerfile and other files. We can copy-paste that registry.access.redhat.com/rhel7/openscap
• Make a script that would create a Dockerfile and all the files and eventually build the image. It could be parametrizable, so the user could choose base image, versions of packages (usptream/distro), etc.

The goal that I want is to be able to easily test the upstream Daemon together with Atomic. I think that it could be also an upstream for registry.access.redhat.com/rhel7/openscap

Any opinions?

[jan-cerny]

I use now this workflow: I have a Dockerfile locally, I have ./build.sh and it creates a Fedora based image, with fresh upstream OpenSCAP Daemon. The image is tagged openscap:testing, then I just change the image name in /etc/atomic.d/openscap and Atomic uses it instead of registry.access.redhat.com/rhel7/openscap automatically. This seems really easy and works OK so far.

Are we insterested to include something like that into upstream?

What about my suggestions from the previous comment?

[jan-cerny]

I have opened a thread on the mailing list to affect more people.
https://www.redhat.com/archives/open-scap-list/2017-June/msg00009.html

[jan-cerny]

What about using S2I for build directly from source? https://docs.openshift.com/enterprise/3.2/creating_images/s2i.html#creating-images-s2i

[jan-cerny]

Fixed in #106