Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman fails to download a image through redirect urls #15187

Open
rahulguptajss opened this issue Aug 4, 2022 · 7 comments
Open

podman fails to download a image through redirect urls #15187

rahulguptajss opened this issue Aug 4, 2022 · 7 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@rahulguptajss
Copy link

rahulguptajss commented Aug 4, 2022

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

/kind bug

Description

podman fails to pull an image through a redirect repo. Docker works just fine.

Steps to reproduce the issue:

1: Running below command fails with error.

Command:

podman --log-level=debug pull cr.netapp.io/harvest:latest

Error:

DEBU[0000] GET https://cr.netapp.io/v2/ DEBU[0002] Ping https://cr.netapp.io/v2/ status 401 DEBU[0002] GET https://netappdownloads.jfrog.io/artifactory/api/docker/oss-docker/v2/token?scope=repository%3Aharvest%3Apull&service=netappdownloads.jfrog.io DEBU[0004] GET https://cr.netapp.io/v2/harvest/manifests/latest DEBU[0005] Content-Type from manifest GET is "application/json;charset=ISO-8859-1" DEBU[0005] Accessing "cr.netapp.io/harvest:latest" failed: reading manifest latest in cr.netapp.io/harvest: unauthorized DEBU[0005] Error pulling candidate cr.netapp.io/harvest:latest: initializing source docker://cr.netapp.io/harvest:latest: reading manifest latest in cr.netapp.io/harvest: unauthorized

  1. Command docker pull cr.netapp.io/harvest:latest works fine.

  2. If I use the URL which cr.netapp.io redirects to with podman then it works fine. Below command works.

podman pull --log-level=debug netappdownloads.jfrog.io/oss-docker-harvest-production/harvest:latest

Describe the results you expected:

podman should be able to download docker image for redirect URLs.

Output of podman version:

podman version 4.1.1

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.2
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - rdma
  cgroupManager: systemd
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.29-1.module+el8.4.0+11822+6cc1e7d7.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: ae467a0c8001179d4d0adf4ada381108a893d7ec'
  cpuUtilization:
    idlePercent: 99.9
    systemPercent: 0.04
    userPercent: 0.05
  cpus: 1
  distribution:
    distribution: '"rhel"'
    version: "8.4"
  eventLogger: file
  hostname: scspo2401522001.nb.openenglab.netapp.com
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 4.18.0-305.19.1.el8_4.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 6548082688
  memTotal: 8146239488
  networkBackend: cni
  ociRuntime:
    name: runc
    package: runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.x86_64
    path: /usr/bin/runc
    version: |-
      runc version spec: 1.0.2-dev
      go: go1.15.13
      libseccomp: 2.5.1
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,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: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.module+el8.4.0+11822+6cc1e7d7.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.1
  swapFree: 0
  swapTotal: 0
  uptime: 5295h 21m 45.55s (Approximately 220.62 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 161049718784
  graphRootUsed: 5457260544
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.1.1
  Built: 1657551413
  BuiltTime: Mon Jul 11 20:26:53 2022
  GitCommit: ""
  GoVersion: go1.17.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.1

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

podman-4.1.1-2.module+el8.6.0+15917+093ca6f8.x86_64
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 4, 2022
@vrothberg
Copy link
Member

Thanks for reaching out, @rahulguptajss!

@mtrmac FYI

@mtrmac
Copy link
Collaborator

mtrmac commented Aug 9, 2022

This seems related (but the information above is not enough to tell for sure) to containers/image#641 . Follow the chain of links of PRs etc. for the full discussion. IIRC it’s a set of fairly subtle behaviors and interactions — still, something we should fix.

@rahulguptajss
Copy link
Author

rahulguptajss commented Aug 10, 2022

@mtrmac Yes #641 is the same issue as this.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Jul 30, 2023

@mtrmac @vrothberg was this ever fixed?

@vrothberg
Copy link
Member

No, containers/image#64 is still open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

4 participants