In Linux werden Einstellungen in Konfigurationsdateien vorgenommen. Ob jetzt händisch oder per GUI spielt dabei keine Rolle. Diese Dateien liegen oft im home, teilweise aber auch in /etc oder ganz woanders. Wenn ich das System neu installiere oder auf ein anderes Derivat wechsle würde ich gerne meine Einstellungen übernehmen. Nur wie gehe ich hier am geschicktesten vor? Eine Möglichkeit wäre, einfach ~ und /etc zu sichern. Allerdings kann ich diese Ordner im neuen System nicht einfach zurückspielen. Ich müsste meinen neuen /etc mit dem Backup diffen um die Stellen zu identifizieren die ich geändert habe. Allerdings ist die Chance sehr groß, dass sich Defaulteinstellungen geändert haben. Auch eine neuere Toolversion kann dazu führen dass sich Konfigdateien unterscheiden. Also muss ich im Prinzip alle Dateien durchsehen und Änderungen jeweils manuell beurteilen und händisch mergen. Das klingt nach viel Arbeit. Geht das auch eleganter? Wie löst ihr sowas? Hintergrund: ich liebe die Paketverwaltung. Ich mach auf einem nackten System ein paar Mausklicks und schon hab ich meine zig Programme, die ich so brauche, wieder installiert und up-to-date. Leider gibt es keine Konfigurationsverwaltung...
Ich ändere in /etc eher nichts, oder nur sehr wenig und das dann grundsätzlich dokumentiert. Über Distributionsgrenzen hinweg ist ein Backup wegen der unterschiedlichen Struktur ohnehin nutzlos. Die für mich wichtigen Konfigurationen liegen alle in /home und sind Anwendungsbezogen. Solange die Programmversionen sich nicht zu sehr unterscheiden, reicht also ein Backup davon. Wenn ein Programm seine alte Konfiguration nicht lesen kann, wird es dich schon darauf hinweisen.
Benji schrieb: > Leider gibt es keine Konfigurationsverwaltung... ähm, doch: ganz einfach: etckeeper professionell: chef, ansible, puppet
Hallo ! Mein Home-Verzeichnis liegt auf einer extra Platte, und das nutze ich schon über mehre verschiedene Distros hinweg - das ist kein Problem. Bei /etc sichere ich bei Bedarf das komplette Verzeichnis und passe dann nur die benötigten Dateien an (smb.conf sei hier als Beispiel genannt). So viele sind das meist nicht. Zugegeben etwas Schwund tritt dabei immer auf... MfG
Hallo! Mein $HOME liegt dort wo der yp-/nis-server es sagt: auf dem NAS. Ich kann mich mit den gleichen credentials an diversen Rechner in diesem yp-/nis-Verbund anmelden, sie fahren unterschiedliche Stände von unterschiedlichen (*nix-oiden) Betriebssysteme, mit unterschiedlichen Versionen von Anwendungen. Habe ich etwas verpasst? Für die jeweiligen /etc gilt das bereits oben genannte.
Kommandozeile vor dem Frühstück für Alle! schrieb: > Habe ich etwas verpasst? ja, es gibt nicht nur einfach Anwender. Samba, Apache, Bin, Proftpd, mysql, Postfix legen kaum Daten unter home ab. Und da kann man nicht mal schnell alles von einer Distri zu nächsten mitnehmen.
Kommandozeile vor dem Frühstück für Alle! schrieb: > yp-/nis-server es sagt: auf dem NAS. Ich > kann mich mit den gleichen credentials Der einzige Schoenheitsfehler ist, dass NIS so unsicher ist, dass man es seit ueber 10 Jahren nicht mehr auf professionalen Server-Installationen antrifft. So was macht man heute mit LDAP ueber sssd in Linux.
Peter II schrieb: > Samba, Apache, Bin, Proftpd, mysql, Postfix legen kaum Daten unter home > ab. Für solche Servergeschichten würde ich wenn ich heute nochmal sowas aufsetzen müsste versuchen alles in separate und eigenständige einfach zu migrierende leichtgewichtige VMs oder Container packen. Da kann dann auch mal die Hardware abrauchen und man zieht die Container einfach um auf die nächstbeste andere Maschine.
Bernd K. schrieb: >> Samba, Apache, Bin, Proftpd, mysql, Postfix legen kaum Daten unter home >> ab. > > Für solche Servergeschichten würde ich wenn ich heute nochmal sowas > aufsetzen müsste versuchen alles in separate und eigenständige einfach > zu migrierende leichtgewichtige VMs oder Container packen. Da kann dann > auch mal die Hardware abrauchen und man zieht die Container einfach um > auf die nächstbeste andere Maschine. naja, dann hast im jeden Container openssl lib die du getrennt updaten musst. Man müsste die Anwendungen nur so bauen, das sie alles in einer Verzeichnis ablegen, dann kann man sich den Overhead von VM komplett sparen wenn man es will.
Peter II schrieb: > naja, dann hast im jeden Container openssl lib die du getrennt updaten > musst. Man kann das auch scriptgesteuert machen, z,B. mit Ansible (oder dergleichen): (sinngemäss, per script) * erzeuge einen neuen leeren Container basierend auf Debian minimal server iso version so-und-so (nur beim ersten Mal) * sorge dafür dass dieses Paket installiert ist * sorge dafür dass jenes Paket installiert ist * sorge dafür dass dieses Paket NICHT installiert ist * sorge dafür dass dieser Nutzer existiert * sorge dafür dass jener Nutzer NICHT existiert * sorge dafür dass alle Pakete aktuell sind * sorge dafür dass der Inhalt dieses Zip and jenem Ort entpackt ist * sorge dafür dass diese Datei diesen Inhalt hat * sorge dafür dass jene Datei diese zwei Zeilen enthält * sorge dafür dass dieser Dienst gestartet ist das lässt Du dann durchlaufen. Beim ersten Mal wird alles aus dem Nichts heraus wunschgemäß und wiederholgenau installiert, bei jedem weiteren Durchlauf wird nur noch aktualisiert. Wenn Du die Konfiguration ändern willst oder die Web-Anwendung updaten dann änderst Du vor dem Durchlauf die entsprechenden Vorlagen, zum Beispiel das obige zip oder die einzelnen Dateien, dann tauscht er sie aus wenn er an der entsprechenden "sorge dafür dass..." Anweisung vorbeikommt. Da kannst Du ein ganzes Cluster von solchen Maschinen oder Containern aufsetzen oder umkonfigurieren oder einfach nur updaten und dabei gemütlich einen Kaffee trinken während die grünen [ OK ] in der Konsole durchrattern und dabei ein berauschendes Gefühl der totalen Kontrolle des Menschen über die Maschine verströmen.
Benji schrieb: > Allerdings ist die Chance sehr groß, dass sich Defaulteinstellungen > geändert haben. Auch eine neuere Toolversion kann dazu führen dass sich > Konfigdateien unterscheiden. > Also muss ich im Prinzip alle Dateien durchsehen und Änderungen jeweils > manuell beurteilen und händisch mergen. > Das klingt nach viel Arbeit. > > Geht das auch eleganter? > Wie löst ihr sowas? In /etc sind es in der Tat nur wenige Änderungen. Ich kommentiere bei einer Änderung immer den alten Wert aus und setze mein Kürzel ("ChrisD") davor, also so: # ChrisD ForwardX11 no ForwardX11 yes Ein "grep -rn ChrisD /etc" findet dann ruckzuck alle Änderungen.
:
Bearbeitet durch Moderator
Bernd K. schrieb: > Peter II schrieb: >> Samba, Apache, Bin, Proftpd, mysql, Postfix legen kaum Daten unter home >> ab. Bitte entschuldige, ich mag den alten ProFTP ja auch, aber seit spätestens zehn Jahren gehört FTP IMHO strengstens verboten. OpenSSH, Putty, WinSCP und Moba Xterm existieren, heute muß niemand mehr seine Login-Credentials und eventuell sensible Daten über unsichere Klartextprotokolle schicken. > Für solche Servergeschichten würde ich wenn ich heute nochmal sowas > aufsetzen müsste versuchen alles in separate und eigenständige einfach > zu migrierende leichtgewichtige VMs oder Container packen. Da kann dann > auch mal die Hardware abrauchen und man zieht die Container einfach um > auf die nächstbeste andere Maschine. Unbedingt!
Bernd K. schrieb: > Peter II schrieb: >> naja, dann hast im jeden Container openssl lib die du getrennt updaten >> musst. > > Man kann das auch scriptgesteuert machen, z,B. mit Ansible (oder > dergleichen): Updates in Containern zu machen ist ein Anti-Pattern! Stattdessen werden einfach nur die Container neu gebaut, das ist doch der ganze Trick hinter Containern im Sinne von "Infrastructure as Code".
Bernd K. schrieb: > Man kann das auch scriptgesteuert machen, z,B. mit Ansible (oder > dergleichen): ja, aber kann auch tausend Maschinen update ohne Container. Irgendwie versteht ich noch nicht genau den sinn von Containern. Wenn ich einen z.b. einen Server nur für mysql einsetzen will, der ruck-zuck fertig. die Datenbank und Passwörter muss ich doch eh selber einrichten (oder per script). Mit eine Container muss noch mehr Pakete installieren.
Chris D. schrieb: > In /etc sind es in der Tat nur wenige Änderungen. > > Ich kommentiere bei einer Änderung immer den alten Wert aus und setze > mein Kürzel ("ChrisD") davor, also so: > > # ChrisD ForwardX11 no > ForwardX11 yes > > Ein "grep -rn ChrisD /etc" findet dann ruckzuck alle Änderungen. So ähnlich habe ich das auch viele Jahre lang gemacht, bis ich etckeeper entdeckt habe. Das hat den Vorteil, daß es auch Änderungen protokolliert, die der Paketmanager bei Upgrades vornimmt. Ein weiterer Vorteil ist, daß man -- entsprechende Disziplin bei den Commit-Messages vorausgesetzt -- dann nicht mehr nur sieht, was man geändert hat, sondern auch, warum. Wo mehrere Sysops gemeinsam eine Maschine verwalten, oder sogar Regreßansprüche lauern, ist das IMHO essentiell.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.