Когда я собираюсь изменить сетевую конфигурацию удаленного сервера, я подумал о некоторых механизмах безопасности, чтобы защитить меня от случайной потери контроля над сервером.
Я использую защиту уровня 0 - это перезагрузка системы по расписанию:
# at now+x minutes
> reboot
> ctrl+D
где x - задержка перед перезагрузкой.
Хотя это относительно хорошо работает для очень простых задач, таких как игра с iptables, этот метод имеет как минимум два недостатка:
Вы, ребята, используете какой-нибудь инструмент для второго пункта? Я хотел бы иметь что-нибудь, способное вернуть конфигурацию системы в ранее известное стабильное состояние, если я не могу подключиться к серверу через X минут после перезагрузки.
Спасибо!
Редактировать:
Сервер представляет собой удаленный сервер Linux с дистрибутивом, подобным Debian или RHEL.
У меня есть доступ только к этому конкретному серверу за брандмауэром. Фильтруются все порты, кроме порта 22 (ssh). Так что нет переключателя KVM, iDRAC и т. Д.
Я могу получить местную поддержку по этой машине в случае критического сбоя, но для этого потребуется слишком много времени: добраться туда на машине можно за три часа. И я предпочитаю потратить это время на serverfault или разрабатывать свои собственные инструменты, чтобы избежать этого.
мой настоящий план: разработать какой-нибудь уродливый инструмент на основе mercurial или git и вызвать «hg revert; reboot» в cron. Мне просто интересно, существуют ли уже несколько хорошо проверенных инструментов.
Это случай для внеполосного управления в виде карта ILO или DRAC или удаленный IP KVM? Это вариант в вашем сценарии?
Если не считать альтернативного метода подключения, например, предложенного ewwhite, я думаю, что ваш метод подойдет. Это просто, и вы можете уделить себе столько времени, сколько считаете необходимым.
Примечание. Я не думаю, что вам нужно перезагружать сервер для проверки ваших изменений - вместо этого перезапустите соответствующие службы, если это абсолютно необходимо. Перезагрузка не требуется для «фиксации» изменений - это всего лишь один из вариантов, позволяющий добиться этого.
Я бы добавил, что вам, вероятно, не следует экспериментировать с изменениями непосредственно в производственной системе. Используйте запланированную перезагрузку в качестве меры предосторожности, но только при применении изменений, которые, как вы уверены, будут работать. Отмените запланированную перезагрузку, когда ваши изменения сработали.
Всегда есть самодельное внеполосное управление. Получите вторую систему и подключите ее к серверу через последовательный кабель. Запустите getty на ttyS0 или на любом другом последовательном порту; это позволяет вам войти через последовательный порт. Если вы сделаете вторую систему доступной через Интернет, у вас будет другой путь к серверу, если вы отключитесь от него.
Когда внешнее управление недоступно, я использую свой собственный сценарий, который сильно зависит от сервера и того, что я настроил.
Наиболее частый случай - смена межсетевого экрана удаленного маршрутизатора. Я запускаю экран сеанс, а затем запустите:
./iptables.sh ;echo Rules applied;echo sleeping until flush...;sleep 5 && echo Sleeping 20 more seconds - rules worked if you\'re reading this press ctrl-c to cancel the flush && sleep 20 && ./iptables-flush.sh || echo Flush cancelled
Итак, в iptables.sh есть мои новые правила, а в iptables-flush.sh есть базовый набор правил, которые позволят мне удаленно подключиться, если я ошибаюсь. Я нажимаю ctrl-c, чтобы отменить сброс, что я могу сделать, только если правила меня не отключили.
Так что вам просто понадобится более подробный сценарий. Например, если вы тестируете изменения в своих сетевых интерфейсах, вы должны написать сценарий и поместить его в rc.local. Он будет пытаться проверить связь с несколькими разными хостами, и если какой-либо из них выйдет из строя, он должен скопировать старый файл сетевого интерфейса и перезагрузиться.
Или, возможно, сценарий может проверить журналы ssh - если он не видит, что вы входите в систему через 90 секунд, восстановите файлы конфигурации и перезагрузитесь.
Итак, краткий ответ: увеличивайте свой баш-фу :-)
И придумайте способ заставить работать внешнее управление. Это действительно правильный ответ, которого я всегда хотел бы в качестве отступления. Например, если у вас есть доступ по ssh (надеюсь, не только к машине, на которой вы работаете), можете ли вы использовать переадресацию портов ssh, чтобы обойти брандмауэр?