Problem mit symlink des Homeverzeichnisses

[JochenF]

Ich habe hier ein seltsames Problem mit meinem Homeverzeichnis. Das wurde in /etc/passwd als /home/jochen angelegt. Nun ist /home aber ein symlink nach /usr/home, und damit gehen die Probleme los. Die bash streicht ja im Prompt den vorderen Teil weg wenn es sich um das Homeverzeichnis handelt. Beim Start von lxterminal bin ich aber in /usr/home/jochen und somit trifft das nicht zu. Ok, kleiner Schönheitsfehler, aber nicht weiter schlimm. Nun sind aber in .config/user-dirs.dirs ein paar Spezialverzeichnisse genannt, die im Dateimanager spezielle Symbole bewirken. Auch die sind häufig weg, weil der Pfad nicht übereinstimmt.

Meine Idee war dann, mein Homeverzeichnis einfach auf /usr/home/jochen abzuändern, was ja eigentlich keinen Unterschied machen sollte. Aber oh Schreck: Thunderbird findet dann sein Profilverzeichnis nicht mehr. Wie kann das denn sein???

 

[Kamikaze]

Ist der Symlink /home → /usr/home noch vorhanden?

 

[JochenF]

Ja klar, sonst hätte ich mich ja vorher gar nicht enloggen können.

 

[JochenF]

Mir fällt da grad was auf. Der Link ist doch nicht korrekt:

lrwxr-xr-x  1 root  wheel  8 12 Dez 13:50 /home -> usr/home

Das müsste doch eigentlich ein absoluter Link sein, kein relativer.

 

[Kamikaze]

Nee, das passt schon. Vor allem funktioniert das auch noch, wenn man / mal woanders hin mountet.

 

[JochenF]

Dem Thunderbird passt das offenbar nicht. Die Aussage "er findet sein Profil nicht" war nicht ganz korrekt. Er findet sein Profil, aber seinen Nachrichtenspeicher findet er nicht.
Mit /home/jochen als Homeverzeichnis sieht das so aus:

Mit /usr/home/jochen als Homeverzeichnis jedoch so:

Was läuft da schief dass der sich ein zweites /usr davorbastelt?

 

[JochenF]

In prefs.js hat sich der TB ein paar abenteuerliche relative Pfade zusammengebastelt, die dann offenbar nicht mehr funktionieren:

user_pref("mail.root.imap-rel", "[ProfD]../../../../usr/home/jochen/.thunderbird/dr1fnhoy.default/ImapMail");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../usr/home/jochen/.thunderbird/dr1fnhoy.default/ImapMail/s2.fahrner.name");
user_pref("mail.server.server2.directory-rel", "[ProfD]../../../../usr/home/jochen/.thunderbird/dr1fnhoy.default/Mail/Local Folders");
user_pref("mail.server.server4.directory-rel", "[ProfD]../../../../usr/home/jochen/.thunderbird/dr1fnhoy.default/Mail/Feeds");

 

[JochenF]

So, Problem gelöst. Das ganze ist ein Bug im Thunderbird. Das "[ProfD]" steht für das Profilverzeichnis. Die Einträge kann man auch einfacher und richtiger schreiben:

user_pref("mail.root.imap-rel", "[ProfD]ImapMail");
user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail/s2.fahrner.name");
user_pref("mail.server.server2.directory-rel", "[ProfD]Mail/Local Folders");
user_pref("mail.server.server4.directory-rel", "[ProfD]Mail/Feeds");

Typisch Mozilla, fällt mir da nur wieder ein.

 

[pit234a]

Du hast zwar dein Problem schon gelöst, aber ich habe es noch nicht verstanden.

Also, die Auswirkungen schon, aber nicht, wieso das Verhalten bei dir überhaupt dementsprechend ist.
Um mal nachzusehen, habe ich lxterminal installiert und wenn ich es starte, zeigt es den prompt korrekt, allerdings nutze ich tcsh. Wechsele nach bash, stimmt der Prompt aber noch immer.

o-box@senyo ~:-> bash
[o-box@senyo ~]$ cd /usr
[o-box@senyo /usr]$ cd
[o-box@senyo ~]$ su pit
Password:
pit@syo /home/o-box:-% cd
pit@syo ~:-% bash
[pit@senyo ~]$ cd /usr
[pit@senyo /usr]$

