Gibt es eine Standardmethode, um geänderte Linux-Konfigurationsdateien getrennt und identifizierbar zu halten?

Gibt es eine Standardmethode, um geänderte Linux-Konfigurationsdateien getrennt und identifizierbar zu halten?

NOTIZDies ist eine Kopie einesgeschlossene Frage von Stack Overflowund eine konstruktive Version, wie ich finde, einerähnliche Frage in Server Fault.

Oft muss ich viele Konfigurationsdateien unter bearbeiten /etc, möchte jedoch nicht, dass diese Änderungen beim nächsten Systemupgrade verloren gehen.

Im Moment habe ich alle Konfigurationsdateien sowie einige meiner Wartungsskripte in untergebracht /opt/adminund /etcdie Ziele dort symbolisch verknüpft, aber das scheint nicht richtig zu seinnach den Standards, die ich gesehen habe. Eine andere Möglichkeit, die mir eingefallen ist, ist, diese in unterzubringen /usr/local. Im oben genannten Dokument steht, dass es für den Systemadministrator bestimmt ist, wenn er Software lokal installiert. Das ist das Beste, was ich habe. /usr/localWird jedoch auch beschädigt, wenn Sie neue, nicht verpackte Software installieren.

Gibt es einen Standard/weitgehend befolgte Best Practice, wie diese gepflegt werden können? Da dies keine Diskussionsseite ist, sollten die Antworten eindeutig sein und durch ein oder zwei Artikel untermauert werden.

NOTIZIch habe meine eigene Antwort beigefügt, die ich bisher als die nützlichste empfand. Ich habe dies hier erneut geöffnet, damit es diskutiert werden kann und weitere Antworten eingehen können.

Antwort1

Obwohl es sie nicht voneinander trennt,usw.Keeperverfolgt Änderungen an Konfigurationsdateien sehr gut. Wenn das Repository irgendwo außerhalb der Box aufbewahrt wird, können diese Änderungen problemlos auf einem neuen Computer wiederhergestellt werden.

Antwort2

Sie können hierfür ein Konfigurationsverwaltungstool verwenden. Dies lässt sich gut skalieren, wenn Sie Server mit derselben Rolle hinzufügen.

Es hört sich an, als hätten Sie eine Lösung gefunden, die Ihren Anforderungen entspricht, aber je nach Ihren Anforderungen und Ihrem Budget möchten Sie sich vielleicht auch Chef, Puppet, Ansible, Opsware oder andere Tools für die Konfigurationsverwaltung/Automatisierung/Orchestrierung ansehen.

Antwort3

Aus den Antworten auf die von mir genannten Fragen scheint hervorzugehen, dass es zwei allgemeine Lösungen gibt: entweder symbolische Links verwenden oder eine Liste von Dateien verwalten (siehe die Antworten von ptman und Jim in den verknüpften Fragen). Ich konnte keinen Artikel mit Best Practices finden.

Ich schlage eine Hybridlösung vor: Sie verwalten nur eine einfache Datei (ich nenne sie FILES) mit einer Liste von Konfigurationsdateien. Ein Skript liest FILESund verknüpft echte Konfigurationsdateien in eine duplizierte Dateisystemhierarchie unter einem ausgewählten Verzeichnis (ich nenne das Skript link-config-files.shund das Verzeichnis system-config).

Auf diese Weise verwalten Sie Dateien nur in einer Datei, die einfach zu bearbeiten ist und keine Shell-Magie erfordert. Konfigurationsdateien, die Ihnen wichtig sind, sind system-configdank des symbolischen Links von aus zugänglich. Ein Cron-Job wurde zum Sichern eingerichtet system-config, sodass alle Konfigurationsdateien automatisch gesichert werden. Und ein weiterer Cron-Job wird regelmäßig ausgeführt, link-config-files.shsodass nur noch bearbeitet werden muss, damit eine Datei in der Datei erscheint (oder verschwindet) system-configund gesichert wird FILES.

Ich finde, das ist bisher die beste Lösung. Natürlich bin ich voreingenommen.hier ist mein Skriptund es verknüpft auch ein Backup-Skript.

verwandte Informationen