namespace info depends on /boot files

[terinjokes]

Running youki info prints information about the running system. Part of this information is the enabled Linux namespaces. However this information is silently omitted if the file at /boot/config-$(uname -r) is not available:

https://github.com/containers/youki/blob/a72a33b3e946a33d83d555f210e89401ef57cef6/crates/youki/src/commands/info.rs#L180-L183

$ youki info | grep Namespaces

I propose two enhancements to this command:

1. If available to the youki process, use the "Kernel .config support" at /proc/config.gz as an alternative to parsing /boot.
2. If neither option is available, print status to alert the user to the missing information.

[Furisto]

1. Seems reasonable. Back when I implemented this, I left out checking /proc/config.gz because I did not want to add an additional dependency for reading gzipped files without knowing on which distributions this is actually a problem. What distro are you using? Would you be interested in implementing it?

2. I do not see a reason to print a warning message, because the intended audience is not the user, but the developers of youki. If someone copies this into an issue, we already know why it is missing.

[terinjokes]

I'm on NixOS, but also work with systems that network boot (and thus don't have a /boot partition). I can take a look at implementing this, but my Rust isn't super great, so I might not be successful.

[Furisto]

Sure, I will assign you. You can reach out here if you are facing any problems.

[YJDoc2]

Hey, looking at this, from man page https://man7.org/linux/man-pages/man5/proc_config.gz.5.html it says

As long as no changes have been made to the following file, the
contents of /proc/config.gz are the same as those provided by:
cat /lib/modules/$(uname -r)/build/.config
/proc/config.gz is provided only if the kernel is
configured with CONFIG_IKCONFIG_PROC.

If so @terinjokes do you think we can get away with reading the info from modules instead of the gz file? That way the issue with /boot not being present would be resolved and we won't need to add a dep for opening gz files just for this case.

[terinjokes]

I haven't thought about this issue in nearly 2 years. Is there a particular need to check config.gz or config? All the other runtimes work without this information available. AFAICT this is just informational, so just printing that it couldn't do a config check is probably fine?

I don't think the availability of the build directory under /lib/modules/$(u name -r) can be assumed: I don't have it on any of my systems.

[YJDoc2]

I haven't thought about this issue in nearly 2 years.

I was just cleaning up old issues and this seemed good one to start on : )

Is there a particular need to check config.gz or config

I think that was the original solution mentioned by you 😅

I don't think the availability of the build directory under /lib/modules/$(u name -r) can be assumed: I don't have it on any of my systems.

Ok got it 👍

this is just informational, so just printing that it couldn't do a config check is probably fine?

Yeah, I think a quick and best solution would be that if we cannot find the config, we just print UNKNOWN in the place.

All the other runtimes work without this information available.

What did you check? both runc info and crun info are not valid. As far as actual working of youki as contianer runtime goes, yes we do not need to parse the config at all.. This is only for the info command to see if namespaces are enabled or not.

[terinjokes]

Yeah, I think a quick and best solution would be that if we cannot find the config, we just print UNKNOWN in the place.

SGTM.