A couple of things here:

• previous experience with rpm has shown that it is often good (if possible) to use a standard uid. Not doing so can lead to issues if the resulting new user has different values and you start copying files from one system to another. With orchestrator it's likely that more than one orchestrator app is running on a system and it's likely that you want these uids to be consistent. Consequently if it's possible in the fpm packaging to provide a suggested (but overridable user/group id) that would be good.
• Generally with the choice between using systemd or using older init scripts if possible I'd prefer the package to be able to figure out which version is appropriate depending on the target OS and version. How possible that is I'm not sure. So perhaps it's possible to recognise at least some OS/version combinations and auto-configure these accordingly. A simple example would be CentOS 6 and earlier uses init scripts, CentOS 7 and later uses systemd. I'd expect that for Debian and Ubuntu similar rules could be found. Others can probably provide support for their faviourite OS and if the combination can't be found force the user to specify the right value.

So it's nice to see support for systemd and also to move away from running as root. Given orchestrator's default port bindings are above port 1024 this change shouldn't make any big change. However, it may mean that scripts expected to run as root may no longer work or require the use of sudo or equivalent if root functionality is required. I guess people who have already written such scripts to deploy with orchestrator will need to be aware of this change as it might cause surprises during MySQL failover handling which would not be good. Maybe if orchestrator should/could log if it's not running as root to make this a bit more noticeable. An extra log line won't cause any harm.

This build fails on one of my boxes: ERROR: Unrecognised option '--user' in fpm execution.

Which means we depend on a specific version of fpm to build orchestrator, which is not a good thing. For a while now I've been considering replacing fpm with nfpm. fpm is a real hassle to install what with ruby versions, various gem dependencies, different OS versions.

So I'm inclined to look into nfpm and include it as a binary within orchestrator's repo.

@mateusduboli which version of fpm are you using? I'm using fpm-1.10.2

So @shlomi-noach, the problem was it needed package prefixes for user and groups.
It's fixed now :)

Extremely sorry for dropping this. Looking into.

Generally with the choice between using systemd or using older init scripts if possible I'd prefer the package to be able to figure out which version is appropriate depending on the target OS and version.

@sjmudd I don't see that there's a generic way to do that. Solutions I see use Post-install scripts to copy either sysv or systemd script to the right place. I'ts not the prettiest.

So it's nice to see support for systemd and also to move away from running as root. Given orchestrator's default port bindings are above port 1024 this change shouldn't make any big change. However, it may mean that scripts expected to run as root may no longer work or require the use of sudo or equivalent if root functionality is required. I guess people who have already written such scripts to deploy with orchestrator will need to be aware of this change as it might cause surprises during MySQL failover handling which would not be good.

Oh yes, I agree. It's great that this PR moves away from root but we also need to consider existing installations. Thinking about this for a bit.

I'm pivoting at #915

Nice work on systemd :)

Is it just me or you need to add :
[Install] WantedBy=multi-user.target
in order to enable this unit file ?
Before I done that, on RedHat reboot, systemd didn't reload orchestrator.service and the command systemctl enable orchestrator.service did nothing.

Is it just me or you need to add :
[Install] WantedBy=multi-user.target
in order to enable this unit file ?
Before I done that, on RedHat reboot, systemd didn't reload orchestrator.service and the command systemctl enable orchestrator.service did nothing.

Same problem

@Honiix could you please open a PR?