Ist das bei dir nicht so? Verstehe ich was falsch?

 

[JochenF]

@pit234a: das hängt immer ganz davon ab ob eine Anwendung die Symlinks dereferenziert oder nicht. Symlink und physisches Ziel sind ja prinzipiell identisch. Mit /home/jochen als Homeverzeichnis ist die Environmentvariable $HOME=/home/jochen. lxterminal dereferenziert bei Start aber dieses Verzeichnis und die bash bekommt /usr/home/jochen als cwd zu sehen. Dies ist nicht identisch mit $HOME, somit wird als Prompt der komplette Pfad angezeigt. Ein einfaches "cd" wechselt nach $HOME, womit cwd = $HOME ist, und der vordere Teil im Prompt entfernt wird. Es ist zwar immer noch das gleiche Verzeichnis, aber es heisst jetzt anders. Das macht den Unterschied aus.

Das Gleiche im Dateimanager pcmanfm. Der vergleicht cwd mit dem was in user-dirs.dirs definiert ist. Bei Gleichheit zeigt er die Sonderymbole für Verzeichnisse an, andernfalls ein normales Verzeichnis-Symbol.

Auch wenn ein Symlink das gleiche physische Verzeichnis bedeutet, so macht es semantisch einen Unterschied. Für viele Anwendungen ist es daher keine gute Idee ein Homeverzeichnis über einen Symlink zu realisieren. Ganz krass ist es im Fall von Thunderbird, der in manchen Situationen versucht den absoluten Pfad in einen relativen Pfad umzuwandeln. Dabei hangelt er sich rauf bis zum Wurzelverzeichnis (mit ../) und anschliessend wieder hinab. Dieser Quatsch funktioniert nur solange der Symlink bzw. $HOME sich nicht ändert.

 

[pit234a]

ok, danke für diese Erklärung.
Nur, dann frage ich mich, wieso das die bash so macht und auch pcmanfm.
Beides benutze ich normalerweise nicht unter FreeBSD, habe es aber schon mal getestet. Bei mir gibt es dann aber keine solcher dirs und ich arbeite mit der tcsh und mir ist solch ein Verhalten da noch nicht aufgefallen.
Es gibt bei mir auch keinen User, der bash in Voreinstellung nutzt. Müsste ich mal bei Gelegenheit testen, macht aber vielleicht auch nicht viel Sinn, weil ich keine Konfiguration für die bash vorgenommen habe, also alles mehr oder weniger auf default steht.
Wenn ich aber mal als root lxterminal aufrufe und dann dies mache:

senyo# cd
senyo# su pit
pit@syo /root:-% cd
pit@syo ~:-% pwd
/usr/home/pit
pit@syo ~:-% cd /usr
pit@syo /usr:-% bash
[pit@senyo /usr]$ cd
[pit@senyo ~]$ pwd
/home/pit
[pit@senyo ~]$

dann kann ich das zwar nachvollziehen, dass sich der Pfad von /usr/home/... nach /home/... geändert hat, aber das ändert nicht die Ausgabe des prompts. Bei mir bleibt das sich gleich, jedenfalls, soweit ich das nun mit tcsh und bash und urxvt und lxterminal probieren konnte.

Ah, grad sehe ich, dass dann, wenn ich in der bash mit cd /usr/home/pit zu dem home des aktiven Nutzers "wechsele", dann auch der Prompt sich ändert, ganz genau, wie du beschreibst. In der tcsh passiert das nicht.

pit@syo ~:-% pwd
/usr/home/pit
pit@syo ~:-% cd /usr/home/pit
pit@syo ~:-% bash
[pit@senyo ~]$ cd /usr/home/pit
[pit@senyo /usr/home/pit]$

Könnte das vielleicht etwas mit der Art des Wechsels ins Verzeichnis zu tun haben und mit einer Eigenart der bash? lxterminal scheint nicht anders zu reagieren, als andere Terminal-Programme auch.

 

[JochenF]

