Arch Linux policy

[mawiegand]

Hey,

I’d like to see support for Arch Linux, and since there hasn’t been any progress on #1198 for a while, I’ve created a new pull request to introduce a policy for Arch Linux. I’d be thrilled if the policy made it into a release. I look forward to your feedback and/or any next steps I can take to make this happen!

Thanks! 🙂

Resolves #1198

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo dnf install -y 'dnf*-command(copr)'
• dnf copr enable packit/sosreport-sos-4273
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[TurboTurtle]

Overall, pretty solid. Just a couple notes, but nothing major.

[TurboTurtle]

No need to define this in the subclass, as it is handled in the base LinuxPolicy. Just set the os_release_name class attr.

[mawiegand]

Thanks for the feedback. I did this to support ID_LIKE as well. See: https://www.man7.org/linux/man-pages/man5/os-release.5.html#OPTIONS

Or am I missing something, and is this also supported in the base LinuxPolicy? Or should I handle this differently?

[pmoravec]

So then it is better to extend https://github.com/sosreport/sos/blob/main/sos/policies/distros/__init__.py#L118, rather than having an extra care for one distro..?

[TurboTurtle]

We don't have a pattern of subclassing Plugins like this (into new plugin sources).

If there is truly nothing different about the collections except the kube_cmd and a single yaml file, I'd suggest we move this into the base kubernetes plugin. I'm not super familiar with k3s myself, but aren't there a reduced number of features with k3s? If so, we'd probably see a lot of collection failures when just directly subclassing the "normal" plugin, but I definitely get not wanting to re-write a plugin as large as that one just to strip out what may not actually be a lot of collection attempts.

@pmoravec or @arif-ali happy to hear your thoughts here too.

[mawiegand]

As far as I'm concerned, we're welcome to move this to kubernetes. I haven't noticed any issues with the collection process in the past. However, the plugin from my fork hasn't been used for quite some time. Alternatively, we could just drop it entirely, as far as I'm concerned. It doesn't have any direct connection to Arch Linux, and k3s is only available in the AUR.

[pmoravec]

+1 for moving it under Kubernetes.

[mawiegand]

Moved it to kubernetes as suggested.

[mawiegand]

@TurboTurtle can this be resolved?

[mawiegand]

Overall, pretty solid. Just a couple notes, but nothing major.

Thanks, @TurboTurtle for the fast feedback! Do you have any suggestions on how I can best handle the sos/report/plugins/filesys.py:108:0: R0901: Too many ancestors (8/7) (too-many-ancestors) error from pylint?

[jcastill]

Do you have any suggestions on how I can best handle the sos/report/plugins/filesys.py:108:0: R0901: Too many ancestors (8/7) (too-many-ancestors) error from pylint?

I think there are two possibilities here, one quick and easy, the other one a bit more complex:

• Simple solution: disable the check with # pylint: disable=too-many-ancestors on top of the function, i.e.:

# pylint: disable=too-many-ancestors
class RedHatFilesys(Filesys, RedHatPlugin):

• Bit more complex solution: The RedHatFilesys class has only one capture, a listing of /tmp. This doesn't exist in the Filesys class, but I think it could be useful to capture that as well for the other distros there. So, this approach will mean:

1. Remove the RedHatFilesys class, and
2. Add the capture to Filesys, like this:

...
        for dev in self.do_regex_find_all(ext_fs_regex, mounts):
            self.add_cmd_output(f"dumpe2fs {dumpe2fs_opts} {dev}",
                                tags="dumpe2fs_h")

            if self.get_option('frag'):
                self.add_cmd_output(f"e2freefrag {dev}", priority=100)
        self.add_cmd_output(f'ls -ldZ {self.policy.get_tmp_dir("/tmp")}')

    def postproc(self):
...

Note: We may want to change that self.add_cmd_output to:

self.add_dir_listing(f'{self.policy.get_tmp_dir("/tmp")}'

This solution will need that you add the _tmp_dir variable in the Arch policy, but I think that's something you should do anyway so it's consistent with most of the other policies.