Firewall permissions for rpm-ostree updates

When I have installed a system with Fedora CoreOS and later want to do updates with rpm-ostree in an environment with restricted Internet access, what minimum permissions must I give to the CoreOS systems on the firewall e.g. what do these need to have access to on the Internet? Is this documented somewhere? I have searched but not found …
Especcially, when rpm-ostree would freely select a mirror, this can become complicated, right?

You need to give rpm-ostree access to and to Fedora mirrors if you use package layering. If you want to be more restrictive, you can select a specific mirror and fix it in the /etc/yum.repos.d/*.repo files where you have metalink entries (you will have to give access to updates-archive's baseurl URL too).

So I have to

  • select a mirror
  • put it into the baseurl= line and make this active
  • comment out the metalink line
    Is this right?
    Looks like some reasearch/guessing is needed for the fedora-cisco-openh264 repo.

That looks right to me. You can get URLs from the metalink files themselves. Since you mentioned the fedora-cisco-openh264 we can use that one as an example:

$ curl -L '' 
<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="" type="dynamic" pubdate="Mon, 19 Jul 2021 18:16:42 GMT" generator="mirrormanager" xmlns:mm0="">
  <file name="repomd.xml">
    <hash type="md5">81793dd5390625969f20f209a3b6fed6</hash>
    <hash type="sha1">059f88f3bdb83e93adcd6bff6045b8b2c7f0edb3</hash>
    <hash type="sha256">c146666f611d5a0bb21d80f35c7b3dedda94f084d1821e3b792207df5300913f</hash>
    <hash type="sha512">0edde2da38b499c03742b79722f26d947f11b6a08bf5ef376c95a9ea2379b9a048cd8213a246b46b408a126fa603d04fc6cb33b2fd8245273dc85d6f63fa3cd1</hash>
   <resources maxconnections="1">
    <url protocol="https" type="https" location="US" preference="100"></url>

So you should be able to use something like baseurl=$releasever/$basearch/os/.

The questions around the rpm-md repos apply to everything that uses dnf/yum (including traditional systems, as well as containers, etc.).

Part of the point of metalink files is that the implementation can change over time. (Mirrors can come and go, etc.)

The most robust method is to have automation that automatically and periodically fetches the metalink files, parses them, and adds those entries to the allowlist - not just a one time thing.

Alternatively, instead of proxy filtering go fully disconnected, with an update mirror server.