Heute ist Freitag der 25.05.2012 und das ist der fünfte Monatsbericht meines Freemail Services.
Gestern Nacht ist das Script was Inaktive Accounts löscht gegen die Wand gelaufen! HAHA. Damit das Script weiß was es machen soll Wertet es diverse Einträge aus der LDAP DB aus und findet darunter auch die Accounts die seit 3 Monaten Inaktiv sind. Genauer gesagt sind es 3 Monate und zwei Tage. Wenn es einen Account findet der genau dieser Zeitspanne entspricht wird als erstes der Accountstatus im LDAP auf „Inactiv“ gesetzt. Somit nimmt Postfix keine Mails mehr für diese Postfach an. Als nächstes wird dem User eine Mail geschickt das sein Postfach Deaktiviert ist und er 24 Stunden Zeit hat sich unter einer bestimmen Mailadresse zu Melden. Dort kann der User entweder ein Backup seiner Mails haben oder sollte der User sich nicht Melden wird der Account gelöscht. Sollte der User sich nicht melden wird die Mailbox in Dovecot gelöscht und der Eintrag im LDAP entfernt. Dazu zählen auch die Adressen, Termine und der gleichen.
Nur das hat nicht Funktioniert!!! Scheiße aber auch!!!!
Als ich das Script entwickelt hatte, hab ich es natürlich auf einem Testserver mit ein paar Mailboxen getestet und das hat gut Funktioniert. Aber jetzt nicht mehr!
Nach einigem Suchen im Code und ein bisschen Debuggen kam mir die Erkenntnis das der Zugriff auf die LDAP DB nicht Funktionierte! Die Fehlermeldung war „Invalid credentials (49)“. Jedoch Passwort und DN stimmten. Somit kann das Script natürlich auch nicht laufen. Da man in der LDAP Konfiguration bestimmte Rechte einem User geben kann war natürlich erstmal hier der Fehler zu Suchen und siehe da nichts. Der User kann, sofern Passwort und DN richtig sind entsprechend seine Arbeit verrichten. Also muss das Problem wo anders liegen.
Um den Betrieb und nicht zu Stören und weniger Arbeit beim Logging durchforsten zu haben hab ich die LDAP DB einfach auf eine Virtuelle Maschine kopiert und das Script gestartet. Um nun zu sehen was in der LDAP passiert hab ich das Logging auf 256 runter gedreht. Bei SLAPD, also Standalone LDAP, sind für mehr Logging Output niedrigere Loggingstufen zuständig. Die 2 ist demnach DEBUG. Die slapd.conf gespeichert und die LDAP DB neugestartet.
Jetzt das Script angeworfen und siehe da, geht nicht!!! Scheiße warum geht das nicht!?!?!?!?!?!
Da man bei den DN´s und OU´s schnell mal Fehler machen kann hab ich Einträge gelöscht und per Hand neu eingetippt und siehe da das Teil läuft!?? KLASSE also WO zum Teufel ist dieser verdammte Fehler???
Um diesen Verdammten Fehler zu finden hab ich auf meiner Maschine beide Scripte mal eben mit DIFF prüfen lassen und siehe DA Fehler gefunden!!! Statt einem Kommata (,) war es ein Punkt (.) im Filter für die DN Suche! Somit ist zwar der Login am LDAP korrekt aber die Suche innerhalb der LDAP DB scheitert weil der DN Falsch ist, bzw einen Schreibfehler aufweist. TYPISCH LDAP, kaum klare Fehlermeldungen!
Deswegen auf dem Cluster den Schreibfehler beseitigt und das Script per Hand angestossen UND es geht endlich.
Ich konnte auch mit der Suche in Subversion feststellen das beim Umstellen des LDAP Clusters sich der Fehler eingeschlichen hatte. Da alle Änderungen von Wichtigen Konfigurationsdateien im Subversion festgehalten werden. Sollte dabei mal was schiefgehen kann man sehr schnell auf eine Lauffähige Konfiguration zurückschalten.