Как сохранить содержимое `CLIPBOARD` из XTerm после его закрытия? (Как, например, Firefox или Leafpad.)

У вас есть выбор. Вот несколько предложений:

  1. Подключитесь от serverB к root @ serverA, используя аутентификацию на основе сертификата, и запустите сценарий в корневом контексте на этом сервере.

    Затем вы можете использовать ту же аутентификацию на основе сертификата, чтобы вернуть полученный файл с помощью scp или rsync . Обратной стороной является то, что ваша учетная запись на serverB тогда имеет полный неограниченный доступ к root @ serverA. однако в строго управляемой среде это может быть приемлемо.

  2. Подключитесь от serverB к root @ serverA, используя аутентификацию на основе сертификата, которая ограничивает соединение запуском одной команды - вашего скрипта.

    Если бы команда выводила свой файл на stdout , его можно было бы захватить непосредственно из сеанса ssh с serverB на root @ serverA без необходимости передавать файл после завершения сценария . Ваша учетная запись на serverB не будет иметь произвольного доступа к root @ serverA.

    Пример необходимой записи для root @ serverA в его файле ~ root / .ssh / authorized_keys для выполнения команды bake может выглядеть примерно так:

     ssh-rsa AAAAB3Nza ... Fr9FvN me @ roaima, command = "/ usr / local / bin / bake", no-agent-forwarding, no-port-forwarding, no-X11-forwarding 
     
  3. Подключитесь с serverB к serverA и используйте sudo для запуска сценария. Вы можете настроить sudo , чтобы разрешить вашей единственной учетной записи запускать сценарий от имени пользователя root, но без запроса пароля.

    Эта запись в / etc / sudoers позволяет пользователю «roaima» запускать указанный сценарий с аргументами или без них от имени пользователя root с помощью такой команды, как sudo / usr / local / bin / bake --fruit = apple, blackberry --type = pie

     roaima ALL = NOPASSWD: / usr / local / bin / bake 
     
  4. Более сложные вещи с триггерами, например, подключение к определенному TCP-порту на serverA и запустив ваш скрипт, запустите его как root.

    Это означает, что любой, у кого есть доступ к этому TCP-порту на serverA, может запустить ваш скрипт, поэтому вам нужно учитывать проблемы DDOS и предотвращать одновременный запуск нескольких экземпляров скрипта.Однако это устранит необходимость иметь какой-либо интерактивный корневой доступ на serverA - даже через sudo .

2
19.06.2018, 00:55
1 ответ

Под X буфера обмена на самом деле нет. Все выборки (первичный, вторичный буфер обмена )копируются, когда два вовлеченных X-клиента общаются друг с другом. (Подробности см., например, в статье Википедии ).

Это означает, что если один X-клиент, удерживающий выбор, больше не работает, выбор пропал.

Что вы можете сделать, так это запустить другой клиент, например. xclipboard, который немедленно копирует выбор из вашегоxterm(или любого другого X-клиента ), как только он будет сделан, и может участвовать в описанной выше связи, даже когда xtermбольше не работает. Конечно, теперь вы должны продолжать xclipboardработать...

Я никогда не замечал, чтобы Firefox делал что-то по-другому, но если выбор действительно доступен после закрытия Firefox, должен быть запущен какой-то другой X-клиент, возможно, что-то, что является частью вашего рабочего стола. Так что да, Firefox должен использовать какой-то внешний инструмент (, но, как я уже сказал, я сам этого не наблюдал. Но тогда я не использую «рабочий стол» в этом смысле, простоfvwm).

3
27.01.2020, 22:09

Теги

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