Мне нужно предоставить некоторую настройку конфигурации для нескольких серверов в нашей небольшой сети отдела. В настоящее время мы используем RHEL5, и поскольку я не хочу повторять работу, я хотел бы создать RPM с этой конфигурацией и загрузить их в наш RHN.
Теперь проблема: предположим, я хочу распространить конфигурацию NTP через /etc/ntp.conf
. К сожалению, нет места, куда /etc/ntp.d/
можно поместить мои файлы, поэтому мне придется перезаписать ntp.conf
своим RPM. Как мне сделать это правильно, т. е. не теряя эту конфигурацию при ntp
обновлении, а также без возможных конфликтов файлов конфигурации?
решение1
Воспользуйтесь решением Дэвида и используйте вместо него марионетку. Серьёзно.
Однако, если вы полны решимости, то можете создать пакет rassie-ntp-conf, содержащий "/etc/ntp.conf.rassie". В файле спецификации вам понадобится , который %post
копирует вашу конфигурацию поверх конфигурации по умолчанию, а также " %triggerin -- ntp-server
", который делает то же самое. Таким образом, если последующее обновление перезапишет конфигурацию, триггер скопирует ее обратно. Может быть, добавить что-то в /etc/cron.daily, чтобы сделать то же самое, чтобы быть действительно уверенным... Вероятно, нужно, чтобы все эти скрипты service ntpd condrestart
также делали после cp.
Это основы. Если вы хотите сделать это для большего количества пакетов, вы можете вместо этого создать стандартный скрипт, который проходит через /etc/rassie/, чтобы найти конфигурации для копирования в /etc, и заставить %post и %triggerin запустить его вместо этого.
Но, на самом деле, игнорируйте это и используйте puppet или Chef или cfengine... Такая схема "выталкивания конфигурации через RPM" чревата тонкими проблемами, вытекающими из фундаментальной проблемы, что RPM не предназначен для того, чтобы два разных пакета сражались за один файл. Трудно тестировать, трудно отлаживать, именно то умное решение, которое заставит вас позже пожалеть, что вы изначально не использовали puppet.
решение2
Могу ли я предложить альтернативное решение? Вы можете обнаружить, что инструмент управления конфигурацией, такой как Puppet или Cfengine2, делает то, что вам нужно. Вы пишете файлы манифеста, которые описывают, как вы хотите, чтобы выглядела система, и он уходит и изменяет систему так, что она выглядит так. Обратите внимание на важное различие: вы описываете, как должна выглядеть система, а не как вы ее меняете. Примером для ntp может быть:
class ntp {
package {"ntpd":
ensure => latest,
}
file { "/etc/ntp/ntp.conf":
source => "puppet:///ntp/ntp.conf",
owner => "root",
group => "root",
mode => 644,
require => Package["ntpd"],
}
service { "ntpd":
ensure => running,
enable => true,
subscribe => File["/etc/ntp/ntp.conf"],
}
}
Когда вы включаете этот класс в определенный узел, вы устанавливаете пакет ntpd, копируете свой файл на сервер и убеждаетесь, что демон запущен. Если puppet вносит какие-либо изменения в ntp.conf, он перезапустит демон ntp (благодаря строке subscribe).
Как это решает ваши проблемы? Ну, когда устанавливается новая версия ntp, если пакет перезаписывает файл конфигурации, puppet скопирует старый обратно. Если есть какие-либо различия, он отобразит разницу по мере ее изменения, так что вы сможете увидеть, какие изменения были сделаны, так что вы сможете заметить любые различия и обновить свою центральную версию, если вы хотите эти изменения.
решение3
Независимо от того, как вы решите вносить изменения, если вам нужно изменить ntp.conf (или любой другой файл конфигурации) и вы не хотите полностью заменять файл, взгляните на Augeas (http://augeas.net). Требуется немного времени на обучение, но это значительно упрощает анализ/редактирование файлов.
решение4
Я пытался справиться, используя только rpms. Это возможно только тогда, когда ваши файлы конфигурации очень просты.
Лучший подход, хотя его и не так просто реализовать, — это использовать такие инструменты, как puppet и cfengine, как все и предлагали.