shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day
"man podman-build" suggests that the context argument is optional:
SYNOPSIS
podman build [options] [context]
podman image build [options] [context]
...
If no context directory is specified, then Podman will assume
the current working directory as the build context, which
should contain the Containerfile.
but if i have a directory with nothing but a Containerfile, i get:
$ podman build
Error: no context directory specified, and no containerfile specified
$
OTOH, specifying context of current directory:
$ podman build .
STEP 1: FROM alpine:latest
... etc etc ...
thoughts?
rday
7 months, 1 week
rootless podman, docker-credential-gcloud, and snaps
by Ioan Rogers
Hi,
I'm on Ubuntu, and I've recently encountered an issue when trying to use rootless podman with the docker-credential-gcloud helper installed via snap.
This works fine when using the official google-cloud-sdk apt packages, and it used to work with snap packages until last October.
Here's what I see now:
```
$ podman pull gcr.io/private/image
Trying to pull gcr.io/private/image...
2021/02/01 13:19:17.474248 cmd_run.go:994: WARNING: cannot create user data directory: cannot create "/root/snap/google-cloud-sdk/166": mkdir /root/snap: permission denied
cannot create user data directory: /root/snap/google-cloud-sdk/166: Permission denied
error getting credentials - err: exit status 1, out: ``
Error: unable to pull gcr.io/private/image: Error initializing source docker://gcr.io/private/image:latest: error getting username and password: error getting credentials - err: exit status 1, out: ``
```
So it looks like the credential helper is being executed as root now. I'm not sure in which component the problem lies, or where I should file an issue.
Any pointers would be appreciated.
Thanks
Ioan Rogers
Sent with ProtonMail Secure Email.
4 years
Permissions on top level of mounted volume in rootless container
by Peter Upfold
Hello,
I'm struggling a little with the permissions set on the top level
directory of a volume that is mounted in a rootless container.
My Containerfile:
https://gist.github.com/PeterUpfold/2f63ad5341ffd9079bc2683a5bb2744c
The top level directory of the volume mount,
/var/www/html/websites/windows, ends up with root:nobody and 0755
permissions inside the container.
I've seen similar issues on this list: Daniel Walsh's suggestion of
`--annotation run.oci.keep_original_groups=1` seems to work beautifully
to change the ownership of the volume folder in the container to be
windowsnoob:windowsnoob, as I would want it, _if_ I'm doing `podman run`.
However, I'm trying to create a pod as follows. Is it possible to have
this permissions configuration work in this scenario?
podman pod create -n windowsnoob -p 8081
podman build -t windowsnoob-fpm .
podman create --name windowsnoob-fpm --pod windowsnoob -v
/var/www/html/websites/windows:/var/www/html/websites/windows:Z,noexec,nodev,rw
windowsnoob-fpm
podman pod start windowsnoob
At the moment, doing this and checking the permissions on the
/var/www/html/websites/windows volume in the created container (via
`podman exec -it [container] bash`) still shows the following:
drwxr-xr-x. 2 root nobody 28 Feb 14 09:45 windows
(Note that I can write to a subfolder already owned by
windowsnoob:windowsnoob _inside_ the volume just fine — I don't believe
this is an SELinux issue, or a permissions issue on anywhere except the
top level of the volume mount!)
Thank you for any insight you might be able to provide!
Peter Upfold
4 years, 3 months
image signing
by Hendrik Haddorp
Hi,
is OpenPGP the only supported image signing open supported by podman /
skopeo or are there other options? Using OpenGPG works quite fine for me
so far but in the end we are trying to sign an image using an IBM 4765
crypto card and so far have not figured out how this can play together.
thanks,
Hendrk
4 years, 3 months
Macvlan
by Rusty Sapper
I’m having trouble setting up a macvlan. I created my config under
/etc/cni/net.d and can successfully start my continater with the macvlan
network.
However, when I exec into the container, it has no network access to
anything except itself. I apologize, I'm new to podman. I need to be able
to ssh into other hosts(jenkins nodes) to run tests. I am unable to use
the host network due to other requirements.
Any help would be appreciated. here is my macvlan config:
{
"cniVersion": "0.4.0",
"name": "testmac1",
"plugins": [
{
"type": "macvlan",
"master": "eno1np0",
"ipam": {
"type": "host-local",
"routes": [
{
"dst": "0.0.0.0/0"
}
],
"ranges": [
[
{
"subnet": "10.89.0.0/24",
"gateway": "10.89.0.1"
}
]
]
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
~
4 years, 4 months
Pushing image tagged with multiple tags to remote repo with the same digest
by Marcin Zajączkowski
Hi. I might miss something obvious - I don't have deep knowledge about
containers, however, trying to migrate my docker-in-docker image
building CI job to buildah, I've encountered the following problem.
My image should be tagged with its real version and in addition with a
special marker tag (such as "devel" or "stable" or "latest"). It seems
to be a common practice with images. While in docker, I could just call:
> docker build -t "$CI_REGISTRY_IMAGE:$VERSION" -t "$CI_REGISTRY_IMAGE:$MARKER_TAG"
> docker push $CI_REGISTRY_IMAGE"
with buildah, it is more problematic as I cannot use multiple tags on
push (--all-tags switch has been also abandoned).
I tried:
> buildah bud -t "$CI_REGISTRY_IMAGE:$VERSION" -t "$CI_REGISTRY_IMAGE:$MARKET_TAG"
> buildah push "$CI_REGISTRY_IMAGE:$VERSION" "$CI_REGISTRY_IMAGE:$VERSION"
> buildah push "$CI_REGISTRY_IMAGE:$MARKET_TAG" "$CI_REGISTRY_IMAGE:$MARKET_TAG"
but while "buildah images --digests" shows the same digest for those two
tags, in the remote repository (GitLab CI container repository) these
tags have two different digests (also both differ from the local one). I
suspect there could be something changed in the manifest.
Q. How can I have one image (with one digests) tagged multiple times in
a container repository using buildah?
buildah version 1.18.0 (image-spec 1.0.1-dev, runtime-spec 1.0.2-dev) on
Fedora 33.
Marcin
P.S. I've seen https://github.com/containers/buildah/issues/2034, but I
don't know if it is related.
4 years, 4 months
OCI runtime error when starting hub.docker.com/r/rocker images as non-root - how to troubleshoot?
by boardbill_unpretended＠simplelogin.co
Dear Podman list,
I am just starting to dip my toes into running containers in Podman 2.2.1 on RHEL 8.3 (Linux kernel 4.18) and would appreciate guidance on how to diagnose and solve an error I get when running as non-root.
My goal is to do R language development in containers, and I used `podman pull` to get these R images from the popular Rocker project (https://www.rocker-project.org/):
https://hub.docker.com/r/rocker/r-base
https://hub.docker.com/r/rocker/tidyverse
https://hub.docker.com/r/rocker/rstudio
The `r-base` image is just the R interpreter and it starts fine where I can just attach it to a terminal to run R commands.
However, the other images (`tidyverse` and `rstudio`) are built on top of `r-base` and when I run them as non-root (e.g. `podman run -ti rocker/tidyverse`) they give this error:
```
Error: OCI runtime error: container_linux.go:370: starting container process caused: process_linux.go:459: container init caused: Running hook #0:: error running hook: exit status 1, stdout: , stderr:
```
I have no idea how to interpret and understand this error message. The only clue I have is that these two images run without errors if I append `sudo` to my `podman run` command. I also checked the Dockerfiles (such as this one: https://github.com/rocker-org/rocker-versioned/blob/master/tidyverse/3.6....) and it's not clear what might be giving the error.
Oh, and the `rocker/rstudio` image allows you to specify ports i.e. `-p 8787:8787` but even if I leave out this argument, I still get the error above when running `podman run` on this image. So I don't think it's an issue with opening or mapping ports (and Podman allows this as non-root, right?).
How should I begin to diagnose the root of this problem and start fixing it?
To be clear, my goal is to run the images listed above ideally as a non-root user. Thank you!
4 years, 4 months
OCI permission denied
by lejeczek
Hi guys.
Here are errors from my unsuccessful attempt to create a
rootless container, which to novices such as myself are
quite cryptic:
-> $ podman run -d --restart=always
--pod=jat-${HOSTNAME%%.*} --security-opt label=disable
--volume /srv/containers/podmania/jat-redis:/data --name
redis docker.io/library/redis
ERRO[0000] error starting some container dependencies
ERRO[0000] "container_linux.go:370: starting container
process caused: process_linux.go:459: container init caused:
rootfs_linux.go:59: mounting \"sysfs\" to rootfs at \"/sys\"
caused: operation not permitted: OCI permission denied"
Error: error starting some containers: internal libpod error
I'm trying to drop the container into a pod which is
rootless too. The error persist also with/in 'Permissive'
selinux.
Somebody could help decrypt & troubleshoot this?
I'm on Centos Steam with:
podman-3.0.0-0.33rc2.module_el8.4.0+673+eabfc99d.x86_64
many thanks, L.
4 years, 4 months
Re: OCI permission denied
by Scott McCarty
We believe it's a kernel bug. We're working on fixing it asap. In fact,
we're also working on figuring out how it got through CI/CD.
Could you try running it as root to verify it works?
4 years, 4 months
all rootless - container in a pod - stderr=\"Link not found\\n\""
by lejeczek
Hi guys.
I'm trying to set a rootless container in a pod but that
fails with:
-> $ podman run -d --restart always --pod
jat-${HOSTNAME%%.*} --name redis docker.io/bitnami/redis
ERRO[0059] error starting some container dependencies
ERRO[0059] "command rootless-cni-infra [alloc
6a1c6d6201bd72a083a0882a1e2cfb52e6b06251d98f4895c352921f5d781ba5
host_local jatymy-c8kubernode3 10.1.1.245 ] in container
6ad3d7cac619f5c98cb2f09d6e5bd0396a77958e7e8f61e69eeab569fbfe34ab
failed with status 1, stdout=\"\", stderr=\"Link not
found\\n\""
Error: error starting some containers: internal libpod error
-> $ cat /etc/cni/net.d/host_local.conflist
{
"cniVersion": "0.4.0",
"name": "host_local",
"plugins": [
{
"type": "macvlan",
"master": "ens10",
"ipam": {
"type": "host-local",
"ranges": [
[
{
"subnet": "10.1.1.0/24",
"rangeStart": "10.1.1.2",
"rangeEnd": "10.1.1.254",
"gateway": "10.1.1.254"
}
]
],
"routes": [
{"dst": "0.0.0.0/0"}
]
}
},
{
"type": "tuning",
"capabilities": {
"mac": true
}
}
]
}
There are no other pods nor containers, neither rootfull or
rootless, in the system which is Centos Stream with
podman-3.0.0-0.33rc2.module_el8.4.0+673+eabfc99d.x86_64
Any suggestions on what the problem might be are greatly
appreciated.
many thanks, L.
4 years, 4 months
