LDAP matching rules

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
hoeschler
Beiträge: 93
Registriert: 05.07.2007 11:28:23
Lizenz eigener Beiträge: MIT Lizenz

LDAP matching rules

Beitrag von hoeschler » 27.03.2012 13:23:50

Hallo,

Ich habe hier ein Setup mit slapd 2.4.23, bei dem ich meine Userdaten mittels Gosa füttere. Das ist jetzt insofern nur wichtig, weil ich ebenfalls den Vacationverkehr mittels Gnarwl abwickel und Gosa in seinen Schemas bereits relevante Attribute wie gosaVacationStart, gosaVacationEnd usw. mit an Bord hat.

Jetzt folgendes Problem:
Gnarwl selbst checkt nicht das Start- und Enddatum der Vacation Message, sondern nur, ob Vacation als aktiv gesetzt ist (für die Kompatibilität hab ichs auf gosaMailDeliveryMode=[*V*] geändert).
Möchte ich jetzt also, dass etwaige Abwesenheitsnachrichten außerhalb des festgelegten Zeitraums nicht gesendet werden (obowhl sie noch als aktiv markiert sind) brauche ich eine Möglichkeit, zu checken, ob die Timestamps in gosaVacationStart/gosaVacationStop entsprechend größer bzw. kleiner sind, als die Systemzeit ist.

Prinzipiell also ein Perlscript, welches time einliest mit einem Queryfilter der Marke

Code: Alles auswählen

filter => "(&(gosaMailDeliveryMode=[*V*])(gosaVacationStart<=$now)(gosaVacationStop>=$now))
Jetzt gibts diese Operationen nur, wenn die Attribute jeweils mit einer ORDERING Matching Rule versehen wurden.
Also hab ich mir die Gosa Schemas angesehen und für das Attribut gosaVacationStart siehts so aus:

Code: Alles auswählen

{40}( 1.3.6.1.4.1.10098.1.1.12.41 NAME 'gosaVacationStart' DESC 'Timestamp for enabling current vacation message' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
Meine Idee war jetzt, das Attribut wie folgt umzuschreiben:

Code: Alles auswählen

{40}( 1.3.6.1.4.1.10098.1.1.12.41 NAME 'gosaVacationStart' DESC 'Timestamp for enabling current vacation message' ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
in der Hoffnung, dass ich damit die Vergleichsoperatoren beim query benutzen kann.
D.h. ich habe die zulässige Syntax von Directory String in Integer abgeändert, da timestamps eh nur unix-formatted gespeichert werden und eigentlich(tm) keine Probleme bereiten sollte
Leider kickt mich slapd mit folgender Meldung:

Code: Alles auswählen

conn=1209 op=20 RESULT tag=103 err=80 text=olcAttributeTypes: AttributeType inappropriate matching rule: "integerOrderingMatch"
Kann mir jemand zufällig sagen, wo genau der Denkfehler ist?
Oder Alternativ:
Hat zufällig jemand selbiges Gesamtproblem bereits vor sich gehabt und erfolgreich gelöst?

Benutzeravatar
hoeschler
Beiträge: 93
Registriert: 05.07.2007 11:28:23
Lizenz eigener Beiträge: MIT Lizenz

Re: LDAP matching rules

Beitrag von hoeschler » 27.03.2012 18:48:18

Ich habe einen ldapsearch nach den angebotenen MatchingRules durchgeführt und danach einfach
mittels copy/Paste zugefügt und slapd hats ohne Probleme geschluckt.

Keine Ahnung, warum C/P ausm ldapsearch > C/P aus irgendeiner Site im Web bzw. selbsttippen ist, aber die Problematik kann so weitgehend als gelöst betrachtet werden.

Übrigens hab ich mir den Query selbst nochmal angeschaut und musste erkennen, dass ich damit nur Entries mit korrekten Zeiträumen bekomme ;)

Schönen Abend noch

Benutzeravatar
hoeschler
Beiträge: 93
Registriert: 05.07.2007 11:28:23
Lizenz eigener Beiträge: MIT Lizenz

Re: LDAP matching rules

Beitrag von hoeschler » 19.07.2012 08:36:06

Hallo,

eine Frage zu diesem Thema, welche rein akademischer Natur ist:

Der ldapsearch nach aktiver vacation erfolgt über ein postfix lookup table:

Code: Alles auswählen

query_filter = (&(|(gosaMailAlternateAddress=%s)(mail=%s))(gosaMailDeliveryMode=[*V*]))
Gibt es eine Möglichkeit, bereits hier gegen die Systemzeit zu checken und den Vergleich mit Start und Stoppzeit

Code: Alles auswählen

filter => "(&(gosaMailDeliveryMode=[*V*])(gosaVacationStart<=$now)(gosaVacationStop>=$now))
direkt mit einzubauen?

Die Grundvoraussetzung dafür wäre, dass man Postfix mit dem Timestamp in $now füttern könnte.

Das hätte den massiven Vorteil, dass ich nicht auf ein Skript ausweichen muss, welches dann mehrmals am Tag den ganzen LDAP Tree durchforsten muss, sondern direkt beim Lookup unpassend gesetzte vacations ausfiltern kann.

Antworten