Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

Here's a systemd service that will automatically start jriver on boot as your user (after the display manager loads), and if JRiver should crash, restarts it within 10 seconds.  This will work best on systems with autologin, but because of the restarting feature, should work fine even if it has to wait for you to login.  You want to put your username in the "user" spot, and put the following text in a file at /etc/systemd/system/jriver.service:

Code: [Select]

  [Unit]
     Description=JRiver
     After=display-manager.service

  [Service]
     Type=simple
     Environment=DISPLAY=:0
     User=your_user_here
     ExecStart=/usr/bin/mediacenter26 /MediaServer
     Restart=always
     RestartSec=10
     KillSignal=SIGHUP
     TimeoutStopSec=45
     LimitRTPRIO=100

  [Install]
     WantedBy=graphical.target

Some technical notes: 

If you want MC to wait until the network connection is available before starting, you can add "network.target" after display-manager.service in the third line, separated by a space.  This may prevent JRiver from starting if there are network issues, however, so make sure that's the behavior you want.

This unit presumes you're running on your actual display, not a virtual display generated by a VNC client.  If you are using such a virtual display, substitute the display variable in the Environment section, and change the "After" line to refer to the name of the systemd service you're using to start your vnc server, but note that VNC virtual displays may not work correctly anymore with MC since 22.0.36. 

In that vein, here's a service to start x11vnc to allow remote access to your actual display on boot.  It similarly will restart if it crashes.  You want to put your username in place of both of the "your_user_here" placeholders below, create a file at /etc/systemd/system/x11vnc.service, and put the following text there:

Code: [Select]

[Unit]
     Description=x11vnc
     After=display-manager.service

  [Service]
     Type=forking
     Environment=DISPLAY=:0
     User=your_user_here
     ExecStart=/usr/bin/x11vnc -rfbauth /home/your_user_here/.vnc/passwd -display :0 -geometry 1920x1080 -auth guess -forever -bg
     Restart=always
     RestartSec=10

  [Install]
     WantedBy=graphical.target

Technical notes: this presumes that you've already setup a VNC password.  If you want to run without a password remove the -rfbauth flag and the path following it.  If you want to set a password run the following command replacing "your_password" with your password:

Code: [Select]

x11vnc -storepasswd your_password ~/.vnc/passwd

Once you've got the services in place you can set them to start on boot by typing

Code: [Select]

sudo systemctl enable jriver.service
and/or

Code: [Select]

sudo systemctl enable x11vnc.service


[bassmann]

This works well if I login...

...but what if i want the service to start at boot...without login or even auto-login?

My usage will be a JR Debian VM on a home server. Happy for the service to even run off root account if that helps...

Other Linux apps achieve this via systemd. e.g SABnzbd.

Appreciate your thoughts...

[mwillems]

This works well if I login...

...but what if i want the service to start at boot...without login or even auto-login?

My usage will be a JR Debian VM on a home server. Happy for the service to even run off root account if that helps...

Other Linux apps achieve this via systemd. e.g SABnzbd.

Appreciate your thoughts...

Unlike most linux applications, JRiver requires a running xserver in order to work, which means it needs a desktop environment or window manager to be running.  By far the easiest way to do that is to have a user account that auto-logs in to a desktop environment or window manager via a display manager, which is what I recommend.  That way JRiver starts on every boot with no interaction. 

Could you explain a little more about the bad consequence you're trying to avoid by avoiding a login?  If you're trying to avoid installing a display manager you could certainly configure jriver to run without a display-manager, but you'd have to launch your window manager or desktop environment via startx or something, and you'd need to configure that to auto-start as a user anyway, so I'm not sure what you're getting by going that route.  If you're concerned about security/access control, you could make a special "jriver" user with limited privileges that auto-logs in (to avoid leaving an administrator account logged in, etc.).  But again, not sure what the actual issue is, this has the ring of an x/y problem the way you framed it.

Bottom line, you need a running xserver because JRiver needs it to start and run (it can't run as a true headless daemon), so however you start it, you need to log in to a graphical environment.

[bassmann]

Its more to do with security than anything else.
The media library is on a storage source on the network which shares are mounted to this VM.

I could create a user with restricted rights however would need appropriate rights to access the storage source...

[mwillems]

Its more to do with security than anything else.
The media library is on a storage source on the network which shares are mounted to this VM.

I could create a user with restricted rights however would need appropriate rights to access the storage source...

I'm not sure I understand your specific security concern, can you explain?  I'm assuming that in either case JRiver would be running with full access to the network resource, and JRiver itself can move or delete files.  I'm not sure that the auto-logged x-session can do much more damage than a daemon running as the same user with the same rights.  What kind of threat model are you concerned about? (i.e. in your use case, what is less secure about a VM auto-logging in as a user versus a VM that has a daemon run by that same user)? 

If you're worried about remote logins being able to exploit the running x-session, you can secure whatever remote desktop method you're using (VNC, Spice, etc.) with its own credentials (or have the VM listen for VNC/Spice connections local-only and tunnel in through ssh) so an attacker would need credentials to ever even see the jriver VM desktop.  You can also set authentication for MCWS (JRiver's built in web service).

If you're worried about someone physically walking up to an unsecured server console and using the GUI, you can setup a screenlocker in the jriver VM and autolock the screen after a few minutes.  JRiver will happily keep running on a locked session.  That would also add extra security to any VNC/Spice connections, etc. 

As an example, my host server doesn't run a GUI so someone walking up to the console needs credentials to login, but you couldn't really interact with a VM's x-session as the host doesn't have x installed.  The only way to actually see my JRiver VM's x-session is to ssh in to my server with my credentials and use spice over ssh.  My JRiver VM isn't meaningfully less secure than my other VMs: you need my ssh credentials or my server console credentials to interact with any of them.

If your concerns are more abstract (i.e. concerned about the x11's security in general) that's unfortunately not meaningfully mitigable for JRiver as an x11 session is mandatory.