Комментарии 70
На одном из серверов у меня установлен вот такой забавный баннер и $PS1 показывает, где и под каким пользователем я нахожусь: ascii.io/a/1166. Но на других серверах также сделать всё руки не доходят.
Мы тоже «раскрашиваем» сервера (вот так habrahabr.ru/post/107038/), но и это помогает не всегда :)
Не поделитесь рецептиком случайно? Спасибо заранее. :)
gist.github.com/3742409
Собственно, .bashrc давно где-то подсмотрел, немного адаптировав под свои нужды, баннер сделал через figlet :)
Собственно, .bashrc давно где-то подсмотрел, немного адаптировав под свои нужды, баннер сделал через figlet :)
sudo su? sudo -i
0. Помнить законы Мерфи. Всё, что может упасть, непременно упадет. Обязательно исходить из худшего при планировании работ.
8. Заранее согласовать maintenance window и убедиться, что отключение сервера не вызовет катастрофы у коллег. Возможно, имеет смысл заранее остановить другие системы, которым может поплохеть от внезапного исчезновения пациента из сети.
9. Постараться организовать инфраструктуру так, чтобы отключение одного сервера не вызывало отказа всего сервиса.
10. Если п.9 выполнен, то перед любыми мало-мальски опасными действиями следует штатно вывести сервер из экспуатации. Это легко реализовать так, чтобы ни один пользователь и ни одна сторонняя система этого не заметили. А потом пусть он хоть сутки лежит — в худшем случае снижаются производительность сервиса и степень резервированности.
8. Заранее согласовать maintenance window и убедиться, что отключение сервера не вызовет катастрофы у коллег. Возможно, имеет смысл заранее остановить другие системы, которым может поплохеть от внезапного исчезновения пациента из сети.
9. Постараться организовать инфраструктуру так, чтобы отключение одного сервера не вызывало отказа всего сервиса.
10. Если п.9 выполнен, то перед любыми мало-мальски опасными действиями следует штатно вывести сервер из экспуатации. Это легко реализовать так, чтобы ни один пользователь и ни одна сторонняя система этого не заметили. А потом пусть он хоть сутки лежит — в худшем случае снижаются производительность сервиса и степень резервированности.
А почему именно физических?
Моё мнение, что это в полной мере относится и к виртуальным машинам, в общем, разве что исключая некоторые ньюансы.
Моё мнение, что это в полной мере относится и к виртуальным машинам, в общем, разве что исключая некоторые ньюансы.
Вы правы. Первоначально в заголовке было и про виртуалки. В процессе редактирования подсократил.
Но с виртуалками чуть проще — часто к ним есть прямой «терминальный» доступ.
Но с виртуалками чуть проще — часто к ним есть прямой «терминальный» доступ.
Там кстати хватает ньюансов, например хост-машина, обращающаяся за авторизацией пользователя на виртуалку — DC, которая живёт на ней, которая внезапно умерла — проходили, мозги админу промывали…
Вообще еще вот сильно хорошо и правильно это документирование — L1,L2,L3, L>4…
Что, где, почём, как настраивалось…
Вообще еще вот сильно хорошо и правильно это документирование — L1,L2,L3, L>4…
Что, где, почём, как настраивалось…
0) Работать в screen.
1) Если вносятся изменения в ssh-server, то заранее поднять ssh-server на альтернативном порту. При разрыве соединения поможет вести себя адекватно :)
1) Если вносятся изменения в ssh-server, то заранее поднять ssh-server на альтернативном порту. При разрыве соединения поможет вести себя адекватно :)
Сочуствую вашей работе, ей богу)
У меня так:
1. сделай в тестинге
2. сделай на паре машин продакшна.
3. сделай на первой половине кластера
4. сделай на оставшемся кластере.
У меня так:
1. сделай в тестинге
2. сделай на паре машин продакшна.
3. сделай на первой половине кластера
4. сделай на оставшемся кластере.
Раскрашено приветствие сервера в .bashrc. Помогает в частности то, что хостнэйм у машин разный, и он ярко выделен.
Правило 0: сделай снимок виртуальной машины.
0. Проведи работы на тестовом сервере и подожди сутки;
7. Веди отдельный лог команд во время проведения работ, чтобы потом судорожно не рыться в history;
8. Работать надо в здравом уме и светлом разуме, а не работать день-вечер и ночью накатвать обновления;
9. Разноси аппаратные, состемные и прикладные обновления как минимум на сутки;
7. Веди отдельный лог команд во время проведения работ, чтобы потом судорожно не рыться в history;
8. Работать надо в здравом уме и светлом разуме, а не работать день-вечер и ночью накатвать обновления;
9. Разноси аппаратные, состемные и прикладные обновления как минимум на сутки;
Не выполняй несколько критичных, требующих внимательности работ параллельно. Закончил с одной — приступай к другой.
Добавлю еще — если не выспался или там отвлекают — лучше вообще сделать logout на сервере. Пару раз в конце дня, сонный и с задуренной головой, едва-едва не выключил удаленный сервер. В принципе у меня в каждом сервере стоит своя kvm, но все равно минут 5-10 простоя критичны, и обидны, когда сделаны из-за глупости. После этого кстати и стал я раскрашивать hostname у серверов — во первых, яркий цвет сразу в глаза бросается, во-вторых при выводе больших сообщений на экран четко видна разница к примеру между двумя выводами сообщений.
От себя еще добавлю пару моментов. К сожалению, screen-ом я не пользуюсь по ряду причин, но пользуюсь tmux, он тоже умеет функции screen. По вечерам и в пятницу никаких обновлений, мне дороги выходные. То есть обновления лучше накатить в районе полуночи, чтобы чуть что — была ночь времени. Обязательно бэкап всех конфигов и прочих важных файлов.
От себя еще добавлю пару моментов. К сожалению, screen-ом я не пользуюсь по ряду причин, но пользуюсь tmux, он тоже умеет функции screen. По вечерам и в пятницу никаких обновлений, мне дороги выходные. То есть обновления лучше накатить в районе полуночи, чтобы чуть что — была ночь времени. Обязательно бэкап всех конфигов и прочих важных файлов.
x. Сложи все сервисы на этом сервере за несколько десятков минут до начала работ. В случае, если окажется, что этот сервер нес что-то критическое, о чем забыли — ты сможешь мгновенно это что-то запустить и отложить maintenance.
А потом объясняйся перед руководством, службой мониторинга, финансами, почему начал работы невовремя и все занервничали…
не всегда. клгда-то у знакомого тоже отвалился сервер, а на нём оказалась достаточно критичная забытая до полной автоматизации штука, нужная раз в день… ночью она, понятное дело не отработала…
У нас еще есть сервер, на котором поднята загрузка по сети. В случае факапа, пострадавший сервер пускается в перезагрузку, загружается по сети, на него можно зайти по ssh, примонтировать разделы и откатить изменения.
НЛО прилетело и опубликовало эту надпись здесь
Ещё есть кошмарный прикол на эту тему. Большие мониторы, переключение активного окна курсором мыши (а не кликом). Периодически такое переключение залипает. В итоге админы тащат мышь, тянут её в консоль и пишут reboot. А потом радостно наблюдают сообщение вида system will be rebooted now в соседней консоли)
Себя в этом месте полечил двумя моментами:
1) ноут никогда не выключать, а усыплять.
2) если нужен ребут локальной машине (ноуту) — делать из ctrl-alt-f1 или по кнопке.
Себя в этом месте полечил двумя моментами:
1) ноут никогда не выключать, а усыплять.
2) если нужен ребут локальной машине (ноуту) — делать из ctrl-alt-f1 или по кнопке.
Как завещал великий Админ — «Бэкап, бэкап и еще раз бэкап».
1) У меня в планах написать программу, которая сканирует сеть nmap'ом и запоминает открытые порты, с тем чтобы после изменений/перезагрузок проверить не потерялось ли что-то (актуально при перезагрузки сервера виртуализации с кучей виртуалок).
2) Наверно стоит netstat перед изменением запускать и сравнивать после изменений — это всё к тому, что некоторые сервисы имеют тенденцию быть запущены вручную год назад, про них все забыли, и в автозагрузку не включили.
3) перед изменениями стоит сделать перезагрузку без внесения каких либо изменений, чтобы убедиться что сервер вообще рабочий. Некоторые ошибки незаметны во время работы, но проявляются при загрузке — например такое бывает у grub при переходе от 1 к 2-й версии, или в некоторых дистрибутивах-сборках типа turnkey, при смене ядра.
4) посмотреть что в логах пишется, отфильтровав сообщения мусорящих сервисов типо cron, postfix
5) убедиться что на сервере достаточно свободного места
6) посмотреть насчёт работающих сессий screen
2) Наверно стоит netstat перед изменением запускать и сравнивать после изменений — это всё к тому, что некоторые сервисы имеют тенденцию быть запущены вручную год назад, про них все забыли, и в автозагрузку не включили.
3) перед изменениями стоит сделать перезагрузку без внесения каких либо изменений, чтобы убедиться что сервер вообще рабочий. Некоторые ошибки незаметны во время работы, но проявляются при загрузке — например такое бывает у grub при переходе от 1 к 2-й версии, или в некоторых дистрибутивах-сборках типа turnkey, при смене ядра.
4) посмотреть что в логах пишется, отфильтровав сообщения мусорящих сервисов типо cron, postfix
5) убедиться что на сервере достаточно свободного места
6) посмотреть насчёт работающих сессий screen
Не правило, но примета: настраиваешь firewall на удаленном сервере — к дороге.
Как выше верно подметили, cron с откатом конфига может спасти от дальней дороги :)
Во FreeBSD есть скрипт /usr/share/examples/ipfw/change_rules.sh который помогает избежать данной ситуации, там если отвалился shell, то происходит возврат правил обратно.
Для iptables возможно тоже есть подобное, если кто знает — подскажите, пожалуйста.
Для iptables возможно тоже есть подобное, если кто знает — подскажите, пожалуйста.
выше уже несколько раз писали про крон
пишем скрипт с дефолтными правилами + обязательно с открытым портом ссх
прописываем скрипт в крон, начинаем работать с фаером
закончили работать, проверили, убрали скрипт
еще главное не забыть убрать)
лет 10 назад ночью наступил на эту «мину», благо правила применял в живую, а не писал в конфиг
попросил сотрудников ткнуть ресет сервера по приходу в офис:)
пишем скрипт с дефолтными правилами + обязательно с открытым портом ссх
прописываем скрипт в крон, начинаем работать с фаером
закончили работать, проверили, убрали скрипт
еще главное не забыть убрать)
лет 10 назад ночью наступил на эту «мину», благо правила применял в живую, а не писал в конфиг
попросил сотрудников ткнуть ресет сервера по приходу в офис:)
Прочёл что большинство техногенных катастроф были в понедельник. Люди за субботу, воскресенье настроят планов и с утра понедельника начинают слишком ретиво всё внедрять.
Взял за правило, в понедельник ничего серьёзного не внедряется, только текущие задачи.
К вторнику обычно все затеи критически переосмысливаются.
То есть на критические изменения в понедельник и в пятницу — табу!
Взял за правило, в понедельник ничего серьёзного не внедряется, только текущие задачи.
К вторнику обычно все затеи критически переосмысливаются.
То есть на критические изменения в понедельник и в пятницу — табу!
Понедельник день тяжелый. Наученный горьким опытом я все делаю в выходные. Желательно в субботу с утра, чтобы был запас времени на устранение внезапно случившегося факапа.
Основное правило — забэкапь всё, с чем будешь работать. При работе с базами (наша весит 600гб и ее простой недопустим в принципе) всегда проверяю возможность восстановления из бэкапа. Заранее минимум день-два предупреждаю всех пользователей о недоступности сервиса, чтобы не сорвать какую-нибудь отчетность у бухгалтерии или другого департамента.
Как уже писали, никогда не вношу изменений если буду отсутствовать в офисе на следующий день. Обновления стараюсь ставить только критичные, в этом вопросе руководствуюсь пословицей «не было печали, апдейтов накачали».
Основное правило — забэкапь всё, с чем будешь работать. При работе с базами (наша весит 600гб и ее простой недопустим в принципе) всегда проверяю возможность восстановления из бэкапа. Заранее минимум день-два предупреждаю всех пользователей о недоступности сервиса, чтобы не сорвать какую-нибудь отчетность у бухгалтерии или другого департамента.
Как уже писали, никогда не вношу изменений если буду отсутствовать в офисе на следующий день. Обновления стараюсь ставить только критичные, в этом вопросе руководствуюсь пословицей «не было печали, апдейтов накачали».
ИМХО, в субботу с утра не самый хороший вариант.
1. Если что-то пошло не так, то возможно придётся поднимать/искать других адимнов. В субботу это сделать сложнее, чем в середине недели, так как админы могут уехать на дачу, напиться и что-то подобное.
2. В субботу обычно не полная нагрузка на системы, как в рабочие дни. Тяжело будет понять, всё ли работает как надо с меньшей нагрузкой.
1. Если что-то пошло не так, то возможно придётся поднимать/искать других адимнов. В субботу это сделать сложнее, чем в середине недели, так как админы могут уехать на дачу, напиться и что-то подобное.
2. В субботу обычно не полная нагрузка на системы, как в рабочие дни. Тяжело будет понять, всё ли работает как надо с меньшей нагрузкой.
Не забываем одно из главных правил: не крути две ручки сразу. То есть: сделал одно изменение — проверь последствия. Только потом меняй что-то еще.
НЛО прилетело и опубликовало эту надпись здесь
Некоторые вещи таки делаются исключительно в небизнес тайм и требуют большого промежутка времени — например очень толстые бекапы, когда ресурс должен быть полностью отключен.
Правила правилами, мы их все мастера составлять :) Видно-же, что грабельки-то затоптанные…
Судя по «своим» и своему опыту, кажется мне, что таки толькосафари по долине Серенгети, пешком, голышом, со свежей говяжей вырезкой намертво прилепленной к спине «экскурсия через семь кругов ада» вызванная факапом собственного производства, включает тот самый режим осторожности, спланированности и обдуманности действий, и лишь в этом случае имеют практическую пользу такие вот советы.
Мы вот взяли за практику новичкам стресс-тест устраивать (и весело и полезно, главное потом не спалиться, что факап подстроен, ну и естественно быть в боеготовности все сделать самим если пациент облажается)
Судя по «своим» и своему опыту, кажется мне, что таки только
Мы вот взяли за практику новичкам стресс-тест устраивать (и весело и полезно, главное потом не спалиться, что факап подстроен, ну и естественно быть в боеготовности все сделать самим если пациент облажается)
lvm --snapshot /dev/vg/root -L 50G -n tmp-root
после этого правка конфига grub: default saved, в пункте 0 — savedefault 1, а пункт 1 — это старый, рабочий конфиг со старым, рабочим томом root
после этого, даже в случае проблем с загрузкой сервера с нового переделанного рута, после физического ребута он по-любому будет «как раньше».
Если через неделю, скажем, всё ОК — можно сносить снэпшот.
после этого правка конфига grub: default saved, в пункте 0 — savedefault 1, а пункт 1 — это старый, рабочий конфиг со старым, рабочим томом root
после этого, даже в случае проблем с загрузкой сервера с нового переделанного рута, после физического ребута он по-любому будет «как раньше».
Если через неделю, скажем, всё ОК — можно сносить снэпшот.
Правила безопасности всегда составляются индивидуально. Обжигаются когда их было недостаточно, замедляют время работы когда они избыточны. Поэтому всегда разговор об идеальной схеме работы заканчивается решением руководствоваться только здравым смыслом.
Аппроксимируя мысль в целом можно сказать, что основная идея безопасной схемы — продуманная архитектура. Когда весь сервис будет доступен в полном или ограниченном режиме всегда. И если все таки не будет доступен, то сможет сказать о проблемах сам или с помощью наблюдающих.
Аппроксимируя мысль в целом можно сказать, что основная идея безопасной схемы — продуманная архитектура. Когда весь сервис будет доступен в полном или ограниченном режиме всегда. И если все таки не будет доступен, то сможет сказать о проблемах сам или с помощью наблюдающих.
А что такого плохого, если сервер не поднимется? Ну попросить инженеров перезагрузить, ну в крайнем случае утром в понедельник переустановить. (хорошо, когда облако).
Если кратко, то «время — деньги».
Время человека или время машины?
Время машины деньги, только если есть кто-то, кто готов за это время платить. Так как всегда есть резерв по серверам, то нет никакой разницы, кто из них будет выключенным.
ЗЫ Я ещё раз намекаю, что в хорошей архитектуре выключение сервера не влияет на функциональность системы.
Время машины деньги, только если есть кто-то, кто готов за это время платить. Так как всегда есть резерв по серверам, то нет никакой разницы, кто из них будет выключенным.
ЗЫ Я ещё раз намекаю, что в хорошей архитектуре выключение сервера не влияет на функциональность системы.
В первую очередь нужно прикрыть собственную жопу необходимым количеством служебок. В идеале — получить от руководства приказ на выполнение такого рода работ, в ответ на который написать рапорт с подробным изложением причин «почему это сделать невозможно, но я попытаюсь».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 очевидных правил безопасного системного администрирования физических серверов