Bug 1273156 - GDM does not work with XDMCP indirect
GDM does not work with XDMCP indirect
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdm (Show other bugs)
7.1
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Ray Strode [halfline]
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-19 15:03 EDT by Wolfgang Baudler
Modified: 2017-08-01 18:57 EDT (History)
5 users (show)

See Also:
Fixed In Version: gdm-3.22.3-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 18:57:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/gdm/:0.log (15.67 KB, text/plain)
2016-09-20 13:42 EDT, Wolfgang Baudler
no flags Details
/var/log/gdm/:0-greeter.log (21.60 KB, text/plain)
2016-09-20 13:44 EDT, Wolfgang Baudler
no flags Details
/var/log/messages showing gdm startup and XDMCP connection attempt (33.60 KB, text/plain)
2016-09-20 15:05 EDT, Wolfgang Baudler
no flags Details

  None (edit)
Description Wolfgang Baudler 2015-10-19 15:03:16 EDT
Description of problem:
When firing up an X server to display the XDMCP chooser like this:

X -indirect 192.33.116.244 -nolisten inet6

I only get a black screen.

Version-Release number of selected component (if applicable):
gdm-3.8.4-32.el7.x86_64

How reproducible:
GDM on RHEL7 is setup like this in /etc/gdm/custom.conf:

[daemon]

[security]
DisallowTCP=false

[xdmcp]
Enable=true
HonorIndirect=true
DisplaysPerHost=3

[greeter]

[chooser]

[debug]
Enable=true

Steps to Reproduce:
1. X -indirect <ip.address> -nolisten inet6

or 

Xephyr -query <ip.address>

Actual results:
black screen or black window (with Xephyr)

Expected results:
GDM XDMCP chooser Window

Additional info
Since kdm has been removed in RHEL7, gdm is the only available choice for XDMCP setups
Comment 1 Wolfgang Baudler 2015-10-19 15:10:19 EDT
Xephyr -query <ip.address>

should have read

Xephyr -indirect <ip.address>
Comment 3 Ray Strode [halfline] 2015-10-26 12:52:58 EDT
what's the output of

iptables -L
Comment 4 Ray Strode [halfline] 2015-10-26 12:53:14 EDT
(on both machines)
Comment 5 Wolfgang Baudler 2015-10-26 13:24:10 EDT
Iptables is at the RHEL7.1 default on both machines

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

