Newbie: Update von openldap2-2.0.12-33 auf suse7.3?
Tach zusammen, Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen. Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest. Bisher habe ich versucht, den Server nur mit Suse-rpms zu beaufschlagen, im Glauben, das System damit wartbarer und fuer andere nachvollziehbar zu halten - das Problem ist, dass es fuer die 7.3 von Suse keine neuere Version von openldap gibt. Welcher der folgenden Wege (oder ein ganz anderer?) waere nu der schlaueste fuer mich: - Sourcen von openldap.org/mirror runterladen, Pfade auf Suse anpassen, Dreisatz, fertig? Wie update ich dann ein solches System auf Dauer - immer so? - Gibt es in den Tiefen des Suse-ftp-Servers ein Verzeichnis, in dem einer der Mitarbeiter (wie bei Samba) neuere Versionen von openldap als rpm liegen hat, und google findet sie nicht? :) - Koennten die rpms der 8.0 fuer die 7.3 funktionieren, wenn man das db-4-paket installiert (bei mir tut es jedenfalls nicht...)? - Was ganz anderes, naemlich [fill in here, please]. Dank im Voraus fuer die Antworten und Muehe, Gruss aus Weimar, tobi... :) -- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hi,
Tach zusammen,
Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen.
Was meinst du damit ?
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Der 2.1.x-Zweig ist in manchen Dingen noch restriktiver als der 2.0.x-Zweig, gerade was Leerzeichen in dn's angeht.
Bisher habe ich versucht, den Server nur mit Suse-rpms zu beaufschlagen, im Glauben, das System damit wartbarer und fuer andere nachvollziehbar zu halten - das Problem ist, dass es fuer die 7.3 von Suse keine neuere Version von openldap gibt. Welcher der folgenden Wege (oder ein ganz anderer?) waere nu der schlaueste fuer mich:
Gute Frage.
- Sourcen von openldap.org/mirror runterladen, Pfade auf Suse anpassen, Dreisatz, fertig? Wie update ich dann ein solches System auf Dauer - immer so?
Macht an sich nix kaputt, dann ist halt nur die rpm-Dartenbank unvollständig.
- Gibt es in den Tiefen des Suse-ftp-Servers ein Verzeichnis, in dem einer
der Mitarbeiter (wie bei Samba) neuere Versionen von openldap als rpm liegen hat, und google findet sie nicht? :)
Weiß ich nicht.
- Koennten die rpms der 8.0 fuer die 7.3 funktionieren, wenn man das db-4-paket installiert (bei mir tut es jedenfalls nicht...)?
db4/sasl/kerberos muß/kann natürlich bei Bedarf installiert werden. db4 ist glaube ich nicht kompatibel zu db3 !!!
- Was ganz anderes, naemlich [fill in here, please].
FILLIN : Ist das bei dir ein Produktionssystem ? Wenn du Zeit hast, dann mach folgendes : Sichere das directory als ldif, hole dir die sourcen von openldap. 2.1.x würde ich für die Produktion noch nicht empfehlen, 2.0.25 wäre ein gutes update. Nachdem du dir die Konfigurationsdatein gesichert hast, kannst du die alte Version deinstallieren. Die Installationspfade kannst du dir zb im yast -> Pakete (de)installieren->info (F2) angucken. Dann configure entprechend starten make/make install (siehe README) und dann einfach versuchen mit den alten Konfigurationsdateien zu starten. Wenns nix ist, logfiles betrachten, Fehler beheben, sollte eigentlich gehen. Dann den ldif-File für ldapadd verwenden, um das gesicherte Directory wieder ins ldap zu bringen. Fertig
Gruss aus Weimar, tobi... :)
Gruß Harry -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Rehi Harry, At 15:16 03.09.2002, you wrote:
Hi,
Tach zusammen,
Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen.
Was meinst du damit ?
Aus meiner mail an die openldap-Liste - es geht um eine kommerzielle Applikation, die per LDAP authentifizieren will, und dabei auch die Teilnehmerschaft eines Users bei einer Gruppe prueft: [output from starting using /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255] [...] filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)) [...] Please notice the leading space before "dc=medien,dc=..." This leads to the fact that an entry like the following is not found, since there is no such space before dc=medien,...: dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de gidNumber: 1000 memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup cn: CMS Administrator
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Der 2.1.x-Zweig ist in manchen Dingen noch restriktiver als der 2.0.x-Zweig, gerade was Leerzeichen in dn's angeht.
So habe ich es gelesen, auf mein gepostetes Beispiel hin kam aber zweimal explizit der hint aufs update...
Bisher habe ich versucht, den Server nur mit Suse-rpms zu beaufschlagen, im Glauben, das System damit wartbarer und fuer andere nachvollziehbar zu halten - das Problem ist, dass es fuer die 7.3 von Suse keine neuere Version von openldap gibt. Welcher der folgenden Wege (oder ein ganz anderer?) waere nu der schlaueste fuer mich:
Gute Frage.
:)
- Sourcen von openldap.org/mirror runterladen, Pfade auf Suse anpassen, Dreisatz, fertig? Wie update ich dann ein solches System auf Dauer - immer so?
Macht an sich nix kaputt, dann ist halt nur die rpm-Dartenbank unvollständig.
ack - was ich, wie erwaehnt, nicht so prickelnd faende...
- Gibt es in den Tiefen des Suse-ftp-Servers ein Verzeichnis, in dem einer
der Mitarbeiter (wie bei Samba) neuere Versionen von openldap als rpm liegen hat, und google findet sie nicht? :)
Weiß ich nicht.
- Koennten die rpms der 8.0 fuer die 7.3 funktionieren, wenn man das db-4-paket installiert (bei mir tut es jedenfalls nicht...)?
db4/sasl/kerberos muß/kann natürlich bei Bedarf installiert werden. db4 ist glaube ich nicht kompatibel zu db3 !!!
was evtl. nochmal einen Test hier wert waere... Gibt es denn einen prinzipielle Aussage, ob 8.0er rpms auf einem 7.3er System laufen/laufen koennen? Was sind da die entscheidenden Punkte?
- Was ganz anderes, naemlich [fill in here, please].
FILLIN :
Ist das bei dir ein Produktionssystem ?
Sollte es sein - ich versuch' halt so gut ich kann, meine Ansprueche an ein Produktionssystem zu erfuellen... :)
Wenn du Zeit hast, dann mach folgendes :
Sichere das directory als ldif, hole dir die sourcen von openldap. 2.1.x würde ich für die Produktion noch nicht empfehlen, 2.0.25 wäre ein gutes update.
Nachdem du dir die Konfigurationsdatein gesichert hast, kannst du die alte Version deinstallieren. Die Installationspfade kannst du dir zb im yast -> Pakete (de)installieren->info (F2) angucken. Dann configure entprechend starten make/make install (siehe README) und dann einfach versuchen mit den alten Konfigurationsdateien zu starten.
ok, werde ich auf meinem Test-System so machen.
Wenns nix ist, logfiles betrachten, Fehler beheben, sollte eigentlich gehen.
:)
Dann den ldif-File für ldapadd verwenden, um das gesicherte Directory wieder ins ldap zu bringen. Fertig
yep. Dank fuer Input! Noch weitere comments, anybody? Gruss, tobi... :) -- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Rehihi Tobias/Liste,
Rehi Harry,
At 15:16 03.09.2002, you wrote:
Hi,
Tach zusammen,
Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen.
Was meinst du damit ?
Aus meiner mail an die openldap-Liste - es geht um eine kommerzielle Applikation, die per LDAP authentifizieren will, und dabei auch die Teilnehmerschaft eines Users bei einer Gruppe prueft:
[output from starting using /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255]
[...] filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de) ) [...]
Please notice the leading space before "dc=medien,dc=..."
This leads to the fact that an entry like the following is not found, since
there is no such space before dc=medien,...:
dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de Hier sind doch die spaces ^ ^ oder etwa nicht ?
gidNumber: 1000 memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup cn: CMS Administrator
Also, so wie ich das sehe, sind zwei Leerzeichen in der dn, wo sie aber NICHT hingehören !!!
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Das glaube ich nicht.
Der 2.1.x-Zweig ist in manchen Dingen noch restriktiver als der 2.0.x-Zweig, gerade was Leerzeichen in dn's angeht.
So habe ich es gelesen, auf mein gepostetes Beispiel hin kam aber zweimal explizit der hint aufs update...
2.1.x wird dir da nicht weiterhelfen, entferne die Spaces aus dem/den directory-Einträgen ...
Bisher habe ich versucht, den Server nur mit Suse-rpms zu
beaufschlagen,
im Glauben, das System damit wartbarer und fuer andere nachvollziehbar zu halten - das Problem ist, dass es fuer die 7.3 von Suse keine neuere Version von openldap gibt. Welcher der folgenden Wege (oder ein ganz anderer?) waere nu der schlaueste fuer mich:
Gute Frage.
:)
- Sourcen von openldap.org/mirror runterladen, Pfade auf Suse anpassen, Dreisatz, fertig? Wie update ich dann ein solches System auf Dauer - immer so?
Macht an sich nix kaputt, dann ist halt nur die rpm-Dartenbank unvollständig.
ack - was ich, wie erwaehnt, nicht so prickelnd faende...
Du kannst auch aus dem compilierten sourcen ein rpm erzeugen, da gibt's ein tool, das heißt checkinstall ...
- Gibt es in den Tiefen des Suse-ftp-Servers ein Verzeichnis, in dem einer
der Mitarbeiter (wie bei Samba) neuere Versionen von openldap als rpm liegen hat, und google findet sie nicht? :)
Weiß ich nicht.
- Koennten die rpms der 8.0 fuer die 7.3 funktionieren, wenn man das db-4-paket installiert (bei mir tut es jedenfalls nicht...)?
db4/sasl/kerberos muß/kann natürlich bei Bedarf installiert werden. db4 ist glaube ich nicht kompatibel zu db3 !!!
was evtl. nochmal einen Test hier wert waere...
Gibt es denn einen prinzipielle Aussage, ob 8.0er rpms auf einem 7.3er System laufen/laufen koennen? Was sind da die entscheidenden Punkte?
- Was ganz anderes, naemlich [fill in here, please].
FILLIN :
Ist das bei dir ein Produktionssystem ?
Sollte es sein - ich versuch' halt so gut ich kann, meine Ansprueche an ein Produktionssystem zu erfuellen... :)
Wenn du Zeit hast, dann mach folgendes :
Sichere das directory als ldif, hole dir die sourcen von openldap. 2.1.x würde ich für die Produktion noch nicht empfehlen, 2.0.25 wäre ein gutes update.
Nachdem du dir die Konfigurationsdatein gesichert hast, kannst du die alte Version deinstallieren. Die Installationspfade kannst du dir zb im yast -> Pakete (de)installieren->info (F2) angucken. Dann configure entprechend starten make/make install (siehe README) und dann einfach versuchen mit den alten Konfigurationsdateien zu starten.
ok, werde ich auf meinem Test-System so machen.
Wenns nix ist, logfiles betrachten, Fehler beheben, sollte eigentlich gehen.
:)
Dann den ldif-File für ldapadd verwenden, um das gesicherte Directory wieder ins ldap zu bringen. Fertig
yep. Dank fuer Input! Noch weitere comments, anybody?
Ich habe das mit den Leerzeichen immer noch nicht verstanden. Sendet denn der Client die Anfrage mit den "fehlerhaften" Leerzeichen in der dn ? Oder sind die nur/auch in deinem directory ?
Gruss, tobi... :)
Gruß Harry PS.: Sorry, wenns total zerupft aussieht, aber ich kann zur Zeit nur aus dem gmx-Webinterface mailen ... -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
hei all, :) At 16:01 03.09.2002, you wrote:
Rehihi Tobias/Liste,
Rehi Harry, At 15:16 03.09.2002, you wrote:
Hi,
Tach zusammen, Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen.
Was meinst du damit ?
Aus meiner mail an die openldap-Liste - es geht um eine kommerzielle Applikation, die per LDAP authentifizieren will, und dabei auch die Teilnehmerschaft eines Users bei einer Gruppe prueft:
[output from starting using /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255]
[...] filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de) ) [...]
Please notice the leading space before "dc=medien,dc=..."
This leads to the fact that an entry like the following is not found, since
there is no such space before dc=medien,...:
dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de Hier sind doch die spaces ^ ^ oder etwa nicht ?
Jetzt wirds interessant - darauf hatte ich noch garnicht geachtet: Das obige ist copy-paste aus einem ldif, das von LDAP Browser\Editor v.2.8.2 erstellt wurde, das folgende ein copy-paste aus einem Terminal, in dem ich einfach mal "ldapsearch -x" eingab: ... # CMS Administrator, Groups, medien, uni-weimar, de dn: cn=CMS Administrator,ou=Groups,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup gidNumber: 1000 cn: CMS Administrator memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de ... Ergo: im dn aus dem ldif stehts mit space, hier ohne. What gives? :) Der springende Punkt ist aber imho, dass nach folgendem Eintrag gesucht wird
memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de
weil der Filter ja so aussieht (copy von oben):
filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)
und dieser ist wiederum copy-paste aus Terminal mit debug-level 255... Will meinen, er sucht nicht nach dem dn, sondern nach dem dn, der posixGroup ist und den memberUid-Eintrag hat - oder?
objectClass: posixGroup cn: CMS Administrator
Also, so wie ich das sehe, sind zwei Leerzeichen in der dn, wo sie aber NICHT hingehören !!!
Dem ist moeglich, vielleicht sind die aber da auch garnicht wirklich, sondern bloss von dem Browser beim Export reingehauen worden - sorry, hatte ich nicht drauf geachtet...
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Das glaube ich nicht.
Haelst Du es jetzt fuer moeglich?
Der 2.1.x-Zweig ist in manchen Dingen noch restriktiver als der 2.0.x-Zweig, gerade was Leerzeichen in dn's angeht.
So habe ich es gelesen, auf mein gepostetes Beispiel hin kam aber zweimal explizit der hint aufs update...
2.1.x wird dir da nicht weiterhelfen, entferne die Spaces aus dem/den directory-Einträgen ...
S.o.: Der relevante Eintrag scheint mir der der memberUid, und der ist, sowohl im Browser als auch im Terminal, gleich - ohne Spaces. Wenn ich die Spaces (per Browser) setze, wird der Eintrag gefunden, und der User als der Gruppe zugehoerig deklariert, was Ziel der Uebung war. [...]
Macht an sich nix kaputt, dann ist halt nur die rpm-Dartenbank unvollständig.
ack - was ich, wie erwaehnt, nicht so prickelnd faende...
Du kannst auch aus dem compilierten sourcen ein rpm erzeugen, da gibt's ein tool, das heißt checkinstall ...
Ich las erst gestern davon - sollte ich mir wohl mal genauer anschauen. Dank fuer Hinweis! :) [...]
yep. Dank fuer Input! Noch weitere comments, anybody?
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. Dank fuer Info bisher, Gruss, tobi... :) -- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo,
Tobias Hofmann
hei all, :)
At 16:01 03.09.2002, you wrote:
Rehihi Tobias/Liste,
Rehi Harry, At 15:16 03.09.2002, you wrote: [...] dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de Hier sind doch die spaces ^ ^ oder etwa nicht ?
Jetzt wirds interessant - darauf hatte ich noch garnicht geachtet: Das obige ist copy-paste aus einem ldif, das von LDAP Browser\Editor
Ich traue diesen Drittprodukten nicht immer über den Weg :-) erstelle mal mittels slapcat eine ldif Datei des gesamten Inhaltes. slapcat -l /tmp/test.ldif sollte da helfen.
v.2.8.2 erstellt wurde, das folgende ein copy-paste aus einem Terminal, in dem ich einfach mal "ldapsearch -x" eingab:
... # CMS Administrator, Groups, medien, uni-weimar, de dn: cn=CMS Administrator,ou=Groups,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup gidNumber: 1000 cn: CMS Administrator memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de ...
Ergo: im dn aus dem ldif stehts mit space, hier ohne. What gives? :)
Nix, kein schulterzuckendes was soll's. Zwischen den Ausgaben von ldapsearch und einer *.ldif Datei liegen Welten. Eine ldif Datei gibt den Inhalt der Datenbank wider, ldapsearch das Suchergebnis einer Anfrage eines Clients.
Der springende Punkt ist aber imho, dass nach folgendem Eintrag gesucht wird
memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de
weil der Filter ja so aussieht (copy von oben):
filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)
und dieser ist wiederum copy-paste aus Terminal mit debug-level 255...
Will meinen, er sucht nicht nach dem dn, sondern nach dem dn, der posixGroup ist und den memberUid-Eintrag hat - oder?
Das ist jetzt alles etwas zerfleddert, woher kommt der Eintrag #line-break by me Was läuft mit debug-level 255, ist das slapd oder ldapsearch? Für slapd gibt es keinen debug level 255. Um die Ausgabe der filter zu debuggen, sollte der level -d 32 gesetzt werden. Was und wie gesucht wird, ist abhängig von den Indices, die Angabe der index Werte aus slapd.conf sollte hier hinweise liefern.
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Das glaube ich nicht.
Haelst Du es jetzt fuer moeglich?
Das ist einer den wenigen Punkte in denen ich nicht mit Harry übereinstimme :-) OpenLDAP-2.1 ist genauso für eine Produktionsumgebung geeignet wie die Version 2.0. Alle Releases gelten als STABLE, nur das CVS HEAD ist unstable. Ich glaube aber, ebenso wie Harry, daß dir OpenLDAP-2.1.x nicht bei deinem Problem helfen wird. Eher wird das Gegenteil der Fall sein. In den aktuellen Versionen findet eine stringentere Prüfung des syntaktischen Aufbaus und der Schema statt. Die Versionen 2.0 lassen vielfach noch fünf gerade sein. [...]
entferne die Spaces aus dem/den directory-Einträgen ...
S.o.: Der relevante Eintrag scheint mir der der memberUid, und der ist, sowohl im Browser als auch im Terminal, gleich - ohne Spaces.
Wie schon dargelegt, die Ausgabe von Clients muß nicht dem tatsächlichen Dateneintrag entsprechen, auch Clients sind fehlertolerant.
Wenn ich die Spaces (per Browser) setze, wird der Eintrag gefunden, und der User als der Gruppe zugehoerig deklariert, was Ziel der Uebung war.
Wie gesagt, das besagt nicht viel. [...]
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.
Für das LDIF Format ist ja auch RFC 2849 zuständig. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hi Liste,Dieter,Tobi,
Hallo,
Tobias Hofmann
writes: hei all, :)
At 16:01 03.09.2002, you wrote:
Rehihi Tobias/Liste,
Rehi Harry, At 15:16 03.09.2002, you wrote: [...] dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de Hier sind doch die spaces ^ ^ oder etwa nicht ?
Jetzt wirds interessant - darauf hatte ich noch garnicht geachtet: Das obige ist copy-paste aus einem ldif, das von LDAP Browser\Editor
Ich traue diesen Drittprodukten nicht immer über den Weg :-) erstelle mal mittels slapcat eine ldif Datei des gesamten Inhaltes. slapcat -l /tmp/test.ldif sollte da helfen.
Joo, das dürfte wohl das Bestes sein :o)
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Das glaube ich nicht.
Haelst Du es jetzt fuer moeglich?
Das ist einer den wenigen Punkte in denen ich nicht mit Harry übereinstimme :-) OpenLDAP-2.1 ist genauso für eine Produktionsumgebung geeignet wie die Version 2.0. Alle Releases gelten als STABLE, nur das CVS HEAD ist unstable.
Ja Dieter,danke für die Blumen :o) Natürlich ist das stable, aber wenn man bisher auf 2.0.x gesetzt hat und zum Beispiel pam_ldap/nss_ldap verwendet ist ein Umstieg auf 2.1.x imho nicht möglich, da sich das zumindest nicht compilieren läßt. Ob man mit einem bereits compiliertem pam_ldap/nss_ldap und 2.1.x was anfangen kann weiß ich nicht. Es wird noch einige ldapabhängige Programme/Module/libraries geben, die nur für 2.0.x angepasst sind und deshalb würde ich einen Umstieg zur Zeiot nicht empfehlen.
Ich glaube aber, ebenso wie Harry, daß dir OpenLDAP-2.1.x nicht bei deinem Problem helfen wird. Eher wird das Gegenteil der Fall sein. In den aktuellen Versionen findet eine stringentere Prüfung des syntaktischen Aufbaus und der Schema statt. Die Versionen 2.0 lassen vielfach noch fünf gerade sein.
ACK.
[...]
entferne die Spaces aus dem/den directory-Einträgen ...
ACK.
-Dieter
Gruß Harry PS.: Dieter, wenn du mitliest, was macht samba ? -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Rehi all, At 09:27 04.09.2002, you wrote:
Hi Liste,Dieter,Tobi,
Hallo, Tobias Hofmann
writes: hei all, :) At 16:01 03.09.2002, you wrote:
Rehihi Tobias/Liste,
Rehi Harry, At 15:16 03.09.2002, you wrote: [...]
[...]
Das ist einer den wenigen Punkte in denen ich nicht mit Harry übereinstimme :-) OpenLDAP-2.1 ist genauso für eine Produktionsumgebung geeignet wie die Version 2.0. Alle Releases gelten als STABLE, nur das CVS HEAD ist unstable.
Ja Dieter,danke für die Blumen :o) Natürlich ist das stable, aber wenn man bisher auf 2.0.x gesetzt hat und zum Beispiel pam_ldap/nss_ldap verwendet ist ein Umstieg auf 2.1.x imho nicht möglich, da sich das zumindest nicht compilieren läßt.
Hrmpf. Dank fuer die Warnung - genau diese Kombi kommt hier zum Einsatz. Gibts da naehere Infos zu? Ich hatte beim Googeln und in der Openldap-Mailingliste nix dazu gesehen...
Ob man mit einem bereits compiliertem pam_ldap/nss_ldap und 2.1.x was anfangen kann weiß ich nicht.
Es wird noch einige ldapabhängige Programme/Module/libraries geben, die nur für 2.0.x angepasst sind und deshalb würde ich einen Umstieg zur Zeiot nicht empfehlen.
Dann werde ich wohl eher bei der 2.0.x bleiben...
Ich glaube aber, ebenso wie Harry, daß dir OpenLDAP-2.1.x nicht bei deinem Problem helfen wird. Eher wird das Gegenteil der Fall sein. In den aktuellen Versionen findet eine stringentere Prüfung des syntaktischen Aufbaus und der Schema statt. Die Versionen 2.0 lassen vielfach noch fünf gerade sein.
ACK.
[...]
entferne die Spaces aus dem/den directory-Einträgen ...
Hm. Nachdem (wie in der letzten Mail beschrieben) das Entfernen der Spaces nix brachte, werde ich das wohl mal mit einer 2.0.x probieren...
ACK.
-Dieter
Gruß Harry
PS.: Dieter, wenn du mitliest, was macht samba ?
Wenn damit Samba+LDAP gemeint sein sollte - hier laeuft es - howto ist gerade am werden, bei Interesse. Wenn nicht, dann will ich mich da nicht einmischen... :) Dank fuer Input, Gruss, tobi... :)
-- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo zusammen, sorry, das hier wird laenger: At 08:37 04.09.2002, you wrote:
Hallo,
Tobias Hofmann
writes: hei all, :)
At 16:01 03.09.2002, you wrote:
Rehihi Tobias/Liste,
Rehi Harry, At 15:16 03.09.2002, you wrote: [...] dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de Hier sind doch die spaces ^ ^ oder etwa nicht ?
Jetzt wirds interessant - darauf hatte ich noch garnicht geachtet: Das obige ist copy-paste aus einem ldif, das von LDAP Browser\Editor
Ich traue diesen Drittprodukten nicht immer über den Weg :-)
Gut, dann fange ich jetzt auch damit an... :)
erstelle mal mittels slapcat eine ldif Datei des gesamten Inhaltes. slapcat -l /tmp/test.ldif sollte da helfen.
Hat es. Dort werden die Leerzeichen angezeigt, also gehe ich weiterhin davon aus, dass in meinem LDAP-Verzeichnis welche drinstehen, bis ich sie herausnehme. Weiter:
v.2.8.2 erstellt wurde, das folgende ein copy-paste aus einem Terminal, in dem ich einfach mal "ldapsearch -x" eingab:
... # CMS Administrator, Groups, medien, uni-weimar, de dn: cn=CMS Administrator,ou=Groups,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup gidNumber: 1000 cn: CMS Administrator memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de ...
Ergo: im dn aus dem ldif stehts mit space, hier ohne. What gives? :)
Nix, kein schulterzuckendes was soll's.
Sorry, so war das nicht gemeint. Was ich meinte, war sinngemaess "Wer gewinnt/hat recht?".
Zwischen den Ausgaben von ldapsearch und einer *.ldif Datei liegen Welten.
Das sehe ich langsam...
Eine ldif Datei gibt den Inhalt der Datenbank wider, ldapsearch das Suchergebnis einer Anfrage eines Clients.
Ok, gekauft.
Der springende Punkt ist aber imho, dass nach folgendem Eintrag gesucht wird
memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de
weil der Filter ja so aussieht (copy von oben):
filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)
und dieser ist wiederum copy-paste aus Terminal mit debug-level 255...
Will meinen, er sucht nicht nach dem dn, sondern nach dem dn, der posixGroup ist und den memberUid-Eintrag hat - oder?
Das ist jetzt alles etwas zerfleddert, woher kommt der Eintrag #line-break by me
Der kommt von mir, das sah im Umbruch mehrdeutig aus - ich hatte gehofft, damit zu klaeren...
Was läuft mit debug-level 255, ist das slapd oder ldapsearch? Für slapd gibt es keinen debug level 255.
hm. man slapd sagt bei mir unter examples: "To start slapd with an alternate configuration file, and turn on voluminous debugging which will be printed on standard error, type: /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255" Das ist aus: OpenLDAP 2.0.12-Release 5 Novemeber 2000 SLAPD(8C)
Um die Ausgabe der filter zu debuggen, sollte der level -d 32 gesetzt werden.
Hm, wenn ich das aber so starte, spuckt er mir keine filter aus, wohingegen ich bei -d 255 folgendes finde: ... end get_filter 0 filter: (&(objectClass=posixGroup)(memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)) ... (Die Zeile, die mit "filter:" beginnt, wird von meinem mailer umgebrochen, wodurch der Blank vor dem dc=medien nicht mehr ersichtlich ist. Im Terminal steht das auf einer Zeile, mit Blank vor dem dc=medien...).
Was und wie gesucht wird, ist abhängig von den Indices, die Angabe der index Werte aus slapd.conf sollte hier hinweise liefern.
hier isses: ---------------------- # Indices to maintain index objectClass eq ## support pb_getsampwnam() index uid pres,eq ## support pdb_getsambapwrid() index rid eq ## uncomment these if you are storing posixAccount and ## posixGroup entries in the directory as well index uidNumber eq index gidNumber eq index cn eq index memberUid eq ----------------------
Bei openldap-software@OpenLDAP.org empfiehlt man mir ein update auf 2.1.x, damit seien diese meine Probleme geloest.
Das glaube ich nicht.
Haelst Du es jetzt fuer moeglich?
Das ist einer den wenigen Punkte in denen ich nicht mit Harry übereinstimme :-)
:)
OpenLDAP-2.1 ist genauso für eine Produktionsumgebung geeignet wie die Version 2.0. Alle Releases gelten als STABLE, nur das CVS HEAD ist unstable.
So hatte ich das, was ich auf der openldap-mailinliste gelesen hatte, interpretiert...
Ich glaube aber, ebenso wie Harry, daß dir OpenLDAP-2.1.x nicht bei deinem Problem helfen wird. Eher wird das Gegenteil der Fall sein. In den aktuellen Versionen findet eine stringentere Prüfung des syntaktischen Aufbaus und der Schema statt. Die Versionen 2.0 lassen vielfach noch fünf gerade sein.
[...]
entferne die Spaces aus dem/den directory-Einträgen ...
S.o.: Der relevante Eintrag scheint mir der der memberUid, und der ist, sowohl im Browser als auch im Terminal, gleich - ohne Spaces.
Wie schon dargelegt, die Ausgabe von Clients muß nicht dem tatsächlichen Dateneintrag entsprechen, auch Clients sind fehlertolerant.
ok, nachvollziehbar.
Wenn ich die Spaces (per Browser) setze, wird der Eintrag gefunden, und der User als der Gruppe zugehoerig deklariert, was Ziel der Uebung war.
Wie gesagt, das besagt nicht viel.
hm, jetzt doch? :) 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))" 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 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.
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... 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? 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... :). 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? Dank fuer euer Feedback und euren Langmut, Ich freu mich immer noch auf feedback, Gruss, tobi... :)
-Dieter
-- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo,
Tobias Hofmann
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@schevolution.com http://www.schevolution.com/tour
Hi Liste, hi Dieter, hi Tobias ist schon spät, aber die mail muß jetzt noch beantwortet werden :o) Erstmal gehe ich konform mit dem, was Dieter in der letzten mail geschrieben hat und werde nur (da müde) das nötigste kommentieren. Dieter Kluenter wrote:
Hallo,
Tobias Hofmann
writes: Ich werde jetzt mal radikal streichen, damit wir den Zusammenhang weiterhin erkennen können. Zum Thema Debugging Werte schreibe ich eine gesonderte Mail [...]
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)
Abgesehen von der RFC gibt es meiner Meinung nach auch keinen vernünftigen Grund in der dn mit SPACES etwas zu formatieren, jedenfalls nicht vor oder nach dem Komma. Wenn man sie wegläßt ist auch einfach eine Fehlerquelle beseitigt, denn kein Server/Client muß sie ignorieren/interpretieren.
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.
Ack.
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?
Immer selber bauen, ist jedenfalls meine Meinung. Da weiß man exakt was man hat, wenn man weiß was man macht (und weiß, was man will).
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 :-)
Ich schließe mich Dieter an, allerdings würde ich trotzdem auf dem Produktionsystem auf 2.0.25 (2.0.26 steht laut H. Chu von openldap vor der Tür) updaten, um eine bugbereinigte 2.0.x am laufen zu haben. Parallel würde ich dann versuchen langsam (auf einem Testrechner) auf 2.1.x (x >= 3) zu migrieren ...
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Selbstverständlich !
Dank fuer euer Feedback und euren Langmut,
Was ist denn Langmut ??? Hier gabs schon echte Nervensägen, soweit bist du noch lange nicht ;o)
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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Der war für mich, aber nicht petzen Dieter :o)
(das war das Wort zum Sonntag :-))
Ja Dieter, da sind wir wohl ein Herz und eine Seele, full ack und amen .....
-Dieter
Gruß Harry
Hallo zusammen, At 00:28 05.09.2002, you wrote:
[...]
Dieter Kluenter wrote:
Hallo,
Tobias Hofmann
writes:
[Dieters Anmerkungen]
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)
Abgesehen von der RFC gibt es meiner Meinung nach auch keinen vernünftigen Grund in der dn mit SPACES etwas zu formatieren, jedenfalls nicht vor oder nach dem Komma.
Nachvollziehbar. Ich hab' damit ja auch nicht angefangen... :*)
Wenn man sie wegläßt ist auch einfach eine Fehlerquelle beseitigt, denn kein Server/Client muß sie ignorieren/interpretieren.
ack.
Um das zum Ende zu bringen:
[Blanks einfuegen schlecht - alle ack.]
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?
Immer selber bauen, ist jedenfalls meine Meinung. Da weiß man exakt was man hat, wenn man weiß was man macht (und weiß, was man will).
:) Beisst sich halt noch ein wenig mit der hier herrschenden Idee, dass rpms die Wartbarkeit eines Systemes erhoehen koennen...
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 :-)
Ich schließe mich Dieter an, allerdings würde ich trotzdem auf dem Produktionsystem auf 2.0.25 (2.0.26 steht laut H. Chu von openldap vor der Tür) updaten, um eine bugbereinigte 2.0.x am laufen zu haben. Parallel würde ich dann versuchen langsam (auf einem Testrechner) auf 2.1.x (x >= 3) zu migrieren ...
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Selbstverständlich !
Siehe letzte Mail von mir - ich kann an dem Suchstring nicht viel aendern, teste aber in der Richtung auch noch weiter - Feedback von mir dazu, sobald ich was habe (Wird etwas dauern - im Freundeskreis heiraten die Doedel immer dann, wenn man ein Wochende zum Spielen braucht...).
Dank fuer euer Feedback und euren Langmut,
Was ist denn Langmut ??? Hier gabs schon echte Nervensägen, soweit bist du noch lange nicht ;o)
:) Dann mal schauen, wie lange ich dafuer brauche... ;*) Gruss, tobi.... :) -- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo,
Dieter Kluenter
Hallo,
Tobias Hofmann
writes:
Jetzt bin ich wieder fit für weitere Ergüsse. [...9
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Nachdem wir ja nun festegestellt habem daß dein Suchstring der Übeltäter ist, und nicht der Eintrag im DIT versuche mal folgenden Suchstring ldapsearch -x -b ou=users,dc=medien,dc=uni-weimar,dc=de -s sub \n "objectclass=posixgroup" Zur Information, hier wurde ein Zeilenumbruch gemacht, der ganze Suchstring solle natürlich in einer Zeile sein, ohne \n. Jetzt sollten dir alle Datensätze, die die objectClass prosixGroup enthalten, ausgewiesen werden. Ich nehme an, dies ist das was du suchst. Wenn nicht,müssen wir den Suchstring noch verfeinern. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo Dieter, Harry, Liste, At 22:11 04.09.2002, you wrote:
Hallo, Tobias Hofmann
writes: Ich werde jetzt mal radikal streichen, damit wir den Zusammenhang weiterhin erkennen können.
Gut, Danke... :)
Zum Thema Debugging Werte schreibe ich eine gesonderte Mail
Antwort darauf schon 'raus...
[...]
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
ok...
Dein Suchstring wird nur als Filter erkannt,
aehm - im Gegensatz wozu? Sind die Begriffe "Suchstring" und "Filter" nicht synonym?
die Base wird auf default gesetzt, was vermutlich (dc=medien,dc=uni-weimar,dc=de) ist,
ack.
scope wird ebenfalls auf Default gesetzt, das ist sub.
ack.
Warum bei dir ein SPACE einen Unterschied macht, kann ich nicht nachvollziehen.
Welcome to the club... :) SCNR...
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))"
Der String kam bei mir an wie (hoffentlich) oben gequotet - sollte das nicht heissen "...,ou=Partner,"? Nur zur Sicherheit... Ah, im Filter stehts richtig, also gehe ich davon aus, dass es stimmt.
# 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))"
...also auch hier wieder der Blank vor der Search Base...
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.
ok...
Die Meldung 'equality candidates: index_param failed' sagt, daß der Index für objectclass eq verlangt
Bloede Frage: von wem oder was verlangt?
und dafür keine Indexparameter vorhanden sind. Aber ich nutze auch die objectclass posixGroup. Das ist noch keine Wertung, erst einmal eine Feststellung.
ok.
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?
Moeglich. Ein Telefonat mit dem Clienthersteller letzte Woche ergab, dass (IIRC) AD unterstuetzt, ansonsten fuer LDAP iPlanet und Qualcomm "empfohlen" seien. Ich war zu dem Zeitpunkt, als wir uns hier fuer OpenLDAP entschieden hatten, davon ausgegangen, dass OpenLDAP sowieso alles und "viel besser" koenne... :) Deswegen hatte ich mich um iPlanet nicht weiter gekuemmert und nach einer Testinstallation von Eudoras Server an einem anderen Fachbereich bei uns die Finger gelassen...
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.
ok.
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)
ok.
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.
aua. ok.
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.
ok, nachvollzogen. Dank fuer Input! :)
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.
ack.
Ich denke, dann kann eine sinnvolle und systemkonforme Lösusng gefunden werden. Harry und ich werden dir mit Rat und Tat zur Seite stehen.
Dank! :)
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.
Dazu zwei Quotes von http://www.OpenLDAP.org/lists/openldap-software/
From: "Pierangelo Masarati"
the point is that dn matching and so in OpenLDAP has always been made against "naively" normalized DNs until 2.1
Update to Openldap 2.1.x .-) ...
Wenn du unbedingt aufrüsten möchtest, dann 2.1.3. Die Version 2.1.4 scheint bei einigen Leuten Probleme zu bringen.
Dann waere das, unter Beruecksichtigung von Quote 2, der Weg... hm.
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.
Na Klasse... :)
Wenn du updatest, solltest du auch Berkeley DB Version 4.x verwenden,
jau, so hatte ich das schon gelesen... Und wenn sich das mit DB3 beisst, wie in diesem Thread frueher vermutet wurde, an DB3 aber ne ganze Menge Pakete dranhaengen, was mache ich dann?
am besten auch gleich cyrus-sasl-2.1.x, wie sieht es mit Kerberos aus?
noch nicht... :)
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.
Was ich ja, da ich den Client nur ueber den Dialog, in dem ich die jeweiligen Werte eintrage, "konfigurieren" kann, nicht ganz in meiner Hand habe...
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.
Die Art und Weise, wie Ihr das macht, gereicht Euch zu Ruhm und Ehre, und wird von mir hoch geschaetzt! :)
(das war das Wort zum Sonntag :-))
Wenn mir das nur immer so gut reinlaufen wuerde... :) Ok, ernsthaft: - Du kannst meinen Testfall, der bei mir tut, bei Dir nicht nachvollziehen - korrekt? - Wuerde es Sinn machen, Dir meine Schemata und ein LDIF meiner Gruppe sowie meines Users per PM/http zukommen zu lassen, um zu schauen, ob es dann (wie bei mir) tut? - Ich werde mich etwas eingraben und versuchen, hier ein 2.1.3/4 System auf meiner Testkiste zum Laufen zu bekommen, und dann werden wir alle sehen, ob und wenn ja, wie es laeuft. Schlauer Ansatz? Mehr faellt mir im Moment nicht ein, Replies auf Eure anderen Mail kommen gleich, Dank und Gruss, tobi... :)
-Dieter
-- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo,
Tobias Hofmann
Hallo Dieter, Harry, Liste,
At 22:11 04.09.2002, you wrote:
Hallo, Tobias Hofmann
writes: [...] Dein Suchstring wird nur als Filter erkannt,
aehm - im Gegensatz wozu? Sind die Begriffe "Suchstring" und "Filter" nicht synonym?
Nein, ein Suchstring setzt sich aus diversen Elementen, wie Base, scope Filter und Atributen zusammen. Was ich sagen wollte ist, daß du ja deiner Meinung nach Suchbasis und Filter angibst, durch die Gestaltung des Suchstrings wird aber die Suchbasis nicht als solche erkannt und das gesamte Gebilde als Filter mit Attribut angesehen.
ctClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de))"
...also auch hier wieder der Blank vor der Search Base...
War ja auch so von mir beabsichtigt, der Blank war ja Bestandteil des Suchstrings. [...9
Die Meldung 'equality candidates: index_param failed' sagt, daß der Index für objectclass eq verlangt
Bloede Frage: von wem oder was verlangt?
Von deinem Index Eintrag in slapd.conf :-) [...]
Kann es sein, daß der Client für Active Directory geschrieben ist?
Moeglich. Ein Telefonat mit dem Clienthersteller letzte Woche ergab, dass (IIRC) AD unterstuetzt, ansonsten fuer LDAP iPlanet und Qualcomm "empfohlen" seien.
OK, iPlanet ist RFC konform.
Ich war zu dem Zeitpunkt, als wir uns hier fuer OpenLDAP entschieden hatten, davon ausgegangen, dass OpenLDAP sowieso alles und "viel besser" koenne... :) Deswegen hatte ich mich um iPlanet nicht weiter gekuemmert und nach einer Testinstallation von Eudoras Server an einem anderen Fachbereich bei uns die Finger gelassen...
Es gibt tatsächlich einige Benchmark Tests, in denen OpenLDAP nicht schlecht abschneidet. :-) Auf jeden Fall gibt es da mehr Support als bei den kommerziellen Anbietern. [...]
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Was ich ja, da ich den Client nur ueber den Dialog, in dem ich die jeweiligen Werte eintrage, "konfigurieren" kann, nicht ganz in meiner Hand habe...
Es geht ja auch darum, den Datensatz erst einmal zu prüfen. In einer andern Mail hatte ich ja einen Suchbefehl formuliert. Hier noch einmal zur Erinnerung und fürs Protokoll ldapsearch -h localhost -x -b ou=users,dc=medien,dc=uni-weimar,dc=de -s sub "objectclass=posixaccount" Diesen String kann man noch erweitern durch Attribute, also z.B. ...."objectclass=posixaccount" "uid" oder auch telephonenumber oder welche Attribute du auch suchst. [...]
Ok, ernsthaft: - Du kannst meinen Testfall, der bei mir tut, bei Dir nicht nachvollziehen - korrekt?
Ja, so ist es.
- Wuerde es Sinn machen, Dir meine Schemata und ein LDIF meiner Gruppe sowie meines Users per PM/http zukommen zu lassen, um zu schauen, ob es dann (wie bei mir) tut?
Im Moment macht das keinen Sinn, lass erst einmal prüfen, was bei einem simplen ldapsearch herauskommt, dann sehen wir weiter.
- Ich werde mich etwas eingraben und versuchen, hier ein 2.1.3/4 System auf meiner Testkiste zum Laufen zu bekommen, und dann werden wir alle sehen, ob und wenn ja, wie es laeuft. Schlauer Ansatz?
Das kann nie schaden. Wen du selbst kompilieren möchtest, benötigst du dazu sinnvoller Weise cyrus-sasl-2.1.x, und da es ja eine Testkiste ist, würde ich auch MIT Kerberos V empfehlen. Mit SASL/GSSAPI macht dann die Authentifizierung richtig Spaß. So z.B. folgender Test -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. dieter@marin:/usr/local/bin> ./ldapwhoami SASL/GSSAPI authentication started SASL username: dieter@AVCI.DE SASL SSF: 56 SASL installing layers dn:cn=dieter kluenter,ou=partner,ou=users,o=avci,c=de Result: Success (0) -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Nur aus der Kenntnis meines Loginnamens wird der entsprechende Distinguished Name geparsed, ohne weitere Athentifizierung oder Passwort Kontrolle. Genug der Werbung für Kerberos. Ich wünsche ein frohes Wochenende -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo zusammen, At 14:44 06.09.2002, you wrote:
Hallo,
Tobias Hofmann
writes: Hallo Dieter, Harry, Liste,
At 22:11 04.09.2002, you wrote:
Hallo, Tobias Hofmann
writes: [...] Dein Suchstring wird nur als Filter erkannt,
aehm - im Gegensatz wozu? Sind die Begriffe "Suchstring" und "Filter" nicht synonym?
Nein, ein Suchstring setzt sich aus diversen Elementen, wie Base, scope Filter und Atributen zusammen. Was ich sagen wollte ist, daß du ja deiner Meinung nach Suchbasis und Filter angibst, durch die Gestaltung des Suchstrings wird aber die Suchbasis nicht als solche erkannt und das gesamte Gebilde als Filter mit Attribut angesehen.
ok, nachvollziehbar.
ctClass=posixGroup)(memberUid=uid=dieter,ou=Partner, ou=users,o=avci,c=de))"
...also auch hier wieder der Blank vor der Search Base...
War ja auch so von mir beabsichtigt, der Blank war ja Bestandteil des Suchstrings.
yep, ok.
[...9
Die Meldung 'equality candidates: index_param failed' sagt, daß der Index für objectclass eq verlangt
Bloede Frage: von wem oder was verlangt?
Von deinem Index Eintrag in slapd.conf :-)
Aua. Danke. :)
[...]
Kann es sein, daß der Client für Active Directory geschrieben ist?
Moeglich. Ein Telefonat mit dem Clienthersteller letzte Woche ergab, dass (IIRC) AD unterstuetzt, ansonsten fuer LDAP iPlanet und Qualcomm "empfohlen" seien.
OK, iPlanet ist RFC konform.
ok.
Ich war zu dem Zeitpunkt, als wir uns hier fuer OpenLDAP entschieden hatten, davon ausgegangen, dass OpenLDAP sowieso alles und "viel besser" koenne... :) Deswegen hatte ich mich um iPlanet nicht weiter gekuemmert und nach einer Testinstallation von Eudoras Server an einem anderen Fachbereich bei uns die Finger gelassen...
Es gibt tatsächlich einige Benchmark Tests, in denen OpenLDAP nicht schlecht abschneidet. :-) Auf jeden Fall gibt es da mehr Support als bei den kommerziellen Anbietern.
Was mich sehr freut... :)
[...]
Im Ernst, wir sollten erst einmal versuchen, deinen Suchstring so zu formulieren, daß auch gefunden wird, was du suchst.
Was ich ja, da ich den Client nur ueber den Dialog, in dem ich die jeweiligen Werte eintrage, "konfigurieren" kann, nicht ganz in meiner Hand habe...
Es geht ja auch darum, den Datensatz erst einmal zu prüfen. In einer andern Mail hatte ich ja einen Suchbefehl formuliert. Hier noch einmal zur Erinnerung und fürs Protokoll
Die war nicht untergegangen - ich hatte das schon getestet, bin da aber gegen ein paar Waende gelaufen, bei denen ich erst nachlesen wollte:
ldapsearch -h localhost -x -b ou=users,dc=medien,dc=uni-weimar,dc=de -s sub "objectclass=posixaccount"
Ah. In der vorigen Mail dazu stand noch "objectclass=posixgroup", was erwartungsgemaess nix findet... Gut, der hier tut, und spuckt mir alle meine User aus (da eh jeder Eintrag in ou=users die objectclass=posixaccount hat).
Diesen String kann man noch erweitern durch Attribute, also z.B.
...."objectclass=posixaccount" "uid"
oder auch telephonenumber oder welche Attribute du auch suchst.
ok. ist jetzt klar.
[...]
Ok, ernsthaft: - Du kannst meinen Testfall, der bei mir tut, bei Dir nicht nachvollziehen - korrekt?
Ja, so ist es.
- Wuerde es Sinn machen, Dir meine Schemata und ein LDIF meiner Gruppe sowie meines Users per PM/http zukommen zu lassen, um zu schauen, ob es dann (wie bei mir) tut?
Im Moment macht das keinen Sinn, lass erst einmal prüfen, was bei einem simplen ldapsearch herauskommt, dann sehen wir weiter.
Scheint imho zu funktionieren.
- Ich werde mich etwas eingraben und versuchen, hier ein 2.1.3/4 System auf meiner Testkiste zum Laufen zu bekommen, und dann werden wir alle sehen, ob und wenn ja, wie es laeuft. Schlauer Ansatz?
Das kann nie schaden. Wen du selbst kompilieren möchtest, benötigst du dazu sinnvoller Weise cyrus-sasl-2.1.x, und da es ja eine Testkiste ist, würde ich auch MIT Kerberos V empfehlen. Mit SASL/GSSAPI macht dann die Authentifizierung richtig Spaß. So z.B. folgender Test -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. dieter@marin:/usr/local/bin> ./ldapwhoami SASL/GSSAPI authentication started SASL username: dieter@AVCI.DE SASL SSF: 56 SASL installing layers dn:cn=dieter kluenter,ou=partner,ou=users,o=avci,c=de Result: Success (0) -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Nur aus der Kenntnis meines Loginnamens wird der entsprechende Distinguished Name geparsed, ohne weitere Athentifizierung oder Passwort Kontrolle. Genug der Werbung für Kerberos.
Hm. Macht Lust. :) Ich suche mir mal die Sachen zusammen und schaue, warum ich es nicht zum Laufen bekomme. Spaetestens dann lasse ich wieder von mir hoeren, ja? Gruss, tobi... :)
Ich wünsche ein frohes Wochenende
-Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo
Tobias Hofmann
At 14:44 06.09.2002, you wrote:
Tobias Hofmann
writes:
Tobias Hofmann
writes: [...] [...] Es geht ja auch darum, den Datensatz erst einmal zu prüfen. In einer andern Mail hatte ich ja einen Suchbefehl formuliert. Hier noch einmal zur Erinnerung und fürs Protokoll
Die war nicht untergegangen - ich hatte das schon getestet, bin da aber gegen ein paar Waende gelaufen, bei denen ich erst nachlesen wollte:
ldapsearch -h localhost -x -b ou=users,dc=medien,dc=uni-weimar,dc=de -s sub "objectclass=posixaccount"
Ah. In der vorigen Mail dazu stand noch "objectclass=posixgroup", was erwartungsgemaess nix findet...
Sorry, meine Gedankenlosigkeit ;-(
Gut, der hier tut, und spuckt mir alle meine User aus (da eh jeder Eintrag in ou=users die objectclass=posixaccount hat).
Diesen String kann man noch erweitern durch Attribute, also z.B.
...."objectclass=posixaccount" "uid"
oder auch telephonenumber oder welche Attribute du auch suchst.
ok. ist jetzt klar.
Wenn das alles so funktioniert wie du es möchtest, solltest du auch deinen Client entsprechend konfigurieren können. Die meisten Clients benötigen ja die Angaben Searchbase scope (manchmal) Filter Attribut
Ich suche mir mal die Sachen zusammen und schaue, warum ich es nicht zum Laufen bekomme. Spaetestens dann lasse ich wieder von mir hoeren, ja? Aber auch Erfolgsmeldungen heben hier das Selbstbewusstsein :-)
-Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo Tobi,
Tobias Hofmann
Hallo Dieter, Harry, Liste,
Tobias Hofmann
writes:
[...]
Moeglich. Ein Telefonat mit dem Clienthersteller letzte Woche ergab, dass (IIRC) AD unterstuetzt, ansonsten fuer LDAP iPlanet und Qualcomm "empfohlen" seien.
Ich war zu dem Zeitpunkt, als wir uns hier fuer OpenLDAP entschieden hatten, davon ausgegangen, dass OpenLDAP sowieso alles und "viel besser" koenne... :) Deswegen hatte ich mich um iPlanet nicht weiter gekuemmert und nach einer Testinstallation von Eudoras Server an einem anderen Fachbereich bei uns die Finger gelassen...
Kann es sein, daß der Client nur LDAPv2 unterstützt? Als Default nutzt OpenLDAP nur LDAPv3. Setze doch mal in slapd.conf die Zeile allow bind_v2 Damit werden dann auch LDAPv2 Clients unterstützt. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hei zusammen, At 14:52 06.09.2002, you wrote:
Kann es sein, daß der Client nur LDAPv2 unterstützt? Als Default nutzt OpenLDAP nur LDAPv3. Setze doch mal in slapd.conf die Zeile allow bind_v2
Tut es nicht. Danach kommt der slapd nicht mehr hoch. man slapd.conf sagt, dass defaultmaessig alle Protokolle unterstuetzt werden, und bietet nur "disallow bind_v2". Wenn ich das setze, kommt der slapd auch wieder hoch, und die Anfrage meines Clients scheitert auch - ergo meine Annahme, dass er v2 verwendet, aber keine Ahnung, ob und wenn ja wie man das dem slapd besser verkaufen koennte als bisher... Gruss, tobi...
Damit werden dann auch LDAPv2 Clients unterstützt.
-Dieter
-- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- ---------------------------------------------------------------------- Dipl.-Ing. Tobias Hofmann Bauhaus-Universitaet Weimar D99423 Weimar Professur fuer Graphische Datenverarbeitung Projekt medienquadrat SnailMail: Bauhaus-Universitaet Weimar, Fak. Medien, D99421 Weimar Location: D99423 Weimar Karl-Haussknechtstr. 7 Zimmer 111 Fon: ++49-(0)3643-58-3780 Fax : -3701 e-mail: mailto:tobias.hofmann@medien.uni-weimar.de ----------------------------------------------------------------------
Hallo,
Tobias Hofmann
Hallo zusammen,
Tobias Hofmann
writes: [...] und dieser ist wiederum copy-paste aus Terminal mit debug-level 255...
Will meinen, er sucht nicht nach dem dn, sondern nach dem dn, der posixGroup ist und den memberUid-Eintrag hat - oder?
Das ist jetzt alles etwas zerfleddert, woher kommt der Eintrag #line-break by me
Der kommt von mir, das sah im Umbruch mehrdeutig aus - ich hatte gehofft, damit zu klaeren...
Was läuft mit debug-level 255, ist das slapd oder ldapsearch? Für slapd gibt es keinen debug level 255.
hm. man slapd sagt bei mir unter examples:
"To start slapd with an alternate configuration file, and turn on voluminous debugging which will be printed on standard error, type:
/usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255"
Das ist aus: OpenLDAP 2.0.12-Release 5 Novemeber 2000 SLAPD(8C)
Um die Ausgabe der filter zu debuggen, sollte der level -d 32 gesetzt werden.
Hm, wenn ich das aber so starte, spuckt er mir keine filter aus, wohingegen ich bei -d 255 folgendes finde:
... end get_filter 0 filter: (&(objectClass=posixGroup)(memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)) ...
(Die Zeile, die mit "filter:" beginnt, wird von meinem mailer umgebrochen, wodurch der Blank vor dem dc=medien nicht mehr ersichtlich ist. Im Terminal steht das auf einer Zeile, mit Blank vor dem dc=medien...).
Ich beziehe mich jetzt auf den Adminstrator's Guide von OpenLDAP.org Debugging Levels für slapd -1 enable all debugging 0 no debugging 1 trace function calls 2 debug packet handling 4 heavy trace debugging 8 connection management 16 printout packets sent and received 32 search filter processing 64 configuration file processing 128 access control list processing 256 stats log connections/operations/results 512 stats log entries sent 1024 print communication 2048 print entry parsing debugging Durch Addition dieser Debugging Levels können diverse Debugging Funktionen kumuliert werden. OK, durch Addition von 128+64+32+16+8+4+2+1 komme ich auf 255. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo,
Tobias Hofmann
Rehi Harry,
At 15:16 03.09.2002, you wrote:
Hi,
Tach zusammen,
Auf meinem Suse7.3-Server laeuft unter anderem openldap2-2.0.12-33, was im Grossen und Ganze macht, was es soll, bis auf die Beantwortung von ldapsearch-Anfragen, in denen Leerzeichen an Stellen sind, die ihm nicht gefallen.
Was meinst du damit ?
Aus meiner mail an die openldap-Liste - es geht um eine kommerzielle Applikation, die per LDAP authentifizieren will, und dabei auch die Teilnehmerschaft eines Users bei einer Gruppe prueft:
[output from starting using /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -d 255]
[...] filter: (&(objectClass=posixGroup) #line-break by me... (memberUid=uid=hofmann9,ou=Users, dc=medien,dc=uni-weimar,dc=de)) [...]
Please notice the leading space before "dc=medien,dc=..."
This leads to the fact that an entry like the following is not found, since there is no such space before dc=medien,...:
dn: cn=CMS Administrator, ou=Groups, dc=medien,dc=uni-weimar,dc=de gidNumber: 1000 memberUid: uid=hofmann9,ou=Users,dc=medien,dc=uni-weimar,dc=de objectClass: posixGroup cn: CMS Administrator
man ldif, oder auch rfc2849 würden dir sagen, das dies nicht geht. Es darf/darf kein Leerraum in dem String eines dn sein. Das ist unabhängig von der OpenLDAP Version, oder auch jedem andern ldap SDK, wie iPlanet o.ä. Da hilft nur, die *.ldif Datei korrigieren. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
participants (4)
-
Dieter Kluenter
-
Harry Rueter
-
Harry Rüter
-
Tobias Hofmann