My method of remote access requires minimal configuration and is fairly robust. It relies on autostarting the machine's actual display hardware without needing to have a monitor attached. The main limitation is that it doesn't work on machines that lack video hardware (i.e. machine's without video outputs), but those are rare (see below)
1) Configure Display Manager Autostart/LoginOn a raspberry pi this step happens automatically, you don't need to do this part. On a normal vanilla x86 debian install you need to make sure you've done two things: a) If you didn't install xfce4 or another lightweight desktop environment during installation,* install lightdm, x11vnc, and xfce4 (i.e. "sudo apt-get install lightdm xfce4 xfce4-goodies x11vnc") and 2) configure lightdm to autologin. You can configure lightdm to autologin by replacing /etc/lightdm.conf with the following (replacing "your_username_here" with your username)
[LightDM]
[Seat:*]
pam-autologin-service=lightdm-autologin
autologin-user=your_username_here
autologin-user-timeout=0
[XDMCPServer]
[VNCServer]
As an aside, I recommend disabling xfce's power management/screensaver options as they're irrelevant in a headless config and can cause mischief.
* I strongly recommend using xfce4 or something lighter like LXDE or openbox for this kind of setup. The debian default DE (gnome) is great for desktop use but has been broken over VNC for years, and has recently introduced new technology (wayland) that will greatly complicate the task of remote access. Installing xfce4 via the installer, or using the command above is the easiest way, but other lightweight DEs should work too.
2) Set up x11vnc to automatically startUse the systemd service I wrote to start x11vnc, see
https://yabb.jriver.com/interact/index.php/topic,108981.0.htmlFollow the recommended steps in that thread, then the VNC server will automatically start on boot, and restart if it fails. If you want to test it immediately, run "sudo systemctl start x11vnc".
You can then connect to the VNC server with any VNC client from other computers (tightvnc, tigervnc, etc.).
This method has several advantages and one disadvantage:Advantages:1) Relies on the actual physical display adapter so is maximally compatible. If jriver or another program works on the native display it will work with this method. At present, some virtual xservers are compatible with JRiver and some are not and there was a big change recently that broke compatibility with several that I was previously using. Because this method is just relaying what's shown on the physical hardware, it should be compatible indefinitely. There are rumors that the dummy-xserver may soon be deprecated (upstream, not by JRiver) and increasing wayland adoption will prevent x-forwarding-based methods from working because wayland isn't network transparent (already an issue with clients running fedora and newer gnome builds which run wayland by default). Wayland would interfere with my method if used on the server side (x11vnc wouldn't work), but will have no effect if used on the client side.
2) Because x11vnc is pulling from the actual display hardware, you see what would be coming out of the HDMI or VGA port if the device were plugged into a monitor. So if your device is intermittently plugged in you'll only have one desktop to worry about (i.e. if your vnc server fails, you can plug in a monitor and see exactly the same desktop). Likewise if you just want to be able to remotely administer your HTPC this method will work for that.
3) Because you're using the actual display hardware you get hardware acceleration which makes the jriver interface much more responsive and allows for using theater view or watching video (not an ideal experience, but is useful for testing) or doing other tasks that require graphical hardware acceleration.
Disadvantages:1) If you're using physical hardware that doesn't have any video outputs or are in a virtualized environment that
doesn't provide a virtual graphics adapter (virtualbox and kvm/qemu do, some others don't) this won't work at all, and you'll need to use the dummy-xserver method described above. Almost all consumer PC hardware has an integrated graphics adapter so this is mostly an issue for dev board type systems on a chip and virtual environments.
Author
Topic: Running MC headless -no physical display on the machine on which MC is installed (Read 10721 times)