Rust rewrite of the dbus code

[dmulder]

This is just an FYI, I'm working on porting the dbus code for this plugin to Rust here: himmelblau-idm/himmelblau#335

Would you guys be interested in having this in your codebase? I can submit an MR if so.

[jan-kiszka]

Sound interesting. But what will be the list of additional crates needed for it? What will be the required rust version?

[dmulder]

It requires Rust version 1.70, and the crates clap, serde, serde_json, tokio, uuid, and zbus.

The advantage is that it dramatically decreases the installation dependencies. You're left with a single, less than 4MB, standalone binary:

dmulder@dmulder-Standard-PC-i440FX-PIIX-1996:~$ file /usr/bin/linux-entra-sso
/usr/bin/linux-entra-sso: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=92ff4866266ba105b7c201f17b85fdc1c443967f, for GNU/Linux 3.2.0, stripped
dmulder@dmulder-Standard-PC-i440FX-PIIX-1996:~$ ldd /usr/bin/linux-entra-sso
	linux-vdso.so.1 (0x00007ffceb0d7000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070f980ca1000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070f980bb8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070f980400000)
	/lib64/ld-linux-x86-64.so.2 (0x000070f980ce0000)
dmulder@dmulder-Standard-PC-i440FX-PIIX-1996:~$ ls -lah /usr/bin/linux-entra-sso
-rwxr-xr-x 1 root root 3.7M Jan  6 17:00 /usr/bin/linux-entra-sso

[dmulder]

The primary reason I'm doing this is because the enterprise distros (RHEL/Rocky and SLE) don't have the Python dependencies required for the current linux-entra-sso.

[jan-kiszka]

And I thought you are switching the programming language for its own properties, not its packaging model... Vendoring dependencies into a package may only shift maintenance responsibilities into the latter, in the worst case multiplying them this way - the "modern" development model. Anyway, we cannot fix that here.

What we should keep an eye on is whether those crates are already common enough for recent distros so that we only get duplication of binary code, not of maintenance. And that looks ok to me from a quick check of current Debian. 1.70 is a bit too fresh there, though. And the zbus crate 5.2.0 is as well.

We likely don't want to maintain two versions of the same logic, just because some distros are too old to handle the rust variant yet. What would be your proposal to avoid that?

[dmulder]

Debian uses a dirt-old rust toolchain. I always just install it using rustup. Debian isn't really a great standard as far as tool chain versions. Their packages are all far older than the enterprise distros, simply for lack of maintainers, I assume.

And actually a customer originally requested I rewrite this in Rust because of it's memory safety, but then I also ran into the packaging issue.

Also, what does the version of the zbus crate have to do with the distro? Do you realize the distros don't package Rust crate versions (as far as I know)? The crates come from crates.io.

[jan-kiszka]

Debian does package zbus, like all the other deps you mentioned. If you are facing a distro that gave up on managing the Rust ecosystem "classically" and just let each package vendor around, see above.

I'm not against going to Rust. We just only to time that step properly. As Rust is still maturing in several ecosystem regards, it may be too early, though.

[dmulder]

Debian does package zbus, like all the other deps you mentioned. If you are facing a distro that gave up on managing the Rust ecosystem "classically" and just let each package vendor around, see above.

I wasn't aware that Debian had distro packages for rust crates. Interesting.