ubuntuusers.de

Hallo Forumsbewohner,

auf der Arbeit nutzen wir Ubuntu 12.04 LTS. Ist die Lightdm gestartet, loggt man sich einmal mit einer Karte und PIN am Kartenlesegerät ein. Anschließend kann man sich am Lightdm lediglich mit Username und Passwort einloggen, und zieht sich das neue Tagesticket auf dem Desktop. Hier wird man einmal nach der PIN gefragt, und das Ticket ist von nun an gültig. Auf meinem Rechner habe ich gerade das Problem, das Lightdm erscheint, dann fragt es in dem Passwortfeld nach der PIN. Hier gebe ich Enter ein und die PIN über das Bedienfeld des Kartenlesers. Anschließend frage mich Lightdm nach meinem Passwort für den PC. Nach der Eingabe werden die Daten übermittelt, jedoch kommt der Desktop nicht zum vorschein. Stattdessen fragt er wieder nach der PIN. Wechsle ich auf eine andere Konsole erscheint die selbe Prozedur in der Konsole. Allerdings kann ich sie hier abschließen. So kann ich nach der Authentifizierung normal in der Shell arbeiten. klist gibt auch ein gültiges Ticket aus. Nun frage ich mich, wo der Haken sein könnte, der bewirkt, das ich nicht in den Desktop hinein kann. Wo könnte ich am besten mit der Suche beginnen?

Gruß Sascha

Das Problem mit dem nicht-anmelden-können tritt hier sporadisch immer wieder auf, und hat in der Regel 2mögliche Ursachen:

1. Die Rechte im Home-Ordner sind nicht mehr korrekt gesetzt. Wie das zu korrigieren ist steht hier. Zusätzlich muss man auch noch die Datei ~/.Xauthority (mit Punkt, also verstecket, und großem X am Anfang) löschen.

2. kürzlich habe ich kennengelernt, dass lightdm einfach geschrottet war und neu installiert werden musste

   sudo apt-get install --reinstall lightdm

   hat es in dem Fall gebracht.

Das könntest du erst mal versuchen. Wenn es nicht funktioniert, muss man weiter sehen.

P.S.: Ich wohne hier gar nicht… 😛

Das Problem lag irgendwie an der SI-Konfiguration. Da ich mit sowas bisher noch nie zu tun hatte, gönnte ich mir vorher mal ein apt-get upgrade für um die 500 Pakete. Kann es sein, das die Paketaktualisierung vorhandene Konfigurationsdateien in /etc überschreibt?

Meines Wissens nicht ungefragt.

Bei Grub und auch bei Samba habe ich bei Neuinstallation schon abfragen erhalten, dassder Paketanbieter eine neue Konfigurationsdatei anbietet, und wie ich weiter verfahren will. Da wird dann außer alte behalten und alte überschreiben auch beide vergleichen angeboten.

Insofern kann ich mir das eigentlich nicht vorstellen. Allerdings ist so ein Upgrade ja immer echt empfehlenswert, und wenn du 500 Pakete upzugraden hattest, dann ist das letzte schon eine Weile her. War das vorher bei dir auf automatisch eingestellt? Vielleicht ist da eins nicht ganz durchgelaufen, und dann können schon mal Inkonsistenzen auftreten, die solche Probleme verursachen.

Ja unser Admin hat sich vor ein paar Monaten ein Ubuntu Image gezogen die betriebsspezifischen Änderungen eingepflegt und mit Clonezilla ein Image ins Intranet gestellt. Das nutzt er für alle Neueinrichtungen. Wenn sich der User eingerichtet hat, macht er nochmal ein spezifisches Userimage. In der sources.list sind auch nur die Standardrepos eingetragen: security, update, backports und ich glaube main. Die 500 Pakete scheinen tatsächlich seit dem Image erschienen zu sein. Am Montag werde ich mir nochmal mein letztes Image ziehen, und erstmal lediglich die Repos security und update aktivieren und updaten. Für den Rest muss ich mir was überlegen. Was mir beim letzten Upgrade aufgefallen ist, ist das einige Dateien in /etc gelöscht wurden (anscheinend nicht mehr benötigt). Möglicherweise greift die SI-Software auf eine davon zu... Wie haltet ihr das mit den Upgrades im betrieblichen Umfeld?

saigkill schrieb:

Wie haltet ihr das mit den Upgrades im betrieblichen Umfeld?

Keine Upgrades zu machen ist grob fahrlässig...

Es gibt mehrere Testrechner, die produktive Systeme spiegeln, auf diesen werden die Updates eingespielt, dann wird getestet. Sollte es nichts zerschossen haben, werden die Upgrades blockweise im Betrieb nach und nach eingespielt. Zuerst die unkritischen Bereiche, falls doch noch was nicht funktionieren sollte, und am Schluss die kritischen, wo kein Ausfall passieren darf.

Und natürlich mit einem APT-Mirror im Betrieb, damit kein Client sich die Updates aus dem Internet holen muss.

Übrigens: Mittlerweile ist das Problem gelöst. Der Grund war eigentlich so einfach, das niemand daran dachte. Unser Admin nutzte ein Script zur Einrichtung der SI. Dieses Script installiert auch eine sources.list, welche aber leider für trusty statt für precise ausgerichtet war. Nach der Änderung läufts wieder ☺