Print

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

[mwillems]

So I've been experimenting with running Media Center on a headless server.  This currently requires creating a dummy X display for mediacenter per this thread.  Given the need to have an active X display to run MC, I figured I might as well try and use the GUI for remote administration as well.  I started out using the X forwarding/SSH method described in that thread for administration, but was having some trouble with it.  

I definitely wanted an SSH-tunneling based solution for security, and the solution from that thread did kind of work for me, but the lag from X forwarding was pretty severe (even on the same LAN), such that it made doing any kind of server-side GUI configuration very difficult and tagging almost impossible. I also wanted to (in theory) be able to do some occasional remote fiddling from android devices, and I haven't found any very functional Xserver apps for android.  So I worked out an alternate solution that has some advantages and some disadvantages over the X forwarding method outlined in the above-referenced thread, and I thought I'd share.  

Instead of using the startup script from the above referenced thread, I use the following script on the server (it can run after network-target in startup, or on a recurring basis in cron, which is what I do):

Code: [Select]

export USER=username-you-want-to-run-MC-as
ps -e | grep tightvnc || vncserver :0 -localhost -geometry 1280x720
export DISPLAY=':0'
ps -e | grep mediacenter || mediacenter20

This script does two things:
1) it tests to see if the vncserver is running, and if MC is running on a virtual display on the server. if both are running, it does nothing
2) If a vncserver and/or MC are not currently running on a virtual display on the server, then the script creates a virtual x display visible from inside the server (as needed), and then loads mediacenter onto the virtual display (if needed).  

[Notes on the script: You could also add the /mediaserver switch to the mediacenter20 call, but I prefer not to use that switch so that I can easily interact with Media Center remotely (see below).   The USER variable should be a real user with appropriate permissions (preferably whoever's login or crontab this is running in).]

When I want to interact with the MC server instance, I run the following ssh command from a remote machine

Code: [Select]

ssh -L 5900:localhost:5900 XXX.XXX.XXX.XXX (where XXX.XXX.XXX.XXX is the server's IP address).  This forwards port 5900 through the ssh tunnel allowing me to connect securely to the localhost-only virtual display on the server.

Then I can use a vncviewer on my remote Linux machine to view the server's dummy display using the command

Code: [Select]

vncviewer localhost:0
This has a couple of advantages (in my setup) over the other configuration:

1) As mentioned, when I tried to use ordinary X forwarding over ssh for administration, I got miserable lag even on the same LAN.  The VNC solution, on the contrary, is about as responsive as a local instance of MC on the same LAN, and still pretty good outside the LAN.
2) Mediacenter is open and available for configuration when I log in. I don't need to kill the process (potentially interrupting client activities) in order to change things on the server, etc.  
3) Using VNC makes remote administration from non-GNU/linux interfaces easier because it doesn't need an Xserver on the accessing machine (i.e. I can login from a windows box or an unrooted android phone and use the gui, which can be handy in a pinch)

It poses at least one disadvantage, which is that it's potentially more memory-intensive and CPU-intensive than the vanilla xforwarding alternative (i.e. tightvncserver and the full mediacenter instance add some overhead), but I'm not sure how much.  I did some testing, and if you use a minimal x window manager on your server (I use openbox) it seems to have a relatively minor impact. My server does not have a lot of grunt (it's an intel 1037U embedded chip) and running both a full mediacenter instance and tightvnc server uses about an incremental 100MB of RAM and between 1% and 2% CPU on top of what my server uses at idle with no X and no MC running.  That's not a big hit for my system, but it might be on another system.  Obviously if the CPU and memory hit is unacceptable the /mediaserver switch does reduce the footprint somewhat, but will negate advantage 2) and 3) above.  

For this to work you obviously need the following additional packages installed on the server
1) tightvncserver or an equivalent vncserver package
2) openbox or some other minimal window manager configured to start when the VNC is started (configured via .vnc/xstartup).

Both are available in the Debian repos and several other distro's repos as well.  You'll also need a VNC viewer on your remote machine; I use tigervnc on my Linux boxes, and bVNC on my phone.  My server is on Debian Testing, and I have successfully logged in using this method from Debian and Arch Linux boxes, and from my Android phone.  Preliminary tests logging in with a windows box suggests it will work there too, but I need to spend a little more time with it over the weekend to be sure.

So far I'm pretty happy with this solution, I'll update if I find any more pros or cons. UPDATED to make it more robust and attempt to restart MC if it's down.

[JimH]

Nice work.  Thanks for the report.

[mwillems]

Thanks for the kind words Jim!

I found a couple issues with my scripts above, so I edited my approach to make it more robust.  I switched from using a startup script to using cron to autodetect whether vncserver and MC are running and start/restart them if they're not running.  This has the advantage of both sorting out some login issues with the other method and adding an extra layer of insurance.