Configuration organization and improvements

[NiceGuyIT]

This is a continuation of the discussion about configuration options. The goal is to allow the server operator to manage configuration options specific to their install (e.g. domain name) while still maintaining application specific configuration options (e.g. log path or log level).

Environmental variables

Environmental variables can be stored in /etc/trmm. Installation will create these files with the basic configuration. Updating will add variables if they don't already exist. Docker can pass the environment through to the containers.

/etc/trmm/celery.env
/etc/trmm/nats-api.env
/etc/trmm/nats-server.env
/etc/trmm/rmm-uwsgi.env

Command line parameters.

Command line parameters can be defined in system defined locations and passed to the systemd service using $ARGS. The location, /etc/default or /etc/sysconfig, may differ for each distro. Where possible, the Linux Standard Base and Filesystem Hierarchy Standard should be followed.

Service files

The service files can be moved to their own directory outside the install.sh and update.sh scripts. Improvements to the systemd service can be made to the *.service files and the update.sh script can install the changes if needed.

User creation

If we make the assumption systemd is available, systemd-sysusers can create system users. This solves the adduser vs useradd dilemma: the installation docs use both. I believe this can be improved, and maybe bootstrapped from root before running the install script as the user.

Directory and file creation with permissions

Again, making the assumption systemd is available, systemd-tmpfiles can create directories/files, apply permissions and change ownership.

Note: while systemd's RuntimeDirectory can create directories, more complex configurations should use tmpfiles.d.

[wh1te909]

I'm ok with all the suggestions. Would you be able to make PR's with these changes? Doesn't have to be done all at once we can do gradually. If we change the install script though we'll also need to add the changes to the update script to migrate existing installs over to the new structure.

[NiceGuyIT]

Yes, I can work on the PRs. I've been meaning to give it a shot but haven't had the time.

If we change the install script though we'll also need to add the changes to the update script to migrate existing installs over to the new structure.

The backup and restore scripts will also need to be considered as they may be impacted by the change.

[wh1te909]

sounds good, no rush. ah yea meant to also say backup and restore scripts too, thanks!

[ninjamonkey198206]

I think I've got most of these built-in in some way to the installer script I am working on.

If there's input on changes to make or whatever I've enabled issues on the repo I'm working from.

Going to read through here and see if anything I've already done needs some tweaking or if I can work the rest into the script.

[ninjamonkey198206]

@wh1te909 @NiceGuyIT I've already pulled the service and nginx conf files out, as well as app.ini. cp commands and sed commands cut that process down to about 3 lines each.

I saw an env file mentioned. If you let me know what info you want stored there, I can write that in, using a check to see if it exists, and if not, populate it via existing or new commands.

As a temporary solution to the useradd vs add user issue, I was going to drop in both using a check on the OS as the deciding factor.

Update: user check and sudo verification, and creation is taken care of.

[davidmwilliams]

Say, was this work completed? I'm hitting a CORS issue moving from rmm.company.com to api.company.com and I see your feature changes here offer a solution. Thanks!