RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 476343 - RFE: Document how to see other user's desktop via VNC
Summary: RFE: Document how to see other user's desktop via VNC
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Deployment_Guide
Version: 6.1
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Stephen Wadeley
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks: 561647
TreeView+ depends on / blocked
 
Reported: 2008-12-13 09:58 UTC by Răzvan Sandu
Modified: 2015-07-23 10:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-23 10:38:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Răzvan Sandu 2008-12-13 09:58:15 UTC
Description of problem:

Despite the fact there is a good guide about setting a VNC server:

http://fedorasolved.org/network-solutions/vncserver-setup

I was unable to find a good-quality piece of documentation that explains how to set up a stock install of RHEL in order to reach other user's desktop via VNC.

All pieces of documentation that I've found deal with setting a generic VNC server, in order to see a *blank* graphical desktop on a remote system. However, for providing technical support to remote users, it is often necessarry to see *that person's actual desktop*.
  
Actual results:
There is no piece of documentation describing how to (canonical) set up a RHEL box in order to (securely) access other's person desktop via VNC.

Expected results:
Such a piece of documentation should exist.


Thanks a lot,
Răzvan

Comment 4 RHEL Program Management 2010-08-09 19:17:25 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 7 RHEL Program Management 2011-06-14 10:05:15 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 13 Stephen Wadeley 2015-04-07 07:15:32 UTC
Hello Răzvan


Thank you for raising this bug.



Please see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-vnc-sharing-an-existing-desktop.html



Thank you

------------------


Red_Hat_Enterprise_Linux-Deployment_Guide-6-en-US-6-5.2

Comment 14 Răzvan Sandu 2015-04-07 16:48:02 UTC
Hello Stephen,

Thanks, that's GREAT, but there is something to be added/clarified:

The command:

x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1

must be given *on each ocassion* by an user standing in front of the "receiving" machine or can be used at any time (even *after* a reboot)? In other words, x0vncserver acts as a daemon (can be started automagically started at boot)

Setting a password for access, as a minimum security, is OK, but if the above command must be given explicitly every time when a user wants to receive a VNC session, the situation is less than ideal.

One can easily imagine scenarios in which the receiving user is not present (such as remote assistance & configuration provided by some administrator overnight, via VNC) or is simply not able/not wanting to type such an arcane command (non-technical users, the usual case).

Best regards,
Răzvan

Comment 15 Stephen Wadeley 2015-04-21 15:12:59 UTC
(In reply to Răzvan Sandu from comment #14)
> Hello Stephen,
Hello Răzvan
> 
> Thanks, that's GREAT, but there is something to be added/clarified:
> 
> The command:
> 
> x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1
> 
> must be given *on each ocassion* by an user standing in front of the
> "receiving" machine
Yes, if you try it you will see it runs in the terminal, even if you try to background it, and outputs logging messages.

 or can be used at any time (even *after* a reboot)? In
> other words, x0vncserver acts as a daemon (can be started automagically
> started at boot)
> 
> Setting a password for access, as a minimum security, is OK, but if the
> above command must be given explicitly every time when a user wants to
> receive a VNC session, the situation is less than ideal.

Besides the privacy issues, an administrator could connect over SSH, become that user, and then issue the command. 
> 
> One can easily imagine scenarios in which the receiving user is not present
> (such as remote assistance & configuration provided by some administrator
> overnight, via VNC) or is simply not able/not wanting to type such an arcane
> command (non-technical users, the usual case).
I agree the command is not user friendly. Perhaps a desktop icon to run the command would help?
See: https://help.gnome.org/admin/system-admin-guide/2.32/menustructure-desktopentry.html.en

Bare in mind GNOME has vino-server. See https://access.redhat.com/node/16608

I think sharing the users desktop is not required if the user is not present. You could use normal VNC or even SSH when the user is not present.
> 
> Best regards,
> Răzvan

Thank you

Regards
Stephen


Note You need to log in before you can comment on or make changes to this bug.