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

Label io.containers.autoupdate.authfile is no-longer effective #11171

Closed
mavit opened this issue Aug 9, 2021 · 1 comment · Fixed by #11357
Closed

Label io.containers.autoupdate.authfile is no-longer effective #11171

mavit opened this issue Aug 9, 2021 · 1 comment · Fixed by #11357
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@mavit
Copy link
Contributor

mavit commented Aug 9, 2021

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

/kind bug

Description

I have several containers with io.containers.autoupdate.authfile labels. These labels no-longer seem to be taken into account by podman auto-update.

Steps to reproduce the issue:

  1. Have containers with systemd services that start them with options --label=io.containers.autoupdate.authfile=/path/to/authfile.json.
  2. Supply credentials to podman login --authfile=/path/to/authfile.json ...
  3. Run sudo podman auto-update, or wait for podman-auto-update.timer.

Describe the results you received:

$ sudo podman auto-update
Error: 2 errors occurred:
        * error registry auto-updating container "87f7fd97f440f17efd343eff365e6e44bfb26aeaf97477301581464c63d98911": image check for "registry.gitlab.com/mavit/example1:master" failed: Requesting bear token: invalid status code from registry 403 (Forbidden)
        * error registry auto-updating container "b0ff3da9a393405fe64acc3c53dcde995145027972097bd4e1b564e385a5e15d": image check for "docker.io/mavit/example2:latest" failed: Error reading manifest latest in docker.io/mavit/example2: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

Describe the results you expected:
The registries can be reached, and the containers are updated.

Additional information you deem important (e.g. issue happens only occasionally):
This can be worked around by using the --authfile argument to podman auto-update (but that's not much help to podman-auto-update.timer).

Output of podman version:

Version:      3.2.3
API Version:  3.2.3
Go Version:   go1.16.6
Built:        Mon Aug  2 20:39:21 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.21.3
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 1
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: eddiemouse.ovh.mavit.org.uk
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.13.8-200.fc34.x86_64
  linkmode: dynamic
  memFree: 270266368
  memTotal: 2011521024
  ociRuntime:
    name: crun
    package: crun-0.20.1-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/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: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 2010640384
  swapTotal: 2011164672
  uptime: 11m 2.03s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 3
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 6
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.2.3
  Built: 1627933161
  BuiltTime: Mon Aug  2 20:39:21 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.2.3

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

podman-3.2.3-2.fc34.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/master/troubleshooting.md)

Yes

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 9, 2021
@Luap99
Copy link
Member

Luap99 commented Aug 10, 2021

@vrothberg PTAL

vrothberg added a commit to vrothberg/libpod that referenced this issue Aug 30, 2021
Make sure that the container's authfile label is used when pulling down
a new image.

[NO TESTS NEEDED] since it would require some larger rewrite of the
auto-update system tests that I currently have no time for.  I added a
reminder to have some breadcrumbs when there is more time.

Fixes: containers#11171
Signed-off-by: Valentin Rothberg <[email protected]>
vrothberg added a commit to vrothberg/libpod that referenced this issue Sep 10, 2021
Make sure that the container's authfile label is used when pulling down
a new image.

[NO TESTS NEEDED] since we need to add authfile tests to the main
branch.

Fixes: containers#11171
Signed-off-by: Valentin Rothberg <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants