Replies: 1 comment
-
|
Update: looks like there is an authentication issue: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
💻 Environment
Host OS: macOS
Container Runtime: Podman Desktop (using a Podman Machine which runs Fedora CoreOS)
Networking: Corporate network requiring an SSL-intercepting HTTPS proxy (running on the macOS host).
Task: Building a container image (fails on the initial FROM line).
🎯 Problem Statement
I am unable to build an image because the initial FROM command fails to resolve and download the base image (opensearchproject/opensearch:3.2.0) from Docker Hub. The error is a network I/O timeout, which is often a masked SSL/TLS error when using an intercepting proxy.
💥 Error Details (During podman build / make start):
failed to solve: DeadlineExceeded: opensearchproject/opensearch:3.2.0: failed to resolve source metadata for docker.io/opensearchproject/opensearch:3.2.0:
failed to do request: Head "https://registry-1.docker.io/v2/opensearchproject/opensearch/manifests/3.2.0": dial tcp [IP Address]:443: i/o timeout
✅ Configuration & Verification Steps Completed
I have verified the following inside and outside the Podman Machine VM:
Proxy Configured & Connectivity Confirmed:
Configuration: The proxy environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) are set in the host's ~/.config/containers/containers.conf file, pointing to the host machine using the internal DNS name (host.containers.internal:8080).
Verification: I SSHed into the VM and successfully used curl to reach an external HTTPS site through the host proxy, confirming network and proxy forwarding are working:
Bash
Inside the VM:
curl -x http://host.containers.internal:8080 https://google.com
-> Returns a successful response (200).
Corporate Root CA Trust Installed:
The full corporate Root CA certificate chain was installed into the VM's system trust store, followed by a system update:
Bash
Inside the VM:
sudo su -
cp my-proxy-ca.pem /etc/pki/ca-trust/source/anchors/
update-ca-trust
exit
The Podman Machine was fully stopped and restarted afterward.
Registry-Specific CA Attempted:
As a backup, I also copied the CA certificate to the registry-specific path within the VM and restarted the machine:
Bash
Inside the VM:
/etc/containers/certs.d/registry-1.docker.io/ca.crt
❓ Specific Question for the Community
Given that the underlying Fedora CoreOS VM can successfully use the proxy and trusts the CA certificate for manual curl requests, why is the image resolution/pull process handled by Buildah (or Podman's pull logic) still failing with a timeout on the FROM line?
Does the Buildah process used by Podman Desktop for image building employ a separate certificate store or network configuration logic that does not fully inherit the standard Fedora CoreOS trust store?
Are there any known issues where the initial FROM resolution fails to correctly use the proxy environment variables, even when they are set in containers.conf?
Is there a Podman Desktop setting or diagnostic log (beyond the VM) that could help confirm if the proxy variables are correctly injected into the build command itself?
Thank you for any insight or alternative debugging steps!
Beta Was this translation helpful? Give feedback.
All reactions