New Package Request: passt

[PhrozenByte]

What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)

None

# rpm-ostree install --dry-run passt
Checking out tree d34ff10... done
Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'fedora-modular'... done
Updating metadata for 'updates-modular'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2022-10-06T11:01:40Z solvables: 4
rpm-md repo 'fedora-modular'; generated: 2022-11-05T07:58:03Z solvables: 1454
rpm-md repo 'updates-modular'; generated: 2023-02-22T11:28:37Z solvables: 1464
rpm-md repo 'updates'; generated: 2023-03-07T01:25:09Z solvables: 26563
rpm-md repo 'fedora'; generated: 2022-11-05T08:04:38Z solvables: 66822
rpm-md repo 'updates-archive'; generated: 2023-03-08T02:27:27Z solvables: 29547
Resolving dependencies... done
Installing 1 packages:
  passt-0^20230222.g4ddbcb9-1.fc37.x86_64 (updates)
Exiting because of '--dry-run' option

What is the size of the package and its dependencies?

About 429 kB

# rpm -qi passt
Name        : passt
Version     : 0^20230222.g4ddbcb9
Release     : 1.fc37
Architecture: x86_64
Install Date: Wed Mar  8 10:15:20 2023
Group       : System Environment/Daemons
Size        : 428906
License     : AGPLv3+ and BSD
Signature   : RSA/SHA256, Wed Feb 22 12:55:10 2023, Key ID f55ad3fb5323552a
Source RPM  : passt-0^20230222.g4ddbcb9-1.fc37.src.rpm
Build Date  : Wed Feb 22 12:42:51 2023
Build Host  : buildvm-x86-24.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://passt.top/
Bug URL     : https://bugz.fedoraproject.org/passt
Summary     : User-mode networking daemons for virtual machines and namespaces
Description :
passt implements a translation layer between a Layer-2 network interface and
native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't
require any capabilities or privileges, and it can be used as a simple
replacement for Slirp.

pasta (same binary as passt, different command) offers equivalent functionality,
for network namespaces: traffic is forwarded using a tap interface inside the
namespace, without the need to create further interfaces on the host, hence not
requiring any capabilities or privileges.

What problem are you trying to solve with this package? Or what functionality does the package provide?

passt provides user-mode networking daemons for virtual machines and namespaces

passt implements a translation layer between a Layer-2 network interface and
native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't
require any capabilities or privileges, and it can be used as a simple
replacement for Slirp.

pasta (same binary as passt, different command) offers equivalent functionality,
for network namespaces: traffic is forwarded using a tap interface inside the
namespace, without the need to create further interfaces on the host, hence not
requiring any capabilities or privileges.

This enables support for Podman's new rootless network mode pasta (Podman 4.4 and later). See man(1) of podman-run --network=pasta. Also see https://passt.top/passt/about/

Can the software provided by the package be run from a container? Explain why or why not.

No, it provides additional functionality for Podman.

Can the tool(s) provided by the package be helpful in debugging container runtime issues?

n/a

Can the tool(s) provided by the package be helpful in debugging networking issues?

n/a

Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.

Yes.

In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?

The package provides binaries only, see https://packages.fedoraproject.org/pkgs/passt/passt/fedora-38.html#files

Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?

Don't think so.

Does the software provided by the package have a history of CVEs?

AFAIK no.

[travier]

Sounds good to me but it should probably be a direct dependency of podman?

[PhrozenByte]

