Про screen
Feb. 14th, 2020 05:13 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
На старости лет, наконец, научился запускать screen в detached mode
В смысле чтобы он сразу в бэкграунд уходил а потом можно было подцепиться и посмотреть что он там делает.
Осталось собраться и прикрутить это к какому-нибудь стартап-скрипту.
Теперь бы еще ключиком -x выучиться пользоваться.
И поигтаться с
(потому что -D и -d это разные вещи, равно как -r, -R и -RR).
Вот бродит у меня мысль что кнопка открытия окна терминала по умолчанию должна запускать не просто shell, а
Это правда не спасет от того, что по завершению сеанса LXDE накроется агент.
В смысле чтобы он сразу в бэкграунд уходил а потом можно было подцепиться и посмотреть что он там делает.
screen -d -m команда
Осталось собраться и прикрутить это к какому-нибудь стартап-скрипту.
Теперь бы еще ключиком -x выучиться пользоваться.
И поигтаться с
ssh-agent screen -D -m команда
(потому что -D и -d это разные вещи, равно как -r, -R и -RR).
Вот бродит у меня мысль что кнопка открытия окна терминала по умолчанию должна запускать не просто shell, а
screen -x -p +
Это правда не спасет от того, что по завершению сеанса LXDE накроется агент.
no subject
Date: 2020-02-14 03:54 pm (UTC)no subject
Date: 2020-02-14 05:42 pm (UTC)no subject
Date: 2020-02-14 07:34 pm (UTC)no subject
Date: 2020-02-15 06:24 am (UTC)no subject
Date: 2020-02-15 04:50 pm (UTC)no subject
Date: 2020-02-15 04:55 pm (UTC)Еще, конечно, могут из /etc/Xsession.
no subject
Date: 2020-02-15 06:30 pm (UTC)no subject
Date: 2020-02-14 03:59 pm (UTC)Поэтому когда я занялся этой задачей (Linux Deploy, ходим через VX Connectbot, и оно отваливается при каждой смене внешней сети, хотя ходит на localhost), пришлось писать в ~/bin подмену для ssh, scp, git, git-is-clean и собственно screen.
У screen перед запуском настоящего запускается нечто, что прикапывает переменные агента (а заодно и DISPLAY), а у остальных запускается вот это вот прикопанное.
no subject
Date: 2020-02-14 05:41 pm (UTC)А если запускать его с -D -m, то такая фигня не получится. Получится другая.
no subject
Date: 2020-02-14 07:41 pm (UTC)Что будет, если запускать с -m, это более внимательно смотреть надо.
no subject
Date: 2020-02-15 06:30 am (UTC)no subject
Date: 2020-02-15 07:25 am (UTC)В результате без ручного запуска агента никакие гиты не работают.
termux, благо, не отваливается после перехода в другую сеть.
no subject
Date: 2020-02-15 07:34 am (UTC)Это решение имеет свои недостатки. Но по-моему, недостатки почти неизбежные при использовании screen - т.е. получается что сессия (к которой принадлдежит агент) долгоживущая и мы к ней периодически из разных мест подключаемся. Что, собственно, концепции screen соответствует, но требует переосмыслить security ключей. Опять же для каждой машины, где мы запускаем такую долгоживущую сессию, требуются, вероятно, свои ключи. не совпадающие с теми, которыми мы авторизовались при доступе к этой машине.
Еще кстати, оцени разницу между -D -RR и -x -p +. Второй вариант интересен для запуска окна терминал-эмулятора в графичческой среде. Но может и не только для него. Получается что при запуске мы создаем новое окно с новой сессей shell, но в рамках старого screen,
При моей сложившейся практике это удобный вариант.
no subject
Date: 2020-02-15 10:03 am (UTC)Так. Поскольку оно не форкается, то агент не завершает работу, пока ее не завершил screen. Но... это не бэкграунд, поскольку он не завершается. То есть недостаток в том, что нельзя выходить из той сессии, где оно запущено. Когда это автоматизированная система, которая запускает что-то долгоиграющее, и ты можешь подцепиться и посмотреть, во что оно там играет. Но запуск из интерактивной сессии чреват боком. Как минимум, сверху нужен nohup. Ну и да, прежде чем оно сможет воспользоваться агентом, надо ключи ему отдать. Внутри запущенной команды. И если они парольные, то сначала подцепиться и сказать пароль.
> разницу между -D -RR и -x -p +
Не запутаться бы... Я на локальной машине обычно не запускаю screen, потому что часто запускаю его на удаленной при заходе на нее по ssh с локальной. А два слоя screen изрядно неудобны в плане управления.
Иногда так приходилось делать с планшета (где вышеупомянутые Linux Deploy и VX Connectbot, и screen локально). Оттуда удобно заходить на сервер, но при запуске screen на сервере получается как раз два слоя. Заманаешься соображать, сколько раз надо нажать a после Ctrl-a, чтобы получить нужный эффект. А главное, чтобы не получить ненужного.
no subject
Date: 2020-02-15 11:24 am (UTC)Как правило
(command </dev/null >/dev/null 2>&1 &)& мне хватает. И никаокй systemd не пытается истребить эту команду при завершении сессии.
Более того, если в xterminal сказатьCtrl-Z bg а потом его закрыть или сделать из него exit, как правило команда остается в бэкграунде.
В этом месте в соверменных линуксах бардак. И Поттеринг его исправить не сумел, хотя пытался.
Вот насчтет того чтобы отдать ключит долгоживущей сессии - это действительно надо думать. На тему того, как и сколько там должны жить ключи.
Возможно, самым правильным способом будет похакать screen, встроив agent-forwarding непосредственно в него.
То есть чтобы запущенные программы видели SSH_AUTH_SOCK, которым управляет сам screen.
А screen-который запускается из сессии, имеющей своего агента, передает ему запросы которые от выполняющихся внутри скрина программ получает мастер-процесс screen,
А насчет того сколько раз нужно нажать 'a' я буду эту проблему иметь в виду при дальнейших экспериментах.
no subject
Date: 2020-02-16 09:39 am (UTC)no subject
Date: 2020-02-16 09:54 am (UTC)no subject
Date: 2020-02-16 10:12 am (UTC)Необходимость на каждом хопе добавлять в стек ещё один мультиплексор мне представляется сомнительной. Один мультиплексор на локальной стороне, 0..1 на удалённой (в случае, если ожидается длительная работа с удалённой стороной), а на станциях пересадок достаточно голого шелла.
Разве что мы, сидя локально на A, работали на удалённой машине B, и тут внезапно обнаружилось, что надо сходить ещё на C и по странному совпадению связь до C есть только через B?
no subject
Date: 2020-02-16 10:19 am (UTC)no subject
Date: 2020-02-16 10:44 am (UTC)no subject
Date: 2020-02-16 10:06 am (UTC)no subject
Date: 2020-02-16 10:13 am (UTC)no subject
Date: 2020-02-16 03:55 pm (UTC)no subject
Date: 2020-02-16 04:30 pm (UTC)no subject
Date: 2020-02-16 07:28 pm (UTC)Я даже ее думал (поменять escape char на планшете, той системе, с которой могло регулярно требоваться ssh screen из-под screen), но отказался, потому что в VX Connectbot удобно было переключать окна нажатием на громкость, прямо-таки на порядок удобнее, чем с клавиатуры, если мы про экранную. Его можно настроить, чтобы он при этом выдавал C-a SPACE. Но, заразу, нельзя настроить, чтобы он выдавал там не C-a, а что-то иное. А переключаться надо часто.
no subject
Date: 2020-02-16 11:51 am (UTC)https://superuser.com/questions/180148/how-do-you-get-screen-to-automatically-connect-to-the-current-ssh-agent-when-re/424588#424588
no subject
Date: 2020-02-16 12:01 pm (UTC)no subject
Date: 2020-02-16 12:08 pm (UTC)Я её обошёл, добавив PID в имя создаваемого файла, но я не уверен, что из этого не следует никаких security implications.
no subject
Date: 2020-02-16 04:21 pm (UTC)В начале ты убиваешь все симлинки других процессов. Не глядя, завершились они или нет, и им эти симлинки еще нужны. В частности, ты можешь убить и ту симлинку, которая у тебя самого в SSH_AUTH_SOCK, если это не .profile, а .bashrc.
А оригинальная идея хороша, ее надо повнимательнее подумать.
no subject
Date: 2020-02-16 04:41 pm (UTC)no subject
Date: 2020-02-16 07:43 pm (UTC)А, присмотрелся. Ты убиваешь (кстати, зря у тебя там -r у rm) только висячие симлинки. Те, которые указывали на уже сдохший сокет.
Тогда да, жизнеспособно.
no subject
Date: 2020-02-16 07:47 pm (UTC)no subject
Date: 2020-02-16 07:56 pm (UTC)Ты, похоже, потерял оригинальное решение.
Тестовый пример.
Заходим по ssh с ForwardAgent на хост A. Там это выполняем, запускаем screen. Детачимся, выходим. Сокет сдох.
Заходим туда снова по ssh. В свежезапущенном шелле всё хорошо, но мы... аттачимся к скрину. И попадаем в первый шелл. Чей симлинк давно указывал в никуда, а при запуске второго шелла был удален. Пытаемся из него зайти по ssh на хост B с помощью агента. Упс...
В оригинальном решении, когда у всех таких шеллов текст SSH_AUTH_SOCK один, симлинк будет просто указывать на новый сокет, и старый шелл сможет воспользоваться новым агентом. Ради чего и делалось. А то, что делаешь ты, вообще не видно, чтобы имело какое-то преимущество перед штатной работой ssh.
no subject
Date: 2020-02-16 08:00 pm (UTC)no subject
Date: 2020-02-17 01:15 pm (UTC)no subject
Date: 2020-02-17 04:49 pm (UTC)no subject
Date: 2020-02-17 05:13 pm (UTC)no subject
Date: 2020-02-20 01:08 pm (UTC)Артефакт, собственно, и был в том, что симлинк переписывают с другого хоста.
Ты вот хорошо умеешь искать по всяким stackexchange etc, но зачем-то забываешь, что найденное там стоит либо поднапрячься и понять, либо не использовать. Даже если кажется, что оно работает :-)
no subject
Date: 2020-02-20 02:09 pm (UTC)no subject
Date: 2020-02-16 08:02 pm (UTC)no subject
Date: 2020-02-16 09:31 pm (UTC)no subject
Date: 2020-02-14 06:16 pm (UTC)и вперед.
Соответственно для запуска чего-то отдельного (чтобы потом посмотреть) ^a^c, ну а когда надо на нужный экран переключился и вперед.
no subject
Date: 2020-02-15 06:28 am (UTC)Поэтому хочется, чтобы запущенный на удаленной машине долгоживущий процесс по умолчанию (без явных действий с моей стороны) оказался бы в screen.
Но, как правило, если ты работаешь на удаленной машине, то тебе постоянно нужен еще десяток удаленных машин, куда надо ходить по ssh по ключам. А ключи - на локальной машине.
И бесшовно скрестить логику screen и логику ssh-agent - не так просто. Вон