Hallo, ich möchte gleich voranstellen, dass ich die Probleme jetzt _auch_ auf meinem Haupt-Server mit openSUSE 11.4 64bit habe. Ich mache auf diesem immer Sonntags die Updates, um nicht mitten in der Woche die gesamte Firma lahmzulegen. Auch hier hat mir aber das Auskommentieren der letzten Zeile geholfen. Am 13.05.2012 16:52, schrieb Christian Boltz:
Hallo Alex, hallo Leute,
Am Freitag, 11. Mai 2012 schrieb Alex Winzer:
Ich hatte im Netz eine Fundstelle gefunden, die auskommentierte bzw. änderte. Ich habe daher nach der Methode try and error jede Zeile in der Datei /ect/pam.d/sshd einzeln und nacheinander auskommentiert und dann einen Login versucht. Und siehe da, es klappt, wenn man folgende, bei mir auch letzte Zeile auskommentiert:
session optional pam_lastlog.so silent noupdate showfailed
Ich habe die Datei pam_lastlog.so aber in /lib/security gefunden, wie die anderen Module auch. Das bringt mich zu den nächsten Fragen: 1. Wieso klappt es nicht? 2. Wie "repariere" ich die Datei? 3. Wie bekomme ich heraus, wer sie kaputt gemacht hat? Überprüfe erstmal, ob eine der betreffenden Dateien verändert wurde.
Mit rpm -qf /pfad/zur/datei bekommst Du heraus, zu welchem Paket eine Datei gehört. In diesem Fall ist das höchstwahrscheinlich "pam" oder "pam-32bit" (letzteres gibt es nur auf 64bit-Systemen).
32bit: pam-1.1.3-4.9.1.i586 64bit: pam-32bit-1.1.3-4.9.1.x86_64 Da ich mich eher als Benutzer denn als Entwickler, Admin oder sonstwas sehe, muss ich an dieser Stelle fragen, was mir das jetzt sagt? Bedeutet das, dass ich die Pakete neu installieren sollte/muss?
Mit rpm -V pam pam-32bit kannst Du dann überprüfen, ob Dateien aus diesem Paket nach der Installation verändert wurden. 32bit: bdc-server:/lib/security # rpm -V pam-1.1.3-4.9.1.i586 ....L.... c /etc/pam.d/common-account ....L.... c /etc/pam.d/common-auth ....L.... c /etc/pam.d/common-password ....L.... c /etc/pam.d/common-session bdc-server:/lib/security #
In der Hilfe zu rpm (man rpm) steht dazu "L readLink(2) path missmatch". Mehr leider nicht. Wie jetzt weiter? 64bit: Es gibt keine Ausgabe. Also ist vermutlich alles OK? Bringt mich zur Frage: Warum geht es dann nicht _mehr_?
Wenn Du noch weißt, wann das Problem erstmals aufgetreten ist, kann /var/log/zypp/history hilfreich sein, um das "schuldige" Paket einzugrenzen.
Beim 32bit System leider nicht mehr. Das ist mein Backup-Server, den ich notfalls neu aufsetzen kann. Die logs habe ich dort unglücklicher Weise schon gelöscht. Beim 64bit System ist die Datei noch vorhanden (ca. 13 KB). Darf man so was lt. Listenregeln als Anhang beifügen? Gruß & Dank, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org