Die tcsh ist dann wohl schlauer. Offenbar dereferenziert die dann beide Pfade ($HOME und cwd) und vergleicht erst dann ob die vorderen Teile gleich sind. Die bash macht das wohl nicht und bemerkt die Gleichheit nicht. Komisch ist auch warum das lxterminal die bash mit /usr/home/jochen startet, anstatt mit /home/jochen, wie es in /etc/passwd steht. Kann aber sein dass das auch wieder an der bash liegt und nicht am Terminal.

Aber den Vogel schiesst ja der Thunderbird ab. Diese Pfadangabe muss man sich mal verinnerlichen:

user_pref("mail.root.imap-rel", "[ProfD]../../../../usr/home/jochen/.thunderbird/dr1fnhoy.default/ImapMail");

Da wollen die sich einen relativen Pfad basteln. [ProfD] ist ja das Profilverzeichnis, so wie es in der ini Datei angegeben ist. Da braucht man eigentlich nichts mehr dran basteln. Jetzt steigen die mit ../../../.. hinauf bis ins Wurzelverzeichnis, und hängen dann den absoluten und dereferenzierten Pfad an. Wer denkt sich so einen Käse aus? Das kann ja nur schief gehen. Übrigens machen die das nur bei 4 Pfadangaben so, andere sind richtig. Den Teil hat offenbar wer anderer programmiert. ;-)

 

[JochenF]

Jetzt habe ich mal die zsh als Loginshell ausprobiert. Ergebnis: die zsh startet im "richtigen" Verzeichnis:

dc7700% pwd
/home/jochen

Die bash hingegen dereferenziert das Homeverzeichnis beim Start, und startet in /usr/home/jochen. Liegt also nicht am lxterminal.

 

[JochenF]

Der Texteditor Geany hat offenbar auch ein Problem mit dem symlink:

 

[JochenF]

Spricht eigentlich was dagegen den symlink zu entfernen und /usr/home nach /home zu verschieben?

 

[Paldium]

Richtig oder nicht richtig liegt im Auge des Betrachters. Technisch passender sind die Ausdrücke "L"ogisch und "P"hysisch.

Ein logischer Pfad enthält symbolische Links, ein physischer Pfad nicht. Welcher jetzt angezeigt und ausgewertet wird, ist abhängig von der Shell. POSIX-konforme Shells nutzen den logischen Pfad, der mit "pwd" angezeigt wird (Ausnahmeregelungen kann jeder gerne selbst nachlesen).

Der logische Pfad /home/jochen ist nunmal nicht /usr/home/jochen, daher wird er auch nicht gegen ~ ausgetauscht. Wären die Pfade gleich, stünde im vorherigen Satz ja auch zweimal das gleiche da.

Wir erhalten den physischen Pfad /usr/home/jochen, wenn wir alle symbolischen Links im logischen Pfad /home/jochen auflösen. Den aktuellen physischen Pfad kann man sich auch mit dem Aufruf "pwd -P" anzeigen lassen:

$ pwd
/home/jochen
$ pwd -P
/usr/home/jochen

Die tcsh ist an dieser Stelle nicht POSIX-konform. Ihr "cd"-Aufruf verhält sich wie ein "cd -P"-Aufruf in einer POSIX-konformen Shell:

$ cd /home/jochen
$ pwd
/home/jochen
$ cd -P /home/jochen
$ pwd
/usr/home/jochen

Generell sollte man mit logischen Pfaden vorsichtig sein. Denn die logischen Pfade interessieren nur die Shell (und Programme, die auf die Umgebungsvariable PWD zugreifen). Auch hierfür ein Beispiel:

$ pwd
/home/jochen
$ (cd ../..; ls)
Inhalt von /: /home/jochen/../..
$ ls ../..
Inhalt von /usr: /usr/home/jochen/../..
$ (cd -P ../..; ls)
Inhalt von /usr: /usr/home/jochen/../..

Richtig haarig wirds dann auch, wenn die Shell automatische Vervollständigung aktiviert und dann Pfade angibt, die quasi nicht existieren. Oder existierende nicht anzeigt. Keine schöne Sache.

Und in POSIX-konformen Shells ist man eben nur dann im Home-Verzeichnis, wenn der logische Pfad mit dem Home-Verzeichnis übereinstimmt.

 