Podman uses pasta, which is a component of passt (it's a single binary). Simply put, passt is for virtual machines, pasta is for containers. So, in general one can use passt without Podman (that's probably the reason why it's packaged separately in Fedora), but for FCOS its use is indeed practically limited to Podman, so it could also be made a direct dependency of Podman, yes.

[dustymabe]

Podman uses pasta, which is a component of passt (it's a single binary). Simply put, passt is for virtual machines, pasta is for containers. So, in general one can use passt without Podman (that's probably the reason why it's packaged separately in Fedora), but for FCOS its use is indeed practically limited to Podman, so it could also be made a direct dependency of Podman, yes.

Considering it's just a single binary that changes behavior whether $0 is pasta or passt I really don't understand why podman wouldn't just make it a dep (at least a weak dep).

For the non-podman use cases those stacks could also just name it as a dep.

[PhrozenByte]

@sbrivio-rh WDYT?

[sbrivio-rh]

So, in general one can use passt without Podman (that's probably the reason why it's packaged separately in Fedora), but for FCOS its use is indeed practically limited to Podman, so it could also be made a direct dependency of Podman, yes.

Strictly speaking, one could also use pasta without Podman (I... actually do :)), just like you can use unshare without it. Practically speaking, yes, I guess it's like you say.

As to whether it should be made a dependency of Podman: I haven't suggested it for "regular" Fedora because one could use slirp4netns, and presumably keep using it for the foreseeable future. Should it become the default network provider for rootless containers, then I guess it should be a dependency.

For Fedora CoreOS, I guess it might make sense to make it a dependency right now.

Mine isn't a very informed opinion though, I'm neither a user nor a developer of Fedora CoreOS.

[cgwalters]

: I haven't suggested it for "regular" Fedora

Hi, I'd appreciate not using the word "regular" here as it implies that we are "not-regular" or irregular, etc. More in openshift/machine-config-operator#3580 (comment)

[travier]

Why is this not the default yet for podman? Why should we ship something that is not the default in podman?

[sbrivio-rh]

Hi, I'd appreciate not using the word "regular" here as it implies that we are "not-regular" or irregular, etc. More in openshift/machine-config-operator#3580 (comment)

I read that thread, but I haven't found a convenient way to clearly refer to Fedora in contrast with Fedora CoreOS. "Default"? "Default flavour of —"?

[sbrivio-rh]

Why is this not the default yet for podman?

It's a relatively young project and the integration was released (in Podman 4.4) just over a month ago, while slirp4netns has been there for years.

Why should we ship something that is not the default in podman?

slirp4netns has some structural disadvantages. For instance, users need to choose whether to 1. preserve correct source and destination addresses for port forwarding (slirp4netns handler) but poor performance (especially for loopback connections) or 2. ditch addressing correctness (rootlesskit handler) to get better performance for loopback connections.

Option 2. breaks non-local connections, option 1. breaks IPv6. There might be a ton of other reasons, but this is probably the most relevant.

[PhrozenByte]

Why is this not the default yet for podman? Why should we ship something that is not the default in podman?

Honestly, I'm not sure what the question is?

Pasta is a new network mode for rootless Podman that was introduced with Podman 4.4. Podman supports it "by default", but requires the external passt binary. That's a common approach for Podman: Podman's slirp4netns support requires the slirp4netns binary, Podman's FUSE-based overlayfs support requires the fuse-overlayfs binary. If these binaries aren't present Podman simply throws an error when attempting to use them. Podman itself doesn't require slirp4netns either, whether a distribution ships it with Podman or not is a decision made by package maintainers, not by Podman.

I don't think that whether pasta is the default network mode for rootless containers matters. Pasta is rather new; it's considered stable, but surely hasn't seen enough users yet to make it the default. Just like Podman didn't switch from CNI to Netavark/Aardvark at day one, that would have been crazy. Yet FCOS supported Netavark/Aardvark before Podman 4.0...

[travier]

Yet FCOS supported Netavark/Aardvark before Podman 4.0.

I don't think we did. What makes you say that?

If podman uses pasta by default if it's there, then it should require/recommend it in the RPM package and we would include it directly.

Thus why I'm asking why is podman not yet requiring the pasta package.

[dustymabe]

we have a community meeting in 30m in #fedora-meeting-1 - want to discuss there?

[PhrozenByte]

Good idea @dustymabe, will join the meeting.

If podman uses pasta by default if it's there, then it should require/recommend it in the RPM package and we would include it directly.

Thus why I'm asking why is podman not yet requiring the pasta package.

Just for the record: Thanks for the clarification, I get your point now 👍 It does, just not for Fedora 37, but Fedora 38+, see https://src.fedoraproject.org/rpms/containers-common/blob/f38/f/containers-common.spec#_75

[dustymabe]

We discussed this in the community meeting today:

12:05:09  dustymabe | #agreed We will add passt to Fedora CoreOS. In F37/F38 there will  
                    | be no functional change to the defaults even with the new package 
                    | added, but the package is small and it will be the default in the
                    | future. Adding it now enables users to get early testing/usage with
                    | it.

[travier]

Adding a test for this functionality alongside the PR that adds this package would be great.

[sbrivio-rh]

Adding a test for this functionality alongside the PR that adds this package would be great.

Two test suites are available, but I'm not sure what would be the effort (and whether it's sensible at the moment) to make them automatically consumable for Fedora CoreOS tests:

• the upstream test suite of passt/pasta itself. It takes a long time to complete (it includes performance tests), requires network access, and uses some tools that are not commonly packaged. There's some ongoing work to restructure the framework that will make test selection easier and reduce dependencies. At the moment this is run as part of the CI and I manually run it on Fedora package updates, but that's about it

• the test cases for Podman (covering pasta only). Those cover basic functionality and take about a minute to complete, but depend on Podman (shouldn't be an issue), bats (I don't know), and require network access to download the test container image

[travier]

I meant adding a test in the Fedora CoreOS config repo (https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola) that would setup passt for podman via a Butane config and then create a container and verify that the network works at least.

See also https://coreos.github.io/coreos-assembler/kola/ & https://coreos.github.io/coreos-assembler/kola/external-tests/.

[travier]

The actual test here would be closer to what's done in the podman test cases.

[sbrivio-rh]

