Using a container to download needed content files for iop

Background

iop services require security content files to be downloaded and made available locally to the services that need them. The first of these was the cvemap.xml. See cvemap downloader. This method supports disconnected by allowing a user to download the file themselves in put it in a well known location.

Limits of this design:

• The download timer service is always running in connected and disconnected modes
• Downloader scripts live in the foremanctl repository
• The scripts run on the host itself

Design

Here is roughly the setup I envisioned, with these benefits:

• More clearly defined deployment -- connected vs. disconnected
• Leans into our architecture of running as containers
• Turns the downloader scripts and idea into a true code repo

Connected

1. A container exists that contains a unified download script
2. A timer exists that executes a container via a quadlet
3. That container has a podman volume mounted to it and puts the files in that container
4. The iop-gateway also mounts the same volume and serves the files

Disconnected

1. foremanctl is ran with a --air-gapped or --disconnected flag
2. The existence of this flag prevents deployment of the download service, thereby saving resources and avoiding a service that could try to reach out to the internet.
3. The iop-gateway mounts the podman volume and serves the files.
4. The user places each file that was downloaded into the podman volume to be picked up by the gateway.

Start with docs/iop.md and the existing CVE map downloader to understand the current content-download flow. Then trace how foremanctl deploys iop services and how the proposed quadlet, container, and Podman volume would connect to iop-gateway. Done means connected deployments use the containerized downloader while air-gapped or disconnected deployments omit it and still allow files in the shared volume.