Happy Hacking
Raspbian Stretch
For those who seem intrested in stretch, I'd like to double down on Volker's comment about VNC not working on stretch. Its unfortunately true, at least for those who need this kind of visual remote access. It has to do with the switching from X11 to Wayland and the handling of user sessions of systemd-logind. You cannot access unless there is a open local session seated at a display device with a VNC server running on it. That would mean the need for direct access --> open session (have not yet been able to figure out how to do this remotely if possible at all) --> run VNC (automatable) in user session --> remote connect. For many scenarios this is insufficient. TeamViewer also suffers from these same constraints, which is to say, no workaround at this point in time. As for the rest of the system, works like a charm with jessie targeted kunbus packages running on stretch based distro. As always we do not touch every usage corner case so YMMV. Be careful and always keep a sandbox rig for pre-testing upgrades before running them in production.
Happy Hacking
Happy Hacking
Please note that TeamViewer RevPi does have no problems with our new image based on stretch. This is because TeamViewer Revpi is totally different and maximizes security:
It is NOT the well known tool which duplicates a local GUI to be remotely accessible!!! TeamViewer RevPi does take the RevPi's Webserver output and channels it over the TV secure mechanisms to a TV client anywhere on the world. The TV client is the same client which can be used for ordinary TV servers. But instead showing a copy of the local GUI it does open a browser window and displays the webpages configured on the server device. The result is very secure because hacks which can normally very easy be done with an ordinary webbrowser using debugger etc. can't be done with the TV client unless it gets totally hacked (which has not been the case in many years of its existence).
TV RevPi does run with the stretch image and will be further part of our image as well as VNC.
VNC:
Our tests have been positive but I will use your comment to analyze what might be different to our compilation. We will come back to this thread to report our testing results...
It is NOT the well known tool which duplicates a local GUI to be remotely accessible!!! TeamViewer RevPi does take the RevPi's Webserver output and channels it over the TV secure mechanisms to a TV client anywhere on the world. The TV client is the same client which can be used for ordinary TV servers. But instead showing a copy of the local GUI it does open a browser window and displays the webpages configured on the server device. The result is very secure because hacks which can normally very easy be done with an ordinary webbrowser using debugger etc. can't be done with the TV client unless it gets totally hacked (which has not been the case in many years of its existence).
TV RevPi does run with the stretch image and will be further part of our image as well as VNC.
VNC:
Our tests have been positive but I will use your comment to analyze what might be different to our compilation. We will come back to this thread to report our testing results...
Unser RevPi Motto: Don't just claim it - make it!
Hi lweberk,
I've tried remote VNC connection today and is does work on our Stretch image without any problems. Although I do not fully understand what you have written, here is what I have done:
1) I used a HDMI monitor and keyboard to
a) I enable VNC service in raspi-config
b) manually starting x-windows using the startx command (this can be changed by configuring "autostart in GUI")
2) I started a local (LAN) connected VNC session using a windows PC with the real VNC client installed.
3) When being connected I opened the realVNC server icon and signed into my realVNC account to register the device in the cloud
4) I closed the local VNC connection and used the remote account login to connect to the device remotely ("cloud connection")
So it was definitely possible to connect via cloud without direct connection running in parallel . You do need of course a possibility to register the device which is normally done using a monitor, mouse and keyboard locally ONCE and then never again.
I have not yet tried to use the system without starting x-windows locally on the device ("virtual mode" of VNC for Raspberry) but it should normally be no problem to autostart in GUI for a system which uses a GUI anyhow.
Regarding you statements about x11 not being part of Stretch our Linux expert Lukas will come back to this thread and explain what is part and what not on our Stretch image.
I've tried remote VNC connection today and is does work on our Stretch image without any problems. Although I do not fully understand what you have written, here is what I have done:
1) I used a HDMI monitor and keyboard to
a) I enable VNC service in raspi-config
b) manually starting x-windows using the startx command (this can be changed by configuring "autostart in GUI")
2) I started a local (LAN) connected VNC session using a windows PC with the real VNC client installed.
3) When being connected I opened the realVNC server icon and signed into my realVNC account to register the device in the cloud
4) I closed the local VNC connection and used the remote account login to connect to the device remotely ("cloud connection")
So it was definitely possible to connect via cloud without direct connection running in parallel . You do need of course a possibility to register the device which is normally done using a monitor, mouse and keyboard locally ONCE and then never again.
I have not yet tried to use the system without starting x-windows locally on the device ("virtual mode" of VNC for Raspberry) but it should normally be no problem to autostart in GUI for a system which uses a GUI anyhow.
Regarding you statements about x11 not being part of Stretch our Linux expert Lukas will come back to this thread and explain what is part and what not on our Stretch image.
Unser RevPi Motto: Don't just claim it - make it!
The stock Raspbian stretch image doesn't include weston or mutter, only the core libwayland-* libraries, and X11 continues to be the default. If your machine is indeed using Wayland without having deliberately migrated to it, then the only explanation I can think of is that it was caused by the upgrade procedure. How did you upgrade anyway, normally the limited amount of free space on the eMMC prevents a smooth "apt-get dist-upgrade", necessitating workarounds such as mounting /var/cache/apt/archives on a USB stick.lweberk wrote: ↑17 Mar 2018, 15:15 For those who seem intrested in stretch, I'd like to double down on Volker's comment about VNC not working on stretch. Its unfortunately true, at least for those who need this kind of visual remote access. It has to do with the switching from X11 to Wayland and the handling of user sessions of systemd-logind. You cannot access unless there is a open local session seated at a display device with a VNC server running on it.
FWIW, it's possible to manually build a stretch image using the procedure documented on GitHub, however we're still busy fixing a bunch of nits and we push improvements to the repo at least once every week.
Thanks!
Hi Volker, Lukas,
I misunderstood the workings of the TeamViewer module for the teamviewer-host server normally used. Indeed if I understand correctly from your explanation, the module will not be affected by moving defaults to wayland at all.
Also I was under the mistaken impression wayland was pushed as default on upstream. If that is not the case, the issue described by me is totally unrelated even for the case of a locally (on the core) running VNC service.
I apologize for making to many assumptions. I'm just currently knee deep in this issue on debian stretch across my deployments from which I seem to have wrongly extrapolated. Its a huge regression there, hope it gets fixed before raspbian catches up.
So what other problems are you having with stretch to the point?
Best Regards,
lwk
I misunderstood the workings of the TeamViewer module for the teamviewer-host server normally used. Indeed if I understand correctly from your explanation, the module will not be affected by moving defaults to wayland at all.
Also I was under the mistaken impression wayland was pushed as default on upstream. If that is not the case, the issue described by me is totally unrelated even for the case of a locally (on the core) running VNC service.
I apologize for making to many assumptions. I'm just currently knee deep in this issue on debian stretch across my deployments from which I seem to have wrongly extrapolated. Its a huge regression there, hope it gets fixed before raspbian catches up.
So what other problems are you having with stretch to the point?
Best Regards,
lwk
Any news concerning the expected release date for stretch?
Schönen Gruß,
matt.s
matt.s
I do understand your questions but all I can do is asking you for patience. If I said 1st quarter of 2018 you can be sure we are not talking about months or weeks. We do have delays and we will communicate all the obstacles which had been crossing our way soon. Hopefully we will finish the last tests successfully next week...
Unser RevPi Motto: Don't just claim it - make it!
