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
6 months, 2 weeks
mqueue msg_max in rootless container
by Michael Ivanov
Hallo!
I'm trying to run my application in podman rootless container and I stumble
on following problem: my program needs /proc/sys/fs/mqueue/msg_max to be at
least 256, but in running container this value is just 10. When I try to
specify this parameter while running the image (--sysctl 'fs.mqueue.msg_max=256')
I get the following error:
Error: open /proc/sys/fs/mqueue/msg_max: Permission denied: OCI permission denied
and container is not created.
My host where container is being run has this parameter set to 256. How can I
expose current host setting for msg_max to my container?
Best regards,
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | |
\^/ | E-mail: ivans(a)isle.spb.ru |
^ ^ | |
1 year, 7 months
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
Podman Community Meeting - Tues June 1, 2021 11:00 a.m. EDT (UTC-4)
by Tom Sweeney
Hi All,
Just a quick note that the next Podman Community Meeting is coming
up a week from this coming Tuesday. It will be Tuesday June 1, 2021 at
11:00 a.m. EDT (UTC-4). We're overloaded with topics this time and
will be talking about Podman and TYE, Podman v3.2.0 updates, Podman in
Kubernetes and Podman Machine updates. The full agenda with the link to
the video conference is here
(https://podman.io/community/meeting/agenda/). Check out the link to
WorldTImeBuddy at the top of the web page for the agenda for an easy
time converter for your local time. As usual, no charge to attend!
Also, I just posted the meeting notes from the May 2021 meeting.
They include links to the slides on Sysbox runtime, a link to the video
recording and my bad attempt at taking notes during the meeting.
https://podman.io/community/meeting/notes/2021-05-04/
As a quick note, given the number of people that we've heard from
who will be on vacation in early July, we have decided to not hold the
meeting that month. Our following meeting will be Tuesday August 3rd,
also at 11:00 a.m. EDT (UTC-4).
t
4 years
docker registry terminates when run under podman
by Michael Ivanov
Hallo,
Not sure whether it is a right place o ask, but still. I am trying to run docker registry
in rootless podman. I have created a 'register' user and started the registry with the
following command:
podman run --privileged -d --name registry -p 5000:5000 -v /srv/registry:/var/lib/registry --restart=always registry:latest
(/srv/registry belongs to 'registry' user, so should be visible in rootless container
as belonging to root).
So far so good, I test the register with podman search and it returns expected results.
But as soon as I exit the ssh session in which I started the container, container
terminates, not immediately but in half minute or so. There;s no diagnostic about
the reason in podman logs, nor in /var/syslog, nor in dmesg output. Just in case
I tried to start it with nohup - same result. I also tried to start it as a service
using the following file:
[Unit]
Description=Containers registry
After=syslog.target network.target
RequiresMountsFor=/srv/registry
[Service]
User=registry
Group=registry
LimitMEMLOCK=infinity
LimitNOFILE=65535
Type=simple
RemainAfterExit=yes
ExecStart=/usr/bin/podman start registry
ExecStop=/usr/bin/podman stop -t 60 registry
[Install]
WantedBy=multi-user.target
And it still terminates in about half a minute after service startup.
How can I find at least some indication about why this happens?
Best regards,
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | |
\^/ | E-mail: ivans(a)isle.spb.ru |
^ ^ | |
4 years, 1 month
systemd rootless service unit (not user users' system) - ?
by lejeczek
Hi guys.
Trying "regular" podman generated systemd service unit with
systemd fails with also what I could have fiddled into it so
I wonder - if a rootless container, created and managed by a
non-root user can be given to systemd(system's, not user's)
for complete management?
many thanks, L.
4 years, 1 month
Re: podman and kubernetes
by Valentin Rothberg
Hi Thierry,
Putting the list back in the loop. I think you accidentally replied to me
only.
On Wed, May 26, 2021 at 5:17 PM Thierry Parmentelat <
thierry.parmentelat(a)inria.fr> wrote:
> Hi Valentin
>
> thanks for your feedback, I’m answering inline
>
> > Podman is not meant to run K8s. Podman targets single-node machines and
> focuses on servers and developer machines. It does not implement Container
> Runtime Interface (CRI) that K8s uses to communicate with the container
> runtime. CRI-O is dedicated to exactly that use-case.
>
> yeah, I got that
>
> so let me rephrase; the fact that I mentioned minikube - that is just a
> first step for me a beginner here - seems to have been misleading
>
> my ultimate goal is to deploy a k8s cluster on a handful of bare-metal
> fedora boxes, running podman instead of docker
> but I was surprised to see **almost no mention** of podman in the k8s
> documentation, where docker appears a zillion of times along with, in
> shorter supply, rkt
>
As mentioned before, Podman is not meant to be running underneath
Kubernetes. That is CRI-O's job.
Docker and rkt are mentioned for historical reasons. Both have been used
underneath Kubernetes for a longer period of time. rkt has been
discontinued a long time ago and also Docker is not supported underneath
Kubernetes anymore.
> I understand that the podman team is not in charge of that documentation,
> I’m just saying this suggests podman cannot be used in this way, which I’m
> pretty certain it is, right ?
>
Podman cannot be used underneath Kubernetes.
> > If you see specific bugs, opening an issue upstream would be great. For
> questions, the mailing list works well, GitHub issues or the #podman
> channel on Freenode IRC (and Libera Chat).
>
> thanks for pointing out irc, I’ll try to join you guys there
>
Great, see you over there :)
Kind regards,
Valentin
4 years, 1 month
podman pod not working with systemd unit system files
by James Miller
Hi,
I have been trying to get podman to work with systemd.
I have a pod with 4 containers inside, along with the pause container, and
I have generated systemd unit files using the command 'podman generate
systemd --files'.
If I place the generated files into the /etc/systemd/user/ directory, then
they run as expected, using the 'systemctl --user enable --now' command.
If I place them into the /etc/systemd/system directory they do not run.
This is as I expected, since the files are all in the standard user's home
directory, as are the volume mounts.
However, although I want them to run in the context of a standard user, I
am concerned that if some hacker breaks out into my system then because the
command to stop and start systemd unit user files will be available to
them, then they can stop the running pod as a standard user, and my server
and django site will be down. It's as simple as 'systemctl --user stop
pod-xxx.service.
I discussed the issue briefly with velix on the irc podman chat, he
suggested I use system groups. However, no matter how I configure my pod
and container unit files, and whether or not I use 'loginctl enable-linger'
I cannot get the pod to start.
I have read that it is possible to start podman-containers having placed
the unit files inside the /etc/systemd/system directory, which would mean
that any command to stop the pod would be followed by the systemd bringing
them back up, and the systemctl command to manipulate the pod wouldn't be
available to the standard user.
So, what is the most secure way of starting the containers, in such a way,
if possible, that should some influence gain unprivileged access, they
cannot stop the pod.
MTIA
James
--
James Stewart Miller Bsc(hons) Psych.
4 years, 1 month
