search

coreos / fedora-coreos-tracker

Issue tracker for Fedora CoreOS
https://fedoraproject.org/coreos/
262 stars 59 forks source link

New Package Request: passt #1436

Closed PhrozenByte closed 1 year ago

PhrozenByte commented 1 year ago

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 commented 1 year ago

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

PhrozenByte commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@sbrivio-rh WDYT?

sbrivio-rh commented 1 year ago

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 commented 1 year ago

: 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 https://github.com/openshift/machine-config-operator/pull/3580#discussion_r1124910396

travier commented 1 year ago

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

sbrivio-rh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

PhrozenByte commented 1 year ago

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 :+1: 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 commented 1 year ago

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 commented 1 year ago

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

sbrivio-rh commented 1 year ago

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:

travier commented 1 year ago

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 commented 1 year ago

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

sbrivio-rh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 :+1:

lukasmrtvy commented 1 year ago

@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 commented 1 year ago

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

lukasmrtvy commented 1 year ago

https://bugs.passt.top/show_bug.cgi?id=44

https://transfer.sh/IsxczY/pasta.pcap

sbrivio-rh commented 1 year ago

@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 commented 1 year ago

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 https://github.com/coreos/fedora-coreos-config/pull/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 commented 1 year ago

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 commented 1 year ago

The package and a test was added in https://github.com/coreos/fedora-coreos-config/pull/2420

dustymabe commented 1 year ago

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

dustymabe commented 1 year ago

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

dustymabe commented 1 year ago

The fix for this went into stable stream release 38.20230527.3.0.