-
Story
-
Resolution: Done
-
Major
-
RH134 - RHEL 8.2 1 20200928
-
None
-
ROLE
-
en-US (English)
URL: https://rol.redhat.com/rol/app/courses/rh134-8.2/pages/ch13s13
Reporter RHNID: ctiwary@redhat.com
Section: containers-lab - Lab: Running Containers
Language: en-US (English)||||||||
Workaround:
Description: In rh134-8.2, ch13s13: Procedure 13.6 Instruction 2 tl;dr: It would be helpful if the training suggested to "ssh as the non-root user that will be running the rootless podman and skopeo commands, as opposed to becoming said user using sudo or su" The solution describes "ssh podsvc@serverb", "podman login", "skopeo inspect" This works, but other logical solutions do not work, and there is no warning in the course about the other solutions not working, or a preference for this given solution. In particular, my natural inclination was to "ssh student@serverb", "sudo su - podsvc", "podman login ...", "skopeo inspect ...". The effect of my steps is an error during "skopeo inspect", apparently because skopeo does not see the registry login. escalating/becoming the user with any incantation of sudo i, sudo su, su -, etc seems to make no difference in the final result. The proximal cause of this error has itself been reported as a skopeo bug https://githubmate.com/repo/containers/skopeo/issues/1240?page=2 The ultimate cause seems to be that skopeo has a hard dependency on systemd user/dbus session, and that is invoked through ssh>pam login and not sudo/su. I think that the presence/absense of the environment variable XDG_RUNTIME_DIR predicts the behavior. Summary: It would be helpful if the training suggested to "ssh as the non-root user that will be running the rootless podman and skopeo commands, as opposed to becoming said user using sudo or su"