[sunbeam] Update plugin to collet more details

[arif-ali]

• Add juju related info for sunbeam
• Add logs from the sunbeam snap home user

Resolves: SET-682

---

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 yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3646
• And now you can install the packages.

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

[pmoravec]

Sounds good to me (from a pure sos side, not knowing either command or file to be collected).

[arif-ali]

I think this does a beg a question, should we improve some of the commands to be able collect commands as a user, so we're not doing blanket su - <user> for every command we want to collect.

The problem also I have this which I discovered last night, is that 2 of these commands will also collect certs within the command itself. If the command could be different, do I put the same login the the postproc(), it just seems like duplicating code. I'll have a think on how best to do it, but others might have an idea already. i.e. would I be ok to use do_cmd_private_sub in setup() to avoid all the complications here?

This is here for collaboration with my team at the moment, and do some improvements.

[pmoravec]

I think some support for "running under user" within Plugin class makes a lot of sense. Three other plugins (aap_eda, saphana and sapnw) will utilize from it as well.

[arif-ali]

This did not work with runas argument as this command has some interactive related items, and the only way to get this working was via su

[pmoravec]

If the user does not exist, getpwnam raises an exception that will end up in sos_logs/sunbeam-plugin-errors.txt:

>>> pwd.getpwnam('no-user')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: "getpwnam(): name not found: 'no-user'"
>>> 

Technically it doesnt matter much since even catching the exception will cause the plugin wont collect anything (due to if user_pwd), just that scenario looks bit non-professional.

Leaving on @arif-ali to decide if it is worth fixing it - I dont want to block this "form of error reporting" point from merging.

[arif-ali]

good catch, I agree it's looks non-professional if that error file is created; I will fix and re-upload. Thanks for catching this; this is exactly why we have others reviewing things