ziti agent should look for systemd ziti service unix domain sockets in well known locations

[plorenz]

ziti controllers and routers running under systemd don't have access to /tmp, but can put their unix domain socket files under /var/lib/ziti-controller and /var/lib/ziti-router. We should check for those locations as well as scanning /tmp.

[qrkourier]

The Linux deployments will use these file paths after this issue is resolved:

• /var/lib/ziti-controller/agent.sock
• /var/lib/ziti-router/agent.sock

[dovholuknf]

what happens when you run more than one controller or more than one router? this worries me a bit.

[qrkourier]

what happens when you run more than one controller or more than one router? this worries me a bit.

The ziti agent command has options for disambiguating the target socket when both controller and router are running concurrently. It's not currently possible to run two controllers or two routers with the Linux deployments.

[michaelquigley]

Why agent.sock? Typically a unix domain socket is named for the service offering it, not the client consuming it...

[qrkourier]

Why agent.sock? Typically a unix domain socket is named for the service offering it, not the client consuming it...

The current name for controller and router socket files is like gops-agent.1110840.sock, and there's no good reason for me to pick agent.sock. Is /var/lib/ziti-controller/ziti-controller.sock superior?

My mention of new socket file names for Linux deployments is about this linked issue. The issue here about looking in additional locations for sockets would enable Linux deployments' sockets to be discoverable by a ziti agent command that is run as root, eliminating the extra steps to locate the socket.

[michaelquigley]

I would think either retaining the gops portion of that name (gops-agent.sock), or naming the socket after the component, as in controller.sock or router.sock would make more sense. If you named them controller.sock and router.sock, you could keep then in a /var/run folder, which seems more appropriate to me than /var/lib.

[qrkourier]

/var/lib/ziti-controller/controller.sock or /var/lib/ziti-controller/gops-agent.sock are equally fine. I'll use /var/lib/ziti-controller/gops-agent.sock in the absence of further feedback. All that's required is that this issue changes ziti agent to include the new socket file paths in the set of well-known paths when running on Linux.

The linked issue about changing the path and filename for the Linux deployments uses the existing state directories under /var/lib assigned by systemd to the service unit, e.g., /var/lib/ziti-controller/. Using those state directories avoids the need to mount an additional packager-defined directory in the controller or router's filesystem namespace where the restricted PID has filesystem write permissions. /var/run, which is a symlink to a tmpfs filesystem mounted on /run on my system, is read-only inside the service unit's filesystem sandbox so it would not be practical for the service to create a socket file there.