Mailinglist Archive: opensuse-de (4628 mails)

[Tobias Hofmann <tobias.hofmann@xxxxxxxxxxxxxxxxxxxx>]

Hallo zusammen,

At 00:28 05.09.2002, you wrote:
> [...]

> Dieter Kluenter wrote:
> >
> > Hallo,
> >
> > Tobias Hofmann <tobias.hofmann@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
----------------------------------------------------------------------