Ausgesperrt, weil zsh defekt

M

morpheus

Well-Known Member
Ich wollte heute den Apache auf unserem Webserver aktualisieren, was mit portmaster auch funktioniert hat. Offensichtlich wurde bei diesem Update aber auch noch eine Lib ausgetauscht, die von der zsh, die ich als Login-Shell eingerichtet habe, benötigt wird.

Wenn ich nun versuche, mich an dem Server anzumelden, erhalte ich die Fehlermeldung: /libexed/ld-elf-so.1: Shared object "libpcre.so.0" not found, required by "zsh"

Leider habe ich keinen direkten Zugriff auf den Server, bzw. ich müsste mich dann erst im Rechenzentrum anmelden, hinfahren etc. oder jemanden im Rechenzentrum telefonisch um Hilfe bitten und hoffen, dass dieser Ansprechpartner auch kompetent ist.

Hat jemand eine Idee, wie ich mir wieder Zugang zum Server verschaffen kann? Meine einzige Idee wäre jetzt, den Server mit einer CD zu booten, die Shell in /etc/passwd zu ändern und dann neu zu starten. Allerdings müsste ich dazu erst mal mit der CD ins Rechenzentrum.

Oder gibt es noch eine andere Lösung?

Gruß, Morph
 
Das funktioniert leider nicht. Ich vermute, die zsh wird bereits zum Ausführen des chsh-Befehls verwendet und da die nicht funktioniert, bricht die Anmeldung sofort ab.
 
Leider hab ich jetzt auch keine Hilfe, wie du das Remote lösen könntest.
Kannst du evtl. Remote ISO Images einhängen zum Booten? Dann müsstest du nicht mit der CD vorbei sondern könnest einfach irgendwo ein ISO Image zurechtlegen.

Seit ich das Problem mal hatte, hab ich mir angewöht (zumindest bei kritischen Systemen) nicht nur immer zuerst in /usr/ports/UPDATING zu lesen, sondern auch einen SSH-Login nach dem Update auszuprobieren, BEVOR ich die bestehenden Verbindungen kappe und ausserdem mindestens zwei User (einen normalen und einen root ("toor")) mit Standard-Shell eingerichtet zu haben, um nicht in selbiges Problem zu geraten.

Hier ist die Problematik mit pcre näher Beschrieben, die dich wohl betrifft:
http://www.bsdforen.de/showthread.php?t=27507&highlight=pcre

Evtl. ist in /usr/ports/UPDATING noch ein einfacherer Weg beschrieben.
 
morpheus schrieb:
Das funktioniert leider nicht. Ich vermute, die zsh wird bereits zum Ausführen des chsh-Befehls verwendet und da die nicht funktioniert, bricht die Anmeldung sofort ab.
Zum Vergrößern anklicken....

Vielleicht wenn man den absoluten Pfad angibt, also /usr/bin/chsh anstelle von chsh?
edit: oder eine Shell explizit angeben, wie in 'ssh server /bin/tcsh -l'
 
ernst schrieb:
Vielleicht wenn man den absoluten Pfad angibt, also /usr/bin/chsh anstelle von chsh?
edit: oder eine Shell explizit angeben, wie in 'ssh server /bin/tcsh -l'
Zum Vergrößern anklicken....

Das funktioniert leider auch nicht. Ich fürchte, mir wird nichts anderes übrig bleiben, als mit einer CD ins Rechenzentrum zu fahren und die Emergency Holographic Shell anzuwerfen, die Rootpartition zu mounten und /etc/passwd von Hand zu editieren...
 
Zuletzt bearbeitet:
bei der gelegenheit solltest du dann auch gleich einen nutzer anlegen der eine andere shell benutzt, z.b. /bin/sh.:belehren:
 
du kannst sonst auch in der .profile eine andere shell starten, allerdings benötigst du dann auch zwei logouts. nachdem mir das mal bei einer lokalen maschine passiert ist, hab ich mir angewöhnt, die standardshell nicht mehr zu ändern. Meinen Kollegen nervt das zwar an, aber er hat sich wohl auch noch nicht ausgesperrt gehabt :)
 
Die Frage ist doch: Wieso braucht "zsh" diese Lib? Sollte "zsh" nicht statisch gelinkt sein?
 
@auge: ohne lokalen zugriff, zumindest per iLOM/ipmi oder kvm, ist das ohne netzwerkzugriff nicht wirklich hilfreich.
 
