0

I KNOW there are other very similar questions here already - but this is subtly different - I have been through all of the similar ones, and none of the advice there solves the issue I am seeing.

It is the logged-in or -out status of the server local user, which differs here (see below) and I don't see why that impacts on what I'm doing.

I have this situation:

  1. Server PC running Lubuntu 16.04

  2. Client PC running Lubuntu 18.04

  3. Want to remote-access Server PC from Client PC, using vino-server for VNC, tunneled through SSH.

Working aspects:

a. I have vino-server installed on the Server and Remmina on the client: these work fine together.

b. I'm familiar with SSH tunnels constructed with the ssh -g - L formulation - that works fine too;

c. If I leave vino-server running and the Server has a keyboard logged in locally, ALL WORKS FINE.

d. But for additional security, I'd like NOT to leave vino-server running all the time, but remote-in initially with a simple remote SSH session, to start it, when I need it. So to test this, I closed vino-server, and logged off as a local user of the Server, and tested remotely. In THIS situation, I can't get the vino-server to start.

Issues:

a. If vino-server is NOT running, but there IS a locally logged on user at the Server PC, if I ssh in to start vino, I get the "could not connect to display" problem;

-- that is solved, by the advice from this question:
How to start a GUI software on a remote Linux PC via SSH

-- essentially, enter export DISPLAY=:0 and then proceed, and all is then good;

b. BUT... if the locally-logged-in user (keyboard) at the server, is logged out, then, the above fix does NOT work. I cannot start vino-server whatever I do.

I've tried various other recommended advice, including more complex forms of the

export DISPLAY=:0

..command, also xhost + , but none of these work.

This seems like it is something simple, because the difference between working and non-working is only that the local user (irrelevant to the process ?) at the server, is logged OUT in the problematic case and logged IN in the working case.

Incidentally: some advice recommended using screen to segregate the session which runs vino-server; I have tried that too: doesn't solve it.

Any and all wisdom on this subject would be appreciated.

Thanks.

PS: Not sure if Lubuntu 18.04 has moved to Wayland, and if that's relevant.. I think it may have.

MikeH London
  • 116
  • 1
    Based on what you wrote, you'd be better off with a traditional VNC server such as vnc4server or tightvncserver, rather than vino-server (which AFAIK is inherently a "desktop sharing" server, meant to interact with a real remote desktop session) – steeldriver Aug 07 '18 at 20:40
  • I have rolled this question back: someone 'helpfully' edited it (without reference to me) and removed a lot of key content. Please leave it as it is. I want the reference to the other question to remain - I was expressly asked to include it, and it's no help if someone comes along and deletes it. – MikeH London Aug 07 '18 at 20:56
  • Steeldriver that's not relevant, with all respect: I'm well aware of other VNC servers and have used each of those before. This is nothing to do with WHICH vnc server I use, it is that Linux won't let it open, when I am remoting in via SSH AND the server has no locally logged in user. In all other respects, vino works perfectly in this guise. – MikeH London Aug 07 '18 at 20:59
  • steeldriver perfectly explained your problem in my opinion. because the server has no logged in user, there is no desktop to share. vino has only 'undefined' to share until the local login occurs (it uses existing login and can't initiate one itself; it runs higher in the software stack and can't access X11 itself to do so), but I'm no expert (https://help.ubuntu.com/community/VNC/Servers , http://www.softpanorama.org/Xwindows/VNC/Vino/activating_vino_from_command_line.shtml and others) – guiverc Aug 07 '18 at 22:46
  • Thanks, I see your point... but.. there is a desktop in a sense, even before login: the "waiting to log in" desktop, with a dialog box at centre. If I use teamviewer to do this same thing, it works, and it shows that very un-logged-in desktop, and allows me to use the user login dialog box which is waiting in the centre of screen. Maybe X windows behaves differently from that (conceivably Teamviewer 'emulates' a desktop to cope with this ?). I have just come across a note about Xvfb, a 'virtual' X screen... will see where that leads. – MikeH London Aug 07 '18 at 23:00

1 Answers1

0

Thanks to all above who commented on this - I've battled with it for a long stretch, learned a lot, found a lot of people with other incarnations of the same problem, and finally - today - solved it.

Most of the problem appears to be inexpert (if familiar) Linux users (like me) not knowing the innermost concepts of how X windows sessions work with window managers and with VNC servers (of which I've now tested about 4), and what all of those do when working remote with no local user logged in.

On the advice of steedriver above, I tried TightVNC, and then vnc4server, as alternatives to vino: but I got essentially the same problem -inability to get a GUI session to 'wake up' so that a vnc server can deliver a GUI through to a remove VNC client session run over an SSH tunnel.

Net changes I've needed to make to finally solve this, were these:

Firstly, on the advice of a number of people, changed my xstartup configuration, under ~/.vnc as follows:

/home/mikeh/.vnc/xstartup ::

~~~~~~~~~~~~~~~~~~~~

#!/bin/sh

def

export XKL_XMODMAP_DISABLE=1

unset SESSION_MANAGER

unset DBUS_SESSION_BUS_ADDRESS

xrdb $HOME/.Xresources

xsetroot -solid grey

x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &

x-window-manager &

# Fix to make GNOME work

export XKL_XMODMAP_DISABLE=1

/etc/X11/Xsession

~~~~~~~~~~~~~~~~~~~~~

Key tweaks there were (a) the addition of the top four lines after #!/bin/sh, and (b) UNcommenting the lines starting x-terminal and x-window-manager

With those changes made, kill & restart the vncserver session (find pid first with ps -ef | grep vnc ).

THEN, remoting in using remmina (through SSH tunnel), I got a "plain grey" window with only an "X" cursor - no 'desktop' in the conventional sense. Took a little more research to realise this is an X window undecorated by a window manager: even though lightdm seemed to be running, not present on the screen the VNC could access.

At this stage, I found RIGHT-click revealed the 'basic' LXDE desktop commands, which include a terminal, 1-of-4 desktop selector, and browser. All work, on 'naked' LXDE (no window manager), but from the terminal, I could then start pcmanfm which worked normally, then vlc which was able to stream video: so clearly all functionality, just no managed window session. So "90% there"..

Futher research this pm, led to advice from here - steeldriver, your advice again:

https://ubuntuforums.org/showthread.php?t=2222849&page=2

Essence of this was your trials leaving to summarised tweaks: which amount to creation of the file ~/.xsession , containing only this:

lxsession -s Lubuntu -e LXDE

Rebooted PC, then

a. remoted simple SSH;
b. started vncserver on the server manually with 

    vncserver                        {   -  reports using desktop session 1 ;  }

c. opened the SSH tunnel from client to server (port 5901 far end);

d. remoted in using remmina vnc client --- WORKING FINE, full GUI desktop.

Huge thanks to all gurus whose advice helped me here -- steeldriver, my apologies for not recognising your skill above in comments earlier / thanks for this solution.

For the record -- this was client PC running Lubuntu 18.04 accessing server PC running Lubuntu 16.04.

MikeH London
  • 116