Bug 1174570

Summary: Rebase to 3.14.2
Product: Red Hat Enterprise Linux 7 Reporter: Matthias Clasen <mclasen>
Component: vinoAssignee: David King <dking>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: b24warbaby, dking, tpelka, vhumpa
Target Milestone: rcKeywords: Rebase
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: vino-3.14.2-1.el7 Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 07:26:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1174373    
Attachments:
Description Flags
gconf-editor none

Description Matthias Clasen 2014-12-16 03:17:48 UTC
We are planning a desktop rebase to GNOME 3.14.x in 7.2. This includes vino, which should be rebased to 3.14.1

Comment 3 b24warbaby 2015-04-06 14:08:48 UTC
CentOS-7  vino is broken also; can't connect to vino using any previous vnc viewers  even after setting :

gsettings set org.gnome.Vino require-encryption false


Screen remains blank

Comment 4 b24warbaby 2015-04-06 14:10:34 UTC
gconf-editor doesn't even show the 

  require-encryption false

 option

Comment 5 b24warbaby 2015-04-06 14:11:46 UTC
Created attachment 1011387 [details]
gconf-editor

Shows no 

require-encryption false

option

Comment 6 b24warbaby 2015-04-06 14:24:56 UTC
rpm -q vino
vino-3.8.1-10.el7.x86_64

Comment 7 David King 2015-04-07 09:38:50 UTC
(In reply to b24warbaby from comment #3)
> CentOS-7  vino is broken also; can't connect to vino using any previous vnc
> viewers  even after setting :
> 
> gsettings set org.gnome.Vino require-encryption false
> 
> 
> Screen remains blank

That is unrelated to this bug, which is about updating to a more recent upstream Vino version, so please file it as a separate bug, with exact steps to reproduce the problem.

(In reply to b24warbaby from comment #4)
> gconf-editor doesn't even show the 
> 
>   require-encryption false
> 
>  option

require-encryption is a GSettings key, so you can find it in dconf-editor.

Comment 8 b24warbaby 2015-04-08 16:20:09 UTC
Specifically , Why did vino stop working without this encryption option set in CentOS7 ? or RH7 ?


vino has worked flawlessly on RH5 and RG6 for years on a variety of viewers on Linux, MacOS. and Windows . 


No documentation even references having to dig through gconf-edit .. How come the GNOME setup is missing this ?

Comment 9 David King 2015-04-08 16:26:07 UTC
(In reply to b24warbaby from comment #8)
> Specifically , Why did vino stop working without this encryption option set
> in CentOS7 ? or RH7 ?
> 
> 
> vino has worked flawlessly on RH5 and RG6 for years on a variety of viewers
> on Linux, MacOS. and Windows . 

It is still unrelated to this bug, and this is not a good forum for discussion. The default configuration changed in Vino so that require-encryption defaults to true. Clients which do not support Vino's encryption protocol are rejected in this configuration. If you want the VNC connection to remain insecure, you are welcome to disable the encryption requirement. Alternatively, you can use Vinagre or another client which supports the same encryption protocol.

> No documentation even references having to dig through gconf-edit .. How
> come the GNOME setup is missing this ?

GConf is not used in GNOME any more, and you should investigate GSettings and dconf-editor instead.

Comment 11 Vitezslav Humpa 2015-08-31 11:44:04 UTC
vino-3.14.2-1.el7 is present within all rhel-7 composes

Comment 12 errata-xmlrpc 2015-11-19 07:26:22 UTC
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://rhn.redhat.com/errata/RHBA-2015-2215.html