Podman build http_proxy=false for remote client causes issues when using the api

[komima]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

podman build defaults to http-proxy=false if remote, and the behaviour seems to not be configurable in any other place than the cli flag podman build --http-proxy to re-enable it.

This causes issues when using for example docker-compose with podman machine npipe api, which otherwise works fine, but builds are broken due to the build not having proxy variables set, and there not being any way (config files, env vars, etc.) to force the http_proxy option back to true, other than using plain manual podman builds with the cli flag before compose up.

For now pulls (uses proxy env vars) and runs (container has proxy env vars set) work fine, but builds do not due to this special default-false option. Its unclear if this is intended behaviour, or should the behaviour be in line with the other commands? At least there could be a way to configure this somehow via env vars or a config file, since all podman build commands ran against a certain podman machine must include the --http-proxy flag.

Steps to reproduce the issue:

1. Be behind a corporate proxy.
2. Run podman build from Windows for a Containerfile that has for example a RUN yum install step, which needs internet access and needs to go through the proxy.

Describe the results you received:

Install hangs for a while and timeouts due to the connection not using the proxy.

Describe the results you expected:

Install succeeds.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.3.0
API Version:  4.3.0
Go Version:   go1.18.7
Git Commit:   ad42af94903ce4f3c3cd0693e4e17e4286bf094b
Built:        Wed Oct 19 20:53:21 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.3.0
API Version:  4.3.0
Go Version:   go1.18.7
Built:        Fri Oct 21 11:16:35 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.4-3.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: '
  cpuUtilization:
    idlePercent: 97.52
    systemPercent: 1.16
    userPercent: 1.32
  cpus: 2
  distribution:
    distribution: fedora
    variant: container
    version: "36"
  eventLogger: journald
  hostname: 842W6S2
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.4.72-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 2347945984
  memTotal: 8346796032
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.6-2.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 2147483648
  swapTotal: 2147483648
  uptime: 5h 31m 22.00s (Approximately 0.21 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 3
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 269490393088
  graphRootUsed: 3139219456
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 34
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.0
  Built: 1666340195
  BuiltTime: Fri Oct 21 11:16:35 2022
  GitCommit: ""
  GoVersion: go1.18.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.0

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman-4.3.0-2.fc36.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Windows WSL2 podman machine

[komima]

I tested this a bit more, it seems a similar problem exists on the WSL2 distro side as well.

If the unix socket api is used (for example with docker-compose binaries), and proxy variables are necessary for containers to access the internet, either --build-arg & --env can be used to pass the variables manually (for build and run, respectively), or containers.conf env can be used to provide variables automatically for run containers, but not for build.

What is interesting is that pulling seems to work fine, i.e. a Containerfile that is just FROM some-image & RUN echo $no_proxy built via docker-compose build --pull fetches the image fine but prints nothing, no idea where the its proxy setup comes from.

Could a separate configuration key be added in containers.conf for build_env?

This way the configuration file can provide kind of "this is what's needed by default to access the network" baseline to anything built or run on the system via env & build_env.