vmspawn: implement machinectl shell for vm class machines and send termination signal via D-Bus-over-SSH

[bluca]

Cannot push to org, so continuing here from #32208

[evverx]

Can I ask why instead of stabilizing the release and addressing known regressions like #30421 introduced by sloppy merges new features with no tests are being pushed in a hurry?

[YHNdnzj]

Yeah, since we've already taken over the PR, there's genuinely no need to rush it in. I'll move the milestone to v257.

[bluca]

Yeah, since we've already taken over the PR, there's genuinely no need to rush it in. I'll move the milestone to v257.

See yesterday's chat

[YHNdnzj]

Yeah, since we've already taken over the PR, there's genuinely no need to rush it in. I'll move the milestone to v257.

See yesterday's chat

I've read that. But there's no clear indication that we need to get this in for v256, and when you asked "anyone disagrees" I wasn't there...

[DaanDeMeyer]

This breaks registering vmspawn vms when using newer vmspawn with older machined, which is pretty much every vmspawn invocation right now. The varlink method will not be available and registering will fail.

[bluca]

Rebased on top of #32709

[evverx]

See yesterday's chat

Can anyone copy-paste that here for mere mortals to see?

[evverx]

Either way I guess the question isn't going to be answered. It answers my question too in a different way.

[evverx]

@bluca can you please stop deleting comments? That's not how open source projects are supposed to operate.

I've found the feedback form on the STF site and I'll contact them. I was going to do that anyway in the context of their bug resilience program. Thanks to the recent improvements (which I have no problem with) and miscommunications (which are problematic) I pulled out my downstream fuzzing infrastructure (even though it isn't broken yet) and they'd probably be interested to see the spreadsheets showing how much they should invest in the infrastructure alone to even cover the basics. Just to be clear I don't think it's STF fault. They were probably be misled into thinking that there is some actual upstream infrastructure where use-after-frees appear out of thin air.

[bluca]

Rebased and picked changes from #32482

[keszybz]

Since we're supposed to merge this after -rc1, the commits must include a solid explanation what is being done and why and what the implications are.

[keszybz]

Code LGTM.

I think it's fine to merge this now. The first commit is a fix, and the other two are relatively simple plumbing changes that will make machinectl shell much more useful. The work of vmspawn and related parts is a big part of this release, so we want to make it work as well as we can. We're after -rc1, but I think this a change of this magnitude is reasonable if it complements some changes that were done earlier in the cycle.

[keszybz]

Ubunutautopkgtests are busted.

[evverx]

Code LGTM.

There are still no tests though as far as I can see.

the other two are relatively simple plumbing changes that will make machinectl shell much more useful

The commit where ssh was chainloaded was removed as far as I can tell so machinectl shell doesn't use that. There were a few other PRs in the meantime apparently where it was probably implemented (or not).

[evverx]

Looking at

ssh: Could not resolve hostname vsock/2747562528: Name or service not known
Failed to get init process of VM: Transport endpoint is not connected

I'm not sure stuff should get stuck like that for several hours but OK.