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 1393971 - [RFE] systemd unit for Xvnc (not vncserver)
Summary: [RFE] systemd unit for Xvnc (not vncserver)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tigervnc
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Grulich
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1393395
TreeView+ depends on / blocked
 
Reported: 2016-11-10 18:13 UTC by vinay
Modified: 2021-06-10 11:39 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 20:50:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2000 0 normal SHIPPED_LIVE Moderate: tigervnc and fltk security, bug fix, and enhancement update 2017-08-01 18:33:08 UTC

Description vinay 2016-11-10 18:13:49 UTC
Description of problem:
tigervnc-server currently contains a systemd unit file for vncserver, but it doesn't really work when one wishes to use VNC with XDMCP.  Instead, something like this is needed:

[Unit]
Description=VNC remote display %I
After=syslog.target

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/xvnc@%i
User=nobody
ExecStart=/usr/bin/Xvnc -SecurityTypes None -query 127.0.0.1 $XVNC_OPTIONS %i

[Install]
WantedBy=multi-user.target

It would be nice to have something like this added to the tigervnc-server-minimal package.

Comment 1 vinay 2016-11-10 18:14:59 UTC
Same was filed for fedora https://bugzilla.redhat.com/show_bug.cgi?id=891802

In addition to above

There also should be a socket unit file. (xinetd is a thing of the past)

I've combined this solution :
https://access.redhat.com/solutions/2516
and same story for centos that is not behind a firewall
http://www.itzgeek.com/how-tos/linux/centos-how-tos/remote-login-with-gdm-and-vnc-on-centos-7-rhel-7-configure-vnc-on-xinetd-with-xdmcp-centos-7-rhel-7.html

with this one
https://access.redhat.com/solutions/2681531

ie use a systemd socket and service not xinetd

Then you have a working xdmcp and vnc setup.

Also a readme explaining how to use these two socket files with an adjustment of the /etc/gdm/custom.conf

cat/etc/gdm/custom.conf
# GDM configuration storage

[daemon]

[security]
AllowRemoteRoot=true
DisallowTCP=false

[xdmcp]
Enable=true
MaxSessions=30

[greeter]

[chooser]

[debug]



cat /etc/systemd/system/xvnc.socket
[Unit]                                                                                                                                             
Description=XVNC Server                                                                                                                            
                                                                                                                                                   
[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target


cat /etc/systemd/system/xvnc.socket                                                                                                
[Unit]                                                                                                                                             
Description=XVNC Server                                                                                                                            
                                                                                                                                                   
[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target


cat /etc/systemd/system/xvnc@.service
[Unit]
Description=XVNC Per-Connection Daemon

[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1024x768 -depth 24 -once -SecurityTypes=None -fp /usr/share/X11/fonts/misc

User=nobody
StandardInput=socket
StandardError=syslog

Comment 5 Dave Close 2017-07-05 20:56:47 UTC
Love this solution! Unfortunately, it is insufficient for me or I'm doing something wrong trying to use it.

The default display manager for F23 and subsequent is SDDM, which does not include any XDMCP capability. A suggestion I found somewhere is to run "dnf install kdm; systemctl enable --force kdm.service". Then proceeding to follow these instructions and those at RH Solutions 2516 and 2681531, and modifying /etc/kde/kdm/Xaccess to uncomment "*", I get a connection but no login screen, just a blank screen with a momentary note about using F8. The log shows several errors at different times in my experiments. Sometimes Plymouth is not running. Sometimes I'm told the VNC service got more than one socket. Usually KDM reports that it can't open the display, using an IPv6 notation for the display.

Comment 6 Ed Greshko 2017-07-08 00:33:55 UTC
(In reply to Dave Close from comment #5)
> Love this solution! Unfortunately, it is insufficient for me or I'm doing
> something wrong trying to use it.
> 
> The default display manager for F23 and subsequent is SDDM, which does not
> include any XDMCP capability. A suggestion I found somewhere is to run "dnf
> install kdm; systemctl enable --force kdm.service". Then proceeding to
> follow these instructions and those at RH Solutions 2516 and 2681531, and
> modifying /etc/kde/kdm/Xaccess to uncomment "*", I get a connection but no
> login screen, just a blank screen with a momentary note about using F8. The
> log shows several errors at different times in my experiments. Sometimes
> Plymouth is not running. Sometimes I'm told the VNC service got more than
> one socket. Usually KDM reports that it can't open the display, using an
> IPv6 notation for the display.

I have this all working well and have answered your question on the Fedora Users List.  Let's follow-up there instead of here.

Comment 7 Dave Close 2017-07-12 20:41:31 UTC
Here's what I actually had to do to make this work on a reasonably vanilla Fedora 23 system.

# dnf -y install kdm
# systemctl enable --force kdm.service
# cat >/etc/systemd/system/xvnc@.service <<EOF
[Unit]
Description=XVNC per Connection Daemon
After=syslog.target
[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1280x1024 -depth 24 -once -SecurityTypes=None -fp /usr/share/X11/fonts/misc
StandardInput=socket
StandardError=syslog
EOF
# cat >/etc/systemd/system/xvnc.socket <<EOF
[Unit]
Description=XVNC Server
[Socket]
ListenStream=5900
Accept=yes
[Install]
WantedBy=sockets.target
EOF
## edit /etc/kde/kdm/Xaccess # uncomment the line, "#* #any host can get a login window"
## edit /etc/kde/kdm/kdmrc # set "Enable=true"
# systemctl enable xvnc.socket
# sed -i 'GRUB_CMDLINE_LINUX/s/"$/ ipv6.disable=1"/' /etc/default/grub
# grub2-mkconfig >/boot/grub2/grub.cfg
# reboot

Comment 8 Dave Close 2017-07-12 20:43:51 UTC
Change the sed line above to,

# sed -i '/GRUB_CMDLINE_LINUX/s/"$/ ipv6.disable=1"/' /etc/default/grub

Comment 9 errata-xmlrpc 2017-08-01 20:50:05 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://access.redhat.com/errata/RHSA-2017:2000

Comment 10 Dave Close 2017-08-01 21:15:58 UTC
Nothing in the advisory addresses the complaint in this ticket.

Comment 11 Ed Greshko 2017-08-01 21:47:19 UTC
IMO, this RFE was written to provide a functionality which did not previously exist.  It did so, and worked well for me.

In our off-line troubleshooting of the problem you encountered we determined that it was necessary, for some unknown reason, for you to disable IPv6 to get things to work while I did not need to take that same action.

Therefore, I believe it is not relevant to this RFE and a new bugzilla be written against either Xvnc (tigervnc-server-minimal) or GDM.  It would appear, I'm guessing, that in your case an IPv6 connection was first tried and when unsuccessful a IPv4 connection was not tried as a fallback.


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