Bug 1273156 - GDM does not work with XDMCP indirect
Summary: GDM does not work with XDMCP indirect
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdm
Version: 7.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-19 19:03 UTC by Wolfgang Baudler
Modified: 2018-03-06 09:40 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-08-01 22:57:55 UTC


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2128 normal SHIPPED_LIVE Moderate: gdm and gnome-session security, bug fix, and enhancement update 2017-08-01 19:38:38 UTC

Description Wolfgang Baudler 2015-10-19 19:03:16 UTC
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 19:10:19 UTC
Xephyr -query <ip.address>

should have read

Xephyr -indirect <ip.address>

Comment 3 Ray Strode [halfline] 2015-10-26 16:52:58 UTC
what's the output of

iptables -L

Comment 4 Ray Strode [halfline] 2015-10-26 16:53:14 UTC
(on both machines)

Comment 5 Wolfgang Baudler 2015-10-26 17:24:10 UTC
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 15:53:23 UTC
Any update on this problem? It has been almost a year now.

Comment 7 Ray Strode [halfline] 2016-09-20 16:52:29 UTC
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 17:42 UTC
Created attachment 1202988 [details]
/var/log/gdm/:0.log

Comment 9 Wolfgang Baudler 2016-09-20 17:44:03 UTC
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 17:44 UTC
Created attachment 1202989 [details]
/var/log/gdm/:0-greeter.log

Comment 11 Ray Strode [halfline] 2016-09-20 17:52:09 UTC
can you attach /var/log/messages ?

Comment 12 Wolfgang Baudler 2016-09-20 19:05 UTC
Created attachment 1203004 [details]
/var/log/messages showing gdm startup and XDMCP connection attempt

Comment 13 Ray Strode [halfline] 2017-01-03 19:53:43 UTC
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 15:17:06 UTC
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 14:55:28 UTC
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 16:56:40 UTC
(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 17:05:35 UTC
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 17:19:24 UTC
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 20:50:33 UTC
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 15:09:04 UTC
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 15:12:20 UTC
With RHEL 7.4 on both client and server machines?

Comment 29 Michael Boisvert 2017-06-27 15:15:08 UTC
(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 22:57:55 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:2128


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