Announcement

Collapse
No announcement yet.

Linux best practices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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, 02:40 AM.

  • #2
    Does anybody have some insight or tried this on a Linux server in connection with Mirth Connect? Is it even necessary?

    Comment


    • #3
      Running Mirth Connect as non-root daemon user

      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:
      [[email protected] ~]# 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

      Comment


      • #4
        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).

        Comment


        • #5
          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

          Comment


          • #6
            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!

            Comment


            • #7
              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

              Comment


              • #8
                Thanks Chris!

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Thanks dvanzuijlekom! Sooner or later I will have to be more comfortable with systemd, so why not now!?!

                    Comment


                    • #11
                      Systemd implementation

                      Today i set up a Mirth server in our company and i had problems with starting the service at logon.

                      I wanted to start the service via systemd implementation.

                      Now i have the solution.

                      Service file in path /etc/systemd/system
                      I called it mirthservice.service

                      Content in the file:

                      # Contents of /etc/systemd/system/mirthservice.service
                      [Unit]
                      Description=Mirth Service

                      [Service]
                      Type=forking
                      User=root
                      WorkingDirectory=/srv/mirthconnect/
                      ExecStart=/srv/mirthconnect/mcservice start
                      ExecStop=/srv/mirthconnect/mcservice stop
                      ExecRestart=/srv/mirthconnect/mcservice restart
                      Restart=on-failure

                      [Install]
                      WantedBy=multi-user.target

                      Comment

                      Working...
                      X