Kategorie: Freemail

Heute ist Freitag der 28.06.2013 und das ist der dritte Monatsbericht meines Freemail Services.

Diesen Monat wurde Dovecot von Version 2.1.15 auf Version 2.2.4 hochgezogen. Damit konnten wieder Performance Verbessungen von gut 3% mit Nagios Messbar nachgewiesen werden. Des Weiteren wurde der Storage in dem die Sieve Scripte liegen auf ein Separates Array ausgelagert was bei Sieve und Dovecot im allgemeinen einen Messbaren Rückgang der I/O Belastung zur Folge hatte und somit Dovecot insgesamt MEHR Performance erzeugt. Das hat zu folge das mehr Dovecot Prozesse die gleiche Systembelastung erzeugen.

Storage Technisch liegen wir diesem Monat bei knapp 880 TB, ein leichter Rückgang im Speicherverbrauch.

Das „Toter Account Löschen“ Script hat in den vergangende 2 Monaten NUR 834 Tote Accounts gelöscht.

Heute ist Freitag der 26.04.2013 und das ist der zweite Monatsbericht meines Freemail Services.

Diesen Monat steigen wir mit Dovecot auf die Version 2.1.15. Nach diversem Testen läuft das Produktion System, also der Cluster, sogar etwas schneller wenn auch minimal, aber gerade eben so das wir einen Unterschied mit Nagios Messen können. Auf dem Array, wo Dovecot seine Indexe Lagert, wurden einige Optimierungen am Dateisystem vorgenommen. Diese sorgen jetzt, gerade bei vielen und kleinen Dateien, für einen Performanceverbesserung die gut bei 8% liegt. Da wir den Durchsatz der Kontroller Erfassen sieht man hier diverse Unterschiede.

Das „Tote Accounts Löschen“ Script hat in den letzten zwei Monaten merkwürdig wenig Arbeit. Nur 381 Tote Accounts wurden Entfernt, diverse dieser Accounts wurden hier in einen Bezahltes Mailpaket umgewandelt. Des Weiteren hat die Überarbeitung des WIKI´s Erfolg gezeigt. Der Zugriff auf das WIKI stieg Ordentlich an und damit wurde auch unser Support Team spürbar Entlastet.

Heute ist Freitag der 28.12.2012 und das ist der zwölfter Monatsbericht meines Freemail Services.

Endspurt zum Jahresende!

Diesen Monat wurden 5.621 Tote Accounts entfernt wobei auch diesmal diverse User auf ein Bezahltes Mailpaket umgestiegen sind. Trotzdem ist und bleib Freemail ein Verlustgeschäft was nicht ganz unwesentlich auch andere Probleme mitbringt.

Account technisch waren die Accounts diesmal in 16 Tagen alle weg. Obwohl hier von 70.000 auf 100.000 Accounts aufgestockt wurde und aus dem Vormonat 9.512 Tote Accounts gelöscht wurden, waren die noch zu vergebenden Accounts schneller weg als erwartet.

Speicher technisch geht es wie immer Bergauf, im Moment liegen wir bei knapp 0.95 PB, also 950 TB. Die Erweiterung der Storageserver wurde ohne Probleme mit einer zwei Stündigen geplante Downtime erledigt.

Auch wenn der Freemail Service diverse Probleme erzeugt, werde ich diesen weiter betreiben und auch Versuchen die besonderen Kunden möglichst zu frieden zu stellen.

Heute ist Freitag der 30.11.2012 und das ist der elfte Monatsbericht meines Freemail Services.

Dickes Update bei den Accounts, es gibt jetzt nicht wie bisher 70.000 sondern 100.00 Accounts. Da man unter Dovecot für Mailboxen eine Kompression verwenden kann spart man hier eine Menge an Speicherplatz. Bei Mails mit Bildern oder PDF Anhängen ist die Kompression zwar nicht ganz so stark, aber der großteil wird Relativ stark Komprimiert. Eingesetzt wird bz2 mit Kompression in der Stufe 9, also die Stärkste aber auch Komplexeste Kompression. Trotz der Kompression hat das System bzw. Dovecot nicht wirklich mehr zu schaffen. Es steig zwar etwas die Last auf den CPU´s aber dafür spart man eine Menge Zugriffe auf die Platten. Der Verbrauch am Hauptspeicher ist auch nicht wirklich groß. Der Vorteil aber ist das die Mailboxen dadurch spürbar schneller geworden sind und das macht sich gerade bei großen Mailboxen mit sehr vielen Mails bemerkbar. Somit ist auf den Storage Servern MEHR Platz was mich dazu bewogen hat die Menge der Accounts von 70.000 auf 100.000 Accounts auf zu stocken. Der Cluster sollte die 30.000 Accounts locker wegstecken, da allein schon die vier Maschinen genügend Ressourcen haben und mehr oder weniger sich langweilen.