[Paldium]

pit@syo ~:-% cd /usr/home/pit
pit@syo ~:-% bash
[pit@senyo ~]$

Also das würde ich jetzt als Bug in der bash einstufen. Wenn man in /usr/home/pit also bash aufruft, landet man in /home/pit?

Das Verhalten hat die bash ja nicht, wenn man sie in /usr aufruft, wie zuvor von dir gezeigt.

 

[JochenF]

Und welche Erkenntnisse ziehen wir jetzt aus dem ganzen Durcheinander? Alle Shells Mist?

So wie ich Unix gelernt habe, sollten Links, egal ob Hardlinks oder Symlinks, völlig transparent sein. Das heisst, man darf nirgendwo mitbekommen das man physisch ganz woanders ist als man angegeben hatte. Wenn HOME=/home/jochen ist, dann will ich da nie und nirgendwo ein /usr/home/jochen auftauchen sehen, außer ich navigiere explizit da hin.

Meine Loginshell ist die bash, die startet die openbox session, und die wiederum startet pcmanfm und Thunderbird. Und wenn im pcmanfm als Ort /usr/home/jochen steht, oder in den Thunderbird Konfigs irgendwo ein /usr auftaucht, ist zwischendrin was schief gelaufen.

 

[Paldium]

Und welche Erkenntnisse ziehen wir jetzt aus dem ganzen Durcheinander? Alle Shells Mist?

Einige Shells halten sich an POSIX, andere nicht.

So wie ich Unix gelernt habe, sollten Links, egal ob Hardlinks oder Symlinks, völlig transparent sein.

.. und alles ist eine Datei. So wie die Netzwerkinterfaces. *hust*

Stark vereinfacht könnte man sowas stehen lassen, aber es stimmt einfach nicht. Hardlinks könnte man noch akzeptieren, aber symbolische Links sind weder für den Programmierer noch für den Anwender völlig transparent.

Der Programmierer darf unter anderem mit stat() vs. lstat() rumhampeln und ein Anwender hat auch mit Programmen seine Freude:

$ mkdir -p dir/subdir
$ ln -s dir link
$ find ./link
./link
$ find ./link/
./link/
./link/subdir

Bei völliger Transparenz wäre es auch recht schwierig, beurteilen zu können, in welchen Verzeichnissen wie viel Festplattenspeicher belegt ist.

Meine Loginshell ist die bash, die startet die openbox session, und die wiederum startet pcmanfm und Thunderbird. Und wenn im pcmanfm als Ort /usr/home/jochen steht, oder in den Thunderbird Konfigs irgendwo ein /usr auftaucht, ist zwischendrin was schief gelaufen.

pcmanfm hat ein elementares Problem. Woher soll es wissen, wie du deinen Weg zum aktuellen Arbeitsverzeichnis gefunden hast? Es müsste auf die Umgebungsvariable PWD zugreifen. Das ist aber schon wieder fehleranfällig. Ich sag nur export PWD=/gibts/nicht.

Wenn du mir nicht glaubst, dann guck mal wie die *BSD-Implementationen von pwd arbeiten. Nicht das eingebaute in deiner bash!

$ cd /home/jochen
$ pwd
/home/jochen
$ /bin/pwd -L
/usr/home/jochen
$ /bin/pwd -P
/usr/home/jochen

Kurz um: Damit deine Programme so arbeiten, wie du es erwartest, müssten sie sich voll und ganz auf die Umgebungsvariable PWD verlassen. Und das macht nicht einmal pwd. Alternativ müssten sie deinen /etc/passwd-Eintrag raussuchen und das Homeverzeichnis nehmen. Aber dann meckert bestimmt jemand anderes, zum Beispiel chroot- oder Jail-Nutzer ohne /etc/passwd-Zugriff...

 

[Paldium]

Oh, das war jetzt mein Versehen. Meine Aussage ist nicht 100%ig richtig.

Meine Testumgebung hatte einen Link von /home/jochen auf /usr/home/jochen. Wenn aber /home selbst ein Link ist und jochen wiederum ein Verzeichnis, dann kann /bin/pwd -L es vernünftig auflösen...

Meine restlichen Anmerkungen bleiben jedoch bestehen.

 

