action #9504
closed[desktop]Remote Desktop Testing
60%
Description
First, the "server side":
6 potential server flavors:
SLES system with ssh enabled
SLES system, with xvnc enabled (running yast2 remote management to
enable the VNC system part)SLES system, with xvnc already enabled. Then, install xrdp, to make
SLES being available as RDP server.SLES system with XDMCP enabled in gdm (we could also test xdm in
addition)
(the SLES system can be a single system with all possible remote access
enabled, it will work fine, you just need to be careful with VNC entry
point)
Windows (could be 7, 8 or 10, don't care). Need to do a install with
a password on the user and then enable RDP support in it. You need to
disable NLA (Network Authentication Layer) on Windows, we don't yet
support it in SP1, will do for SP2)SLED (or SLES + WE) system, with logged user, then enabling vino
desktop sharing from GNOME.
2 client flavors:
SLED system, with vinagre, tigervnc and Xephyr installed
Windows (can be the same as the server one)
test matrix:
XDMCP:
- from SLED system, try to run Xephyr -query to check if you get gdm prompt on the SLES server
X11 over SSH:
- from SLED system, login to SLES over ssh and try to run a graphical application (gedit for instance).
VNC:
- connecting from SLED to SLES XVNC: test with both vinagre and tigervnc
- connecting from SLED to SLES XVNC, but using Firefox and Java applet
- connecting from SLED to SLES over Vino: user must be first logged on SLES server, in order to SLED to take control of the desktop session on SLES (should be tested from vinagre in priority, but also test it from tigervnc)
RDP:
- connecting from Windows (as client) to SLES over RDP: use Windows built-in Remote desktop client and ensure you get sessman session chooser and try to login. This should bring up gdm, similar to XVNC
- connecting from SLED to Windows (as server): use vinagre to connect on Windows session => for this one, you will need to use "--no-nla" to connect to Windows, in the options field in Vinagre.
Updated by RBrownSUSE almost 9 years ago
- Checklist item changed from to [ ] SLE
- Target version deleted (
156)
Updated by fcrozat about 8 years ago
Update for SLE12 SP2:
- we are now supporting NLA for Windows. So the test for Windows should be to test with NLA enabled and NLA disabled.
- we are now shipping VNCManager (SUSE code) which is able to handle several connections to VNC (allow a new session or connect to an existing one)
- connecting to a user which is already using a desktop on non-shared connection is detected by gdm and refused (need to test this too)
Updated by qkzhu almost 8 years ago
Hi Frederic,
I'm summarizing this issue for our Remote Desktop testing plan on SP3 stage, and I have a question for your last comments:
fcrozat wrote:
Update for SLE12 SP2:
...
- connecting to a user which is already using a desktop on non-shared connection is detected by gdm and refused (need to test this too)
What does the 'non-shared connection' mean ?
Updated by fcrozat almost 8 years ago
VNC sessions can have two modes:
- shared session: several connections are allow at the same time to the VNC server and all clients can use remote desktop at the same time. If one client disconnect, the remote desktop session is not terminated.
- non-shared session: only one connection is available on remote desktop. When it is already used, gdm (in SP2) will display an error that it is already used.
Updated by qkzhu almost 8 years ago
fcrozat wrote:
VNC sessions can have two modes:
- shared session: several connections are allow at the same time to the VNC server and all clients can use remote desktop at the same time. If one client disconnect, the remote desktop session is not terminated.
- non-shared session: only one connection is available on remote desktop. When it is already used, gdm (in SP2) will display an error that it is already used.
Got it, it's also called One-time VNC Sessions and Persistent VNC Sessions in SUSE Doc.
Updated by qkzhu almost 8 years ago
Hi all,
We are going to implement remote desktop testing in our regression test of SP3 (including manual test and automation test/openQA).
So I have summarized and updated the above comments, here is the new test matrix, if you have any comments/suggestions please feel free to reply.
Content:
- 4 ways we should cover for remote desktop:
- 7 potential server flavors:
- 2 client flavors:
- test matrix/cases:
4 ways we should cover for remote desktop:
- X11 forwarding over OpenSSH (Clinet: SLED; Server: SLES)
- XDMCP (Clinet: SLED; Server: SLES)
- VNC (Clinet: SLED; Server: SLED, SLES)
- RDP (Client: SLED, Windows; Server: SLES, Windows)
7 potential server flavors:
- SLES with ssh enabled
- SLES with XDMCP enabled in gdm and SLE-Classic SLES with XDMCP enabled in xdm and icewm
- One-time VNC Sessions:
SLES with xvnc but without session management(configured via yast2 remote)
- SLES with xrdp enabled (the above SLES can be a single system with all possible remote access enabled, it will work fine, you just need to be careful with VNC entry point)
- Persistent VNC Sessions:
SLES with xvnc and session management enabled (configured via yast2 remote)
we should setup a persistent connection before the test
- Windows (could be 7, 8 or 10, don't care). Need to do a install with a password on the user and then enable RDP support in it.
- SLES + WE with vino enabled via gnome-control-center sharing
2 client flavors:
- SLED system, with vinagre, tigervnc and Xephyr installed
- Windows (can be the same as the server one)
test matrix/cases:
X11 forwarding over OpenSSH (Clinet: SLED; Server: SLES)
1. SLED login to SLES (sshd enabled) over ssh and try to run a graphical application (gedit for instance).
XDMCP (Clinet: SLED; Server: SLES)
2. SLED try to run Xephyr -query to check if you get gdm prompt on the SLES with XDMCP enabled in gdm and SLE-Classic
3. SLED try to run Xephyr -query to check if you get gdm prompt on the SLES with XDMCP enabled in xdm and icewm
see: https://fate.suse.com/317876
VNC (Clinet: SLED; Server: SLED, SLES)
One-time VNC Sessions:
4. SLED using vinagre access SLES with xvnc enabled
5. SLED using tigervnc access SLES with xvnc enabled
6. SLED using Firefox and Java applet access SLES with xvnc enabled
7. SLED using vinagre access a SLES which is already using a desktop on non-shared connection is detected by gdm and refused
Persistent VNC Sessions:
8. SLED using vinagre access SLES with xvnc and session management(VNCManager) enabled, connecting to a new session and reconnect to it
see: https://fate.suse.com/319319
vino:
9. SLED using vinagre in priority then tigervnc access SLES+WE with vino
note: user must be first logged on SLES server, in order to SLED to take control of the desktop session on SLES
see: https://fate.suse.com/318311
RDP (Client: SLED, Windows; Server: SLES, Windows)
10. Windows access SLES with xrdp enabled
use Windows built-in Remote desktop client and ensure you get sesman session chooser and try to login. This should bring up gdm
11. SLED using vinagre with NLA enabled and NLA disabled access Windows
Updated by qkzhu over 7 years ago
- Status changed from New to In Progress
- Assignee set to qkzhu
Update supportserver boot, login and add xvnc, ssh to supportserver roles
- We are going to implement remote desktop testing in poo#9504 which needs:
- SLES12SP2+gnome(gdm/vino...is necessary) supportserver qcow2 image
- one time session xvnc server
- persistent session xvnc server
- ssh server for X11 forwarding
- vino server
- XDMCP with gdm and SLE-Classic configured
- XDMCP with xdm and icewm configured
- xrdp server supportserver is a good choice for Remote Desktop testing, but we have to update the login part and add the needed server roles in setup.pm.
- We used to use boot.pm and login.pm to boot into the supportserver image and it only supports console login. boot.pm is dropped in this commit and login.pm is updated by using wait_boot which supports both console and graphical login.
- Adding xvnc server role which supports both onetime VNC session and persistent VNC session, the VNC type is configured by variable in testsuits: REMOTE_DESKTOP_TYPE = persistent_vnc REMOTE_DESKTOP_TYPE = one_time_vnc
Add 4 remote desktop cases for x11regressions
- onetime_vncsession_xvnc_java.pm Remote Login: One-time VNC Session with Jave applet and xvnc
- onetime_vncsession_xvnc_tigervnc.pm Remote Login: One-time VNC Session with tigervnc and xvnc
- persistent_vncsession_xvnc.pm Remote Login: Persistent VNC Session with tigervnc and xvnc
- x11_forwarding_openssh.pm Remote Login: X11 forwarding over OpenSSH
Validation runs:
remote-desktop-client1: http://147.2.212.167/tests/298
remote-desktop-supportserver1: http://147.2.212.167/tests/296
remote-desktop-client2: http://147.2.212.167/tests/299
remote-desktop-supportserver2: http://147.2.212.167/tests/297
PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2536
Updated by qkzhu over 7 years ago
Add 2 remote desktop cases to x11regression
- Add xdmcp to supportserver roles Generally it will stop the firewall and modify the configure file for xdmcp remote access.
- Add xdmcp_gdm.pm Remote Login: XDMCP with gdm and SLE-Classic configured
- Add onetime_vncsession_multilogin_failed.pm Remote Login: One-time VNC Session failed due to a previous graphical session
see also: poo#9504
PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2564
Validation runs:
onetime_vncsession_multilogin_failed
remote-desktop-client1: http://147.2.212.167/tests/369
remote-desktop-supportserver1: http://147.2.212.167/tests/368
xdmcp_gdm
remote-desktop-client2: http://147.2.212.167/tests/367
remote-desktop-supportserver2: http://147.2.212.167/tests/366
Updated by qkzhu over 7 years ago
Add a case of remote desktop via xdmcp_xdm to x11regressions
Validations:
Client: http://147.2.212.115/tests/429
Server: http://147.2.212.115/tests/428
PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2625
Updated by qkzhu over 7 years ago
Add autoyast xml file for remote desktop supportserver¶
This xml file is used to generate the qcow2 image for remote desktop supportserver which will be used as:
- SLES12SP2 base OS ( vncmanager and gdm is required )
- dhcp server
- ssh server
- xvnc server
- X server with xdmcp configured
Add a vino remote desktop case to x11regressions¶
This is a multi machine case for Gnome sharing (vino remote desktop) testing. We can not use supportserver or any apis in mm_networks since vino requires NetworkManager. I wrote a subroutine in x11regressiontest.pm to set static IP for NetworkManager.
Add main entry for 8 remote desktop cases in x11regressions¶
- onetime_vncsession_multilogin_failed.pm
- onetime_vncsession_xvnc_java.pm
- onetime_vncsession_xvnc_tigervnc.pm
- persistent_vncsession_xvnc.pm
- vino_client.pm
- vino_server.pm
- x11_forwarding_openssh.pm
- xdmcp_gdm.pm
- xdmcp_xdm.pm
Validation runs for the newly added vino cases and main entry : Please only see the green jobs
http://147.2.212.115/tests/overview?distri=sle&version=12-SP3&build=0156&groupid=60
PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2707
Updated by qkzhu over 7 years ago
Updated by qkzhu over 7 years ago
The qcow2 image was also generated as remote_desktop_supportserver.qcow2 : https://openqa.suse.de/tests/859839
I will create the testsuits and add them to job groups once the needles are merged.
Updated by qkzhu over 7 years ago
- Checklist item changed from [ ] SLE to [ ] SLE, [ ] TW
- % Done changed from 0 to 60
Updated by qkzhu over 7 years ago
The first 8 cases were added to o.s.d: https://openqa.suse.de/tests/overview?distri=sle&version=12-SP3&build=0174&groupid=61
Updated by okurz over 6 years ago
- Subject changed from Remote Desktop Testing to [desktop]Remote Desktop Testing
Hi qkzhu, what is your plan regarding this ticket?
Updated by qkzhu over 6 years ago
- Related to action #33493: [sle15sp1][desktop] Add RDP remote desktop cases to SLED15 added
Updated by qkzhu over 6 years ago
- Status changed from In Progress to Resolved
okurz wrote:
Hi qkzhu, what is your plan regarding this ticket?
Most cases of the test matrix have been implemented except the RDP cases which require a window qcow2 image.
And it was blocked by the window license issue, finally Yifan and I decided to use the window image from o.o.o
I will close this ticket and track the RDP issue by poo#33493