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.
Podman 4.4
31–40 of 43 posts
Re: Podman 4.4
#32How 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...
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.
Re: Podman 4.4
#33The version in official Ubuntu apt repo is still 3.x ..
Re: Podman 4.4
#34There 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
#35There 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
#36Earlier 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.
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:22Re: Podman 4.4
#37Re: Podman 4.4
#38Earlier 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.
Re: Podman 4.4
#39Earlier 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…
As in -- on a multi-user machine, this could be a problem.
Re: Podman 4.4
#40Earlier 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.