Storage verbrauch liegt mittlerweile bei 600 TB auch hier wieder Tendenz steigend.

Bei den gelöschten Accounts gab es auch hier wieder diverse Kunden die auf ein Bezahltes Mailpaket umgestiegen sind ber auch diverse User die ganz weg sind. Insgesamt 9.521 Tote Accounts wurden gelöscht und stehen wieder, mit den 30.000 neuen Accounts, wieder zu Verfügung.

 

Heute ist Freitag der 26.10.2012 und das ist der zehnte Monatsbericht meines Freemail Services.

Diesen Monat ist einiges Passiert. Die im Vormonat gelöschten Toten Accounts waren innerhalb von 11 Tagen weg!!! Ich hatte eigentlich nicht damit gerechnet das es so schnell geht, aber COOL!! Dafür wurden diesen Monat 281 Tote Accounts gelöscht und damit wieder Speicherplatz von etwas mehr als 2 TB wieder freigegeben.

Auch hat es ein Update der Mailserver Software gegeben die Version von Dovecot hat sich von 2.1.3 auf 2.1.10 geändert. Um die neue Version von Dovecot zu Installieren wurde immer ein Server Abgeschaltet und nach der Geplante Downtime von 6 Stunden wieder im Cluster Integriert. Diese Spiel wurde an 4 Tagen in der Nacht von 2:00 bis 8:00 Uhr erledigt.

Am Server selbst hat sich der Hauptspeicher vergrößert von 64 GB auf 128 GB und die Raidarrays wurden beim Neustart des Servers auf Dateisystemfehler geprüft.

Postfix, Dovecot, Amavis mit ClamAV und dem Webserver wurden an den grösseren Hauptspeicher angepasst und Postfix hat jetzt eine RAM Disk bekommen was bei Postfix für einen Massiven Performance Schub sorgt, da die Mails die durch Postfix laufen jetzt nicht mehr auf die Platte geschrieben werden sondern direkt im SUPER Schnellen RAM liegen und Postfix nun richtig seine Muskeln Spielen lassen kann.

Speicherplatz technisch liegen wird jetzt, trotz Kompression bei den Mailboxen, bei fast 520 TB. Aber Dovecot erzeugt jetzt nicht mehr so viel I/O Last da die Kompression im Speicher gemacht wird und Dovecot somit weniger auf die Platten zugreifen muss.

Heute ist Freitag der 28.09.2012 und das ist der neunte Monatsbericht meines Freemail Services.

Dies ist der erste Monat wo nenneswert Accounts gelöscht wurden und zwar gleich 12.721 Accounts. Wenn ich das mit meiner Kundenliste vergleiche sind da viele die jetzt ein Mailpaket gebucht haben was einige andere Features hat und auch mehr Speicherplatz, meist so um die 100 GB oder noch mehr. Des Weiteren sind auch viele der User „abgesprungen“ die des öfteren schon diverse Tickets aufgemacht hatten und uns, ich will mal sagen, nur genervt haben. Andererseits sind die aber meist auch diejenigen die am längsten irgendwelche „Kostenlosen Angebote“ ABGREIFEN und glauben sie könnten da noch diverse Goodys rausschlagen. Aber eben nicht bei mir! Warum? Ganz einfach, es gibt kaum Freemailanbieter die komplett auf Werbung verzichten so wie ich. Also keine Werbung im Webinterface und/oder in den Mails.

So gesehen ist das für mich, bzw für die Firma ein KOMPLETTES zu Brot Geschäft was eigentlich mehr Kosten verursacht als es Nutzen bringt. Okay, ich muss aber dazu auch sagen das es diverse Freemail User gab die jetzt ein Bezahltes Mailpaket haben. Trotzdem ist und bleibt es ein Verlustgeschäft. ABER egal!

Da nun wieder 12.721 Accounts frei sind warte ich jetzt natürlich wieder darauf wie schnell die wieder weg sind. Da das Thema bei Facebook was gebracht hat werde ich das gleiche wiederholen und schauen wie lange es braucht bis wir wieder auf 70.000 Accounts sind.

Durch das bereinigen der Toten Accounts sind auch gleich wieder 86 TB frei geworden.

Heute ist Freitag der 31.08.2012 und das ist der achte Monatsbericht meines Freemail Services.

