Говорим серверу:

Создание авторизационной записи

Если вы хотите использовать xauth, запустите X-сервер с аргументом -auth authfile. Если вы пользуетесь скриптом startx, лучше это сделать в нем. Создайте авторизационную запись, как показано ниже в вашем скрипте startx.

Отрывок из /usr/X11R6/bin/startx:

mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority"

Mcookie - это простая программа в пакете util-linux (ftp://ftp.math.uio.no/pub/linux/). Кроме того, вы можете использовать md5sum для преобразования случайных данных (например, из /dev/urandom или ps -axl) в формат авторизационной записи:

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority"

Если вы не можете отредактировать скрипт startx (если вы не root), скажите своему системному администратору, чтобы он настроил startx правильно, или пусть установит xdm. Если он не хочет или не может, вы можете создать скрипт ˜/.xserverrc. Если он у вас есть, он запускается через xinit, а не через X-сервер. Затем вы можете запустить X-сервер из этого скрипта с правильными аргументами:

#!/bin/sh mcookie|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

Если для управления сеансами вы используете xdm, то можно легко использовать xauth. Определите ресурс DisplayManager.authDir в /etc/X11/xdm/xdm-config. Во время запуска X-сервера xdm сам укажет аргумент -auth, а когда вы войдете в систему, xdm положит авторизационную запись в ваш ˜/.Xauthority. Для дополнительной информации читайте xdm(1). Например, мой /etc/X11/xdm/xdm-config содержит следующую строчку:

DisplayManager.authDir: /var/lib/xdm

Передача авторизационных записей

Теперь, когда вы запустили X-сервер на машине light.uni.verse и у вас есть файл ˜/.Xauthority, нужно передать авторизационную запись на машину клиента dark.matt.er.

Самое простое, если у вас один и тот же сетевой домашний каталог на машинах light и dark. Файл ˜/.Xauthority один и тот же и авторизационная запись передается моментально. Тем не менее, здесь есть одна проблема: когда вы кладете авторизационную запись для :0 в ˜/.Xauthority, машина dark думает, что эта запись для нее, а не для light. Поэтому вам нужно явно указывать имя компьютера во время создания записи. Можно установить одинаковую запись для :0 и light:0 при помощи:

#!/bin/sh cookie=`mcookie` xauth add :0 . $cookie xauth add "$HOST:0" . $cookie exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

Если домашний каталог не разделяется между машинами, вы можете передать авторизационную запись при помощи rsh:

light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -

1. Извлечь запись из ˜/.Xauthority (xauth nlist :0).

2. Передать на dark.matt.er (| rsh dark.matt.er).

3. Поместить ее в ˜/.Xauthority there (xauth nmerge -).

Замечу насчет ${HOST}. Вам нужно передать авторизационную запись, явно ассоциированную с локальной машиной. Удаленное приложение может интерпретировать :0 как ссылку на удаленную машину, а это не то, что вы хотите!

Возможно, что rsh не разрешен для вас. Кроме того, rsh имеет недостаток с точки зрения безопасности (можно подделать имя машины, если я правильно помню). Если вы не можете или не хотите использовать rsh, передайте авторизационную запись вручную. Примерно так:

light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% logout light$

Для дополнительной информации см. rsh(1) и xauth(1x).

Есть возможность передать авторизационную запись в переменных окружения TERM или DISPLAY. Это делается таким же образом, как и передача переменной DISPLAY. См. раздел "Говорим клиенту:". Это моя точка зрения, но я заинтересован в том, чтобы кто-нибудь подтвердил или опроверг ее.

Использование авторизационной записи

X-приложение на машине dark.matt.er, такое как xfig, автоматически заглядывает в файл ˜/.Xauthority и ищет нужную запись для авторизации.

Есть небольшая проблема во время использования localhost:D. X-клиент во время поиска записи может перевести localhost:D как host/unix:D. На самом деле это означает, что авторизационная запись для localhost:D в ˜/.Xauthority не имеет эффекта.