[ssh] Disable option 'userconfs' by default

[jcastill]

Having this option enabled by default
can cause problems when users have their
home directories on automount. Leave the
option disabled by default so if needed
we can enable it in the command line.

Related: RHEL-22389

---

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?

[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-3490
• And now you can install the packages.

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

[arif-ali]

Personally, changing a default behaviour can give unexpected behaviour, especially if we're expecting it to be there. My hunch here is that we leave this as is. As it typically helps to debug wrong permissions in .ssh, and it is very rare (at least in my experience) to find an environment that we're supporting that has automount.

If we could tackle this in a different way, I would rather go in that direction.

just my 2 cents on this

[jcastill]

Personally, changing a default behaviour can give unexpected behaviour, especially if we're expecting it to be there. My hunch here is that we leave this as is. As it typically helps to debug wrong permissions in .ssh, and it is very rare (at least in my experience) to find an environment that we're supporting that has automount.

On the other hand, I have seen a couple of cases where this has happened to customers in the last month. So there's that. We already have an unexpected behaviour because of having this enabled by default.

If we could tackle this in a different way, I would rather go in that direction.

I'm open to any suggestions.

[TurboTurtle]

We could change the default of the plugin opt to our standard auto/on/off approach, and if auto, then we perform a check to see if autofs is in use for homedirs (perhaps easier said than done? I'm just spitballing here), and if it is we don't perform the collection. This allows off/False and on/True to be used by end users as desired.

[jcastill]

We could change the default of the plugin opt to our standard auto/on/off approach, and if auto, then we perform a check to see if autofs is in use for homedirs (perhaps easier said than done? I'm just spitballing here), and if it is we don't perform the collection. This allows off/False and on/True to be used by end users as desired.

I think this may work! Checking if home dirs are on autofs may be tricky, but I think I have an idea about how to do it.

[pmoravec]

Just to clarify:

• the option should have on/auto/off values, with auto as the default
• value on means current behaviour (collect dirs of all users)
• value off means no dirs of users are collected
• value auto means just dirs not on automount will be collected

Let me know if I understood it wrongly.

(I feel we are over-engineering the plugin option behaviour, tbh)

[TurboTurtle]

• value auto means just dirs not on automount will be collected

Not exactly. auto means "check if we're using autofs for home dirs, if we are behave as if this option is set to False, else (if we are not using autofs and only have locally mounted user homedirs) behave as if it is set to True".