Bug 136596

Summary: Unexpected behavior from vino when multiple logins on the same X server
Product: [Fedora] Fedora Reporter: Jef Spaleta <jspaleta>
Component: vinoAssignee: David Zeuthen <davidz>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mclasen, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-07 00:02:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jef Spaleta 2004-10-21 04:35:51 UTC
Description of problem:
A) Multiple logins on the same server (different users or the same
user multiple times) enabling vino, the configuration tool lists
server:0 in the text for all cases... even when really the display
number is changing  so i should be seeing server:0 server:1 server:2
etc... depending on the X display number that each desktop on the
machine is actually using.  The text in the config tool should update
depending on the display in use on the server for that desktop.

B) Multiple desktop logins of the same user on a server only.
When vino is enabled on one desktop, its enabled on ALL the running
desktops for that user on the same server. In large multiuser networks
this could be an important case to consider. I would expect vino to be
enabled per desktop and not enabled for all desktop displays that user
is logged into. Should I file this issue seperately from the first?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce Problem A:

1. log into gnome desktop as user1
2. start a second desktop using gdmflexiserver  as user2
3. in user2's desktop use vino config tool... note which server:number 
string is mentioned. the number is 0 for me.
4. in user1's desktop use vino config tool... note the same
server:number string as fore user2
5. connect remotely using vncviewer on another machine to server:0.
note which user it is user1 or user2. connect remotely to server:1 and
note which user it is.
Steps to Reproduce Problem B:
1. log into gnome desktop as user1
2. start second desktop using gdmflexiserver as user1
3. in second desktop start vino
4. connect remotely using vncviewer and notice that both :0 and :1 are
accessible to vncviewer even though you have configure vino in only
one desktop 

Expected results:
A: text in the config tool needs to match the display number thats
actually in use instead of being stuck at :0

B: i would have expected to be able to control vino per desktop
instance for a user. Multiple logins to the same central X server isnt
unheard of in large multiuser networks, with semi-public computer labs.

Comment 1 Bug Zapper 2008-04-03 15:43:07 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 2 Bug Zapper 2008-05-07 00:02:08 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here: