*** Bug 1757978 has been marked as a duplicate of this bug. ***

Martine can you please verify.

Thanks
-Tom

Please try with the latest build: tigervnc-1.9.0-12.el8.

Reproducer (written in /usr/lib/systemd/system/vncserver@.service):
1.# cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@.service

2. Replace <USER> with the actual user name and edit vncserver
  parameters in the wrapper script located in /usr/bin/vncserver_wrapper
   
  my file:
   
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple

# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/bin/vncserver_wrapper test2 %i
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'

[Install]
WantedBy=multi-user.target



3.# systemctl daemon-reload`
4.# systemctl enable vncserver@:88.service --now
5.Run vinagre, connect to <machine_ip>:88
6.Search for Lock in gnome-shell, Click Lock Screen
7.Press enter to see password prompt, type password, press enter

Successfully logged in, once more thanks a lot for help Jan :) .

tigervnc-1.9.0-12.el8

*** Bug 1767285 has been marked as a duplicate of this bug. ***

Can someone inform me how to get this version .12 that resolves the issue...yum in my case is pointing to the .10 release with the bug and 
I'm new to red hat and have no clue how to force the update to grab the 12 release...sorry for being so green...

thanks gang...
btw they should update the repos to this bug fix version my red hat install is less then 2 weeks old...


dan

(In reply to dducharme from comment #23)
> Can someone inform me how to get this version .12 that resolves the
> issue...yum in my case is pointing to the .10 release with the bug and 
> I'm new to red hat and have no clue how to force the update to grab the 12
> release...sorry for being so green...
> 
> thanks gang...
> btw they should update the repos to this bug fix version my red hat install
> is less then 2 weeks old...
> 
> 
> dan

It will be officially released within 8.2.0. What version have you installed? If 8.1.0 than you need to wait for 8.2.0.

Running 

cat /etc/redhat-release 

should give you a hint about version.

-Tom

Im running 8.1...thank god I haven't migrated customers to this release they would be angry that vnc access would fail...the application
issues alone would be a major nightmare....lesson learned and glad i caught this as if I migrated over I would be in a huge mess...
I think this issue is a bug on tiger vnc side...but it's hard to understand how this was missed in qa...remote access is critical and it's crazy that something like this missed in testing....how in lab environments with remote access being the primary access method...was this missed....

(In reply to dducharme from comment #25)
> Im running 8.1...thank god I haven't migrated customers to this release they
> would be angry that vnc access would fail...the application
> issues alone would be a major nightmare....lesson learned and glad i caught
> this as if I migrated over I would be in a huge mess...
> I think this issue is a bug on tiger vnc side...but it's hard to understand
> how this was missed in qa...remote access is critical and it's crazy that
> something like this missed in testing....how in lab environments with remote
> access being the primary access method...was this missed....

That is a good question, unfortunately I don't have the answer. But we will investigate whether we are missing something important.

Anyway as 8.2.0 is going to be released in some time do you want z-stream update for vnc in 8.1.0.z so you are not blocked and don't need to wait for 8.2.0?

-Tom

Running Tigervnc as systemd service was always a pain and will always be, until upstream finishes proper systemd support. At this time it wasn't our change in Tigervnc which broke this behavior, but it was a systemd change. Same happened in RHEL 7. Using systemd user service was the only solution we were able to come up with during RHEL 8.1 development and this bug was an unfortunate side effect, because when Tigervnc runs as a user service, then the session is not properly authenticated and thus you cannot unlock the screen. You could still run "vncserver" directly (not using systemd) and that would work perfectly fine.

For RHEL 8.2 we found a solution and we are now able to use systemd system service again, but little bit in a different way.

so moving forward....how are we supposed to connect to vnc/x windows remotely on rhel8.1? currently I get black screens for user/service# configs....and i have to disable lock screen
on root access which is dangerous in production/internet exposed systems...this is crazy...just tell customers wait until 8.2...how can red hat executive management/sales be ok with this...this makes NO sense
red hat will loose market share growth as we want to deploy 8.1 to aws/azure cloud services....

thanks again Jan

dan

Couple of things:
1) VNC session cant be considered as secure compared to ssh access for example
2) openning VNC for root is even worse idea

but I'm not here to judge or argue about how you set expectations. 

May I ask for your use case? The admin of the system is simply connecting through VNC as root to do admin job in some sort of GUI admin console or third party app? Have you seen cockpit?

Also based on your reply I assume you would appreciate fix prior to 8.2. Let me see what we can do here.

-Tom

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1662