Even after a "iptables --flush" on both machines, I still get the same result.
Comment 6 Wolfgang Baudler 2016-09-20 11:53:23 EDT
Any update on this problem? It has been almost a year now.
Comment 7 Ray Strode [halfline] 2016-09-20 12:52:29 EDT
can you add Enable=true to the [debug] section of /etc/gdm/custom.conf, reboot, reproduce and then attach /var/log/messages and /var/log/gdm/* ?
Comment 8 Wolfgang Baudler 2016-09-20 13:42 EDT
Created attachment 1202988 [details]
/var/log/gdm/:0.log
Comment 9 Wolfgang Baudler 2016-09-20 13:44:03 EDT
Enable=true in the [debug] section was already set.

Re-tested with RHEL 7.2 and the same problem still exists (black screen instead of usable XDMCP chooser).

/var/log/messages:
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: invalid (NULL) pointer instance
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: invalid (NULL) pointer instance
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: g_object_bind_property_full: assertion 'G_IS_OBJECT (source)' failed
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: invalid (NULL) pointer instance
Sep 20 13:36:48 rhel7-test gdm: GLib-GObject: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Sep 20 13:36:48 rhel7-test gdm: gdm_slave_start: assertion 'GDM_IS_SLAVE (slave)' failed
Sep 20 13:36:50 rhel7-test gdm: gdm_slave_start: assertion 'GDM_IS_SLAVE (slave)' failed
Sep 20 13:36:54 rhel7-test gdm: gdm_slave_start: assertion 'GDM_IS_SLAVE (slave)' failed

The GDM_IS_SLAVE failed messages repeat about every 16 seconds.

/var/log/gdm/* files added as attachments.
Comment 10 Wolfgang Baudler 2016-09-20 13:44 EDT
Created attachment 1202989 [details]
/var/log/gdm/:0-greeter.log
Comment 11 Ray Strode [halfline] 2016-09-20 13:52:09 EDT
can you attach /var/log/messages ?
Comment 12 Wolfgang Baudler 2016-09-20 15:05 EDT
Created attachment 1203004 [details]
/var/log/messages showing gdm startup and XDMCP connection attempt
Comment 13 Ray Strode [halfline] 2017-01-03 14:53:43 EST
I believe the problem is this code:

        g_object_class_install_property (object_class,•
                                         PROP_SLAVE_TYPE,•
                                         g_param_spec_gtype ("slave-type",•
                                                             "slave type",•
                                                             "slave type",•
                                                             GDM_TYPE_SIMPLE_SLAVE,•
                                                             G_PARAM_READWRITE | G_PARAM_CONSTRUCT));•


inside gdm-display.c.

The GDM_TYPE_SIMPLE_SLAVE there is too specific.  It should just say the more general GDM_TYPE_SLAVE, so that a slave type of GDM_TYPE_XDMCP_CHOOSER_SLAVE is allowed, as specified in gdm-xdmcp-chooser-display.c.

This bug was introduced as part of the cleanup work done upstream here:

https://bugzilla.gnome.org/show_bug.cgi?id=726380
Comment 19 Michael Boisvert 2017-06-20 11:17:06 EDT
I have two 7.4 machines set up, one with the custom.conf specified and one I am using to try to connect to it. Both have gdm-3.22.3-11. I start both in runlevel 3 and run "X -indirect <ip address> -nolisten inet6" I only get a black screen still. Am I missing something or can you give it a try with your setup Wolfgang?
Comment 22 Wolfgang Baudler 2017-06-21 10:55:28 EDT
I don't have a RHEL 7.4 (beta?) machine at the moment, but I just now re-tested this on RHEL 7.3 with gdm-3.14.2-20.el7_3.x86_64 and the problem still persists. All I get is the black screen.

I will try to get a RHEL7.4 test setup, but your report with gdm-3.22.3-11 is not encouraging.

It has been quite a while since I reported this. What needs to happen to get this bug fixed? It is preventing upgrades to RHEL7 on our XDMCP servers.
Comment 23 Michael Boisvert 2017-06-21 12:56:40 EDT
(In reply to Wolfgang Baudler from comment #22)
> I don't have a RHEL 7.4 (beta?) machine at the moment, but I just now
> re-tested this on RHEL 7.3 with gdm-3.14.2-20.el7_3.x86_64 and the problem
> still persists. All I get is the black screen.
> 
> I will try to get a RHEL7.4 test setup, but your report with gdm-3.22.3-11
> is not encouraging.
> 
> It has been quite a while since I reported this. What needs to happen to get
> this bug fixed? It is preventing upgrades to RHEL7 on our XDMCP servers.

I am able to get Xephyr to work correctly and as you described. Can you elaborate on the exact setup in order for the "X -indirect <ip address> -nolisten inet6" command to previously function?
Comment 24 Wolfgang Baudler 2017-06-21 13:05:35 EDT
X or Xephyr should not matter. Using Xephyr is just easier to use for testing this.

Xephyr works for you? You get a XDMCP chooser window displayed as it should when connecting to a RHEL7 gdm display manager?

This works for me only with RHEL6, which uses kdm, not gdm. I have actually not tried with gdm on RHEL6. But since kdm is no longer available on RHEL7, it is necessary to make it work with gdm now.
Comment 25 Michael Boisvert 2017-06-21 13:19:24 EDT
I stand corrected. I cannot connect a 7.4 to a 7.4 machine using either of the methods. I am able to use Xephyr to connect to the 7.4 "host" from a Fedora 24 "client." Both methods provide a black screen with using 7.4 machines. Also note, multiple restarts and iptables -F didn't make a difference. 

gdm-3.22.3-11.el7 on both machines.
Comment 26 Ray Strode [halfline] 2017-06-21 16:50:33 EDT
Hi Wolfgang,

Mike is on the QE team and is testing some fixes that are designed to address this bug report for the next synchronous update of Red Hat Enterprise Linux (7.4).  Based on testing feedback from Mike, those fixes are either incomplete or there's a configuration problem with Mike's setup. Red Hat will continue to investigate and report back.
Comment 27 Michael Boisvert 2017-06-27 11:09:04 EDT
Ray came over and found an issue with the firewall on my "client" machine. Fortunately it was a setup issue and I am now able to use both methods described in this bug to see the XDMCP greeter and subsequently log into an XDMCP session.
Comment 28 Wolfgang Baudler 2017-06-27 11:12:20 EDT
With RHEL 7.4 on both client and server machines?
Comment 29 Michael Boisvert 2017-06-27 11:15:08 EDT
(In reply to Wolfgang Baudler from comment #28)
> With RHEL 7.4 on both client and server machines?

Correct, both machines have RHEL 7.4 Workstation installed on them.
Comment 30 errata-xmlrpc 2017-08-01 18:57:55 EDT
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:2128

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