Da ich seit einiger Zeit auf einer Testmaschine Dovecot 2.* laufen habe und diesen über Mstone und Postfix mit Mails Bombardiere, um die Stabilität von Dovecot zu Testen, ist es langsam Zeit Dovecot 2.* in den Produktiven Einsatz zu stellen. Zu dem ist mir vor knapp 6 Wochen ja ein HP SmartArray Kontroller abgefackelt was mich dann am Wochenende dazu gezwungen hat den Server komplett zu ersetzen, damit der Cluster wieder komplett ist.

Also hab ich dann auch gleich die anderen Maschinen im Cluster erneuert. Jetzt besteht der Cluster aus 4 HP DL580 mit 64 GB Ram, je zwei P411 SmartArray Controllern und zwei HP Quadport Lankarten mit 4 x 1Gbit LWL Controllern.

Dovecot, Postfix, OpenLDAP und MySQL werden auf allen Maschinen selbst gebaut und angepasst.

Bei Dovecot 2.* hab ich seit geraumer Zeit auch die Mailbox Compression aktiv die alle Mailboxen mit bz2 und Faktor 9 Komprimiert. Somit hat zwar die CPU mehr zu Leisten aber dafür spart man eine Menge I/O Leistung, was Dovecot insgesamt mehr Bums verschafft. Des Weiteren können die Mailboxen mit Dsync von Server zu Server migriert werden ohne großartig Passworte ändern zu müssen. Also ein Recht „einfaches“ System. Mal sehen ob das auch am Lebenden Objekt geht.

Die Migration hat genau 2 Stunden gedauert und wurde über ein Script gesteuert was mit Dsync einen Mirror Prozess angestoßen hat. Über die 4 Port 1 GBit Lankarte ging das entsprechend zügig nur die Synchronisation in das zweite Rechenzentrum dauert wegen der 155 MBit Anbindung länger was aber nicht wirklich zu großen Störungen führte. An die Stelle von ImapProxy tritt jetzt der Dovecot Director der ähnlich wie der ImapProxy funktioniert.

Somit lässt sich der Cluster einfacher Verwalten und Überwachen da jetzt Dovecot alles in einer Hand hat und man auch im Laufenden Betrieb Mailboxen von Backend zu Backend verschieben kann was mit ImapProxy so nicht funktioniert hat.

Nichts desto trotz gab es bis auf die Geplanten 2 Stunden Downtime keine Probleme und Morgens um 6:00 Uhr war der Cluster wieder voll Einsatzbereit.

Im Zuge dessen konnte ich auch gleich das entfernen der Toten Mailboxen überwachen was ja vor vier Monaten zu Problemen führte. Durch die Aktive Kompression der Mailboxen ist der Platzverbrauch von knapp 600 TB auf 480 TB gesunken. Ein Blick in die Nagios Langzeitüberwachung zeigt neben der gesunken I/O Last nur ein Minimalen Anstieg der Systemlast und ein etwas größeren RAM Verbrauch bei Dovecot. Auch der gleichzeitige Umstieg von Maildir auf Mdbox (also Multi Mbox) zeigt eine Reduzierung der Systemlast an, was sich auch gleich beim Backup bemerkbar machte was mal eben 6 Stunden weniger Zeit benötigt.

 

Heute ist Freitag der 27.07.2012 und das ist der siebente Monatsbericht meines Freemail Services.

Am 21.07 bekam ich morgens um 4:24 Uhr einen Telefonanruf von Nagios!! JAAAA, Nagios kann mit uns Reden. Sowas ist Echtzeit Kommunikation!!!!!!

Upala dachte ich, son Mist! Da hat man schon mal Bereitschaft und wird auch noch mitten beim Schlafen gestört. Scheibenkleister, gut was solls. Also an den Aparat gegangen und Zugehört was Nagios so zu Sagen hat. Den Anruf zur Störungserkennung bestätigt, ansonsten wird der nächste aus dem Bett geklingelt.

Das erste was in einer solchen Situation unbedingt erforderlich ist, ist KAAAAFFEEEEE 🙂 . Ansonsten geht bei mir nicht viel. Also erstmal die Kaffeemaschine angeworfen und danach unter die Dusche. Nachdem der KAAAAAFFFFFEEEEEE endlich durch war ging es ran an den Rechner um zu sehen was Nagios gefunden hat und um die ersten Maßnahmen in die Wege zu leiten.

