Re: Logcheck <-> slapd Frage
Hallo, Am Montag, den 11.09.2006, 18:51 +0200 schrieb Torsten Flammiger: > ich nutze 'LogLevel 0' > 256 mag gut sein, wenn man wissen will ob eine Anfrage auch dort > ankommt, wo man denkt, das sie es tun soll. Ansonsten müllt sie dir > das Logfile voll. Wenn alles funktioniert, würde ich das drastisch > zurück drehen: hat man nämlich noch alles andere 'dran' hängen, wie > SAMBA, IMAP, Postfix, VSFTP, Login, SSH dann kommen schon einige > Bytes zusammen: auch bei einem Home-Server. Done. > jain: > > ist keine Fehlermeldung sondern bedeutet nur, das kein Index auf den > entsprechenden Attributen liegt: die Abfrage geht halt "langsamer". > Der slapd will Dich freundlich darauf hinweisen, doch bitte Indizes > auf die entsprechenden Attribute zu setzen (siehe weiter unten). > > Auf einem zu hause stehenden LDAP-Server, der nur fürs Adressbuch > missbraucht, ist das kein Beinbruch. > > Abhilfe schafft (ein einfaches Beispiel) folgendes in slapd.conf: > > index cneq > index sn eq Vielen Dank, ich habe Deine Beispiele eingetragen und es schein besser zu sein. Da ich jetzt auch das Loglevel runtergesetzt habe, habe ich Ruhe ;) Danke für die Tips, Andre -- BOFH-excuse of the day: Borg implants are failing signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Logcheck <-> slapd Frage
Andre Timmermann schrieb: > Hallo Liste, Servus > ich verwende auf meinem Server logcheck und den LDAP-Server slapd. Wenn > ich mit Evolution auf mein Adressbuch zugreife, bekomme ich sehr viele > Meldungen im Logcheck, da für slapd nur eine Zeile > in /etc/logcheck/ignore.d.server/slapd vorgesehen ist. > > Frage 1: welches Loglevel benutzt Ihr im slapd? Ich habe 256 > eingetragen, weil das so in einem HowTo empfohlen wurde. ich nutze 'LogLevel 0' 256 mag gut sein, wenn man wissen will ob eine Anfrage auch dort ankommt, wo man denkt, das sie es tun soll. Ansonsten müllt sie dir das Logfile voll. Wenn alles funktioniert, würde ich das drastisch zurück drehen: hat man nämlich noch alles andere 'dran' hängen, wie SAMBA, IMAP, Postfix, VSFTP, Login, SSH dann kommen schon einige Bytes zusammen: auch bei einem Home-Server. > Frage 2: ist sowas hier: > Sep 11 13:45:02 filez slapd[31465]: <= bdb_substring_candidates: (sn) [selbiges...] > Sep 11 13:45:02 filez slapd[31465]: <= bdb_substring_candidates: (sn) > index_param failed (18) > > eine echte Fehlermeldung, oder ist das Normal und kann ignoriert werden? > Ich nehme an, dass es nur an dem recht hohen Loglevel liegt. jain: ist keine Fehlermeldung sondern bedeutet nur, das kein Index auf den entsprechenden Attributen liegt: die Abfrage geht halt "langsamer". Der slapd will Dich freundlich darauf hinweisen, doch bitte Indizes auf die entsprechenden Attribute zu setzen (siehe weiter unten). Auf einem zu hause stehenden LDAP-Server, der nur fürs Adressbuch missbraucht, ist das kein Beinbruch. Abhilfe schafft (ein einfaches Beispiel) folgendes in slapd.conf: index cn eq index sn eq Den entsprechenden Abschnitt gibt es sicher schon in der slapd.conf. Anschließend den slapd stoppen, und das Kommando slapindex aufrufen. Den slapd wieder starten und zumindest die obigen Meldungen sollten der Vergangenheit angehören. HTH Torsten
Logcheck <-> slapd Frage
Hallo Liste, ich verwende auf meinem Server logcheck und den LDAP-Server slapd. Wenn ich mit Evolution auf mein Adressbuch zugreife, bekomme ich sehr viele Meldungen im Logcheck, da für slapd nur eine Zeile in /etc/logcheck/ignore.d.server/slapd vorgesehen ist. Frage 1: welches Loglevel benutzt Ihr im slapd? Ich habe 256 eingetragen, weil das so in einem HowTo empfohlen wurde. Frage 2: ist sowas hier: Sep 11 13:45:02 filez slapd[31465]: <= bdb_substring_candidates: (sn) index_param failed (18) Sep 11 13:45:02 filez slapd[31465]: <= bdb_substring_candidates: (cn) index_param failed (18) Sep 11 13:45:02 filez slapd[31465]: <= bdb_substring_candidates: (sn) index_param failed (18) eine echte Fehlermeldung, oder ist das Normal und kann ignoriert werden? Ich nehme an, dass es nur an dem recht hohen Loglevel liegt. Greetz, Andre -- BOFH-excuse of the day: tachyon emissions overloading the system signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
