Fixes support for syslog when salt is running as non-root user

[shadow38]

What does this PR do?

Same as #62263

The documented way to write to syslog is to use the config: log_file: file:///dev/log.

This breaks in some circumstances when running as non-root, for example, when log_level: info is set. In that case, /dev/log is not "writeable", so the code falls back to writing to /root/.salt/master.log, which is definitely not writeable by the non-root user salt is configured to run as.

This is an improved version of the original PR #62263. This PR uses an improved syslog path parser to manage all variant of syslog path supported by salt (file and tcp / udp connection). This function is mainly based on the salt source code. (see salt._logging.impl#setup_logfile_handler)

This version should work on any os.

What issues does this PR fix or reference?

Likely also fixes: #61286

Previous Behavior

Salt will try and write logs to /root/.salt/master.log, which is inaccessible when running as non-root, which means salt-master crashes out with a permissions error.

New Behavior

salt-master starts correctly.

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

No

[dwoz]

@shadow38 I think this PR should be made against 3006.x

[shadow38]

Closing this PR as requested by @dwoz.
Reopening with target branch 3006.x instead of master: #68890

[bdrx312]

What happens if /dev/log is used instead of file:///dev/log?

[shadow38]

This is not working because writing to a syslog endpoint ( through a unix socket file or a tcp / udp channel) should be done by a syslog handler. If you define the log path as /dev/log, salt tries to write to it as a normal file and crashes. This PR reuse some syslog path parsing from salt source code to fix a bug which is present since a very long time.

If you read the manual, you'll see that we can also define a factory in the syslog path.

In my job, we try to use journald for almost everything and try to not rely on the rsyslog / logrotate packages (we are deploying saltstack in a debian environment) because we don't need to have log in clear and in a separated log file. We are sending all the logs using otelcol to a centralized logging system and the easiest way to do this job is to rely on a journald receiver provided by otelcol-contrib and not building a custom file log parser

(I also have a native implementation through a custom log_handler for journald; this is maybe the way to follow but this PR is still relevant)