Gérer la configuration via RPM?

J'ai besoin de personnaliser la configuration de plusieurs servers dans notre petit réseau de services. Nous utilisons actuellement RHEL5 et, puisque je ne veux pas répéter le travail, j'aimerais créer des RPM avec cette configuration et les download dans notre RHN.

Maintenant, le problème: en supposant que je souhaite dissortingbuer la configuration NTP via /etc/ntp.conf . Malheureusement, il n'y a pas /etc/ntp.d/ pour mettre mes files, donc je devrais écraser ntp.conf avec mon RPM. Comment puis-je le faire correctement, c'est-à-dire sans perdre cette configuration lorsque ntp est mis à jour et sans conflit de files de configuration possible?

5 Solutions collect form web for “Gérer la configuration via RPM?”

Allez avec la solution de David à l'aide de marionnettes à la place. Vraiment.

Toutefois, si vous êtes déterminé, ce que vous pouvez faire, c'est créer un package rassie-ntp-conf qui contient "/etc/ntp.conf.rassie". Dans le file de spécifications, vous aurez besoin d'une %post qui copy votre configuration sur la configuration par défaut et aussi un " %sortingggerin -- ntp-server " qui fait la même chose. De cette façon, si une mise à niveau ultérieure écrase la configuration, le triggersur sera copié sur elle. Peut-être déposer quelque chose dans /etc/cron.daily pour faire de même pour être vraiment sûr … Probablement besoin de tous ces scripts faire un service ntpd condrestart après le cp, aussi.

C'est l'essentiel. Si vous voulez le faire pour plus de packages, vous pouvez plutôt créer un script standard qui se déroule à travers / etc / rassie / pour find des configurations à copyr dans / etc et que les% post et% sortingggerin stuff soient exécutés à la place.

Mais, en fait, ignorez cela et utilisez marionnette ou Chef ou cfengine … Ce type de système "pushing configuration out via RPM" est chargé de problèmes subtils découlant du problème fondamental que RPM n'est pas conçu pour que deux packages différents se battent un seul file. Difficile à tester, difficile à débarrasser, exactement le genre de solution intelligente qui vous fera plus tard souhaiter que vous soyez allé avec des marionnettes en premier lieu.

Puis-je proposer une solution alternative? Vous pourriez constater qu'un outil de gestion de la configuration comme Puppet ou Cfengine2 fait ce que vous voulez. Vous écrivez des files de manifeste qui décrivent comment vous souhaitez qu'un système apparaisse et qu'il disparaisse et que vous modifiez le système pour qu'il ressemble à cela. Notez la distinction importante que vous décrivez de la manière dont le système devrait se situer, et non la façon dont vous modifiez le système. Un exemple pour ntp pourrait être:

 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"], } } 

Lorsque vous incluez cette class dans un nœud particulier, vous installez le package ntpd, copyz votre file sur le server et assurez-vous que le démon est en cours d'exécution. Si la marionnette modifie ntp.conf, elle redémarre le démon ntp (grâce à la ligne de souscription).

Comment cela résout-il vos problèmes? Eh bien, lorsqu'une nouvelle version de ntp est installée, si le package écrase le file de configuration, la marionnette copyra l'ancien. S'il y a des différences, il affichera un diff au fur et à mesure qu'il le modifiera, afin que vous puissiez voir les modifications apscopes, afin que vous puissiez remarquer des différences et mettre à jour votre version centrale si vous souhaitez ces modifications.

Indépendamment de la façon dont vous décidez de supprimer les changements, si vous devez modifier ntp.conf (ou tout file de configuration, vraiment) et ne souhaitez pas replace le file en gros, regardez Augeas ( http://augeas.net ). Il y a un peu une courbe d'apprentissage, mais elle supprime beaucoup de la complexité de l'parsing / de l'édition des files.

Je pense que Puppet ou CFEngine est la voie à suivre à long terme. Mais comme première étape, il est plus facile de mettre en œuvre un système de contrôle de version tel que subversion ou git. Vous voudrez garder votre historique de modification des files de configuration même sous Puppet et CFEngine.

J'ai essayé de gérer l'utilisation uniquement de rpms. Ce n'est que lorsque vos files de configuration sont très simples.

La meilleure approche, mais ce n'est pas simple à mettre en œuvre, c'est l'utilisation d'outils comme la marionnette et le cfengine comme tout le monde l'a suggéré.

  • "Yum groupinstall" packages i686 sur x64?
  • Yum ne réinstallera pas PHP sur Amazon Linux
  • Installation de RPM Fedora dans CentOS
  • Plusieurs keys GPG identiques. Qu'est-ce qui peut causer cela?
  • Signatures Bad RPM
  • comment conserver un package rpm pendant la mise à niveau du système?
  • Pouvez-vous m'aider avec mon problème de dépendance du logiciel?
  • Options de configuration de rpm
  • Existe-t-il un moyen de voir si un rpm a été installé manuellement ou installé à partir d'un count de rechange?
  • CentOS 5.11: yum installe, mais les packages restnt manquants
  • Problèmes avec mysql-libs * après * installation de MariaDB
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.