passt/test/passt.mbuto, branch 2025_06_11.0293c6f

rampstream: Add utility to test for corruption of data streams

2025-02-12T18:48:17+00:00

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

dhcp, dhcpv6: Add hostname and client fqdn ops

2025-02-10T17:30:24+00:00

Both DHCPv4 and DHCPv6 has the capability to pass the hostname to
clients, the DHCPv4 uses option 12 (hostname) while the DHCPv6 uses option 39
(client fqdn), for some virt deployments like kubevirt is expected to
have the VirtualMachine name as the guest hostname.

This change add the following arguments:
 - -H --hostname NAME to configure the hostname DHCPv4 option(12)
 - --fqdn NAME to configure client fqdn option for both DHCPv4(81) and
   DHCPv6(39)

Signed-off-by: Enrique Llorente 
Signed-off-by: Stefano Brivio

debug: Add tcpdump to mbuto.img

2025-02-06T08:43:09+00:00

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

test: Look for possible sshd-session paths (if it's there at all) in mbuto's profile

2024-08-27T07:03:47+00:00

Some distributions already have OpenSSH 9.8, which introduces split
sshd/sshd-session binaries, and there we need to copy the binary from
the host, which can be /usr/libexec/openssh/sshd-session (Fedora
Rawhide), /usr/lib/ssh/sshd-session (Arch Linux),
/usr/lib/openssh/sshd-session (Debian), and possibly other paths.

Add at least those three, and, if we don't find sshd-session, assume
we don't need it: it could very well be an older version of OpenSSH,
as reported by David for Fedora 40, or perhaps another daemon (would
Dropbear even work? I'm not sure).

Reported-by: David Gibson 
Fixes: d6817b3930be ("test/passt.mbuto: Install sshd-session OpenSSH's split process")
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson 
Tested-by: David Gibson

test/passt.mbuto: Install sshd-session OpenSSH's split process

2024-08-21T10:03:03+00:00

OpenSSH now ships a per-session binary, sshd-session, with sshd
acting as mere listener. It's typically not found in $PATH, so specify
the whole path at which it's commonly installed in $PROGS.

Link: https://www.openssh.com/releasenotes.html#9.8p1
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

test/passt.mbuto: Run sshd from vsock proxy with absolute path

2024-08-21T10:02:37+00:00

...OpenSSH >= 9.8 otherwise complains that:

  sshd requires execution with an absolute path

Link: https://bugs.gentoo.org/936041
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078429
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

test: Allow sftp via vsock-ssh in tests

2024-05-02T14:13:36+00:00

During some debugging recently, I wanted to extact a file from a test
guest and found it was tricky, since the ssh-over-vsock setup we had didn't
allow sftp/scp.  We can fix this by adding a line to the guest side sshd
config from mbuto.  While we're there correct an inaccurate comment.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

test: Fix passt.mbuto for cases where /usr/sbin doesn't exist

2024-01-16T20:48:31+00:00

f0ccca74 ("test: make passt.mbuto script more robust") is supposed to make
mbuto more robust by standardizing on always putting things in /usr/sbin
with /sbin a symlink to it.  This matters because different distros have
different conventions about how the two are used.

However, the logic there requires that /usr/sbin at least exists to start
with.  This isn't always the case with Fedora derived mbuto images.
Ironically the DIRS variable ensures that /sbin exists, although we then
remove it, but doesn't require /usr/sbin to exist.  Fix that up so that
the new logic will work with Fedora.

Fixes: f0ccca741f64 ("test: make passt.mbuto script more robust")
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

test: make passt.mbuto script more robust

2023-12-27T18:33:31+00:00

Creation of a symbolic link from /sbin to /usr/sbin fails if /sbin
exists and is non-empty. This is the case on Ubuntu-23.04.

We fix this by removing /sbin before creating the link.

Signed-off-by: Jon Maloy 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

passt: Relicense to GPL 2.0, or any later version

2023-04-06T16:00:33+00:00

In practical terms, passt doesn't benefit from the additional
protection offered by the AGPL over the GPL, because it's not
suitable to be executed over a computer network.

Further, restricting the distribution under the version 3 of the GPL
wouldn't provide any practical advantage either, as long as the passt
codebase is concerned, and might cause unnecessary compatibility
dilemmas.

Change licensing terms to the GNU General Public License Version 2,
or any later version, with written permission from all current and
past contributors, namely: myself, David Gibson, Laine Stump, Andrea
Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian
Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov.

Signed-off-by: Stefano Brivio