Feature Request: Using the module without Tmux

[frantisekhanzlikbl]

Hi. First things first, thanks for your (and all the contributors') amazing work on this! I spent far too much time packaging various servers & proxies myself, and this project is going to make my life much easier. :heart:

I'd also love to migrate my ad-hoc solution to the provided module, but I don't really like the fact that it runs the server in a tmux session. I love Tmux as a terminal multiplexer, but using it for services has some really annoying problems that I don't think can be solved in any elegant way:

• Logs don't end up in the system journal—this is probably the biggest one. This means that when something goes wrong and the service crashes, I am left without any information whatsoever unless it ends up in the server logs (which, e.g., startup script failures won't.). It also means I can't process the logs automatically via Loki, fail2ban, and other such tools.
• The server can't be nicely automated from the outside. I really don't want to blindly pipe random keys into tmux and pray that they end up in the command prompt, not mixed with some other rubbish.
• Connecting to the socket remotely is unnecessarily complicated.
• Although not strictly forced by using tmux, I dislike having to run all servers under the same user. Ideally, I'd use systemd's DynamicUser for every server. Supporting this with Tmux would be fairly complicated.

A solution that I use currently, which has none of these problems, is to just run the server process directly, controlling it via RCON. It's not perfect, particularly because none of the RCON clients I could find are very nice, but I find it to be a much cleaner approach.

I'd love to add support for this workflow to the provided module, but I'm not sure whether such a PR would be accepted. If so, how do you think it should work? A global toggle? A per-server one? Something else? I'm open to all suggestions.

Thanks in advance!

EDIT: I just noticed #52, which addresses most of these issues. I guess I'll use the fork from there for now, and add support for multiple users after it lands.

[Infinidoge]

I'd rather not use tmux either, however unfortunately I haven't really found a good replacement that is less weighty yet. Abduco or similar would be a preferable replacement. The reason why it uses tmux at all is so that the actual console can be accessed, because annoyingly that is impossible to do directly via systemd sockets. (And IMO, rcon is just plain bad. I tried to use it once and stopped immediately because it was so inadequate. I like to actually see what's happening as the server runs lol. Admittedly I do use commands more extensively through the console than the average admin.)

As per that PR, it will hopefully in the future be a configurable option, it just isn't yet. If I get some free time, I might poke at it myself, however being in college unfortunately ties up most of my time.

[frantisekhanzlikbl]

Yeah, I feel you. I'm in college myself, and it's nearly impossible to find time for anything. It's true that RCON is pretty bad, but to be fair, you still get some amount of feedback, so I've been willing to stick with it for years. I'll see if I find the time to make #52 mergeable, but no promises for now. :-)

EDIT: also worth mentioning: my biggest problem with RCON is probably the lack of decent clients, but I'm hoping that fRCON might be a huge advancement in that area.

[Infinidoge]

Personally the biggest problem for me is that I don't get a live console output, only responses to commands, when I rely a lot on the console output. fRCON does seem to be a big improvement, at least.

[frantisekhanzlikbl]

Yep. I get what you're saying. I mostly just use journald -f, but I'm still very much pro making the behaviour configurable, if only to keep backwards compat. I'll try to make #52 configurable when I find the time and make a PR. Until then, unless you think this isn't really a problem, I'd probably keep this issue open.

[Infinidoge]

The issue will definitely stay open. I'm surprised I hadn't made one myself for it before, since this is an issue I've known about and intended to fix for the longest time.

[frantisekhanzlikbl]

Alright, I planned to move this forward much sooner, but college was colleging & job jobbing, so I didn't have a single hour of leisure time in the last two months. #67 should be a good step in the right direction, though. :slightly_smiling_face:

[Infinidoge]

Thanks for the PR! It's absolutely a step in the right direction, and it uses submodules in a way I hadn't considered using for it, definitely need to use submodules more.