Hudson-Update, Sonar-Update und das liebe LDAP

Seit Ende November ist das neue Sonar-Release 2.4.1 draußen. Und da gerade in der letzten Vor-Weihnachtswoche das Büro mal nicht voll besetzt war, bot sich ein Update unserer Buildsysteme an. Neben ein paar unserer internen Tools haben wir auch gleich noch Hudson auf den neusten Stand gebracht. Die Mittagspause wurde dann gut mit einem Vollbackup aller Anwendungen gefüllt (Achtung : beim nächsten Mal gleich für genügend Plattenplatz für die Sonar- und Artifactory-Datenbank-Dump sorgen) und nach Rigatoni de la Casa war das Hudson-Update auch keine große Sache dank integrierter Update-Funktion: „Manage Hudson“ >> „neue Version installieren“ und Service-Neustart… Fertig! Sonar bietet seit Version 2.2 auch ein vereinheitlichtes Vorgehen bei Versionsupdates, aber in der Vergangenheit gab es da (besonders bei der 1.9 auf 2.1) doch schon ein paar Probleme bei der Migration der Analyse-Ergebnisse. Also die entsprechenden sonar.properties aus unserer alten Insatallation (2.2) mit der neuesten Version (2.4) gemerged, weil es dort neue Einträge für das Update-Center der Version 2.4 gab. Für das Update-Center selbst noch die Proxy-Einstellungen in die Properties eingetragen und dann per automatischem Setup die Datenbank-Werte auf die neue Version updaten. Bei knapp 40% CPU-Auslastung rödelte das MySQL-DBMS dann so 30min und erfreulicherweise erschien dann auch das Sonar-Login-Fenster. Puh! Jetzt noch mit der Versionsmatrix alle unserer bisherigen Plugins auf ihre neueste Version anheben und neustarten. Das Sonar-Log sieht gut aus und wächst gemächlich mit jeder verstreichenden Sekunde, dann wieder das Anmelde-Fenster. Gewohnheitsgemäß melde ich mich mit meinem ADS-Account an… hmm…. rot? Ok, nochmal… wieder nix? Verdammt. Dass ich nicht an vorrübergehender Passwort-Amnesie leide, bestätigen 3 weitere Versuche an diversen anderen Systemen. Das Wartungsfenster für die System-Updates neigte sich dem Ende, also hab ich nochmal die gemergden LDAP-Zugangsdaten in der sonar.properties überprüft. Fehlanzeige, stimmte alles. Die Website des sonar-ldap-Plugins angeschaut, leider gibt’s dort ein Versions-Salat mit dem Download der Version 1.0, aber den Beispielen für 0.1 🙁 Na gut, rein in die aktuellen Sourcen und per logback.xml das Logging für die Authentifizierung verfeinert, den Finger schon am Rollback-Button für das in der Mittagspause gemachte Backup :

<logger name="org.sonar.plugins.ldap">
    <level value="DEBUG"/>
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="SONAR_FILE"/>
</logger>

Nach ein paar weiteren Minuten fiel mir dann auf, dass das LDAP-Plugin einen Test gegen den ADS-DomainControler macht… zwar mit den richtigen Werten für Url und Password, aber aus einem unerfindlichen Grund wurde für bindDn null gesetzt. Naja, unerfindlich nicht: das Attribut fehlte einfach in der Properties-Datei… Merkwürdigerweise war der aber auch nicht per ldap.bindDn in der 0.1er Version gesetzt. Hm, kleiner Fehler, große Wirkung. Schnell den Eintrag gemacht, den Neustart-Button weiter abgenutzt und dann klappte die Anmeldung auch mit dem Domain-Account. Schade, dass das Ldap-Plugin beim Testen keinen Fehler wirft… Wäre jetzt schon interessant gewesen, dass ein Selftest nicht funktioniert hat 🙂
Auf den ersten Blick macht die 2.4er Sonar-Version ne ganze Menge her : anpassbare Dashboards, ein Update-Center für kinderleichte Plugin-Installation und -Updates und dank einer wachsenden Community mehr und mehr Unterstützung für andere Sprachen.