Podman 4.4(github.com)
github.com
Podman 4.4
https://github.com/containers/podman/releases/tag/v4.4.0
42 comments
Did they sort out rootless networking? I've tried podman twice but simply cannot get networking to work properly when using a docker-compose file.
I haven’t had issues with rootless networking but I run pretty simple apps. I gave up on podman-compose though and run individual commands to create podman objects. Once rootless containers are in the same pod you can access other containers in the same pod over localhost
I embraced pods and now I don’t think I would want to go back to docker without them.
Once I get everything built the way I want I dump the config to a yaml with “podman generate kube” for future reference.
It’s also nice being able to use systemd service files to start/stop everything, and podman has a command to generate those too.
Once I get everything built the way I want I dump the config to a yaml with “podman generate kube” for future reference.
It’s also nice being able to use systemd service files to start/stop everything, and podman has a command to generate those too.
Podman has a Docker-compatible service API, so you can use it via docker-compose.
Since docker-compose is designed to exclusively work with rootful containers (basically the only thing docker supports), it's not a surprise you're having problems trying to run it rootless.
Podman added an optional rootful daemon a few releases ago that you can run in place of/next to the docker daemon that (theoretically) supports all the same docker network functionality specifcally so docker and docker compose commands can be run unchanged on podman.
Podman added an optional rootful daemon a few releases ago that you can run in place of/next to the docker daemon that (theoretically) supports all the same docker network functionality specifcally so docker and docker compose commands can be run unchanged on podman.
I too have issues with this, but mainly trying to run protected ports (port 53 for DNS with PiHole) as rootless Podman -- it just did not work. Went back to docker and have not had an issue since.
I think that’s by design. Non-root users aren’t supposed to be able to listen on protected ports. If you need to run PiHole as a non-root user, you could start the container rootless to listen on 5353/udp (arbitrary). Then (as root), add a firewall rule to redirect traffic from 5353/udp -> 53/udp. That probably the only way to make this work while still running the container as a non-root user.
There are two ways around this:
Frist, you can run the container with --cap-add=net_bind_service which allows processes to bind to privileged ports:
Frist, you can run the container with --cap-add=net_bind_service which allows processes to bind to privileged ports:
$ podman run --cap-add=net_bind_service --rm -it --user=1 localhost/socat
bash-5.1$ id
uid=1(bin) gid=1(bin) groups=1(bin)
bash-5.1$ capsh --print
Current: cap_net_bind_service=eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap
Ambient set =cap_net_bind_service
Current IAB: !cap_dac_read_search,!cap_linux_immutable,^cap_net_bind_service,!cap_net_broadcast,!cap_net_admin,!cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_write,!cap_audit_control,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore
Securebits: 00/0x0/1'b0 (no-new-privs=0)
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
secure-no-ambient-raise: no (unlocked)
uid=1(bin) euid=1(bin)
gid=1(bin)
groups=1(bin)
Guessed mode: UNCERTAIN (0)
bash-5.1$ socat -dd - TCP-LISTEN:22
2023/02/21 09:19:34 socat[82] N reading from and writing to stdio
2023/02/21 09:19:34 socat[82] W ioctl(5, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device
2023/02/21 09:19:34 socat[82] N listening on AF=2 0.0.0.0:22
$ podman run --sysctl=net.ipv4.ip_unprivileged_port_start=0 --rm -it --user=1 registry.access.redhat.com/ubi9/ubi-minimal
bash-5.1$ id
uid=1(bin) gid=1(bin) groups=1(bin)
bash-5.1$ socat -dd - TCP-LISTEN:22
2023/02/21 09:26:55 socat[59] N reading from and writing to stdio
2023/02/21 09:26:55 socat[59] W ioctl(5, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device
2023/02/21 09:26:55 socat[59] N listening on AF=2 0.0.0.0:22Just don't use rootless. You can still do user namespace containers (the real benefit to rootless, IMO) as a root user. I predict we will find all sorts of fun, niche security bugs that were made to get rootless containers working, especially networking--linux really doesn't like unprivileged changes to the networking stack.
If you already have sudo/root access for your user, rootless is just going to cause more problems.
If you already have sudo/root access for your user, rootless is just going to cause more problems.
Start the container via systemd and ensure it has CAP_NET_BIND?
Podman 4.0 brought a new network stack for rootless called Netavark. Works nicely for me.
What was wrong with it?
It is very difficult getting containers that aren’t in a pod together to be able to talk to each other, with rootless pods, and without just host-binding everything. None of the normal hostname conveniences are in place, and if it’s possible to do it isn’t default and probably needed much more underlying knowledge than I had when I tried.
I think the new network implementation in Podman 4 ("netavark") helps with that sort of thing.
So the following works:
It's worth noting if you are trying this on a system where you previously ran podman <= 3, I think you have to 'podman system reset' to get a new configuration with the new Podman 4 network implementation.
(Personally I just run all containers with --host=net, this is just for local development, who cares)
I think this will work with docker-compose as long as you 'systemctl --user start podman.socket' and 'export DOCKER_HOST=unix:/$XDG_RUNTIME_DIR/podman/podman.sock'.
So the following works:
[sam@isis ~]$ podman network create foo
foo
[sam@isis ~]$ podman run -d --name=host1 --network=foo --init registry.access.redhat.com/ubi9/ubi-minimal sleep inf
1f7ffa0e474f7116d782ffa4d8dd9c0454893e9dac54b2cd9e61481a7f86a2ff
[sam@isis ~]$ podman run -d --name=host2 --network=foo --init registry.access.redhat.com/ubi9/ubi-minimal sleep inf
d8ffa58cb9de77305545b9f85043c016d03193adb6543b1768a68623b044b0e5
[sam@isis ~]$ podman exec host1 getent ahosts host2
10.89.0.3 STREAM host2.dns.podman
10.89.0.3 DGRAM
10.89.0.3 RAW
[sam@isis ~]$ podman exec host2 getent ahosts host1
10.89.0.2 STREAM host1.dns.podman
10.89.0.2 DGRAM
10.89.0.2 RAW
It's worth noting if you are trying this on a system where you previously ran podman <= 3, I think you have to 'podman system reset' to get a new configuration with the new Podman 4 network implementation.
(Personally I just run all containers with --host=net, this is just for local development, who cares)
I think this will work with docker-compose as long as you 'systemctl --user start podman.socket' and 'export DOCKER_HOST=unix:/$XDG_RUNTIME_DIR/podman/podman.sock'.
Had the same issue, the containers did not resolve each other by hostname. This fixed it (run on the host):
apt install containernetworking-plugins podman-plugins
apt install containernetworking-plugins podman-plugins
That's not needed/used since Podman 4, where the networking stack was rewritten; one of the features of the new "netavark" stack is that it has DNS resolution for containers within a network by default, no plugin needed.
I hope more open source projects support it.
Most repos I check out still have only docker specific commands…
Even though most things are similar, the differences in e.g networking (for example host.docker.internal vs host.containers.internal) create lots of Issues for me
Most repos I check out still have only docker specific commands…
Even though most things are similar, the differences in e.g networking (for example host.docker.internal vs host.containers.internal) create lots of Issues for me
You may be able to symlink podman to /usr/bin/docker and things should "Just Work"
I got my simple docker files working with podman but my more advanced ones didn't. This was about 8 months ago. After running podman for about 2-3 weeks on my dev machine, I went back to docker.
I had the same experience. Even though I tried really hard and gave it a few months, I went back to Docker. I'm keeping an eye on Podman, though, and hope they can pull through to replace Docker soon.
That was the smartest decision they made other than the product itself
[deleted]
Ok, I really want to use podman, but the last time I built an image and tried to run it, I ran into a brick wall.
I think I used something called buildah to package something, and it had some parameter for a name, but then trying to run it using podman, podman didn't seem to have any way to reference the container image that I THINK buildah created. I think there was also something called spokeo but I don't recall what it did, or it did not help this workflow.
The tutorials all seemed to assume pulling images from the internet.
Anyone have a good podman tutorial that really goes from install podman -> make container -> run container on a Linux box?
I think I used something called buildah to package something, and it had some parameter for a name, but then trying to run it using podman, podman didn't seem to have any way to reference the container image that I THINK buildah created. I think there was also something called spokeo but I don't recall what it did, or it did not help this workflow.
The tutorials all seemed to assume pulling images from the internet.
Anyone have a good podman tutorial that really goes from install podman -> make container -> run container on a Linux box?
This works for me on Ubuntu 22.10:
$ sudo apt install podman buildah
$ mkdir empty && cd empty
$ cat > Containerfile <<EOF
FROM alpine:3.14
RUN echo 'echo hello podman!' > /root/hello.sh
ENTRYPOINT ["/bin/sh", "/root/hello.sh"]
EOF
$ buildah build -f Containerfile -t hello-podman .
$ podman run -it --rm localhost/hello-podman:latest
hello podman!
AH, so it must be the localhost/hello-podman:latest was the axle-wrap.
I will now bitch about how everything needs to be converted to some obscure url or pseudo-url when a file path would do. This has bitten me on:
- JSP tag libraries
- XML xsd references (which back in the Spring XML namespace-go-nuts era was really annoying)
- file:///fully/qualified/path
There, I have bitched.
I will now bitch about how everything needs to be converted to some obscure url or pseudo-url when a file path would do. This has bitten me on:
- JSP tag libraries
- XML xsd references (which back in the Spring XML namespace-go-nuts era was really annoying)
- file:///fully/qualified/path
There, I have bitched.
Were you building from a Dockerfile or Containerfile? If so, you don't need to use buildah you can just use podman build, same as you would docker. So to build an image from a Dockerfile/Containerfile in the current directory just run
podman build -t what_the_image_to_be_tagged .
Then to reference the container by name when you run it, you gotta specify that at runtime:
podman run --name foo the_image_you_just_tagged
podman build -t what_the_image_to_be_tagged .
Then to reference the container by name when you run it, you gotta specify that at runtime:
podman run --name foo the_image_you_just_tagged
There are no builds for Ubuntu 22.04 LTS on arm64, anyone can tell me how to run it on there?
The version in official Ubuntu apt repo is still 3.x ..
The version in official Ubuntu apt repo is still 3.x ..
How do we encourage other repos like Ubuntu to update to this version? I'd love to have some Ubuntu like distro that has faster / rolling updates for WSL and some VMs. Even the next version of Ubuntu is still stuck on version 3.4...
It's in Ubuntu's Universe repository. That means it's usually just the upstream Debian package or one maintained by the community rather than Ubuntu itself.
Ubuntu's podman 3.4 was pulled from Debian Unstable at some point (Debian Stable is still on 3.0?). It looks like Debian Testing has 4.3, so they're probably waiting to just use that from Debian Stable in Ubuntu Lunar rather than the community maintaining their own version.
https://code.launchpad.net/ubuntu/+source/libpod
Ubuntu's podman 3.4 was pulled from Debian Unstable at some point (Debian Stable is still on 3.0?). It looks like Debian Testing has 4.3, so they're probably waiting to just use that from Debian Stable in Ubuntu Lunar rather than the community maintaining their own version.
https://code.launchpad.net/ubuntu/+source/libpod
It's in universe, so I guess wait for the newer package to be pulled from Debian (unstable currently has 4.3.4)?
Or maybe you can request it via the process outlined at https://wiki.ubuntu.com/SyncRequestProcess?
Or maybe you can request it via the process outlined at https://wiki.ubuntu.com/SyncRequestProcess?
A not what you're asking, but answer you're actually looking for response might be don't use Ubuntu, use a 'rolling release' distro such as Arch? (Or coming from Ubuntu perhaps the derivative Manjaro.)
By contributing the change you want to see to Debian. Ubuntu is almost entirely a straight rebuild of Debian.
That isn’t the issue. Debian experimental already has 4.4.0, but it won’t make it into Debian unstable and thus Ubuntu for a while. The issue is how frequently Debian and Ubuntu release.
How is that an issue? If you want to live on the bleeding edge, you can run experimental or unstable or whatever. Or just pull the package you want. The poster asked how to "encourage" the distros to ship the package they wanted, and now they know.
This has been out for weeks. Went to check my version and I'm on 4.4.1 (Fedora).
What are the benefits of using podman over docker desktop? I've just got my new M1 macbook and are tempting to try docker desktop alternatives..
I don't know how podman machine compares, but I've found colima [0] to be a much better experience to Docker Desktop on Apple Silicon Macs.
[0] https://github.com/abiosoft/colima
[0] https://github.com/abiosoft/colima
Nice, but seems sort of as complicated as I remember Systemd itself to be.