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 |
^ ^ | |
5 months
podman container storage backup
by Michael Ivanov
Greetings,
I make periodic backups of my laptop where I use some podman containers.
To perform a backup I just invoke rsync to copy my /home/xxxx/.local/share/containers
directory to nfs mounted filesystem.
Containers are running, but quiescent, no real activity occurs.
Is this a correct way to back up or is there anything special about
container directory to be taken into account? As far as I understand
some hash-named subdirectories are shared between different containers
and images using special kind of mounts, can this lead to duplicate
copies r inconsistencies?
Underlying fs is btrfs.
Thanks,
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | |
\^/ | E-mail: ivans(a)isle.spb.ru |
^ ^ | |
1 year, 6 months
cgroups not configured for container
by ugiwgh＠qq.com
There is somthing warning, when I add "--pid=host".
How can I get this warning gone?
OS: 8.3.2011
Podman: 2.2.1
[rsync@rsyncdk2 ~]$ podman run --rm --pid=host fb7ad16314ee sleep 3
WARN[0000] cannot toggle freezer: cgroups not configured for container
WARN[0000] lstat : no such file or directory
1 year, 10 months
systemd for a pod without infra
by Muayyad AlSadi
Hi,
when creating a pod with nothing shared and without infra
podman generate systemd -n pod_test
Error: error generating systemd unit files: Pod "pod_test" has no infra
container
here is the full commands
podman pod create --name=pod_test --infra=false --share=
podman network create pod_net
podman run --name=test_web80 -d --net pod_net --hostname web80
--pod=pod_test busybox httpd -f -p 8080 -h /etc
podman run --name=test_web90 --requires=test_web80 -d --net pod_net
--hostname web90 --pod=pod_test busybox httpd -f -p 9090 -h /etc
podman pod ps
9a894043a1e1 pod_test Running 18 seconds ago 2
if we replace
podman pod create --name=pod_test --infra=false --share=
with
podman pod create --name=pod_test --share=
podman pod ps
would display Degraded
5f2458ba5eac pod_test Degraded 18 seconds ago a3a4ca1b8e4d 3
if we remove --share=
it would complain about multiple hostnames
what do you suggest?
and why systemd care about infra?
2 years, 2 months
Show Git SHA version of podman inside podman machiine VM?
by Craig Rodrigues
Hi,
On macOS, I did the following to test the HEAD version of podman:
brew update
brew install --HEAD podman
podman version
Client: Podman Engine
Version: 4.0.0-dev
API Version: 4.0.0-dev
Go Version: go1.17.6
Git Commit: d3699bbce63f283a609053d4aca23e4abe7dae4d-dirty
Built: Wed Feb 23 07:29:12 2022
OS/Arch: darwin/amd64
Server: Podman Engine
Version: 4.0.0-dev
API Version: 4.0.0-dev
Go Version: go1.16.13
Built: Thu Feb 17 13:48:15 2022
OS/Arch: linux/amd64
podman ssh
podman version
Client: Podman Engine
Version: 4.0.0-dev
API Version: 4.0.0-dev
Go Version: go1.16.13
Built: Thu Feb 17 13:48:15 2022
OS/Arch: linux/amd64
The podman CLI on macOS shows the Git Commit as part of the output of
*podman** version*, but the CLI inside the podman machine VM does not. Is
it possible to determine the Git commit of the podman inside the VM?
--
Craig
2 years, 2 months
Re: pasta (passt) draft integration patch and demo
by Paul Holzinger
>
> [Note: you didn't send this to the list, I guess it's by accident, but
> I'm answering in private just in case -- if it's really by accident,
> I'll also answer on list ;)]
>
That was by accident, let me put this back into the list.
So, to recap, I guess the to-do list is:
>
> - drop automatic port bindings (both ways) in default configuration
> options passed by Podman
>
> - drop also the loopback trick (by default)
>
>
- add option to bind ports to specific addresses, per-port
>
>
...anything else? I would wait a couple more days for any
> additional feedback and then come back with the changes.
>
I think one big question would be packaging passt/pasta in distros. I don't
think it is a good user experience when users cannot get this from the
official repos.
Dan, Brent, Matt, Giuseppe WDYT?
On Wed, Feb 23, 2022 at 5:46 PM Stefano Brivio <sbrivio(a)redhat.com> wrote:
> [Note: you didn't send this to the list, I guess it's by accident, but
> I'm answering in private just in case -- if it's really by accident,
> I'll also answer on list ;)]
>
> On Wed, 23 Feb 2022 16:35:54 +0100
> Paul Holzinger <pholzing(a)redhat.com> wrote:
>
> > >
> > > Perhaps it would be reasonable to make it non-default in the options
> > > passed by Podman ("-t none -u none" if no ports are passed), and keep
> > > it the default in pasta (it saves some typing).
> >
> > That would be fine, I don't care about the pasta default as long as
> podman
> > uses the secure option by default this is fine for me.
>
> Okay, I'll change that in the patch (and in the demo).
>
> > > Perhaps we could also allow restricting the amount of ports (say, five)
> > > that can be bound automatically. Would something like that preferable
> as
> > > default?
> >
> > I don't think this helps much, we should only add ports that were
> > explicitly set with podman run -p ...
> > A container should not be able to alter the host by default.
> >
> > > The interface isn't really shared, but yes, ports can be directly bound
> > > both ways.
> >
> > I see, I got confused because reverse mapping was working.
> >
> >
> > Another question, does pasta support binding only a specific host
> address?
> > I only see the port:port syntax in the man page. In podman you can do -p
> > ipv4:port:port or [ipv6]:port:port.
>
> Not explicitly: one can pass a host interface that's used to source the
> address -- by default, that's the interface with the first returned
> least-specific route for IPv4, i.e. the default gateway, or for IPv6 if
> IPv4 is disabled/not available.
>
> Addresses can also be overridden with "-a" (separately for IPv4 and IPv6)
> --
> and the configured address will be used.
>
> ...but not with different per-port addresses. I can definitely add an
> option for that.
>
> Now, passt doesn't use dynamic memory allocation (for security reasons), so
> I'll need to move the binding routines to the command line argument parsing
> stage (ports are stored as bitmaps, I can't store an arbitrary number of
> addresses), but it's a quick change.
>
> So, to recap, I guess the to-do list is:
>
> - drop automatic port bindings (both ways) in default configuration
> options passed by Podman
>
> - drop also the loopback trick (by default)
>
> - add option to bind ports to specific addresses, per-port
>
> ...anything else? I would wait a couple more days for any
> additional feedback and then come back with the changes.
>
> --
> Stefano
>
>
2 years, 2 months
Re: pasta (passt) draft integration patch and demo
by Stefano Brivio
[Just for the records, original email sent to Paul, also missing in
list]
On Wed, 23 Feb 2022 16:35:54 +0100
Paul Holzinger <pholzing(a)redhat.com> wrote:
> >
> > Perhaps it would be reasonable to make it non-default in the options
> > passed by Podman ("-t none -u none" if no ports are passed), and keep
> > it the default in pasta (it saves some typing).
>
> That would be fine, I don't care about the pasta default as long as podman
> uses the secure option by default this is fine for me.
Okay, I'll change that in the patch (and in the demo).
> > Perhaps we could also allow restricting the amount of ports (say, five)
> > that can be bound automatically. Would something like that preferable as
> > default?
>
> I don't think this helps much, we should only add ports that were
> explicitly set with podman run -p ...
> A container should not be able to alter the host by default.
>
> > The interface isn't really shared, but yes, ports can be directly bound
> > both ways.
>
> I see, I got confused because reverse mapping was working.
>
>
> Another question, does pasta support binding only a specific host address?
> I only see the port:port syntax in the man page. In podman you can do -p
> ipv4:port:port or [ipv6]:port:port.
Not explicitly: one can pass a host interface that's used to source the
address -- by default, that's the interface with the first returned
least-specific route for IPv4, i.e. the default gateway, or for IPv6 if
IPv4 is disabled/not available.
Addresses can also be overridden with "-a" (separately for IPv4 and
IPv6) -- and the configured address will be used.
...but not with different per-port addresses. I can definitely add an
option for that.
Now, passt doesn't use dynamic memory allocation (for security
reasons), so I'll need to move the binding routines to the command line
argument parsing stage (ports are stored as bitmaps, I can't store an
arbitrary number of addresses), but it's a quick change.
So, to recap, I guess the to-do list is:
- drop automatic port bindings (both ways) in default configuration
options passed by Podman
- drop also the loopback trick (by default)
- add option to bind ports to specific addresses, per-port
...anything else? I would wait a couple more days for any
additional feedback and then come back with the changes.
--
Stefano
2 years, 2 months
bind-propagation=rshared has no effect
by Rudolf Vesely
Hi Everybody,
I tried to mount filesystem inside unprivileged container using fuse3 and it's working. The only thing I had to do was to mount /dev/fuse using "--device" and add "SYS_ADMIN" capability.
Example:
podman run \
-d \
--device=/dev/fuse \
--cap-add SYS_ADMIN \
localhost/myimage
After that I can mount fuse inside.
Now I'd like to access the mounted filesystem from another container in a pod or from the container host. In order to do that I used "bind-propagation=rshared" like this:
podman run \
--mount=type=bind,source=/from,destination=/to,bind-propagation=rshared \
-d \
--device=/dev/fuse \
--cap-add SYS_ADMIN \
localhost/myimage
When I mount fuse inside the container into "/to" or "/to/subfolder" I can again see / access the filesystem from inside of the container but I don't see it from the host / from another containers in a pod that mount "/from".
Could you please tell me Am I missing something?
I was thinking that maybe AppArmor but looking into logs - nothing.
Running Podman 3.4.4 on Debian Bookworm (kernel 5.16).
Thank you.
Kind regards,
Rudolf Vesely
2 years, 2 months