bei allen vernünftigen Lösungen, die mir nun einfallen, muss jemand vor Ort sein. Vorsorge hättest du treffen können, doch das ist ja nun vorbei.

Eine "unvernünftige" Möglichkeit könnte vielleicht sein, wenn du per ftp einloggen könntest und ausreichend rechte besitzt, die betreffenden Dateien zu ändern. Also entweder die fehlende lib vorübergehend durch einen Link auf eine hoffentlich vorhandene Version ersetzen oder einen vorübergehenden Link von der zsh zu einer funktionierenden Shell setzen.

Die Änderung der /etc/passwd würde ich natürlich auch probieren, aber ich weiß auch, dass die gar nicht verantwortlich ist und ohne einloggen und vipw wird das eher nichts.
 
Es geht nicht, es gibt keinen Weg es zu ohne lokalen Zugriff zu reparieren. Der Grund ist, dass bei jedem Login vom System die in /etc/passwd hinterlegte Shell ausgeführt wird. Die Session endet, wenn diese Shell beendet wird und das System logt darauf hin den Nutzer aus. Crasht die Shell, denkt das System eben die Session sei zu Ende und wirft den Nutzer raus. Der einzige Weg wäre eine Software, die nicht auf das System zum Login zurückgreift. Aber eine solche kann hoffentlich /etc nicht schreiben.
 
Yamagi schrieb:
Es geht nicht, es gibt keinen Weg es zu ohne lokalen Zugriff zu reparieren. Der Grund ist, dass bei jedem Login vom System die in /etc/passwd hinterlegte Shell ausgeführt wird.
Zum Vergrößern anklicken....

Ich telefoniere jetzt schon seit Stunden mit dem Techniker vom RZ, aber er scheint es nicht hin zu bekommen. Dabei sollte es doch funktionieren wenn man den Server im Singleuser-Modus startet, dann mount -uo rw / und dann mit vipw die /etc/master.passwd editiert. Der Mitarbeiter vor Ort behauptet aber, es würde nicht funktionieren. Wobei ich mir nicht so sicher bin, ob er tatsächlich das Richtige tut...

Ich fürchte, da wird mir wohl nichts anderes übrig bleiben, als doch mal persönlich vorbei zu fahren.
 
makenoob schrieb:
du kannst sonst auch in der .profile eine andere shell starten, allerdings benötigst du dann auch zwei logouts.
Zum Vergrößern anklicken....

Du kannst deine Wunschshell ja mit exec starten und vorher nachgucken, ob sie da ist.
Zum Beispiel in der .profile:
Code: 
test -x /usr/local/bin/bash && exec /usr/local/bin/bash

Selbst wenn die Shell dann wegen Libs oder so nicht starten kann geht hoffentlich das exec auch nicht und du bist noch in der csh... :D

Habe ich so auch bei verschiedenen root-Usern im Einsatz.

Mario
 
Du kannst ihm ja auch sagen, das er ein neuen User mit adduser, was ja ziemlich einfach ist, anlegen soll, oder in der sshd_config root login erlauben.

Es ist interessant, das wir hier in kuerzester Zeit zweimal im Prinzip das selbe Problem haben. Ein Grund, wenn man experimentieren will sich zumindest einen User (z.B. rueckwaerts buchstabiert) anlegen, der eine der Standard Shells hat.
 
So, es läuft wieder. Der Grund, warum es trotz Anpassung der /etc/master.passwd mit vipw durch den Techniker nicht funktioniert hat war schlicht und ergreifend der, dass der Techniker den Server nach dem Ändern der Datei im Singe-User-Mode belassen hat. Dass dann ssh nicht funktioniert, dürfte eigentlich klar sein. Damit hat sich mein Verdacht bestätigt, dass der Techniker vom RZ nicht wirklich wusste, was er da tat. (Seine Entschuldigung: "Ich kenne mich nur mit Linux aus und nicht mit *BSD")

Nach einem "exit" ging der Rechner in den Multiuser-Mode und ein ssh-login war wieder möglich. Ich werde auf jeden Fall die csh als Loginshell beibehalten und dann manuell zur zsh wechseln, das erscheint mir doch sicherer und nervenschonender.
 
also wenn man selbst die shell in der passwd oder eher master.passwd ändert, muss man das folgende ausführen um die datenbank neu zu schreiben.

Code: 
pwd_mkdb /etc/master.passwd

Ich persönlich würde immer die master.passwd nutzen, da es anscheinend so ist, dass FreeBSD die Datei vorrangig nutzt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben