web stats
Linux best practices - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 10-16-2017, 02:28 AM
Peanut Peanut is offline
Mirth Newb
 
Join Date: Aug 2017
Posts: 13
Peanut is on a distinguished road
Question Linux best practices

Hello!

I would like to have mirth connect startup and run as a non root user? Is there a thread or Mirthcorp article that points me in the right direction? I would like to implement this on a Debian server.

Last edited by Peanut; 10-16-2017 at 02:40 AM.
Reply With Quote
  #2  
Old 10-25-2017, 07:32 AM
Peanut Peanut is offline
Mirth Newb
 
Join Date: Aug 2017
Posts: 13
Peanut is on a distinguished road
Default

Does anybody have some insight or tried this on a Linux server in connection with Mirth Connect? Is it even necessary?
Reply With Quote
  #3  
Old 11-01-2017, 07:19 AM
dvanzuijlekom dvanzuijlekom is offline
Mirth Newb
 
Join Date: Nov 2017
Posts: 9
dvanzuijlekom is on a distinguished road
Default Running Mirth Connect as non-root daemon user

Quote:
Originally Posted by Peanut View Post
I would like to have mirth connect startup and run as a non root user?
I was playing around with this on a test machine. We typically deploy and run Mirth Connect as root, but this shouldn't really be necessary (and should actually be discouraged).
Basically, you'd create a new daemon/system user, unpack the tarball to some location, chown it to the daemon user and use that in a systemd unit file. I haven't gotten to that last part though, since this is only a testing environment for me.

Here's what I did, based on my shell history:
Code:
cd /opt/
tar xzf ~/Downloads/Mirth/mirthconnect-3.5.1.b194-unix.tar.gz
mv Mirth\ Connect/ mirthconnect-3.5.1.b194
useradd -c "Mirth Connect daemon" -m -r -d /home/mirthconnect/ mirthconnect
chown -R mirthconnect:mirthconnect mirthconnect-3.5.1.b194
chmod -R o-rwx mirthconnect-3.5.1.b194
ln -s mirthconnect-3.5.1.b194 mirthconnect
Below is what your deployment should look like. By using a symlink to the specific Mirth Connect version, you'll be able to upgrade to a new version by unpacking the tarball to a new versioned directory besides the live one and gracefully upgrade during downtime, with a rollback strategy to the old version in case you need it. The idea is that you'd only reference the "/opt/mirthconnect/" path in your scripts etc.
Code:
[root@varuna ~]# ls -lah /opt/
total 28K
drwxr-xr-x.  7 root         root         4,0K Oct  4 14:27 .
dr-xr-xr-x. 21 root         root         4,0K Sep 12 15:18 ..
lrwxrwxrwx.  1 root         root           23 Oct  4 14:27 mirthconnect -> mirthconnect-3.5.1.b194
drwxr-x---. 16 mirthconnect mirthconnect 4,0K Oct 31 16:17 mirthconnect-3.5.1.b194
Reply With Quote
  #4  
Old 11-02-2017, 03:03 AM
dvanzuijlekom dvanzuijlekom is offline
Mirth Newb
 
Join Date: Nov 2017
Posts: 9
dvanzuijlekom is on a distinguished road
Default

Actually, if you want to secure your installation even more, you could change various files and directories to read-only and/or execute-only for the daemon user and change the ownership to the root user. This could prevent the daemon from altering/replacing/damaging binaries or critical files which shouldn't normally be touched by the daemon. You'd need to know which files/directories should be writable by the daemon user. I'm guessing the "appdata" and "logs" directory should be writable (or at least certain files and/or subdirectories inside).
Reply With Quote
  #5  
Old 11-07-2017, 06:48 AM
ChrisJ ChrisJ is offline
Mirth Newb
 
Join Date: Jun 2017
Posts: 10
ChrisJ is on a distinguished road
Default

I can confirm what @dvanzuijlekom says. I have a test/dev instance running in Linux, but it's locked down so everything is owned by root except for the folders (which I have owned by a user 'mirth'):
  • appdata
  • extensions
  • logs

If you're not likely to use custom extensions, or import them from the Mirth administration tool, then extensions can be locked down as well.

I'm then starting Mirth from /etc/rc.local (because I can't be asked arguing with systemd) using this command to start as the mirth user:

Code:
su -c '/opt/MirthConnect/mcservice start' mirth
Reply With Quote
  #6  
Old 11-13-2017, 02:35 AM
Peanut Peanut is offline
Mirth Newb
 
Join Date: Aug 2017
Posts: 13
Peanut is on a distinguished road
Default

Thank you @dvanzuijlekom and @ChrisJ for confirming and explaining this. The symbolic link is a very nice way for future upgrades!

I have never deployed a Linux server onto the Internet and wanted to at least have the obvious low hanging fruit taken care of before I do so.

There is one detail that I can't wrap my head around though. I apologize profusely if you have mentioned this already, but, how can I make systemd start the daemon/service via the "example user" mirth?

I am not claiming to be a Linux guru but it seems to me we have the binaries taken care of as well as the folders. But what about the actual service that runs Mirth?

So sorry if I come across as dense!
Reply With Quote
  #7  
Old 11-14-2017, 02:56 AM
ChrisJ ChrisJ is offline
Mirth Newb
 
Join Date: Jun 2017
Posts: 10
ChrisJ is on a distinguished road
Default

Quote:
Originally Posted by Peanut View Post
There is one detail that I can't wrap my head around though. I apologize profusely if you have mentioned this already, but, how can I make systemd start the daemon/service via the "example user" mirth?

I am not claiming to be a Linux guru but it seems to me we have the binaries taken care of as well as the folders. But what about the actual service that runs Mirth?
I've not got on with systemd, so can't help you with a unit file. As mentioned though, /etc/rc.local still exists and can be used to start the Mirth daemon at boot time. This is /etc/rc.local from my Ubuntu box. You could use this as a stop-gap until the systemd unit file is worked out :-)

Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

su -c '/opt/MirthConnect/mcservice start' mirth

exit 0
Reply With Quote
  #8  
Old 11-14-2017, 03:16 AM
Peanut Peanut is offline
Mirth Newb
 
Join Date: Aug 2017
Posts: 13
Peanut is on a distinguished road
Thumbs up

Thanks Chris!
Reply With Quote
  #9  
Old 11-15-2017, 03:56 AM
dvanzuijlekom dvanzuijlekom is offline
Mirth Newb
 
Join Date: Nov 2017
Posts: 9
dvanzuijlekom is on a distinguished road
Default systemd

I haven't got much love for systemd either, but it is advisable to hook Mirth Connect into it, instead of using the rc.local mechanism. The reason for this, is that you and your OS has more control over the daemon, you can stop it and restart it easier (you won't accidentally start it as the 'root' user) and the daemon will be properly started or shut down during runlevel/target changes.

Check here, here and here for a few nice articles on systemd and how to create your own unit files.
Reply With Quote
  #10  
Old 11-20-2017, 03:04 AM
Peanut Peanut is offline
Mirth Newb
 
Join Date: Aug 2017
Posts: 13
Peanut is on a distinguished road
Default

Thanks dvanzuijlekom! Sooner or later I will have to be more comfortable with systemd, so why not now!?!
Reply With Quote
Reply

Tags
daemon, linux, non-root, service, startup

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 02:28 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation