Live data from Hacker News

Podman 4.4

github.com

31–40 of 43 posts

Re: Podman 4.4

#31
post #28
post #22

Earlier quoted context omitted.

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.

Re: Podman 4.4

#32

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

Re: Podman 4.4

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

Re: Podman 4.4

#34
post #33

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.

Re: Podman 4.4

#35
post #34
post #33

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

Re: Podman 4.4

#36
post #25

Earlier quoted context omitted.

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:

  $ 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

Re: Podman 4.4

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

Re: Podman 4.4

#38

Earlier quoted context omitted.

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.

Re: Podman 4.4

#39
post #36
post #25

Earlier quoted context omitted.

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

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.

Re: Podman 4.4

#40
post #39
post #36

Earlier quoted context omitted.

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

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.
Post reply on HN