feat: include nsenter when building util-linux binaries

[the-wondersmith]

PR just includes nsenter in the subset of built binaries when compiling util-linux. Specifically, having nsenter allows several common tools written in golang to run on Talos.

[smira]

This seems to be part of linkerd story, what exactly calls nsenter in this case?

[the-wondersmith]

This seems to be part of linkerd story, what exactly calls nsenter in this case?

linkerd-proxy-init ref. It's not strictly a linkerd-only issue though. It actually stems from a golang quirk, which in turn affects anything that would do cni-similar things on talos.

[smira]

That is not true for sure, as Talos itself is using CNI and netns without any issues (not inside Talos Linux, but talosctl cluster create in QEMU mode). So calling out to nsenter/iptables is more like solution from 5 years ago, right now goroutine can easily enter netns, do nftables calls as needed (no iptables!), and so on.

This PR will put nsenter to /usr/local/bin, not /usr/bin, so not sure if Linkerd would be able to call it this way.

[the-wondersmith]

...

This PR will put nsenter to /usr/local/bin, not /usr/bin, so not sure if Linkerd would be able to call it this way

Is /use/bin not in PATH by default? Assuming it is, it shouldn't be an issue 🙂

[smira]

I don't know what is the $PATH in that case.

[the-wondersmith]

I don't know what is the $PATH in that case.

Far easier to do PATH resolution than to shadow box the go runtime 😅. Are there any objections to merging the change?

[smira]

Are there any objections to merging the change?

Can you actually get it tested?

[the-wondersmith]

...

Can you actually get it tested?

Happy to 🙂

Given that the change only enables one extra output from a build process that is itself already proven and tested, could you please define what additional checks you'd like to see to constitute "tested" in this instance?

[smira]

Given that the change only enables one extra output from a build process that is itself already proven and tested, could you please define what additional checks you'd like to see to constitute "tested" in this instance?

I mean build & install this extension to Talos, and verify that Linkerd works now.

[the-wondersmith]

I mean build & install this extension to Talos, and verify that Linkerd works now.

On it 🫡

...
Can you actually get it tested?

FWIW, here's the diff from dive in visual form:

Current Build Output

Proposed Build

---

For anyone who's curious why the current image appears almost completely empty despite the inclusion of --enable-libmount --enable-libblkid and --enable-fstrim in the current manifest, it's because the install step runs rm -rf /rootfs/usr/local/{include,lib,share} after it completes. Here's what the images look like without those removals.

Current Build Output (without post-install scrubbing)

Proposed Build Output (without post-install scrubbing)

[the-wondersmith]

@smira Well... that was 8 shades of Less Than Fun™, but I got it done in the end 😅 🎉

Steps:

1. create a cluster normally (as per the docs): talosctl cluster create
2. deploy linkerd
3. immediately get the expected error:

4. destroy ^ that cluster
5. create new cluster w/ customized images: talosctl cluster create --image='docker.io/thewondersmith/talos:v1.7.2-nsenter' --install-image='docker.io/thewondersmith/talos-installer:v1.7.2-nsenter'
6. deploy linkerd
7. success (as expected)

---

All of the images used in testing are public and available for your inspection and independent verification if you'd like:

• docker.io/thewondersmith/talos:v1.7.2-nsenter
• docker.io/thewondersmith/util-linux-tools:2.40.1
• docker.io/thewondersmith/talos-installer:v1.7.2-nsenter

[smira]

For anyone who's curious why the current image appears almost completely empty despite the inclusion of --enable-libmount --enable-libblkid and --enable-fstrim in the current manifest, it's because the install step runs rm -rf /rootfs/usr/local/{include,lib,share} after it completes. Here's what the images look like without those removals.

This is expected, as it uses those libraries from the host (they're already there), to make extension size smaller.

[smira]

success (as expected)

thanks for testing it, I can get this change to the queue of changes to Talos 1.7, so it pops up in 1.7.3

[smira]

/ok-to-test

[smira]

/m