Update to podman 5, including netavark and pasta

[mattcen]

• Remove slirp4netns, and replace with pasta
• Build and install netavark
• Upgrade to podman 5.0.0

[mgoltzsche]

Hi @mattcen, thanks for creating the PR!
Though, the CI pipeline fails because of the following issues:

• The podman remote tests fail because the podman version within Dockerfile-remote needs to be updated correspondingly.
• The podman networking tests fail because the netavark binary requires libgcc to be linked dynamically, e.g. see:

not ok 3 rootful podman - internet connectivity (CNI networking) in 1738ms
# (in test file test/rootful.bats, line 18)
#   `$DOCKER run --rm --privileged --entrypoint /bin/sh -u root:root \' failed with status 126
# Resolving "alpine" using unqualified-search registries (/etc/containers/registries.conf)
# Trying to pull docker.io/library/alpine:3.17...
# Getting image source signatures
# Copying blob sha256:3c854c8cbf469fda815b8f6183300c07cfa2fbb5703859ca79aff93ae934961b
# Copying config sha256:eaba187917ccc6af1386ecfdd95a56858a553d14888387980fb07b326e8ce890
# Writing manifest to image destination
# Error loading shared library libgcc_s.so.1: No such file or directory (needed by /usr/local/lib/podman/netavark)
# Error relocating /usr/local/lib/podman/netavark: _Unwind_Resume: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetIPInfo: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetDataRelBase: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetRegionStart: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_SetGR: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetTextRelBase: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_DeleteException: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_RaiseException: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetIP: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_Backtrace: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_GetLanguageSpecificData: symbol not found
# Error relocating /usr/local/lib/podman/netavark: _Unwind_SetIP: symbol not found
# Error: netavark: : EOF

Can we get rid of that dependency somehow?
Otherwise, can we statically link it?

[mattcen]

Heya!

I created this PR just because I wanted to to upgrade to pasta and decided to share my work. I'm not sure how much capacity I'll have to fix these issues in the immediate future, but I'll try to book some time to look into them.

Thanks for the feedback!

[mattcen]

I've pushed a fix to Dockerfile-remote. Apparently the tests all fail when I run them on my Mac, but I suspect that's because they make some Linux-specific assumptions.
Haven't dug into the netavark thing yet. Another thing to note on that though is that it might be worth building it from a different (Rust-specific) container base rather than waste time installing a bunch of Rust stuff into the Go Alpine image.

[mgoltzsche]

Now that you also updated the podman version within the remote Dockerfile, the podman remote tests are passing.
However, the netavark binary is still dynamically linked to libgcc which makes the networking tests fail.
Given that the tests are not running on your machine, you could quickly verify that the netavark build is producing a statically linked binary by running ! ldd /usr/local/lib/podman/netavark within the podman container. The command should terminate successfully or list the (missing) dynamically linked library. You could as well add that command to the Dockerfile step that builds the binary to make sure it is really statically linked.

[mgoltzsche]

Why did you add slirp4netns back? Did it turn out to be required still?

[mattcen]

Another commit I didn't mean to push that I can revert.
For completeness though, my reason for this change was that pasta and slirp4netns have different default network configurations it appears, such that when I tried to run a container that accessed a TCP port on the host with pasta, it failed (the default pasta config gave the container the same IP as the host, whereas the default slirp4netns config gave it a different IP from the private IP range). I didn't have time to dissect what was going on here and needed this particular container to work, so I wanted to re-build the latest versions of things, including slirp4netns, so I could fall back to it until I had time to configure pasta correctly for my purposes.

[mgoltzsche]

Thanks again @mattcen! I'll carry it from here...