[sos_extras] Allow obfuscation in sos_extras configs

[pmoravec]

Resolves: #3768

---

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 protected]?
• 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-3768
• And now you can install the packages.

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

[pmoravec]

Limitations:

• different globs for files/cmds to collect (/path/to/file.log*) and to obfuscate in (/path/to/file.log.*) - this is user unfriendly
• no way to express space in either RE (to search or to replace)
• example line *:/path/to/files(.*) pass:\\s*(.*) \1******** should have \s instead of \\s but that would raise W605 invalid escape sequence '\s' :(

Worth to discuss:

• particular syntax

[TurboTurtle]

I'm torn on this.

On the one hand, it is useful functionality and I can see the practicality. On the other, we don't really want to encourage using sos_extras as an alternative to plugin development. It's chiefly meant to serve as a function of "I need this right away while a plugin is being updated or developed which is either currently happening or I am about to open a request for".

[pmoravec]

The request comes from a customer having some logs written to an unusual customized location that sos will never collect. But the logfile is important for troubleshooting. Like, e.g. /var/log/httpd/access_log is moved to /var/log/httpd/my_custom_access_log.

The httpd access log is just ilustrative example. I will check if we can't (or even shouldn't) parse some config file that specifies such custom logfiles, and collect the custom logfiles automatically.