configed Login Problem

[kressefresser]

Hallo,

das System ist auf dem aktuellsten Stand. Die Probleme fingen nach dem letzten Update an.

Was ich bisher vergessen habe zu erwähnen. Wir benutzen LDAP als Benutzerdatenbank, kann es evtl. damit zusammenhängen?

Bis dahin

Oliver

[tinheap]

Ich arbeite hier auch an dem Problem. Inzwischen kann man sich an dem Server anmelden, was vermutlich mit der Reaktivierung des nscd zu tun hat. Keine Ahnung warum das so sein soll, aber nachdem der nscd läuft geht es halt.

Allerdings kann der opsiconfiged die Benutzer nicht der Grupper opsiadmin zuordnen.
Ich versuche mal zusammenzufassen, was ich bisher weiss:

Der Benutzer existiert und ist Mitglied der Gruppe opsiadmin, soweit es Linux angeht.

Code: Alles auswählen

server:~# getent passwd user
user:x:1000:501::/home/user:/bin/bash
server:~# getent group opsiadmin
opsiadmin:*:1008:user,pcpatch[...]
server:~# id user
uid=1000(user) gid=501(domadmins) Gruppen=[...]1008(opsiadmin),501(domadmin)

Ich habe vor allem bei den Gruppen einen grossen Teil entfernt.
Bei einem Anmeldeversuch entstehen folgende Zeilen im Logfile auf debug level:

Code: Alles auswählen

[5] [Sep 07 10:53:36] Now using log-file '/var/log/opsi/opsiconfd/192.168.67.238.log' for object 0x8e8f06c (Logger.py|330)
[4] [Sep 07 10:53:36] Client '192.168.67.238' did not send cookie (opsiconfd|257)
[4] [Sep 07 10:53:36] New session created (opsiconfd|933)
[5] [Sep 07 10:53:36] Storing hostname '' in session (opsiconfd|307)
[6] [Sep 07 10:53:36] Trying to get username and password from Authorization header (opsiconfd|313)
[6] [Sep 07 10:53:36] Authorization header found (type: basic) (opsiconfd|316)
[5] [Sep 07 10:53:36] Got json-rpc request: {'params': [], 'id': 1, 'method': 'authenticated'} (opsiconfd|240)
[4] [Sep 07 10:53:36] Authorization request from user@192.168.67.238 (opsiconfd|350)
[5] [Sep 07 10:53:36] OS reports 'domainname.local' as default domain (BackendManager.py|110)
[5] [Sep 07 10:53:36] Reading config file '/etc/opsi/backendManager.d/10_file.conf' (BackendManager.py|361)
[5] [Sep 07 10:53:36] Reading config file '/etc/opsi/backendManager.d/11_ldap.conf' (BackendManager.py|361)
[...]
[5] [Sep 07 10:53:36] Using backend OPSI.Backend.OpsiPXEConfd.OpsiPXEConfdBackend. (BackendManager.py|211)
[5] [Sep 07 10:53:36] Using backend OPSI.Backend.File31.File31Backend. (BackendManager.py|211)
[5] [Sep 07 10:53:36] Backend config for 'WakeOnLAN': {'defaultdomain': 'domainname.local'} (BackendManager.py|195)
[5] [Sep 07 10:53:36] Using backend OPSI.Backend.WakeOnLAN.WakeOnLANBackend. (BackendManager.py|211)
[6] [Sep 07 10:53:36] Trying to authenticate by Operating System... (BackendManager.py|161)
[6] [Sep 07 10:53:36] PAM conversation: query 'login:', type '2' (BackendManager.py|304)
[6] [Sep 07 10:53:36] PAM conversation: query 'Password: ', type '1' (BackendManager.py|304)
[6] [Sep 07 10:53:36] Primary group of user 'user' is 'domadmins' (BackendManager.py|334)
[6] [Sep 07 10:53:36] User 'ben' is member of group 'adm' (BackendManager.py|339)
[6] [Sep 07 10:53:36] User 'ben' is member of group 'dvgsamso' (BackendManager.py|339)
[6] [Sep 07 10:53:36] User 'ben' is member of group 'svnuser' (BackendManager.py|339)
[5] [Sep 07 10:53:36] Operating System authentication successful for user 'user', groups 'domadmins,adm,dvgsamso,svnuser' (BackendManager.py|165)
[4] [Sep 07 10:53:36] BackendManager created. (opsiconfd|387)
[5] [Sep 07 10:53:36] RPC method: 'authenticated' params: '[]' (opsiconfd|467)
[5] [Sep 07 10:53:36] Executing:  authenticated([]) (opsiconfd|520)
[5] [Sep 07 10:53:36] Got result... (opsiconfd|534)
[5] [Sep 07 10:53:36] Took 0.000s to process authenticated() (opsiconfd|549)
[...]

