XDMCP‎ удаленно

gdm какой версии?
В новых xdmcp был давно сломан. В дженте вон вообще 2.20.* используется до сих пор по этой причине.

насколько я помню, gdm по-умолчанию не слушает tcp.

пропиши в конфиге DisallowTCP=false

В новых xdmcp был давно сломан

Fedora 13, все работает, gdm-2.30.2, ЧЯДНТ?

И там есть «удаленный вход с использованиям XDMCP»?

Да, нормально заходит с удаленной машины.

[daemon]

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[greeter]
GraphicalTheme=Feel_The_Benefit
GraphicalThemes=Feel_The_Benefit:FedoraInfinity

[chooser]

[debug]

Тьфу, или ты хотел из локального gdm подключиться к удаленной системе? Такое не проверял.

> Fedora 13, все работает, gdm-2.30.2, ЧЯДНТ?
Как там насчёт патчей? Есть в rpm для сборки? В дженте же не чинят, а просто тупо замаскировали. И емнип у папая слакварь. Там сборщики могут быть не приучены к горшку^Wпатчить.

был:
# gdm --version
GDM 2.20.1

стал:
gdm3 --version
GDM 2.30.5

Не помогло, тотже черный экран X и все:(

> пропиши в конфиге DisallowTCP=false

непомогло

> И емнип у папая слакварь.

нет:)в этом, частном случае,- это удаленный объект и там Debian squeeze

Трафик ни что не блокирует, т.к. окно X я всетаки получаю, не получаю только приветствие GDM. Попробовал и KDM и XDM. Используя любой из них, получаю все тот же экран голого X.
Похоже, что проблема с тем, что я пытаюсь удаленно через инет зайти используя белый адрес. Потому как подобного я раньше, ни когда не наблюдал подключаясь в локальной сети.

Подними тоннель в локалку. Попробуй подключиться через него.

> Подними тоннель в локалку. Попробуй подключиться через него.

server: ssh -N -R 1771:localhost:177 dmitry@1.2.3.4

host: Xnest :1771

получаю тоже пустое X окно,,,,

Всем спасибо за участие!

Задача для меня останется НЕ решенной.
Время - дороже!

пойду другим путем .....

кстати, а gdm как демон запущен?

То, что рисуется окно иксов, не значит, что есть связь с сервером XDMCP. Оно сначала рисуется, потом начинается собственно диалог.

При соединении по XDMCP клиент явным образом при handshake'е передает свой IP-адрес. То есть если клиент за NAT'ом, то он передаст какой-нибудь 192.168.1.34, и сервер будет слать ответ, соответственно, именно на этот адрес, в никуда. Поэтому XDMCP за NAT'ом — это фантастика, насколько я понимаю. Если на клиенте несколько сетевых интерфейсов, то тоже может быть неразбериха, для надежности надо запускать с ключиком -from.

жесть, сколько умных слов в каментах
покажи свой ~/.xinitrc или как у вас там файл зовётся, который gdm при запуске выполняет?

а простой xforward не спасает?

> То есть если клиент за NAT'ом,

NATа нет, сессия устанавливается между двумя белыми адресами.

> а простой xforward не спасает?

Да конечно можно. Но мне нужно давать удаленному пользователю приветствие kdm, gdm или xdm и соответствующую сессию, а не форвардить отдельное X приложение. Дело в том, что вообще там всегда стоял и стоит x11vnc и все прекрасно работало до пары дней назад. Сейчас появился vnc-глюк, который я побороть не могу. В этой связи я и решил, а почему бы не запустить XDMCP‎

> покажи свой ~/.xinitrc или как у вас там файл зовётся, который gdm при запуске выполняет?

До ~/ дело так и не доходит, т.к. приглашения ввести имя пользователя я не получаю.

есть /etc/X11/xinit/xinitrc который НЕ является конфигом и содержит одну строчку указывающую на использование /etc/X11/Xsession, который в свою очередь является: # global Xsession file — used by display managers and xinit (startx) и соответственно также не является настраиваемым.

запускай с -nodaemon и цепляйся при помощи Xnest -query AA.BB.CC.DD -ac :1.0

Дополню: и порт 177 проверьте, не закрыт ли на целевой машине...

> запускай с -nodaemon и цепляйся при помощи Xnest -query AA.BB.CC.DD -ac :1.0

Спасибо, но уже x11vnc заработал, хотя и он уже не нужен, т.к. я сделал решение всех задач для этого хоста только для консоли. Так что админам, что будут туда подключаться X уже и не нужен... Да, и в долгожданный отпуск я отправляюсь так что не до экспериментов сейчас :)

Как бы то ни было - СПАСИБО!

P.S. хотя, после отпуска попробую, т.к. знаю, что не успокоюсь, - самому интересно:))

Дополню: и порт 177 проверьте, не закрыт ли на целевой машине...

root@ryabinovaya:/home/alex# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            
root@ryabinovaya:/home/alex#