Normalerweise kann Nagios viele Dinge selbst erledigen, also Maschinen Resetten oder Maschinen Aktivieren, wenn einer unser Cluster droht abzuschmieren oder ungewöhnliche Lastspitzen auftreten. Aus dem Grund Kaufe ich auch nur HP Maschinen da die GUTEN Modelle schon alle eine ILO Karte drin haben die sogar den Zugriff erlaubt wenn die Maschinen abgeschaltet sind. Aber Nagios zeige nichts der gleichen, NEIN schlimmer ein Raidcontroller hat die Beine breitgemacht und ein Raidarray gekillt! Scheisse dachte ich, Dovecot TOT. Maschine TOT. Nein NUR Dovecot war abgeschmiert da genau auf dem Raidarray die Indexe der Dovecot Mailboxen drauflagen, da Dovecot das Array nicht mehr findet startet Dovecot natürlich auch nicht mehr, MIST!!!! Also was machst´e war die erste Überlegung. Platten wurden vom Controller nicht mehr erkannt, ich kam nicht mal mehr in´s Controller BIOS rein also WAT NUN??

Erstmal in die DOKU vom Server rein gesehen. Welche Controller sind drin und was hängt an den Controllern. Am Onboard Controller hängen die Systemplatten als Raid 1+0 dran. Also 4 x 400 GB SAS Platten und ein Raid 1 mit zwei Platten auch 400 GB SAS, System belegt mit allem drum und dran knapp 250 GB auf dem Raid 1+0. Dann ins Backup geschaut und den Taschenrechner gezückt. Per Hand nachgerechnet wie groß der Platzverbrauch der Indexe ist und siehe DA es passt. Indexe verbrauchen 284 GB Platz. Also zweites Raidarray leer gemacht und Dovecot gestoppt. Dann rein in die Dovecot Konfiguration und den Pfad für die Indexe angepasst. Konfig natürlich Kopiert und vorsichtshalber gleich in Subversion geschoben.

Zum Testen dann noch Dovecot gestartet und in die Logs geschaut. AHHHH Dovecot läuft und Postfix macht seine Queue leer. 800 Mails in der Postfix Queue, 1000 sind das Limit ab dem Nagios anfängt um Hilfe zu schreien. Eskalation merkt aber das Dovecot weggebrochen ist und unterdrückt die Störmeldung von Postfix!! Nachdem die Postfix Queue leer ist zum Testen noch mal die Komplette Kiste einem Neustart unterzogen.

Neustart erledigt!

Dovecot? Läuft!

Postfix? Läuft auch!

Storage für den Dovecot Index?? Super hängt an der korrekten Stelle, und LÄUFT!

Glücklicherweise hat es nur den Controller zerrissen auf dem das Array für Dovecot´s Mailbox Indexes liegen. Das soll ja laut Dokumentation bei Fehlern ein einfaches Löschen des Indexes helfen. Denn Index baut Dovecot dann wieder beim Zugriff auf die Mailbox wieder allein auf. NAAA mal sehen ob das Funktioniert.

Da aber heute Samstag ist hab ich nicht wirklich große Lust ins Büro zu fahren und mich um die Maschine zu kümmern!!! HAÄÄÄÄÄ was soll´s scheiß drauf, Wochenende ist sowieso im Arsch. Also zum Becker getrottet, Brötchen geholt und erstmal in Ruhe mit $Freundin und $beideKinder Gefrühstückt. War ja mittlerweile dann auch schon 8:00 Uhr durch.

Nach dem Frühstück in die $Firma gefahren, ein Glück war es der Server der im RZ im Büro steht und das ist schnell Erreicht! Als erstes im Büro erstmal die Kaffeemaschine angeworfen, wie gesagt in solch einer SITUATION Hilft nur die Braune Brühe damit ich den Tag überstehe. Maschine läuft also rein ins RZ Schrank auf gemacht und Server nach vorn gezogen, Deckel auf und mit der Taschenlampe erstmal die Dunkelheit im Server vertrieben!

BOOOOHHHHAAAAAA, Scheisse noch mal!!! Ich hab noch nie gesehen das RICHTIGE Server Hardware HP kaputt gegangen ist. Okay eine Platte und ein Ramriegel, war aber alles noch in der Garantie und wurde gleich von HP Getauscht. Aber der Kontroller ist im wahrsten Sinne Abgebrannt! Da wundert es mich nicht das ich nicht mal mehr ins BIOS vom Kontroller komme. Jetzt noch hoffen das die Platten und das Storage Array das überstanden haben. Also wieder in´s Büro getigert und am Rechner erstmal die Doku zum Server ausgedruckt und ins Lager gegangen um zu sehen was da noch so rumsteht! Mittlerweile war der Kaffee durch und ich hab wieder Hoffnung geschöpft. Im Lager lag dann dann aber nicht wirklich das passende rum, nur nen DL580 G5 mit 32 GB Ram und zwei zusätzlichen SmartArray P411 SAS Kontrollern, na gut dann eben den. Also Kiste eingepackt und ins Rack gehängt, Monitor und Tastatur dran und erstmal auf die Platten Debian Installiert damit die Kiste von der Ferne erreichbar ist. Nach 10 Minuten war die Kiste soweit fertig das ich den Rest in meinem Büro vom Rechner per SSH Konsole machen konnte. Nach knapp 2 Stunden war dann der Rechner komplett Online und ich konnte die alte Maschine abschalten und dem neuen Server die IP des alten Verpassen. Damit war der Cluster wieder Vollständig und ich konnte wieder nach Hause Fahren.