Man sieht also, dass opsiconfd der Meinung ist, dass der user nicht Mitglied der Gruppe ist.
Wenn ich alles richtig interpretiere ist hier der Teil des Codes aus BackenManayger.py, der Zuständig ist:

Code: Alles auswählen

self.__userGroups = [ grp.getgrgid( pwd.getpwnam(user)[3] )[0] ]
logger.debug("Primary group of user '%s' is '%s'" % (user, self.__userGroups[0]))
groups = grp.getgrall()
for group in groups:
     if user in group[3]:
          self.__userGroups.append(group[0])
          logger.debug("User '%s' is member of group '%s'" % (user, group[0]))

Was mich jetzt wunder ist das hier:

Code: Alles auswählen

server:~# python
Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp;
>>> for gruppe in grp.getgrall():
...     if gruppe[0] == "opsiadmin" and "user" in gruppe[3]:
...             print "Mitglied von opsiadmin!"
... 
Mitglied von opsiadmin!

FYI: Zum Abschluss noch die Systeminfo, die der Kollege bisher nicht mitgepostet hatte

Code: Alles auswählen

samson:~# cat /etc/debian_version 
5.0.2
samson:~# dpkg -l '*opsi*' | grep ^ii
ii  opsi-atftpd                       0.7.dfsg-1.4               advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                     1.3.3-2                    OPSI config editor
ii  opsi-depotserver                  3.3-10                     server fuer das Softwareverteilungssystem OPSI
ii  opsi-linux-bootimage              20090126-1                 Linux-Bootimage fuer das Softwareverteilungssystem OPSI
ii  opsi-utils                        3.3.1.0-4                  OPSI utils
ii  opsiconfd                         2.0.0.12-1                 OPSI configuration service
ii  opsipxeconfd                      0.3.6-1                    OPSI PXE configuration daemon
ii  python-opsi                       3.3.1.0-5                  OPSI python library

Eine letzt information noch: Mir ist aufgefallen, daß Python ebenfalls in einer neuen Version installiert wurde. Alte war 2.4 und neue ist 2.5. Also habe ich den manuellen Test (siehe oben) noch einmal gemacht, aber expliziet mit dem 2.4 binary. Hier schlägt der Test fehl. Habe darufhin geprüft ob opsiconfd /usr/bin/python nutzt und ob dieser auf python 2.5 zeigt. Beides ist korrekt. Allerdings tritt der fehler auch nach einem Neustart des Servers weiterhin auf mit dem leichten nebeneffekt, dass der Fehler clientseitig nur sehr träge angezeigt wird.

[wolfbardo]

mmh tinheap,

Am Anfang des Threads heisst es

Hallo,

nach einem Update auf 3.4 habe ich das Problem...

und nun

FYI: Zum Abschluss noch die Systeminfo, die der Kollege bisher nicht mitgepostet hatte

Code: Alles auswählen

samson:~# cat /etc/debian_version 
5.0.2
samson:~# dpkg -l '*opsi*' | grep ^ii
ii  opsi-atftpd                       0.7.dfsg-1.4               advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                     1.3.3-2                    OPSI config editor
ii  opsi-depotserver                  3.3-10                     server fuer das Softwareverteilungssystem OPSI
ii  opsi-linux-bootimage              20090126-1                 Linux-Bootimage fuer das Softwareverteilungssystem OPSI
ii  opsi-utils                        3.3.1.0-4                  OPSI utils
ii  opsiconfd                         2.0.0.12-1                 OPSI configuration service
ii  opsipxeconfd                      0.3.6-1                    OPSI PXE configuration daemon
ii  python-opsi                       3.3.1.0-5                  OPSI python library

Das ist nicht opsi3.4 und dies sind auch nicht die neuesten Pakete von opsi3.3.1

????

Gruss
Bardo Wolf

[tinheap]

Das ist mir gar nicht aufgefallen. Keine Ahnung wie der Kollege auf 3.4 gekommen ist, gleich mal klären.

Aber das es nicht neuesten sind wundert mich ein wenig:
server:~# grep opsi /etc/apt/sources.list
deb http://download.uib.de/debian lenny opsi3.3

Wie gesagt, keine Ahnung wo diese 3.4 jetzt herkommen sollte.

Dennoch:

Code: Alles auswählen

server:~# apt-get update | grep uib
Ign http://download.uib.de lenny Release.gpg
Ign http://download.uib.de lenny/opsi3.3 Translation-de
Ign http://download.uib.de lenny Release
Ign http://download.uib.de lenny/opsi3.3 Packages/DiffIndex
Ign http://download.uib.de lenny/opsi3.3 Packages
OK   http://download.uib.de lenny/opsi3.3 Packages

Code: Alles auswählen

