My new $HOME is my Castle, oder Konfigs und Homeumzüge Teil1

Über früher oder später wird Otto-Normal-Linuxer damit konfrontiert sein System upzugraden, es neu zu installieren oder auf andere Hardware umzuziehen. Das geht, wenn man es kann, immer problemlos. Mal einfach und schnell, mal etwas umständlicher und länger dauernd.
Mit diesem kleinen Tutorial will ich die Basics dazu vermitteln, diesen Job unter egal welchen Umständen sauber zu erledigen.
Dazu sollte man wissen,

wie das mit den Konfigurationen in Linux generell funktioniert
Und dafür wiederum, braucht man einen

Überblick über die verschiedenen Formate von Konfigurationsdateien unter Linux
Bis auf ganz wenige Ausnahmen sind alle Konfigurationsdateien in Linux reine Textdateien, die man mit jedem x-beliebigen Editor ändern kann. Dabei kommen viele verschiedene Formate zum Einsatz.
Während die Konfigs für die bash (oder viele andere Shells) nur gültige Shellanweisungen enthalten können, da sie schlicht "gesourced" werden, verwenden viele Programme auch das von Windows bekannte "ini"- Format. Also eine Zeile enthält eine [section] in eckigen Klammern, der dann beliebig viele Zeilen mit Konfigurationsanweisungen folgen, bis die nächste [section] auftaucht, oder die Datei endet.
Dann gibt es noch alte Klopfer, wie z.B. postfix, der Standard MTA (MailTransferAgent). Der verwendet das BDB Format (BerkeleyDataBase). Das ist im Prinzip -obwohl es auch ein zeilenorientiertes Format ist- eine Key-Value Datenbank. Tatsächlich ist das der Urahn der modernen Datenbanksysteme, wie Redis, nosql usw.. Dessen wesentliche Eigenschaft ist, dass am Anfang einer Zeile (ohne voranstehnde Leerzeichen) der Key steht, und nach einem trennenden Leerzeichen der Wert. Sollte eine Zeile nicht ausreichen, so kann man diese Zeile in der folgenden fortsetzen, aber dann MUSS am Anfang der folgenden Zeile mindestens ein Leerzeichen stehen.
Generell gilt die Syntax
<key><separator><value>
Natürlich gibt es noch andere Exoten und sogar wirklich binäre Konfigurationsdateien, die ohne entsprechendes Programm gar nicht gelesen werden können.
Die sind aber -Gott sei Dank- selten.

Unterkonfigurationen und alle möglichen Dateiendungen
Ein mächtigeres Programm hat meist auch enorm viele Konfigurationseinstellungen. Da das verwirrend und schwer lesbar ist, sind diese Konfiguration meist auch aufgesplittet in viele Dateien. Ein typisches Szenario für MeinRiesenProgramm wäre, dass es eine Hauptkonfigurationsdatei hat, die dann eben MeinRiesenProgramm.conf heißt. Oder .config als Extension hat.
In ganz alten Zeiten war so eine ewig lange Extension für eine Konfigdatei natürlich unmöglich. postfix verwendet .cf als Extension für seine Konfigdateien.
Und die bash schlicht rc (== RessourceControl )

Natürlich verwenden mache Programme für ihre Konfigurationsdateien auch die Extension .ini, was darauf hindeutet, dass es sich auch um dabi um das oben beschriebene Format handelt.
WENN sich die Programmierer an die Konvention gehalten haben.

Verlasst euch nicht auf das hier Geschriebene!
Linux ist ein breit gefächertes Sammelsurium guter Ideen, die in Code gegossen wurden. Zwar gibt es all diese Konventionen, aber es sind auch nur Konventionen. Nichts und niemand hindert dich daran, ein völlig neues, natürlich völlig revolutionäres und natürlich total viel besseres Schema zu ersinnen.
Verlasst euch lieber auf euren Instinkt. Finden sich in einer Extension die Buchstaben c und f, sollte bei euch der Possible-Konfig-File-Detected Alarm klingeln. Bei der Extension .ini natürlich ebenso. Findet ihr ein MeinRiesenProgrammrc (ohne Punkt zwischen Programmname und rc!!!) ist die Sache eh klar: Das muss eine Konfigurationsdatei von einem Programm sein, das sogar noch älter ist, als postfix, weil sie sich sogar den Punkt in der Extension gespart haben. Zu der Zeit kämpfte man um jedes Bit. Eine Extension, wie .config galt als teure Speicherplatzverschwendung.
Linux selbst kennt übrigens gar keine Extensions. Die dienen wirklich nur dazu uns das Leben leichter zu machen, im Gegensatz zu Windows, wo sie das System steuern. Es sind Dateien. Sonst nichts.

