Проблемы менеджера дисплея

Когда Х-сервер на Х-терминале успешно запустился, он пытается соединиться с менеджером дисплея сервера Х-терминалов для получения графического приглашения ввода имени пользователя и пароля. Если с настройками менеджера дисплея что-то не так, то пользователь Х-терминала будет лицезреть на сером фоне экрана большой Х-курсор “мышки”. Это наверное самая распространенная проблема, которая встречается при настройке удаленного подключения к менеджеру дисплея, используя протокол XDMCP.

Если вам "посчастливилось" увидеть этот унылый серый фон рабочего стола и одинокий курсор в виде буквы “Х”, и вы смотрите на него уже более 1 минуты, значит проблема подключения к менеджеру дисплея сервера налицо. Для выявления причин такого поведения Х-терминала, проверим запущена ли программа менеджера дисплея. Посмотрите на результат выполнения этой команды:

# netstat -ap | grep xdm
udp        0      0 *:xdmcp                 *:*                                 912/gdm-binary

Как видно, с протоколом XDMCP действительно связан процесс с идентификатором 912 и именем программного файла gdm-binary. В противном случае сервер просто не обрабатывает запросы по протоколу XDMCP или менеджер дисплея не запущен.

Если программа менеджера дисплея работает, а подключение к ней Х-терминалов все равно не происходит, то причину ошибки следует искать в ее настройках. Так, в некоторых случаях, менеджер дисплея может попросту игнорировать запросы от удаленных компьютеров.

В операционной системе Linux используются в основном 3 менеджера дисплея: XDM, GDM и KDM. XDM – это старейший представитель подобных программ, включается практически во все дистрибутивы X-Windows. GDM и KDM - это соответственно менеджеры дисплеев таких оконных менеджеров как Gnome и KDE. Они отличаются от XDM более широкими возможностями по настройке экрана графического входа в систему. В зависимости от того, каким менеджером дисплея пользуетесь вы, вам следует проверить его файлы конфигурации.

XDM

В файле /etc/X11/xdm/xdm-config не должно быть такой строки:

DisplayManager.requestPort:     0

Иначе удаленные XDMCP-запросы на 177 порту будут попросту игнорироваться.

В файле /etc/X11/xdm/Xaccess должна присутствовать такая строка:

*            #any host can get a login window

Обратите особое внимание, что данная строчка не должна быть закомментирована символом “#”.

KDM

Проверьте содержимое файла /etc/X11/xdm/kdmrc (в некоторых дистрибутивах /etc/kde/kdm/kdmrc). Вас в частности должны интересовать такие строки раздела [Xdmcp]:

[Xdmcp]
# Whether KDM should listen to XDMCP requests. Default is true.
Enable=true
# The UDP port KDM should listen on for XDMCP requests. Don't change the 177.
#Port=177

Если опция XDMCP “Enable=true” и порт для XDMCP запросов 177, то менеджер дисплеев KDM должен отвечать удаленным пользователям Х-терминалов.

GDM

Для менеджера дисплеев GDM находим в файле /etc/X11/gdm/gdm.conf раздел [xdmcp]:

[xdmcp]
# Distributions: Ship with this off.  It is never a safe thing to leave
# out on the net.  Alternatively you can set up /etc/hosts.allow and
# /etc/hosts.deny to only allow say local access.
Enable=true
# Honour indirect queries, we run a chooser for these, and then redirect
# the user to the chosen host.  Otherwise we just log the user in locally.
HonorIndirect=true
# Maximum pending requests
MaxPending=4
MaxPendingIndirect=4
# Maximum open XDMCP sessions at any point in time
MaxSessions=16
# Maximum wait times
MaxWait=15
MaxWaitIndirect=15
# How many times can a person log in from a single host.  Usually better to
# keep at 1 to fend off DoS attacks by running many logins from a single
# host
DisplaysPerHost=2
# The port.  177 is the standard port so better keep it that way
Port=177
# Willing script, none is shipped and by default we'll send
# hostname system id.  But if you supply something here, the
# output of this script will be sent as status of this host so that
# the chooser can display it.  You could for example send load,
# or mail details for some user, or some such.
Willing=/etc/X11/gdm/Xwilling

В первую очередь проверяем, разрешены ли вообще XDMCP-запросы (опция “Enable=true”, в некоторых старых версиях GDM “Enable=1”). Потом, смотрим на каком порту ожидаются эти запросы (должен быть “Port=177”). Если вы наблюдаете ситуацию, когда Х-терминал иногда подключается к удаленному менеджеру дисплеев GDM, а иногда нет, то проверьте также параметры “MaxSessions” и “DisplaysPerHost”. Значение MaxSessions означает, сколько всего удаленных пользователей может подключиться к менеджеру дисплеев GDM, а значение DisplaysPerHost позволяет ограничивать число параллельных запросов на подключение с одного узла (IP-адреса) локальной сети. Хотя из соображений безопасности (например, для борьбы с DoS атаками) целесообразно устанавливать DisplaysPerHost=1, иногда при аварийном выключении Х-терминала, он не может повторно подсоединиться к менеджеру дисплея. Поэтому, чтобы лишний раз не отвечать на вопросы пользователей, почему их Х-терминал не включается, я устанавливаю DisplaysPerHost равным 2.

Иногда проблема подключения удаленного пользователя к менеджеру дисплея связана с неправильными настройками DNS или тем, что вы просто забыли описать Х-терминал в файле /etc/hosts. При похожих проблемах обязательно проверьте правильно ли сопоставляется доменное имя Х-терминала и его IP-адрес. Например, для Х-терминала, с IP-адресом 192.168.1.23 и доменным именем natax это можно протестировать при помощи команды ping:

$ ping -c 3 192.168.1.23
PING 192.168.1.23 (192.168.1.23) 56(84) bytes of data.
64 bytes from 192.168.1.23: icmp_seq=1 ttl=64 time=0.132 ms
64 bytes from 192.168.1.23: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 192.168.1.23: icmp_seq=3 ttl=64 time=0.119 ms

--- 192.168.1.23 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.113/0.121/0.132/0.012 ms

$ ping -c 3 natax       
PING natax.alker.net (192.168.1.23) 56(84) bytes of data.
64 bytes from natax.alker.net (192.168.1.23): icmp_seq=1 ttl=64 time=0.118 ms
64 bytes from natax.alker.net (192.168.1.23): icmp_seq=2 ttl=64 time=0.114 ms
64 bytes from natax.alker.net (192.168.1.23): icmp_seq=3 ttl=64 time=0.489 ms

--- natax.alker.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2038ms
rtt min/avg/max/mdev = 0.114/0.240/0.489/0.176 ms

Пока интересно, читаем дальше!