[Paldium]

Ach herrje, und ich hatte PWD absichtlich falsch gesetzt um das zu testen...
Ich gebs auf. pwd und /bin/pwd geben beide das Richtige zurück. pcmanfm sollte also PWD und getcwd() prüfen, so wie /bin/pwd das macht.

Was ich ja eigentlich sagen wollte: Ist nicht (unbedingt) Schuld der Shell, sondern der Anwendungen. Und teilweise auch gar nicht anders möglich. In diesem Fall schon.

 

[JochenF]

Mein Fazit aus dem ganzen Scheiss: never use a symlinked home

 

[pit234a]

von diesen Betrachtungen abgesehen, wundert es mich eben doch, dass ich derartige Probleme noch niemals festgestellt habe. Ob das nur mit der tcsh zusammenhängt?
Beinahe vermute ich eher, dass Variablen durch unterschiedliche Startvorgänge unterschiedlich weitergereicht werden.
So macht auch geany bei mir gar keinen Stress mit irgendwelchen Dateien aus meinem ~ oder auch von anderswo (vorausgesetzt, die rechte passen ansonsten).

Bei mir startet KDM (oder etwa XDM bei einer Installation von OpenBSD, wo ich auch keine solchen Probleme erfahren hatte) openbox. Auch ohne KDM (muss ich mal testen) hatte ich keine solchen Probleme bemerkt, aber nur kurz dieses Szenario benutzt. Dann startet .xsession openbox und von dort in einem Autostart mehrere Anwendungen. Tastenkombinationen rufen weitere auf, etwa urxvt oder gmrun, mit dem ich dann weitere Anwendungen starte.

Also, ich verstehe die Vorgänge, die Paldium erklärt und der Fehler von JochenF im Thunderbird ist ja auch nachvollziehbar.
Aber, dass ich wegen derartiger Vorfälle wie mit geany geneigt gewesen wäre den (anfänglich ungewohnten) FreeBSD-Link nach /usr/home zu entfernen oder um zu bauen, kann ich nicht behaupten. Mir sind damit noch keine Probleme begegnet. Und ich meine damit nun nicht unbedingt einen unschönen Eintrag im Prompt einer shell.

 

[pit234a]

pcmanfm
überlegte ich gerade, vielleicht auch unter FreeBSD mal häufiger zu benutzen und ging deshalb die Konfiguration durch. Da kann man einen Pfad für "persönlichen Ordner" wählen. Default ist der /home/Nutzer.
Obwohl die angezeigten Dateien vollkommen gleich aussehen, ändert sich tatsächlich das icon für Desktop, wenn ich von /home/Nutzer zu /usr/home/Nutzer umschalte. Bei anderen Ordnern konnte ich das nun nicht sehen, habe vermutlich auch kaum Spezial-Ordner. Das Verzeichnis .config/user-dirs.dirs sehe ich bei mir nicht. Da wird wohl nicht der Pfad zu den icons eine Rolle spielen, sondern der Name für das heimatverzeichnis und pcmanfm nimmt von irgendwoher an, dass der /home/Nutzer sei und dass dies passt. Vermutlich wird da kurz geprüft und dann eben /home/Nutzer genutzt, wie das in der GNU/Linux Welt wohl meist der Fall sein wird.

 

[pit234a]

Also, wenn ich in der ~/.cshrc ((t)csh ist meine login-shell) die Variable HOME mit /usr/home/Nutzer belege, kann ich das Verhalten ändern. Aus einer so gestarteten Shell aufgerufen sind sowohl pcmanfm als auch die bash bereit, /usr/home/Nutzer zu akzeptieren.
Wieder sehe ich keine Unterschiede oder Probleme, alle Anwendungen finden ihre Dateien, nur der Prompt sieht eben nun anders aus und das icon für Desktop ändert sich eben auch andersherum, also sobald der aktuelle Pfad = HOME ist.

Wie gesagt, Probleme habe ich damit auch diesmal keine gesehen und ich frage mich, warum eigentlich nicht in der passwd /usr/home/Nutzer genommen wird, um alle Verwechselungen auszuschließen (hatte JochenF sich glaube ich auch weiter oben auch schon gefragt).