server:~# apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Lese Status-Informationen ein... Fertig
Die folgenden Pakete werden aktualisiert:
  base-files libperl5.10 libssl-dev libssl0.9.8 linux-libc-dev openssl perl
  perl-base perl-doc perl-modules python-support tzdata x11-common
  xbase-clients xlibmesa-gl xlibmesa-glu
16 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 25,7MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 1455kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? 

Das System ist zwar nicht mehr, wie unsprünglich angegeben auf dem aktuellsten Stand, aber es sollen auch keine Opsipakete eingespielt werden. Insofern wundere ich mich, dass wir da nicht auf der aktuellen 3.3 sein sollen, habe auch kurz auf den Server geschaut, da sehe ich spotan auch keine neueren Packete. Könnten die Anderen Packete der Grund für die Probleme sein. Dann würde ich es Donnerstag nochmal probieren, da Mittwoch Updatetag ist. Aber so wirklich will ich daran nicht glauben.

[wolfbardo]

Hallo,

das System ist auf dem aktuellsten Stand. Die Probleme fingen nach dem letzten Update an.

Was ich bisher vergessen habe zu erwähnen. Wir benutzen LDAP als Benutzerdatenbank, kann es evtl. damit zusammenhängen?

Bis dahin

Oliver

welches letzte Update ? Nach tinheap sicher kein Update von opsi-Paketen.

Nach den von tinheap geposteten opsi-Paketen koennte es ein opsi 3.3 / opsi 3.3.1 RC 1 zwitter sein

...

Bardo Wolf

[tinheap]

welches letzte Update ? Nach tinheap sicher kein Update von opsi-Paketen.

Ok, das kann jetzt aufklären. Das System wurde von Debian etch auf lenny gebracht und er ist davon ausgegangen, dass in diesem Zug auch OPSI in einer neuen Version (nämlich 3.4) eingespielt wurde. Das ist, wie oben zu sehen, definitiv nicht der Fall.

Nach den von tinheap geposteten opsi-Paketen koennte es ein opsi 3.3 / opsi 3.3.1 RC 1 zwitter sein

Das ist wohl auch richtig, entspricht aber genau dem was download.uib.de für lenny unter opsi3.3 anbietet.
Sollte das Problem also hier liegen, müssten alle Nutzer mit der Kombination opsi3.3 und Debian lenny die Probleme haben, oder?

Ich im Lauf des Tages ein wenig weiterforschen. Sollte ich neue Ideen oder Informationen haben poste ich sie hier.

[tinheap]

Habe jetzt auf dem fraglichen System auch 3.3.1 eingespielt. Leider keine Veränderung der Lage.

Code: Alles auswählen

server:~# grep opsi /etc/apt/sources.list && apt-get update | grep uib && apt-get upgrade && dpkg -l '*opsi*' | grep ^ii
deb http://download.uib.de/debian lenny opsi3.3.1
Ign http://download.uib.de lenny Release.gpg
Ign http://download.uib.de lenny/opsi3.3.1 Translation-de
Ign http://download.uib.de lenny Release
Ign http://download.uib.de lenny/opsi3.3.1 Packages/DiffIndex
Ign http://download.uib.de lenny/opsi3.3.1 Packages
OK   http://download.uib.de lenny/opsi3.3.1 Packages
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Lese Status-Informationen ein... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
ii  opsi-atftpd                       0.7.dfsg-1.4               advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                     1.3.3-2                    OPSI config editor
ii  opsi-depotserver                  3.3-10                     server fuer das Softwareverteilungssystem OPSI
ii  opsi-linux-bootimage              20090414-1                 Linux-Bootimage fuer das Softwareverteilungssystem OPSI
ii  opsi-utils                        3.3.1.1-1                  OPSI utils
ii  opsiconfd                         2.0.0.16-1                 OPSI configuration service
ii  opsipxeconfd                      0.3.7-1                    OPSI PXE configuration daemon
ii  python-opsi                       3.3.1.11-1                 OPSI python library
server:~# 

[d.oertel]

Hi,

Was ich bisher vergessen habe zu erwähnen. Wir benutzen LDAP als Benutzerdatenbank, kann es evtl. damit zusammenhängen?

Ja - das ist schon möglich.
Und auch hier empfehle ich einen Supportvertrag.

gruss
d.oertel

[thomas.besser]

Dasselbe Problem (gleiche Fehlermeldungen) tritt hier (opsi 3.4, aktuellste Version) auch auf. User in der zentralen LDAP-Benutzerverwaltung kann sich ohne Probleme via SSH auf dem OPSI-Server anmelden.

Irgendwelche Hinweise im freien Support?

Danke und Gruß
Thomas

[j.schneider]

Schon mal in die /var/log/auth.log geschaut?