Недавно я изменил с Ubuntu 16.04 LTS на 18.04 LTS, так как мне нужна была новая версия kvm / qemu.
С 16.04 я смог легко запустить службу x11vnc (daemon), выполнив инструкции из «Community Help Wiki»: Ссылка
У этого есть сценарий, необходимый для настройки службы демона x11vnc, которая позволяет удаленно входить в систему без предварительной регистрации на локальном компьютере. Я требую этого, поскольку у меня есть моя машина, работающая как сервер, и находится в подвале, и я всегда получаю ее через VNC, а не локально.
Изначально я ничего не делал с моей чистой установкой 18.04, кроме добавления скрипта systemctl
точно в соответствии с инструкциями «Справка сообщества»: «Имейте x11vnc запускать автоматически через systemd в любой среде (Vivid +)».
Обнаружив, что это больше не работает, я сделал следующее, основанное на некотором поиске:
-
Диспетчер отображения отключен «Wayland», отредактировав
/etc/gdm3/custom.conf
и установивWaylandEnable=false
в этом скрипте:[daemon] # Uncoment the line below to force the login screen to use Xorg #WaylandEnable=false WaylandEnable=false <--- HERE
-
Изменена команда
/lib/systemd/system/x11vnc.service ExecStart
, чтобы использовать другую директивуxauth
, так как в 18.04, как представляется, автоматически не создается файл$HOME/.Xauthority
, который можно найти с помощью директивы-xauth guest
:From:
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /home/USERNAME/.vnc/passwd -rfbport 5900 -shared
To:
ExecStart=/usr/bin/x11vnc -auth /run/user/120/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/USERNAME/.vnc/passwd -rfbport 5920 -shared
Я сделал это, основываясь на некоторых чтениях и тестировании на Xauthority, которые указали, что местоположение токена .Xauthority
теперь предоставляется через переменную среды $XAUTHORITY
.
Чтобы найти значение этого, я запускаю следующую команду « find
», чтобы определить, какие процессы имеют переменную среды XAUTHORITY
.
ПРИМЕЧАНИЕ: для поиска переменных среды процесса используется файловая структура linux /proc/<procid>/environ
,
cd /proc
sudo find . -maxdepth 1 -type d -exec sh -c "(test -f '{}'/environ && cat '{}'/environ | tr 'sudo find . -maxdepth 1 -type d -exec sh -c "(test -f '{}'/environ && grep -aH XAUTHORITY= '{}'/environ )" \;
' '\n' | grep XAUTHORITY= )" \;
Это привело к двум различным результатам:
-
XAUTHORITY=/run/user/120/gdm/Xauthority
-
XAUTHORITY=/run/user/1000/gdm/Xauthority
Затем я использовал следующее, чтобы найти соответствующие идентификаторы процессов:
240 tty1 Sl+ 0:00 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
14923 tty2 Sl+ 0:00 /usr/lib/gnome-session/gnome-session-binary --session=ubuntu
Соответствующие процессы для них:
13/05/2018 16:19:14 *** XOpenDisplay failed.
Первый из них, похоже, связан с экраном приветствия входа, а второй - рабочим столом пользователя.
Дальнейшая проверка переменных окружения показывает, что у кого USER=gdm
, а у другого есть USER=<ME>
Проблема заключается в том, что если я использую «greeter» auth location, тогда мне будет предложено указать пароль, за которым следует черный / пустой экран. Если я использую пользовательское местоположение auth, то я вообще не получаю никакого клиентского соединения, так как статус возвращает ошибку, что он не может открыть Дисплей:
%pr_e%Итак, кажется, что вы попадаете в изменение механизма xauth.
Может кто-нибудь, пожалуйста, дайте некоторые рекомендации по этому поводу?