sshuttle merged to 1.1.0-1ubuntu1 fails autopkgtests - needs merged for kinetic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sshuttle (Ubuntu) |
New
|
High
|
Frank Heimes |
Bug Description
An attempt to merge sshuttle prior to jammy FF failed, because of autopkgtest failures.
The delta between Debian and Ubuntu is d/t/* only.
A v1.1.0-1ubuntu1 is available here: https:/
The failures can be found here:
https:/
Especially:
-------
remote-trusty: lxc start remote-trusty
remote-trusty: Waiting for remote-trusty to finish starting
this ssh connection should timeout:
running: lxc exec remote-trusty -- ssh -o ConnectionAttem
ssh: connect to host 10.252.0.1 port 22: No route to host
ssh failed (as expected)
running: lxc exec remote-trusty -- sshuttle --python python3 -r 10.254.0.2 10.252.0.0/24
waiting for sshuttle to start....sshuttle failed :-(
skipped 'This is an expected failure, ignoring test failure'
ERROR
=======
ERROR: setUpClass (__main_
-------
Traceback (most recent call last):
File "/tmp/autopkgte
remote = Remote(
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
raise Exception(f'Timed out waiting for remote {self.name} networking')
Exception: Timed out waiting for remote remote-xenial networking
=======
FAIL: test_local_
-------
Traceback (most recent call last):
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
VerboseAssertio
Test detail: testbed-trusty sshuttle 1.1.0-1ubuntu1 to remote-trusty
=======
FAIL: test_local_
-------
Traceback (most recent call last):
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
VerboseAssertio
Test detail: testbed-trusty sshuttle 1.1.0-1ubuntu1 to remote-trusty python2
=======
FAIL: test_remote_
-------
Traceback (most recent call last):
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
VerboseAssertio
Test detail: remote-trusty sshuttle 0.54-2 to reverse-
=======
FAIL: test_remote_
-------
Traceback (most recent call last):
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
File "/tmp/autopkgte
self.
VerboseAssertio
Test detail: remote-trusty sshuttle 0.54-2 to reverse-
-------
Ran 30 tests in 2749.995s
FAILED (failures=4, errors=1, skipped=2)
-------
It seems that this is likely due to jammy's move to cgroup2, which now prevents older trusty and xenial containers from starting.
Options are:
1) fix trusty and xenial to be able to boot as a container under jammy
2) disable the tests against trusty and xenial (which would be unfortunate, since its idea is to ensure Ubuntu cross-release compatibility of sshuttle)
This needs further investigations and discussions, hence opening this FFe.
summary: |
- [FFE] sshuttle merged to 1.1.0-1ubuntu1 fails autopkgtests + sshuttle merged to 1.1.0-1ubuntu1 fails autopkgtests |
tags: |
added: server-todo removed: needs-merge |
summary: |
- sshuttle merged to 1.1.0-1ubuntu1 fails autopkgtests + sshuttle merged to 1.1.0-1ubuntu1 fails autopkgtests - needs merged for + kinetic |
tags: |
added: kinetic needs-merge removed: jammy server-todo |
Changed in sshuttle (Ubuntu): | |
milestone: | none → ubuntu-22.05 |
importance: | Undecided → High |
Changed in sshuttle (Ubuntu): | |
assignee: | nobody → Frank Heimes (fheimes) |
I looked a bit more into the trusty failure and it seems like that isn't a cgroups issue, since it doesn't use systemd and instead uses upstart, which doesn't seem to care about what cgroup is mounted. On trusty, the problem appears to be that it's simply too old to run with the python from jammy.
By default, trusty sshuttle attempts to use 'python' on the remote system, which no longer exists in jammy.
If --python is manually specified using jammy's python3, it fails:
root@test-t:~# sshuttle --python python3 -r ubuntu@10.46.117.1 1.1.1.1/24 10.46.117. 1's password: sys.stdin. read(764) , "assembler.py", "exec")
^
ubuntu@
File "<string>", line 1
import sys; skip_imports=1; verbosity=0; exec compile(
SyntaxError: invalid syntax
client: fatal: server died with error code 1
If --python is manually specified using jammy's python2 (which isn't installed by default), that still fails:
root@test-t:~# sshuttle --python python2 -r ubuntu@10.46.117.1 1.1.1.1/24 10.46.117. 1's password:
ubuntu@
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "assembler.py", line 26, in <module>
File "server.py", line 170, in main
File "server.py", line 71, in list_routes
File "server.py", line 51, in _list_routes
File "ssubprocess.py", line 606, in __init__
File "ssubprocess.py", line 1117, in _execute_child
OSError: [Errno 2] No such file or directory
client: fatal: server died with error code 1
So it may not be possible to use sshuttle from trusty->jammy at all, unfortunately, and the jammy autopkgtests might need to just stop running the trusty->jammy tests completely.
Note that the jammy->trusty connection does appear to work.