У нас есть два веб-сервера CentOS 5.3 с балансировкой нагрузки, которые обрабатывают приличное количество (~ 20) индивидуальных торговых сайтов. Конечным результатом является то, что у нас должен быть отдельный защищенный сайт для каждого продукта, что приводит к большому количеству сетевых псевдонимов, по одному для каждого IP-адреса, чтобы SSL работал.
Очевидно, что управлять этим вручную было бы неинтересно, особенно когда серверы умирают, и вам нужно перестраивать, и вы хотите обеспечить согласованность.
Однако ИТ-менеджеру неудобно использовать инструменты интерфейса командной строки для управления определенными вещами, и он непреклонен в использовании инструмента с графическим интерфейсом, например system-config-network доступен на случай, если он захочет что-то изменить.
Сценарии, которые я написал для управления конфигурациями машины, пытались учесть это, и для большей части конфигурации сети я использую system-config-network-cmd -e > netconfig чтобы сбросить конфигурацию, внести изменения, а затем system-config-network-cmd -i -c -f netconfig чтобы импортировать изменения обратно.
Проблема, которую я обнаружил, заключается в том, что разные версии s-c-n-cmd действуют по-разному, и часто то, что импортируется, не сохраняется на самом деле. Даже просто делая system-config-network-cmd -e > netconfig за которым сразу следует system-config-network -i -c -f netconfig без внесения каких-либо изменений приводит к другой конфигурации (запуск system-config-network-cmd -e > netconfig2 и делать diff netconfig netconfig2 показывает различия).
Будут ли устранены проблемы с s-c-n-cmd, кто-нибудь еще занимался этой проблемой? Я пробовал изменить /etc/sysconfig/networking/* напрямую, но и это не всегда работало правильно.
Есть ли какой-нибудь правильный путь (TM), который гарантирует, что инструменты RH GUI и / etc / sysconfig / network-scripts могут жить в гармонии, оставаясь при этом дружественными к скриптам?
Я смотрю на то, чтобы со временем перейти на марионетку, но он находится далеко внизу в длинном списке других проектов, которые необходимо выполнить, поэтому я надеюсь на что-то, что будет поддерживать нас до тех пор.
Вопрос: почему ИТ управляющий делами хотите поменять конфигурацию сети, когда ему не комфортно даже с оболочкой? Я бы посоветовал ему держаться подальше от производственных серверов, если он ожидает, что я буду делать свою работу правильно. Он делает свою работу (платит мне), я делаю свою (рабочие сервера).
В любом случае, может быть, вам поможет команда «setup». А как насчет того, чтобы сделать / etc / sysconfig / network-scripts репозиторием svn или git. По крайней мере, вы можете вернуться к предыдущей версии. Я сам не сталкивался с такой проблемой, как ваша, потому что я обычно использую сценарий конфигурации сети во время развертывания и оставляю все как есть. Однако то, что вы описываете, звучит как ошибка, поэтому вы можете отправить отчет об ошибке о непоследовательном поведении этого инструмента.
Кстати, настроить марионетку для такой тривиальной задачи, как эта, не так уж и сложно, так что это может стать хорошим решением.