Test Parsec installation as a systemd daemon

[hug-dev]

It would be nice to have PARSEC installed and run inside a Docker container as a systemd daemon from a local checkout of this repository.
The container could share with the host the Unix socket to communicate with the daemon.
This could be put in the CI to test systemd installation.

[hug-dev]

This should exist only to test Parsec installation with systemd, the communication should only happen inside the container.

[hug-dev]

An installation script could be used out of this!

[anta5010]

I've been looking at this issue and I think we need to clarify its requirements.

For information only:

1. Initial work was done as a part of Make PARSEC a daemon #35 PR: Add a compile-time option for a daemon binary #46
2. Additional changes were made in PRs: Improve handling of systemd activation #50 and Add provider configuration #51

The small issues I noticed:

1. The parsec systemd service definition is missing --config parameter
2. The "How to install Parsec on Linux" page is missing a recommendation to un-comment "log_timestamp = false" when Parsec is deployed as a service.
3. Hard-coded SOCKET_PATH in parsec service and parsec test clients source code is different from the one defined in the systemd socket definition file. The socket path is documented anywhere.

The main question I have now is what exactly do we want to achieve with this issue?

• Is it about developing, documenting and testing a parsec deployment procedure? Do we know what the typical deployment would be (from a local repo or from crates.io, service on a host or process in a docker container for example, standard service or socket activated one, etc)? Should we cover all?
• What type of systemd service should be tested - standard or socket activated? Do we expect that socket activated services might be used by customers?
• Would manual testing be sufficient or we need a CI one? To be able to use systemd inside a docker container we need to either run the container as privileged (tested on MacOS) or with "--volume /sys/fs/cgroup:/sys/fs/cgroup:ro" parameter (not tested, I need a linux machine for that, doesn't work on MacOS). I don't think the first option is allowed for github CI containers and not sure about the second one as well.

[ionut-arm]

@hug-dev did most (all?) of the work around setting up the "Parsec-as-a-systemd-service" feature, so I can't really comment on most of these things, but I will touch on (3) briefly:
We definitely should document the socket path somewhere and it should be a hardcoded value. As I remember, socket activation was a nice feature to have so that Parsec wouldn't be idling, waiting for a connection, but I'm not sure if we ever resolved the question of "how does a client know where the socket is in that case?" Potentially with an environment variable or with the admin creating a symbolik link from daemon socket to hardcoded socket path?

[anta5010]

The question about "where the parsec socket is" exists in all cases, not only in socket activated systemd service.

[ionut-arm]

Not if the socket path is hardcoded and everyone knows exactly where it should be! Then it might, at most, become a problem for the admin if that path is not available.

[anta5010]

Sure, I just meant that the path should be properly documented because it's needed for all cases.
BTW, I would prefer to have it in /var/run/parsec instead of /tmp. But, because it would require root privileges for parsec deployment, may be we can use something more parsec specific than we use now. For example /tmp/parsec-service/daemon-socket

[ionut-arm]

The reason why a lot of this isn't solidly decided on yet is that we've not had a proper production use case to aim and cater for.

Making the path as Parsec specific as possible is definitely a good aim! I think having root privileges for deployment is sensible to expect, as long as anyone can actually access the socket and write/read from it. It would certainly mitigate some possible threats around other users impersonating Parsec by popping a socket at the right path in the /tmp folder.

[anta5010]

FHS even recommends to use /run instead of /var/run (although I saw deployments where / was mounted read-only)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html

Anyway, we just need to remember that for development/manual testing we should be able to run parsec without root privileges.

[hug-dev]

Thanks for your investigation! A few comments on my side:

• the socket path is documented in the Listeners page.
• the installation method described in the book is to install Parsec as an user systemd daemon, without root privilege. Note the --user option to systemctl commands.
• the configuration path is not in the systemd unit file as the daemon is meant to be started from the home directory of the parsec user.
• thinking about it now, having the socket inside the parsec home directory is not a good idea: this folder will probably not be readable by other users. As you mentioned, we should as well probably put the socket in a more idiomatic location. Having a socket in /run but which is read/writable by other users seems a good idea to mitigate the spoofing threat about it as @ionut-arm said. I think it is expected that some parts of the installation step expect root privileges. But then, if the socket does not exist at that path, Parsec will try to create it, but it won't have the good privilege! This needs to be investigated I guess.

Having at least one installation method that is tested (can be nightly) on the CI would be good I think to make sure that it is possible. Even if that installation method will change in the future.

[hug-dev]

@joechrisellis looked at it in #218
systemd is not directly meant to be used inside a Docker container which makes the testing complicated.
This issue could be changed into "testing the Linux permission over the socket with a parsec user creating the service and multiple client users trying to access it".

[hug-dev]

Closed in favor of #245