Пересылка SSH X11 через VPN очень медленная

Интересная ошибка, какой файл/путь Вы используете? Действительно ли это - системный путь, Вы выполнили powershell как администратор (контроль учётных записей)?

Ваш демонстрационный сценарий обновит владельца файла, поскольку это - часть $acl.

4
задан 25 January 2016 в 13:52
2 ответа

Проблема с пересылкой современного X (не того «старого» X, когда была изобретена его сетевая прозрачность) со сглаживанием шрифтов: чтобы правильно сгладить каждый глиф текста, отображаемого на некоторой поверхности, X-сервер должен получить растровое изображение, которое находится под ограничивающим прямоугольником этого глифа, от клиента, который желает визуализировать этот глиф. (Это необходимо для правильной работы алгоритма сглаживания, так как он принимает во внимание контекст, в котором глиф отображается.)

Следовательно, с современными инструментами графического интерфейса, объем трафика между X-сервером и его клиентами составляет огромный: вы можете увидеть это, включив TCP на своем локальном X-сервере (в наши дни они обычно запускаются с помощью -nolisten tcp ) и заставьте некоторый клиент X на основе GTK или Qt взаимодействовать с сервер через TCP:

$ DISPLAY=localhost:x11 /usr/bin/that/x-app

(см. grep x11 для стандартных портов X-сервера). Вы сразу заметите, насколько медленно ведет себя этот клиент, даже если X-трафик не покидает локальный хост: это просто потому, что обычно X-трафик переносится через сокет Unix-домена, который в основном просто копирует байты между буферами в памяти, таким образом имея довольно низкий накладные расходы, и теперь он проходит через весь стек TCP / IP со всеми его очередями и сложной логикой. Теперь подумайте, что происходит, когда этот трафик отправляется в вашем случае - заключенный в три уровня протоколов передачи данных: SSH-туннель, переносимый VPN-туннелем, переносимый TCP / IP по проводам.

Что касается того, что с этим делать, я Я не уверен.

Поскольку mosh не используется , я бы попробовал поиграть с опцией IPQoS клиента OpenSSH.

Другой подход состоит в том, чтобы атаковать проблему с другой стороны: попробуйте доступ к вашему приложению на основе VNC. Здесь варианты меняются:

  • Вы можете начать просто с экспорта всего дисплея через x11nvc или что-то вроде этого.
  • Используйте программные пакеты, которые могут «экспортировать» конкретное приложение или окно - Xpra и winswitch .
  • Попробуйте более тяжелое, но полное решение, такое как X2Go .
4
ответ дан 3 December 2019 в 03:28

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

$ echo "$TIMEFORMAT"
        %R
$ time meld --version
meld 3.20.0
        25.293

Это - то же самое время как другое медленное применение, которое я нашел (Немо, gedit).

комбинация Осмотра с strace, кажется, что это ожидает некоторого события, которое никогда не прибывает и существует на тайм-ауте, который имеет точно 25.

вероятно, что эта проблема совпадает с тем, о котором сообщили здесь: https://bbs.archlinux.org/viewtopic.php? id=230036

Это - dbus проблема - вид среды сессии, которая не установлена по ssh. К сожалению, я не знаю, как зафиксировать это.

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

Редактирование

Найденный им! Запустите dbus просто и экспортируйте переменные, о которых сообщают:

$ dbus-launch 
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-2EzslkNeji,guid=c9dec1622d6575f468559f8b5d9ee0e0
DBUS_SESSION_BUS_PID=4745

вышеупомянутое Набора и экспорт, затем:

$ time meld --version
meld 3.20.0
        0.268

я помещу это в свой сценарий запуска на удаленном и сообщу здесь.

Продолжение

Это является довольно подробным и в основном из объема, но как мне действительно нравится легкий к попытке скопировать/вставить решения в сообщениях, которые я вижу, я могу за исключением того, что Вы также делаете. Я протестировал следующее как сценарий сессии для питания ssh с (например, ssh-X my@dark-side ~/bin/session):

#!/bin/bash

LAUNCH=(
    #   xload
    #   thunderbird
      dbus
      konsole
)

Tmp=$(mktemp -d)
mkdir -p $Tmp

KILLS=()
WAITS=()

echo "info: starting session" >&2

app_dbus() { # # Launch dbus and remember to kill
  # redirect error because of "create ~/.dbus/session-bus/" 
  # deal with failure by checking DBUS_SESSION_BUS_PID afterwards
  dbus-launch > $Tmp/dbus.sh 2>/dev/null
  . $Tmp/dbus.sh

  if [ "$DBUS_SESSION_BUS_PID" ] && 
       ps --no-header -o pid -p "$DBUS_SESSION_BUS_PID" \
          > /dev/null 2>&1
  then
    export DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_PID
    KILLS+=( $DBUS_SESSION_BUS_PID )
  else
    echo "warning: failed dbus" >&2
  fi
}
app_konsole() { # # Launch konsole and remember to wait for
  konsole &
  WAITS+=( $! )
}

for APP in "${LAUNCH[@]}"
do
  app_$APP
done

rm -r $Tmp  # not needed anymore

wait "${WAITS[@]}"

echo "info: ending session" >&2

for ID in "${KILLS[@]}"
do
  kill $ID
done
0
ответ дан 3 December 2019 в 03:28

Теги

Похожие вопросы