Podman 4.4 | Hacker News Reader

Podman 4.4

github.com

89 pointsharporoeder41 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.

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:

    [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

i.e., we have a network called 'foo' to which containers 'host1' and 'host2' are attached; they can resolve each others hostnames.

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

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 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

Podman has a Docker-compatible service API, so you can use it via docker-compose.

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.

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.

Just 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.

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:

  $ 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

Second, you can run the container with --sysctl=net.ipv4.ip_unprivileged_port_start=0 which tells the kernel to allow any process to bind to ports above 0 instead of the default of 1024:

  $ 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:22

That seems like a security issue if podman can do that without root access, yes?

As in -- on a multi-user machine, this could be a problem.

This is only within the context of the pod's network namespace.

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.

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.

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

You may be able to symlink podman to /usr/bin/docker and things should "Just Work"

That was the smartest decision they made other than the product itself

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.

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?

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!

edit: stryan has more minimalist instructions above.

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.

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

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 ..

Best solution I've found is installing the v4.3 .debs from Debian bookworm. Only caveat is you need to do some of the dependencies manually as well.

thank you

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 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?

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.

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.)

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

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

Nice, but seems sort of as complicated as I remember Systemd itself to be.

Reply on news.ycombinator.com