Mailinglist Archive: opensuse-de (4628 mails)
| < Previous | Next > |
Re: Newbie: Update von openldap2-2.0.12-33 auf suse7.3?
- From: Dieter Kluenter <dieter@xxxxxxxxxx>
- Date: Wed, 04 Sep 2002 22:11:36 +0200
- Message-id: <m34rd5347b.fsf@xxxxxxxxxxxx>
Hallo,
Tobias Hofmann <tobias.hofmann@xxxxxxxxxxxxxxxxxxxx> writes:
Ich werde jetzt mal radikal streichen, damit wir den Zusammenhang
weiterhin erkennen können. Zum Thema Debugging Werte schreibe ich eine
gesonderte Mail
[...]
Der Suchstring sieht etwas seltsam aus.
Ich erkenne langsam den Zusammenhang :-)
Der Suchstring von ldapsearch setzt sich folgendermaßen zusammen
ld/base/scope/filter/attribute
Der Suchstring kann auch geschrieben werden /*/*/*/filter, oder ///filter
Dein Suchstring wird nur als Filter erkannt, die Base wird auf default
gesetzt, was vermutlich (dc=medien,dc=uni-weimar,dc=de) ist, scope
wird ebenfalls auf Default gesetzt, das ist sub.
Warum bei dir ein SPACE einen Unterschied macht, kann ich nicht
nachvollziehen.
Ich habe mal deinen Suchstring, für mein System umgesetzt,
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
marin:/usr/local/bin # ./ldapsearch -x
"(&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partn
r, ou=users,o=avci,c=de))"
# extended LDIF
#
# LDAPv3
# filter: (&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partner,
ou=users,o=avci,c=de))
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Mit, oder ohne Space an den unterschiedlichen Stellen, der Filter wird
nicht erkannt. In meinen Logfiles steht dazu
-.-.-.-.--.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Sep 4 21:21:25 marin slapd[1025]: daemon: conn=197 fd=16 connection from
IP=192.168.100.95:4983
7 (IP=:: 389) accepted.
Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 BIND dn="" method=128
Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 RESULT tag=97 err=0 text=
Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SRCH base="o=avci,c=de"
scope=2 filter="(&(obje
ctClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de))"
Sep 4 21:21:25 marin slapd[1054]: <= bdb_equality_candidates: index_param
failed (18)
Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SEARCH RESULT tag=101 err=0
nentries=0 text=
Sep 4 21:21:25 marin slapd[1052]: conn=197 op=2 UNBIND
Sep 4 21:21:25 marin slapd[1052]: conn=197 fd=16 closed
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.-.-.-.-.-.-
Wie du siehst, ist Default Searchbase o=avci,c=de, scope=2, das ist
sub und default.
Die Meldung 'equality candidates: index_param failed' sagt, daß der
Index für objectclass eq verlangt und dafür keine Indexparameter
vorhanden sind. Aber ich nutze auch die objectclass posixGroup.
Das ist noch keine Wertung, erst einmal eine Feststellung.
Jetzt können wir der Sache schon näher kommen. :-)
Kann es sein, daß der Client für Active Directory geschrieben ist? Das
würde einiges erklären, insbesondere die seltsame Positionierung der
Base, ans Ende des Suchstrings. Sofern dc=medien ... als Base
definiert ist.
Jein. OPenLDAP ist da sensibler, und sagt, wenn in einem String ein
SPACE als füllendes Element gesetzt wird, liegt das in der
Verantwortung des Administrators. SPACES werden nicht komprimiert,
sprich nicht als 'nicht vorhanden' behandelt.
Die Gefahr besteht, daß zwei oder mehr SPACES gesetzt werden, dies
bedeutet dann, daß der Rest des Strings BASE64 kodiert werden kann,
oder auch andere mehrdeutige Interpretationen zuläßt. So steht es aber
auch in RFC 2849, z.B. zum Thema dn specification. (SPACE = FILL)
Die Definition von 'Whitespace' ist nicht eindeutig. Das könnte SPACE
oder TAB bedeuten. RFC 2849 spricht eindeutig nur von SPACE, ASCII
Zeichen 0x20. Auch die Formulierung 'ignore'ist nicht eindeutig. Es
könnte beuten, als 'nicht gesetzt' betrachten, oder aber auch als
'übernehmen aber nicht weiter berücksichtigen'.
OpenLDAP übernimmt die Interpretationsmöglichkeit 'übernehmen, aber
nicht weiter berücksichtigen'. Dies kann aber dann in einigen Fällen
zu Konflikten führen, wie oben angedeutet.
Das mit dem Blank scheint mir eine schlechte Lösung zu sein. Ich
denke, dann kann eine sinnvolle und systemkonforme Lösusng gefunden
werden. Harry und ich werden dir mit Rat und Tat zur Seite stehen.
Ich habe hier zu Testzwecken vier verschieden OpenLDAP Versionen,
1.2.11, 2.0.23, 2.1.2., 2.1.3. Mein bevorzugtes Testobjekt ist die
Version 2.1.3, auf 2.0.23 laufen noch ein paar Anwendungen, 1.2.11 ist
für meinen Mailserver und 2.1.2 wird nicht mehr genutzt.
ein update auf eine andere 2.0.x Version halte ich nicht für
sinnvoll. Wenn du unbedingt aufrüsten möchtest, dann 2.1.3. Die
Version 2.1.4 scheint bei einigen Leuten Probleme zu bringen. Aber ich
warne dich, ein update kann Probleme bringen, wenn die Datensätze
nicht RFC konform sind. Ein simples slapcat zur Erzeugung eines *.ldif
und dann ein ldapadd auf 2.1.x kann katastrophal werden. Nicht das das
Problem unlösbar wäre, aber vermutlich verwendest du unwissentlich
inkompatible objectclasses in einem Datensatz, hast bei der
ursprünglichen Erstellung des Datensatzes am Ende eines Strings kein
CR durchgeführt, oder ähnliches.
Wenn du updatest, solltest du auch Berkeley DB Version 4.x verwenden,
am besten auch gleich cyrus-sasl-2.1.x, wie sieht es mit Kerberos aus?
PAM könnte auch die neuste Version vertragen :-)
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu
formulieren, daß auch gefunden wird, was du suchst.
Ich spreche jetzt mal für Harry mit, denn ich glaube er wird meine
Worte unterstützen :-)
Wir freuen uns über jeden Aspiranten, der sich OpenLDAP zuwendet und
versuchen ihn im Rahmen unseres Wissens und unserer Freizeit (manchmal
auch darüber hinaus) zu unterstützen.
(das war das Wort zum Sonntag :-))
-Dieter
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter@xxxxxxxxxxxxxxxx
http://www.schevolution.com/tour
Tobias Hofmann <tobias.hofmann@xxxxxxxxxxxxxxxxxxxx> writes:
Ich werde jetzt mal radikal streichen, damit wir den Zusammenhang
weiterhin erkennen können. Zum Thema Debugging Werte schreibe ich eine
gesonderte Mail
[...]
Zusammenfassung:
Ein Client sendet eine Reihe von Anfragen an meinen LDAP-Server - er
will wissen, ob es den Nutzer gibt, und ob er in einer bestimmten
Gruppe ist.
Das Suchen, Finden und Authentifizieren des Nutzers scheint kein
Problem zu sein, funktioniert wie soll.
Das Finden der Gruppe(n), in denen der Nutzer Mitglied ist, scheitert,
wenn der Eintrag des Nutzers in die Gruppe durch Setzen des Attributes
memberUid=uid=username,ou=Unitname,dc=medien,dc=uni-weimar,dc=de
derart geschieht, dass vor der search base (dc=medien...) _kein_
Leerzeichen steht.
Der folgende Befehl:
holix:~ # ldapsearch -x
"(&(objectClass=posixGroup)(memberUid=uid=hofmann9,ou=Users,
dc=medien,dc=uni-weimar,dc=de))
Der Suchstring sieht etwas seltsam aus.
den ich fuer analog der Suche meiner Applikation halte (sh. gefundener
filter aus debug-log), fuehrt nur zu einem Suchergebnis, wenn ich vor
der search base das blank einfuege (per slapcat kontrolliert).
Dabei spielt es keine Rolle, ob im dn der Gruppe Blanks eingetragen
sind oder nicht, lediglich dass eine Mistblank vor der Search Base
macht den Unterschied...
Ich erkenne langsam den Zusammenhang :-)
Der Suchstring von ldapsearch setzt sich folgendermaßen zusammen
ld/base/scope/filter/attribute
Der Suchstring kann auch geschrieben werden /*/*/*/filter, oder ///filter
Dein Suchstring wird nur als Filter erkannt, die Base wird auf default
gesetzt, was vermutlich (dc=medien,dc=uni-weimar,dc=de) ist, scope
wird ebenfalls auf Default gesetzt, das ist sub.
Warum bei dir ein SPACE einen Unterschied macht, kann ich nicht
nachvollziehen.
Ich habe mal deinen Suchstring, für mein System umgesetzt,
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
marin:/usr/local/bin # ./ldapsearch -x
"(&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partn
r, ou=users,o=avci,c=de))"
# extended LDIF
#
# LDAPv3
# filter: (&(objectClass=posixGroup)(memberUid=uid=dieter,ou=Partner,
ou=users,o=avci,c=de))
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Mit, oder ohne Space an den unterschiedlichen Stellen, der Filter wird
nicht erkannt. In meinen Logfiles steht dazu
-.-.-.-.--.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Sep 4 21:21:25 marin slapd[1025]: daemon: conn=197 fd=16 connection from
IP=192.168.100.95:4983
7 (IP=:: 389) accepted.
Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 BIND dn="" method=128
Sep 4 21:21:25 marin slapd[1053]: conn=197 op=0 RESULT tag=97 err=0 text=
Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SRCH base="o=avci,c=de"
scope=2 filter="(&(obje
ctClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de))"
Sep 4 21:21:25 marin slapd[1054]: <= bdb_equality_candidates: index_param
failed (18)
Sep 4 21:21:25 marin slapd[1054]: conn=197 op=1 SEARCH RESULT tag=101 err=0
nentries=0 text=
Sep 4 21:21:25 marin slapd[1052]: conn=197 op=2 UNBIND
Sep 4 21:21:25 marin slapd[1052]: conn=197 fd=16 closed
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.-.-.-.-.-.-
Wie du siehst, ist Default Searchbase o=avci,c=de, scope=2, das ist
sub und default.
Die Meldung 'equality candidates: index_param failed' sagt, daß der
Index für objectclass eq verlangt und dafür keine Indexparameter
vorhanden sind. Aber ich nutze auch die objectclass posixGroup.
Das ist noch keine Wertung, erst einmal eine Feststellung.
Jetzt können wir der Sache schon näher kommen. :-)
[...]
Ich habe das mit den Leerzeichen immer noch nicht verstanden.
Sendet denn der Client die Anfrage mit den "fehlerhaften" Leerzeichen
in der dn ?
Yep, genauso wie oben geschrieben - vor "dc=medien,..." ist ein
space. Wenn ich einen Link haette, der bestaetigt, dass Spaces in
solchen Anfragen nix koennen, wuerde ich den gerne dem Hersteller der
Soft geben... :) Mir hat die Lektuere von RFC 2254 und 2252 nicht sehr
weitergeholfen.
Kann es sein, daß der Client für Active Directory geschrieben ist? Das
würde einiges erklären, insbesondere die seltsame Positionierung der
Base, ans Ende des Suchstrings. Sofern dc=medien ... als Base
definiert ist.
Für das LDIF Format ist ja auch RFC 2849 zuständig.
... den ich mittlerweile gelesen habe - Dank fuer Hinweis! :)
Zwei Fragen dazu:
Zum Einen kam von Dir und Harry der Hinweis, im dn sollen keine Blanks
stehen, die Beispiele unter http://www.faqs.org/rfcs/rfc2849.html
haben aber alle ein Blank drin? Gibts da was neueres? Ich fand auch
keine Aussagen zu den Strings...
Jein. OPenLDAP ist da sensibler, und sagt, wenn in einem String ein
SPACE als füllendes Element gesetzt wird, liegt das in der
Verantwortung des Administrators. SPACES werden nicht komprimiert,
sprich nicht als 'nicht vorhanden' behandelt.
Die Gefahr besteht, daß zwei oder mehr SPACES gesetzt werden, dies
bedeutet dann, daß der Rest des Strings BASE64 kodiert werden kann,
oder auch andere mehrdeutige Interpretationen zuläßt. So steht es aber
auch in RFC 2849, z.B. zum Thema dn specification. (SPACE = FILL)
Zum Anderen habe ich mich von rfc 2849 zu rfc 2253 durchgehangelt und
dort folgenden Absatz gefunden:
Implementations MUST allow a semicolon character to be used instead
of a comma to separate RDNs in a distinguished name, and MUST also
allow whitespace characters to be present on either side of the comma
or semicolon. The whitespace characters are ignored, and the
semicolon replaced with a comma.
Hu? Steht das in einem ganz anderen Kontext und ich verhau da was?
Die Definition von 'Whitespace' ist nicht eindeutig. Das könnte SPACE
oder TAB bedeuten. RFC 2849 spricht eindeutig nur von SPACE, ASCII
Zeichen 0x20. Auch die Formulierung 'ignore'ist nicht eindeutig. Es
könnte beuten, als 'nicht gesetzt' betrachten, oder aber auch als
'übernehmen aber nicht weiter berücksichtigen'.
OpenLDAP übernimmt die Interpretationsmöglichkeit 'übernehmen, aber
nicht weiter berücksichtigen'. Dies kann aber dann in einigen Fällen
zu Konflikten führen, wie oben angedeutet.
Um das zum Ende zu bringen:
Damit ich habe, was ich will (User werden den Gruppen zugeordnet) kann
ich entweder haendisch immer das hier benoetigte blank einfuegen
(baeh) oder updaten (sh. Hinweise der openldap-mailingliste - wenn die
Recht haben... :).
Das mit dem Blank scheint mir eine schlechte Lösung zu sein. Ich
denke, dann kann eine sinnvolle und systemkonforme Lösusng gefunden
werden. Harry und ich werden dir mit Rat und Tat zur Seite stehen.
Deswegen fuerchte ich, dass ich entweder versuchen sollte, die
openldap2-2.0.23-111.i386.rpm fuer die 8.0 auf meiner 7.3 zum laufen
zu bekommen, oder ich baue mir entweder 2.0.25 oder 2.1.4 selber -
stimmt das so?
Ich habe hier zu Testzwecken vier verschieden OpenLDAP Versionen,
1.2.11, 2.0.23, 2.1.2., 2.1.3. Mein bevorzugtes Testobjekt ist die
Version 2.1.3, auf 2.0.23 laufen noch ein paar Anwendungen, 1.2.11 ist
für meinen Mailserver und 2.1.2 wird nicht mehr genutzt.
ein update auf eine andere 2.0.x Version halte ich nicht für
sinnvoll. Wenn du unbedingt aufrüsten möchtest, dann 2.1.3. Die
Version 2.1.4 scheint bei einigen Leuten Probleme zu bringen. Aber ich
warne dich, ein update kann Probleme bringen, wenn die Datensätze
nicht RFC konform sind. Ein simples slapcat zur Erzeugung eines *.ldif
und dann ein ldapadd auf 2.1.x kann katastrophal werden. Nicht das das
Problem unlösbar wäre, aber vermutlich verwendest du unwissentlich
inkompatible objectclasses in einem Datensatz, hast bei der
ursprünglichen Erstellung des Datensatzes am Ende eines Strings kein
CR durchgeführt, oder ähnliches.
Wenn du updatest, solltest du auch Berkeley DB Version 4.x verwenden,
am besten auch gleich cyrus-sasl-2.1.x, wie sieht es mit Kerberos aus?
PAM könnte auch die neuste Version vertragen :-)
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu
formulieren, daß auch gefunden wird, was du suchst.
Dank fuer euer Feedback und euren Langmut,
Ich freu mich immer noch auf feedback,
Ich spreche jetzt mal für Harry mit, denn ich glaube er wird meine
Worte unterstützen :-)
Wir freuen uns über jeden Aspiranten, der sich OpenLDAP zuwendet und
versuchen ihn im Rahmen unseres Wissens und unserer Freizeit (manchmal
auch darüber hinaus) zu unterstützen.
(das war das Wort zum Sonntag :-))
-Dieter
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter@xxxxxxxxxxxxxxxx
http://www.schevolution.com/tour
| < Previous | Next > |