Schönes Wochenende!!

Heute ist Freitag der 29.06.2012 und das ist der sechste Monatsbericht meines Freemail Services.

HALBZEIT!!! Sechs Monate sind Vergangen und es ist Zeit ein Resümee zu ziehen.

Was brachten die letzten sechs Monate für Erkenntnisse? Im allgemeinen sehr gute, finde ich. Meine Befürchtungen das solche Freemail Services grundsätzlich von Spammern und „Störenfrieden“ missbraucht werden haben sich nicht wirklich bewahrheitet. Warum? Ehrlich gesagt weis ich das auch nicht so genau, ich stelle aber mal ein paar Vermutungen an.

Greylisting!

Wehrt schon mal zuverlässig Spammer von Extern ab, da die Dummen Spammer Bots meist keine Queue haben und somit schon beim Einliefern scheitern.

Webinterface!

Da der Zugang ausschließlich nur über das Webinterface, geht also KEIN Externes einliefern über SMTP, man kann hier also keine Klienten Missbrauchen die über SMTP ihren Müll Verbreiten.

Amavis/ClamAV!

Da der Zugriff nur über das Webinterface möglich ist, kann ich sämtliche Mails, die auf den Webservern erzeugt werden, durch ClamAV schon mal Viren frei halten, desweiteren wird der Account gleich Geblockt und ich bekomme eine Mail. Somit kann ich nachvollziehen ob das vielleicht auch nur ein „False Positive“ ist.

Anhänge!

Allein das Verbieten von bestimmten Anhängen, wie EXE, PIF, VB Scripte, lässt sich schon einiges unterbinden.

Passwort Politik!

Um sich am System anmelden zu können muss bei der Registrierung ein Passwort verwendet werden was min. 8 Zeichen lang ist, Gross- und Kleinbuchstaben beinhaltet und min. eine Ziffer. Somit werden die Passworte von Anfang an schon schwer Knackbar und durch das Verbieten von Externen POP3, IMAP und SMTP Verbindungen wird eine Brute Force Attacke erschwert. Zwar nicht verhindert aber schon mal so schwer wie möglich gemacht. Klar kann das Passwort geknackt werden aber Hürde ist Deutlich höher als sonst.

Löschen Toter Accounts!

Verhindert das Missbrauchen der Toten Accounts, es ist nur schwer die Balance zu finden wann ein Account Tot ist oder einfach nur nicht länger verwendet wurde.

Die User!

Obwohl es ein Ausführliches WIKI gibt, was SEHR viele Fragen beantwortet, gibt es immer wieder wieder USER die es einfach nicht können. Man versucht schon so viel wie möglich Informationen in das WIKI zu stellen um den großteil der üblichen Fragen abzudecken, aber irgendwie gibt es immer wieder User die aus der Reihe Tanzen und für Frust sorgen.

FAZIT!

Die Idee die ich hatte und für die ich komische Blicke einstecken musste was sehr Positiv und ist es auch noch immer. Es hat auf Anhieb fast alles Funktioniert und die Hardware machte bisher auch mit. Auch die Software, insbesondere Dovecot, hat mich SEHR überzeugt das gerade Junge Software, die Dovecot ja nun mal ist, wirklich zuverlässig laufen kann und auch läuft. Bugs wurden und werden ziemlich schnell ausgebügelt und die Entwicklung geht schnell voran. Auch die Features sind Sinnvoll und machen einem das Leben an vielen Stellen einfacher, teilweise sogar zum Kinderspiel. Aber es erzeugt auch hin und wieder Langeweile, da man in manchen Situationen, gerade bei Dovecot, einfach nur sieht das es läuft. Das geht mit Cyrus auch anders, das man Tagelang versucht irgendein Murks zum laufen zu bekommen.

ALSO!! Es geht weiter!!! 🙂

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.