Wenn nun unser MeinRiesenProgramm enorme Netzwerkfähigkeiten mitbringt (was heute eigentlich jedes bessere Programm tut), dann haben wir verdammt viele Parameter zu konfigurieren. In einer einzigen Datei macht das überhaupt keinen Sinn und Spaß. Deshalb splittet man die Gesamtkonfiguration in einzelne Teile. Die dann durch Sourcen eingebunden werden.

Was ist "sourcen"?
Sourcen ist ein ganz einfacher Mechanismus, den viele Programme verwenden. Die Shell (bei uns also die bash) kenn dafür sogar einen eigenen Befehl source oder synonym dazu in Kurzform schlicht ein . bewirken nichts anderes, als dass diese "Source zeile", also source /pfad/zu/einer/Unterkonfig.datei.conf mit dem Inhalt die Unterkonfig.datei.conf ersetzt wird. Hilfe dazu gibt der Befehl help source oder wieder synonym dazu help .
(Die Hilfe für Shell- interne Befehle erhält man mit dem Befehl help, Hilfe für externe Befehle, also Befehle, die in /bin oder /sbin als echt ausführbare Programme liegen, mit man <befehlsname>.
Bestimmte interne Befehle wollen natürlich gequotet werden. So muss man z.B. zum Kommando [[ die Hilfe mit help "[[" aufrufen.)

Hat nun unser Programm MeinRiesenProgramm eine riesige Anzahl an Detailkonfigurationen, so macht man einfach ein Directory namens MeinRiesenProgramm.d. Dort liegen dann alle Subkonfigurationen und werden von der eigentlichen Konfigurations aus gesorced, mit einem Kommando, wie z.B. bei dem Webserver nginx include /Pfad/zu/MeinRiesenProgramm.d/*.conf
Ja: source und include tun genau das gleiche. include kennt man von vielen Programmiersprachen, wo sie einem ähnlichen Zweck dienen. Ein bekannter Mechansimus.

Natürlich braucht man bei komplexen Konfigurationen auch irgendeine Ordnung bzw. Reihenfolge. Die gewährleistet man (wenn man sie denn braucht), indem man den einzelnen Konfigurationsdateien eine meist zweistellige Zahl im Dateinamen voranstellt. Also in unserem Falle läge in MeinRiesenProgramm.d z.B. eine Datei namens 00-user.conf und eine 37-ssl.conf. Damit wird zuerst die 00-user.conf "gesourced", weil sie eben die niedrigere Nummer am Anfang im Namen trägt.

Mit diesem kleinen Vorspiel sind wir nun endlich beim eigentlichen Thema angelangt:
Wie passen all die verschiedenen Konfigurationen zusammen?
Da Linux von Haus aus ein Mehrbenutzersystem ist, hat sich eine bestimmte Reihenfolge erst eingebürgert, die dann zur Konvention wurde, und heute mehr oder weniger Gesetz ist. Damit viele verschiedene Unices zusammenarbeiten können, und die grundlegenden (GNU-) Tools auch überall, wie gewohnt, arbeiten, gibt es heute im Prinzip drei sehr wichtige Standards dazu, die man zumindest einmal gehört haben sollte.

• POSIX Standard
  garantiert, dass ein Programm, das diesen Standard unterstützt, auch korrekt läuft.
  POSIX == Portable Operating System Interconnect (and eXchange; das eXchange ist nicht gesichert, manche interpretieren es als Ziffer x, die die damalige IEEE Spezifikation steht)
  Die bash kann man im POSIXLY_CORRECT Modus laufen lassen, sie verhält sich dann, wie eine reine Posixshell. (Ein POSIX Shell- Script kann etwas weniger, kennt keine modernen Shell Syntax- Konstrukte, ist dafür aber auf jedem posixkompatiblen System ausführbar. Und ja: Es gibt Systeme, die nicht einmal eine Bash haben. )
• LSB, die Linux Standard Base
  das ist der Versuch der Linuxfoundation ein Regel- und Normenwerk zu schaffen, die alle möglichen Schnittstellen definiert, so dass verschiedene Linuces problemlos miteinander arbeiten können.
• FHS, der FileHierarchyStandard
  der beschreibt, was in welches Verzeichnis gehört. Es wird dort also genau der Zweck der gängigen Verzeichnisse definiert, und was dort liegen soll, was nicht.
  Dieser Standard gilt als Gesetz und wird von der LSB auch als solches vorausgesetzt.

Die ersten zwei mögen für Otto-Normal-Linuxer eher von akademischen Interesse sein, den FHS sollte man aber lesen, oder zumindest mal überfliegen.

Was passiert nun,
wenn ein Programm seine vollständige Konfiguration liest:

• Zuallererst kommen so genannte "hardcoded" Einstellungen zum Zuge. Wer schon mal programmiert hat, weiß, dass jedes Programm (falls es nicht völlig dilettantisch programmiert wurde) intern für alle relevanten Variablen Default- Werte hat, die zum Zuge kommen, wenn (später) nichts anderes angegeben wird.
• Danach werden - so vorhanden- Einstellungen aus /etc gelesen.
  Das /etc- Verzeichnis ist laut FHS für die hostweite Konfiguration zuständig. Also für alle Einstellungen, die für alle User dieses Systems gelten.
  Damit kann root bestimmte Vorgaben durchsetzen, die von Usern zu verwenden sind (oder eben doch überschrieben werden können).
• Die Konfiguration im $HOME des jeweiligen Users wird gelesen.
• Erst jetzt beginnt das Programm mit seiner Arbeit.
  Oder auch nicht.

Bevor wir endlich zum Umziehen eines Homes kommen, werfen wir noch einen kurzen Blick darauf, was ein Home eigentlich ist, und was passiert, wenn auf einem Host ein neuer User angelegt wird.

Was ist eigentlich ein HOME?
(ich lasse hier Setups mit LDAP und kerberisierte Systeme, die in großen Installationen verwendet werden hier außer Acht gelassen. Dort läuft manchen ganz anders.)
Nun, es ist schlicht ein Verzeichnis, das IRGENDWO liegt. Dort hat der User, dem dieses HOME gehört alle Rechte, andere Gruppen oder Gäste nur eingeschränkte oder keine Rechte.
Wo dieses Verzeichnis liegt, ist völlig egal. Es müssen auch nicht alle User ihre HOME unter /home liegen haben. Es ist wirklich nur ein Verzeichnis, das irgendwo liegen muss. Es ist sogar egal, ob das lokal auf dem Host liegt, oder über das Netz zur Verfügung gestellt wird.

Die entscheidende und einzige Stelle, die festlegt, wo das HOME eines Users liegt, ist die Datei /etc/passwd
Generell kann man für viele Programme die möglichen Konfigurationseinstellungen im 5. Kapitel der Manpages nachlesen.
Ein man 5 passwd zeigt also, wie diese Datei aufgebaut ist, und was man dort alles eintragen kann.
Im wesentlichen sind es sieben Felder, die durch einen : getrennt werden. Und die sind schnell erklärt:

• Feld: Der Login Name, also der Username
• Feld: Das Passwort.
  Früher stand dort tatsächlich das Passwort. Heute steht dort fast immer nur ein x. Und das meint, dass es ein Passwort gibt, aber dieses Passwort verschlüsselt in der Datei /etc/shadow zu finden ist. ( man 5 shadow )
• Feld: Die numerische User ID
• Feld: Die numerische Group ID
• Feld: Das sogeannte "Gecos" Feld.
  GECOS ist ein Acronym für GeneralElectric Compenhensive Operating Supervisor - ein 36Bit Mainframe von GE/Honeywell.
  Honeywell ist tot, und GE hat das Computern längst aufgegeben. Das Feld findet auch kaum mehr Anwendung, und beherbergte im Laufe der Zeit verschiedene Klassen von Informationen.
  Heute wird dort allenfalls noch der volle Name des Users eingetragen.
  Per definitionem ist das ein kommasepariertes Feld mit <voller UserName>,<Stockwerk Raumnummer>,<Diensttelephon>,<Privatnummer>,<weitere Infos>
• Feld: Hier steht jetzt, wo der User sein HOME liegen hat.
  Dies ist wirklich der einzige Eintrag, den man mit jedem Texteditor ändern einfach ändern kann, um sein HOME zu "verlegen".
• Feld: Hier steht die Standard Login- Shell des Users.
  Bei den meisten Distris, auch bei (open)SUSE ist das /bin/bash
  Ein häufig verwendeter Mechanismus ist, hier /usr/sbin/nologin einzutragen.
  Damit wird -wie der Name schon schreit- der User schlicht deaktivert. Egal, ob er sich an einer Konsole oder an einem DE anmelden möchte:
  Er kriegt nur eine Meldung: "Du nicht. Rede mit root."
  Man nennt das eine "Pseudoshell" (und ja: es gibt davon noch ein paar mehr)

Damit können wir nun jederzeit unser HOME nach belieben verschieben. Egal, wohin.

Ein Punkt aber bedarf noch einer kurzen Erläuterung:
Für die Bash liegen in /etc einige Konfigurationsdateien. Die Bash liest beim Start diverse sogenannte Dotdateien. Dieser Name rührt tatsächlich daher, dass die meisten Distris im HOME eines jeden Users eine Datei namens .bashrc liegen haben. Eben, wie wir jetzt wissen ein ResourceControl Datei für die Bash, die normal nicht angezeigt wird, eben weil der erste Buchstabe im Dateinamen ein Punk ist. Eben eine Dotdatei.
Das Pendant zu dieser Datei im HOME heißt aber im Verzeichnis /etc (also für alle User gültig) zwar auch bashrc, aber eben ohne führenden Punkt im Namen.

Und das gilt für so ziemlich alle Konfigdateien. Aus einem einfachen Grund:
Der User arbeitet mit allerlei Dateien in seinem HOME, aber nicht ständig mit seinen spezifischen Konfigurationsdateien, der Programme, die er einsetzt. Daher wurde die Konvention vor langer Zeit eingeführt, dass Konfigdateien im HOME mit einem Punkt beginnen, der bewirkt, dass sie schlicht nicht angezeigt werden.
Dieses Nicht- Anzeigen ist aber keine Eigenschaft des Dateisystems, sondern wirklich nur eine Konvention, an die sich z.B. ls einfach hält.
In Windows gibt es auch "hideen files". Aber dort ist das eine Eigenschaft, die im Dateisystem als Flag mit gespeichert wird. Ist das hidden- Flag gesetzt, wird diese Datei von keinem Befehl mehr "gesehen".
Im Gegensatz zu Linux, wo es der Befehl ls sehr wohl "sieht", sie aber schlicht nicht anzeigt - es sei denn man gäbe als Option -a oder -A beim Aufruf mit an.
Dieser Unterschied im Dateinamen zwischen /etc und einem HOME ist also eine historische Konvention, um dem User das Finden von Dateien im HOME zu erleichtern, weil viele Dotdateien (und es können sehr viele werden) einfach nicht angezeigt werden. In /etc sieht man alles, weil dort eh nur root rumkonfiguriert.

Noch ein Wort zu den Desktop Environments,
wie KDE, Gnome, oder, oder, oder...
Diese DEs bestehen grundlegend nicht nur aus einem Fenstermanager und sehr vielen kleinen Apps. Es sind dabei auch "große" Programme, wie Dolphin unter KDE, dabei. Und alle diese großen und kleine Programme nutzen fleißig eine gemeinsame Platform, können untereinander leicht kommunzieren, tauschen Daten aus usw.
Deshalb gibt es im HOME eines jeden Users eine unglaubliche Vielzahl von Konfigurationsdateien im Dotordner des jeweiligen DesktopEnvrionments. Für KDE/Plasma wären das .config und .local
Dort findet sich eine manchmal riesige Struktur von weiteren Unterverzeichnissen und Dateien, die allesamt der .config dienen, oder .local(e) Daten enthalten.

Aber das Prinzip, wie oben besprochen, bleibt gleich.

Was ist schief gegangen, wenn etwas schief geht?
Egal, was man gemacht hat: Wenn das System als solches hochkommt, kann es nicht schlimm sein.
Das kriegen wir hin.

Hat man über eine alte Installation ein Upgrade auf einen neuere Version gemacht, und alles spinnt, kann man drauf wetten, dass sich irgendeine Konfigurationsdatei in diesem Wust befindet, die noch eine alte -jetzt inkompatible- Einstellung(szeile) beherbergt.

Der allererste Test ist, schlicht kurzerhand einen neuen User anzulegen.
Wenn man das macht, wir einfach ein neues HOME für diesen User angelegt, und ein Konfigurationsskelett, das sich in /etc/skeleton (skeleton == engl. für Skelett, Gerippe) befindet, dann in das neue HOME kopiert.
(Ja: Alte Hasen kopieren sich ihre Standard- Konfigs nach /etc/skel und kümmern sich nicht mehr weiter drum. Jeder neue User hat von da an immer gleich alle Grundkonfigurationen mit dabei. Noch vor seinem ersten Login)
Funktioniert das mit dem neuen User, so ist bewiesen, dass es sich wirklich nur um einen inkompatiblen Konfigurationseintrag handelt.

Es kann aber bei dieser Fülle schwierig sein, den bösen Buben zu finden.

Handelt es sich um ein Programm, das nicht direkt zu einem großen DesktopEnvironment gehört, ist die Sache einfach: Die jeweilige Dotdatei löschen oder umbenennen. Oder selektiv einzelne Einträge dieser Konfigdatei auskommentieren und probieren, bis man die schuldige Zeile gefunden hat.
Das Auskommentieren meint einfach ein Kommentarzeichen am Anfang einer Zeile einzufügen. Die häufigsten Kommentarzeichen sind # und ; Aber wir wissen ja: ein man 5 programm.conf sagt uns, was aus einer Einstellung einen Kommentar macht.

Führt das nicht zum Erfolg, bietet sich
das selektive Kopieren von Konfigs im HOME an
Bei dieser Methode sollte man immer zwei elementare Tatsachen im Hinterkopf behalten. Sie sind der Schlüssel zur Vermeidung häufig auftretender Probleme.

• Jedes Dateisystem kennt nur die UserID, also eine Zahl, und hat überhaupt keinen Plan oder Wissen von Usernamen.
• Dem Kernel sind Usernamen ebenso völlig egal. Auch er "kennt" nur UserIDs

Das klingt nun nicht wirklich spektakulär, aber das wird es sofort, wenn man sich diese Geschichte vor Augen hält:
Der User "loser" hackt auf dem alten System munter vor sich hin. Er hatte sich -natürlich- seinen allerersten Useraccount auf dem alten System mit dem Usernamen "loser" erstellt.
Das System ordnete beim Erstellen des Accounts dem User "loser" die UserID 1000 zu. Das ist (zumindest für openSUSE) normal. Er hackte munter vor sich hin, vergeigte dies, versemmelte jenes.
Später bekannte er sich zu seiner Neigung und wurde mittels Medizintechnik zu "loserine".
Sein -pardon: ihr- System war nun mittlerweile so zerschossen, dass eine Neuinstallation fällig wurde.
Alles alte wollte sie nicht übernehmen, aber auch nicht einfach wegwerfen. Also flugs ein neues System installiert. Natürlich hieß der erste User nun "loserine".

Aber die UserIDs von "loser" im alten System war GLEICH der UserID von "loserine" im neuen System.
Beim Anlegen eines neuen Users wird schlicht die nächst freie UserID vergeben (solange man nichts anderes angibt).

Es wäre eigenlich nicht schlimm, was bisher passierte. Ja, mehr noch, es wäre sogar sehr geschickt, da ja nun alle Dateien und Verzeichnisse des alten HOMEs schon dem neuen User gehören würden.
Bis auf die Tatsache, dass in der /etc/passwd etwas anderes steht.
Denn dort -und das ist für den Kernel und alles weiter maßgeblich- steht eben ein ANDERES Verzeichnis als HOME.

Aber wir können uns diesen Umstand zu Nutze machen.

Wenn ich meine Kiste genügend zerschossen habe, so dass eine Neuinstallation fällig wird, tue ich das mit einer schlichten Methode:
Zuerst benenne ich als root einfach mein HOME um. Aus /home/loser wird da dann /home/migrant
mv /home/loser /home/migrant reicht völlig und geht sauschnell.
Dann installiere ich mir mein neues System und richte mir dabei meinen neuen Useraccount ein.
Ich muss keinerlei Rücksicht darauf nehmen, ob die HOMES woanders liegen oder nicht, ob Gefahr droht, dass irgendwelche Verwechslungen subtile Fehler einschleusen, oder anderes Unheil droht, solange ich den Usernamen "migrant" nicht verwende.

Damit habe ich ein "jungfräuliches" Home und kann mir aus dem alten Migrantenhome selektiv alle Konfigs rüberkopieren. Wenn es dann kracht, weiß ich, der letzte Kopierjob war nicht so gut, aber ich weiß dann, wo ich wirklich nach Inkompatiblitäten zu graben habe. Oder ignoriere es und konfiguriere für diesen Teil einfach neu.

Das ganze mache ich tatsächlich nicht.
Ich mache es umgekehrt:
Ich übernehme das alte Home komplett, und verschiebe dann -wenn es tatsächlich kracht- die verdächtigen Teile irgendwohin.
Solange, bis fast alles geht.
Dann kopiere ich einzeln alles wieder zurück, bis ich den Schuldigen gefunden habe.

Selektives Kopieren von Konfigs im HOME eben.

Das ist die immer schneller Methode ein altes Home problemlos auf eine neue Installation umzuziehen. UND dabei evtl. auftretende Inkompatabilitäten auszumerzen.

Der wichtigste Befehle für all solche Operationen:

chown -R user:usergroup /welcher/Pfad
CHange mir die OWNership -Recursiv (also für alles, was dort und darunter liegt) auf den User user mit : der Group usergroup des Verzeichnisses /welcher/Pfad

Alle Befehle, die sich mit solchen User- und Rechtegeschichten befassen, verstehen beides: Usernamen oder UserIDs.
Synonym wäre also (wenn user die UserID 1000 hat und die GroupID 46543) :
chown -R 1000:46543 /welcher/Pfad

man chown erzählt euch mehr, aber das wisst ihr ja längst, da ihr ja ständig irgendwelche Manpages lest...
Oder etwa nicht?

Und nun habt ihr das Verständnis und könnt euch deshalb beruhigt auf die faule Haut legen.
Damit könnt ihr jedesmal euer altes Home in neue Installationen übernehmen.
Und sollte es doch krachen, den Krach auch wieder abstellen.

Have fun.

Ganz nach Gusto.

Manche Programme halten ihre Konfigdateien im Home in Unterverzeichnissen, manche verwenden nur eine Datei

Der Editor vi zum Beispiel verwendet unter anderen eine .vimrc Konfigdatei im Home des Users, aber dort auch ein Unterverzeichnis .vim (Dort finden sich Plugins und diverse (third-party) Funktionen.

Man kopiert nach /etc/skel also die .vimrc selbst und das Pluginverzeichnis .vim

Es ist wirklich so schlicht:

ALLES, was in /etc/skel liegt (egal wie tief die Verzeichnisse dort geschachtelt sind), wird beim Erstellen eines neuen Users einfach in das neue Home kopiert (und natürlich Owner auf den neuen User gesetzt).

Ebenso schlicht: Die, die du nicht brauchst.

Und wenn du das nicht weißt, können das nicht einmal die Götter wissen.

Programme erstellen sich bei der Installation und/oder beim ersten Aufruf im Home des jeweiligen Users ihre Konfig- Dateien, oder eben nicht. Und bearbeiten sie bei allen Folgeaufrufen, oder eben nicht.

Das hängt alleine von dem Programm selbst ab.

Zwar mögen NSA und BKA wissen, welche Programme du tatsächlich verwendest, aber die Götter sicher nicht.

Wie sollte ich dir da helfen können?