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.
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.
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.
