Expose salt event publisher for Saline

[vzhestkov]

What does this PR change?

To include Saline with the separate container to the server it's required to expose salt event publisher socket.
Originally it's published with unix socket, but in case of changing the transport to tcp it's listening on 127.0.0.1 and it's hardcoded, so socat is used here to expose the socket as tcp.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

Test coverage

ℹ️ If a major new functionality is added, it is strongly recommended that tests for the new functionality are added to the Cucumber test suite

• No tests: TBD once Saline will be included to the server deployment.

Links

Tracks: https://github.com/SUSE/spacewalk/issues/24751

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

Before you merge

Check How to branch and merge properly!

[rjmateus]

Do we need to expose one more port with this? I'm assuming not, since this port should be for consumption inside the uyuni network and not exposed to the outside world.
Do you think we need to have some kind of authentication mechanism for it?

[cbosdo]

This basically boils down to sharing the IPC namespace between the saline container and the server one. Did you try https://docs.podman.io/en/latest/markdown/podman-run.1.html#sharing-ipc-between-containers ? In any case this should probably not be the default and only added if saline is enabled.

[vzhestkov]

@rjmateus this port is not intended to be exposed outside, but required just for saline container to connect and it's working in one direction only, but exposes the unencrypted data. Do we need to protect it somehow if we are not going to expose it except to the other containers on the server? In case of detaching salt-master and salt-api we should expose couple more ports the same way to make it possible for salt-api to communicate to salt-master.

@cbosdo feel bit stupid but I didn't get how it could be applicable here, the section you send the link to is describing interprocess communication with shared memory, but in this case it's just a socket. There is a way to enable tcp transport there in the master config, but it's using hardcoded 127.0.0.1 and can't be exposed that way. If I understood the idea wrong, could you please point me to more clear example of using such approach?

[cbosdo]

@cbosdo feel bit stupid but I didn't get how it could be applicable here, the section you send the link to is describing interprocess communication with shared memory, but in this case it's just a socket. There is a way to enable tcp transport there in the master config, but it's using hardcoded 127.0.0.1 and can't be exposed that way. If I understood the idea wrong, could you please point me to more clear example of using such approach?

IIRC Unix sockets are also parts of the IPCs and thus sharing the IPC namespace between saline container and the container running salt could do the trick.

[vzhestkov]

It's a type of IPC, but not using shared memory, basically it's a file and what I found before that in some cases it's shared as a file volume, I've read the section by the link you pointed, but still didn't get the idea how to make it working. And I can't find any example for such use case.