Задача: с линуксового сервера (centos 6) одновременно установить ssh соединения с несколькими системами — и писать в файлы (по одному на соединение) все, что прилетит от тех систем, ничего не отправляя. При разрыве соединения переподключаться. На той стороне импортирован открытый ключ, т.е. ручная аутентификация не требуется. Адреса тех, к кому подключаться, можно парсить из текстового файла. Создавать по отдельному скрипту на соединение — не дело.
Очевидное решение: внутри for-цикла вызывать нечто вроде «ssh user@$IP >> log-$IP.txt &». Не работает, вывод запущенного в фоне SSH не улетает в stdout, хотя без амперсента все отлично. "| tee file.txt &" тоже не работает в фоне. Как и любые другие основанные на стандартном клиенте ssh и на stdout решения, которые я сумел нагуглить за несколько часов. Ничего не помогает.
Собственно, вопрос. Каким образом добиться того, чтобы запущенный в фоне ssh клиент (любой, можно не только родной) мог держать соединение с той стороной бесконечно долго (пока та сторона его не отобьет) и при этом логгировать все услышанное в файл?
Победил.
Запуск в фоне sh, bash и прочих скриптов не работает. За исключением expect. Вызов вот этого скрипта с пайпом и амперсентом корректно пишет увиденное в файл:
#!/usr/bin/expect -f
set timeout -1
set user [lrange $argv 0 0]
set ipaddr [lrange $argv 1 1]
while { true } {
spawn ssh $user@$ipaddr
expect "impossiblesequence"
sleep 10
}
Тоже проверял. sh -c 'ssh user@example.org' & > /path/to/output — файл создается, но не наполняется. sh -c 'ssh user@example.org' > /path/to/output — файл создается и наполняется. Но в фоне не работает.
И повторюсь — никаких команд слать не нужно. Только слушать. Слать можно, но только если без этого никак.
sh -c 'ssh user@example.org cmd 2>&1' > /path/to/output & — даже без амперсента не работает. sh -c 'ssh «user@example.org cmd 2>&1»' > /path/to/output & — без амперсента работает, с ним нет.
Я и говорю — задача не такая тривиальная, как кажется. Почему-то ssh из бекграунда категорически не хочет слать в srdout. Есть возможность проверить на другой системе? Может, баг какой.
Если хочется ИМЕННО с амперсандом, то вот так:
sh -c 'ssh user@example.org «do-smth» > /path/to/output' &
В таком виде сессия мгновенно закрывается после выполнения «do-smth», а если его не указывать, то сессия закрывается сразу. А мне нужно висеть долго и писать в файл все, что прилетит.
>>Проверил из шелла — каретка не возвращается.
Какой вариант не работает, screen или sh? Проверил оба — сразу уходят в фон, а в лог пишется.
>>А мне нужно висеть долго и писать в файл все, что прилетит.
Что может прилететь, если на той стороне ничего не происходит в текущей сессии? Задача отработала, сессия в каком-то там tty закрылась. Можно, конечно, организовать вечный цикл :) Но, в общем-то, не понятно дальнейшее использование.
Что может прилететь, если на той стороне ничего не происходит в текущей сессии?
Много чего.
Подключение идет к портам терминального сервера, к которому подключены консоли (COM порты) разнообразных железок. Эти железки периодически шлют сообщения в консоль. Надо эти сообщения записывать. В принципе, если руки дойдут, я напишу статью на эту тему — дело важное, а временами и спасительное.
В случае тестовой среды без реального терминального сервера можно просто подключиться к другому линуксу (или даже к 127.0.0.1) и писать в файл все прилетевшие в TTY броадкасты, руками генерируя их. Это полностью воспроизводит ситуацию.
Отметая вопросы: локальные решения на терминальном сервере работать не будут, нужна именно сторонняя система, подключающаяся по ssh и слушающая порты.
Проверил оба — сразу уходят в фон, а в лог пишется.
Учитывая вышесказанное, спрошу — ssh сессия висит ничего не делая и пишет услышанное в файл, или сразу закрывается? Если последнее, то не годится.
>>TTY броадкасты
Вот, это было бы хорошо упомянуть в исходном вопросе. А то возникло недопонимание.
Мои решения были из серии как запустить XXX на YYY машинах параллельно, а потом централизованно собрать логи их работы. У вас же другая задача
В этом свете expect видится компактным и адекватным решением.
Вот, это было бы хорошо упомянуть в исходном вопросе.
На самом деле боевой скрипт будет слушать вовсе не броадкасты.
Я думал, «установить ssh соединения с несколькими системами — и писать в файлы (по одному на соединение) все, что прилетит от тех систем, ничего не отправляя.» — вполне понятно, но да, задача нетривиальная, понять смысл непросто :)
Заодно: мне не очень нравится expect «impossiblesequence». Как-то это не очень красиво. Есть ли более правильный способ сделать так, чтобы к «sleep 10» и на повторную итерацию цикла оно уходило только после завершения «spawn ssh»?
Подключение идет к портам терминального сервера, к которому подключены консоли (COM порты) разнообразных железок. Эти железки периодически шлют сообщения в консоль. Надо эти сообщения записывать.
А не лучше тогда в таком случае при помощи syslogng слать все это на удаленный syslog-сервер?
Откуда слать? Терминальный сервер — цискин роутер. К тому же, их много — на каждом писать TCL скрипты или EEM апплеты, редиректящие сообщения в сислог? Да и я как-то не в курсе, каким образом перехватывать сообщения, приходящие с AUX-образных линий. Да и разделять их, дабы не было каши, непросто.
А на сервере, который как раз собирает логи консолей с терминального сервера, можно сделать с ними что угодно, включая их пересылку на сислог. В принципе, я уже все настроил, и оно работает отлично. Добавление нового устройства на сервере — одна маленькая строчка в конфиге. Учитывая, что всего железок с HWIC-*A или задействованными под соединение с консолью AUX портами сотни, это весьма здорово :)
Скорее всего, я все-таки напишу статью по этому поводу. Или завтра, или на следующих выходных. Все-таки централизованное логирование именно с консолей (не доверяя поднятому на железках сислогу или SNMP) — маст хев.
Нет ничего проще, чем собирать логи с цисок и терминальных серверов.
Логи, отправляемые самой циской средствами «logging x.x.x.x», в общем случае годятся, но иногда их мало. Когда циска падает, она не всегда успевает отправить сообщение об аварии в сислог (но в консоль — всегда), она не всегда создает crashinfo, она не всегда дает внятную информацию о причинах падения в show ver. Я на это напарывался уже дважды, на разных железках, в обоих случаях TAC не смог установить причину аварии, как и воспроизвести ее. Инженер TAC рекомендовал озаботиться этим самым централизованным сбором логов конкретно с консоли — он сам так делал на прошлой работе, и это много раз давало бесценную информацию. Правда, скриптами поделиться не смог, ибо потеряны.
А в logging buffer терминальной железки не включаются логи с линий. А если бы и включались — была бы страшная мешанина.
Я пока не понимаю, что за загадочные «логи с линий». В остальном же, надежность решения с ssh будет ниже, чем с syslog+snmp. Вот эти вот «не всегда» и прочие потери частей логов будут случаться чаще из-за обрывов ssh-сессий, ведь переустановление не мгновенно происходит.
надежность решения с ssh будет ниже, чем с syslog+snmp.
Надежность консоли несравнимо выше надежности syslog/SNMP. Как я уже писал, то, что умирающая железка может не успеть послать в сеть, она точно выплюнет в консоль. Где эти сообщения поймает другая железка. Соединенная с out-of-band management сетью, функционирующей независимо от подключенных к ней консолью устройств. Кроме того, в отличие от сислога, ssh работает поверх TCP. Те несколько секунд, что может отрабатывать реданданси, все отправляемые по сислогу сообщения будут дропаться, а вот ssh будет ждать дольше, и после восстановления сразу все выплюнет на сервер. Это может сильно упростить выявление причин серьезных аварий.
Ну а если сервер сделать не виртуальным, а физическим, и одним портом воткнуть в терминальный сервер — что бы не произошло, ни одно полезное для диагностики сообщение не будет потеряно.
Еще раз, назначение всей схемы — услышать и записать последние слова умирающего, а кроме того собирать лог перезагрузки. Это не заменяет, а дополняет настроенный локально на железках syslog/snmp.
Предлагаю продолжить споры в будущем топике на эту тему. В нем я постараюсь получше разжевать необходимость записи событий с консоли.
Да я по ссылке на предыдущий уже все понял, что ты сторонник самоделкин-way. Вопросов больше не имею, в связи с этим. Разве что один — как часто происходят такие вот ужасные сбои? Может проблему не мониторингом решать надо, если постоянно что-то ломается?
Сислог, кстати, тоже можно по tcp передавать, это так, для справки.
Да я по ссылке на предыдущий уже все понял, что ты сторонник самоделкин-way.
А ты, конечно, сейчас поделишься правильным вариантом…
На самом деле я как раз категорический противник «самоделкин-way» по любым мало-мальски критическим направлениям. Однако, использование роутера с чем-то вроде HWIC-16A является Cisco-approved методом организации подключения к консолям железок. У них даже продается соответственно названный бандл под это дело — CISCO2901-16TS/K9 «2901 w/ HWIC-16A and 2 CAB-HD8-ASYNC Terminal Server Bundle». Любопытная такая самоделка. И кстати, что-то я не видел в продаже ни одного более удобного решения, с аналогичной плотностью — все-таки 64 консоли на юнит, причем железке никто не мешает параллельно заниматься другими делами. Нет, девайсов класса «network serial concentrator» до черта, но выполняют они в точности то же: железка собирает данные с консолей и выплевывает их в сторону сервера, причем вовсе не по syslog…
А еще есть маленькие филиалы, в которых стоят маленькие роутеры вроде 2911 и маленькие свитчи вроде 2960. От роутера до свитча неплохо бы протянуть rollover кабель…
Что до надежности самодельного сборщика логов — от него даже двух девяток никто не требует. Хотя при этом резервировать — как два пальца.
как часто происходят такие вот ужасные сбои?
Где-то в среднем раз в полгода происходит авария одной из сотен железок, полного понимания причин которой нет, т.е. по моим стандартам слишком часто.
А ты правда считаешь, что дополнительная информация — это плохо, даже если она пригодится раз в пару лет?
Сислог, кстати, тоже можно по tcp передавать
Угу. А если в момент генерации сообщения сеть у железки уже отказала — есть ли разница? ;)
Где-то в среднем раз в полгода происходит авария одной из сотен железок, полного понимания причин которой нет
Это не просто «слишком часто», это мля, охренеть как часто. Тут два варианта: либо железо совсем говно и подлежит замене, либо кто-то не соответствует занимаемой должности и также подлежит замене. Либо оба варианта сразу. И чуть более подробный мониторинг тут не поможет.
Ну и одно дело консольная сеть, про нее никто не говорит, что это самоделка, и совсем другое — сабжевая реализация сбора логов. Впрочем, хозяин-барин, чего это я так разволновался.
Тут два варианта: либо железо совсем говно и подлежит замене
Вообще говоря — есть немного. Особенно SUP720-10G в последнее время подводят. Причем как-то раз полученная по RMA замена, успешно пройдя тестирование, в боевом шасси падала раз в несколько минут. Вторая замена (тот же конфиг, тот же иос) — и проблем нет.
кто-то не соответствует занимаемой должности и также подлежит замене
В последнее время думается мне, что занимаемой должности не соответствуют руководители отделов разработки и тестирования в Cisco Systems, не говоря уже о самих разработчиках и тестировщиках. К сожалению, не удается десятилетиями сидеть на одной версии софта, иногда приходится обновляться… Да и с железячниками не все хорошо. Как-то раз полученный по RMA 720-й суп работал куда хуже заменяемой железки, хотя в лабе вел себя идеально, не обкакавшись ни одним трейсбеком и ни разу не упав. Пришлось еще раз менять.
и совсем другое — сабжевая реализация сбора логов.
А что в этом плохого?
Какие есть профиты:
1) Иногда может предоставить информацию, которую невозможно получить иным образом.
2) Лишнее резервирование централизованного сислога и SNMP, т.е. надежность сервиса «сбор логов» повышается в любом случае.
3) Интересно же. Я не прочь на досуге поговнокодить, да и вообще изучить что-то новое.
А также отсутствие коммерческих решений на эту тему, ну и отсутствие угроз безопасности (соединение шифровано, в консоль боевой железки логиниться не надо, доступ используемой для сбора учетки легко ограничивается коротким перечнем железа и нулевой длины списком команд) либо надежности работы серверной или сетевой инфраструктуры со стороны такого скрипта. Нету рисков.
А какие минусы видит г-н архитектор в логировании с консоли по сравнению с отсутствием логирования с консоли? Наверное, очень серьезные, раз ты так разволновался…
Шепну по секрету: по достоверной информации где-то 5-летней давности от бывшего винадмина ЦБ, существенная часть бекапов виндовой инфраструктуры была построена там на батниках. И ничего, ни разу не подводило. А ведь это — бекапы, штука ну очень критическая, а ЦБ не назовешь конторой, обделенной бюджетом…