I meant adding a test in the Fedora CoreOS config repo (https://github.com/coreos/fedora-coreos-config/tree/testing-devel/tests/kola) that would setup passt for podman via a Butane config and then create a container and verify that the network works at least.

Oh, I see. If we just want to check basic network functionality, also pasta --config-net -- curl -s fedoraproject.org >/dev/null will do, no need for Podman or test containers there.

[travier]

Oh, I see. If we just want to check basic network functionality, also pasta --config-net -- curl -s fedoraproject.org >/dev/null will do, no need for Podman or test containers there.

Well, the point is to test the integration of the whole stack together in a system (here Fedora CoreOS), so setting it properly as default in the settings and then creating a container and verifying that it is effectively used by default and that it works would be best.

We don't want to reproduce other projects test suite, we want to have something that tests a coherent story / use case on Fedora CoreOS.

[sbrivio-rh]

@PhrozenByte do you plan to do the job here? Anybody else interested? Otherwise I can give it a try within a couple of weeks, but I can't guarantee at the moment.

[PhrozenByte]

@PhrozenByte do you plan to do the job here? Anybody else interested? Otherwise I can give it a try within a couple of weeks, but I can't guarantee at the moment.

I'm afraid I'm not going to have enough time to look into how to add new packages to FCOS, never did that before. Would be great if someone more experienced picks this up 👍

[lukasmrtvy]

@PhrozenByte
It's still somehow broken..

[core@ip-10-1-36-63 ~]$ pasta --version
pasta 0^20230310.g70c0765-1.fc37.x86_64

[core@ip-10-1-36-63 ~]$ podman run --rm -it --network pasta alpine
/ # apk add iperf3
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/1) Installing iperf3 (3.12-r0)
Executing busybox-1.35.0-r29.trigger
OK: 7 MiB in 16 packages
/ # iperf3 -c 88.86.XX.YY  -p 5203
Connecting to host 88.86.XX.YY, port 5203
[  5] local 10.1.36.63 port 40416 connected to 88.86.XX.YY port 5203
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   656 KBytes  5.37 Mbits/sec    3   8.00 KBytes       
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   656 KBytes   537 Kbits/sec   15             sender
[  5]   0.00-10.11  sec   140 KBytes   113 Kbits/sec                  receiver

iperf Done.

cc @sbrivio-rh

[sbrivio-rh]

@PhrozenByte It's still somehow broken..

Mind sharing the information I asked on Podman's chat (packet capture with --net=pasta,-p,/tmp/pasta.pcap) so that I can actually look into it? You can use tools such as https://github.com/7h3rAm/pcapedit to edit out the IP addresses.

[sbrivio-rh]

@PhrozenByte It's still somehow broken..

[core@ip-10-1-36-63 ~]$ pasta --version
pasta 0^20230310.g70c0765-1.fc37.x86_64

[core@ip-10-1-36-63 ~]$ podman run --rm -it --network pasta alpine
/ # apk add iperf3
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/1) Installing iperf3 (3.12-r0)
Executing busybox-1.35.0-r29.trigger
OK: 7 MiB in 16 packages
/ # iperf3 -c 88.86.XX.YY  -p 5203
Connecting to host 88.86.XX.YY, port 5203
[  5] local 10.1.36.63 port 40416 connected to 88.86.XX.YY port 5203
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   656 KBytes  5.37 Mbits/sec    3   8.00 KBytes       
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   8.00 KBytes       
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    3   8.00 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   656 KBytes   537 Kbits/sec   15             sender
[  5]   0.00-10.11  sec   140 KBytes   113 Kbits/sec                  receiver

iperf Done.

cc @sbrivio-rh

By the way, this should now be fixed in upstream version 2023_03_21.1ee2f7c, Fedora 37 build: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0972b1a0a9 (passt-0^20230321.g1ee2f7c-1.fc37), commit https://passt.top/passt/commit/?id=1ee2f7cada9e6f739a00d39bb9821f1ce3493d92 ("tcp: Don't reset ACK_TO_TAP_DUE on any ACK, reschedule timer as needed")

[PhrozenByte]

Any updates on this?

I just recently learned how to add a package to FCOS (as far as I'm not mistaken it's really just coreos/fedora-coreos-config#2420...), but I've no idea how to add a test as suggested by @travier... So, shall we add the package now and remember the test for later?

[sbrivio-rh]

Any updates on this?

No, sorry, it had just recently reached a respectable position in my to-do list. However:

I just recently learned how to add a package to FCOS (as far as I'm not mistaken it's really just coreos/fedora-coreos-config#2420...)

that's great, thanks! I was afraid it would be a more involved process.

but I've no idea how to add a test as suggested by @travier... So, shall we add the package now and remember the test for later?

By the way, I think we should "just" run Podman's tests for pasta -- they can run outside the test suite with bats -f test/system/505-networking-pasta.bats. No idea how to do that either. Rather than getting frequent reports of users struggling to install the package on Fedora CoreOS, I would also just add the package and figure out the tests later -- I'm not sure if it's acceptable.

[dustymabe]

The package and a test was added in coreos/fedora-coreos-config#2420

[dustymabe]

The fix for this went into next stream release 38.20230527.1.1. Please try out the new release and report issues.

[dustymabe]

The fix for this went into testing stream release 38.20230527.2.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 38.20230527.3.0.