Su uno dei Fire 4800 abbiamo un'applicativo che utilizza una directory openldap per la gestione delle utenze. Se ho ben capito replica su una tablespace Oracle le utenze e utilizza questa replica nel caso il demone slapd non fosse disponibile.
L'utilizzo di openldap pare dovuto a un decisamente buono incremento prestazionale rispetto all'utilizzo del db.
Ora, dopo un aggiornamento dell'applicativo interessato (un accrocchio di jboss tomcat e oracle), la versione di openldap in uso da 3 anni, una 2.1.25 ha cominciato a dare problemi.
Dopo un periodo di debug, kilometri di logs letti, dovrei avere stabilito l'origine del problema. Si tratterebbe di un bug documentato, dove un cambio password eseguito dall'applicativo causerebbe una corruzione del db (un BerkeleyDB 4.2.52 pacchettizzato SunFreeware). Unico modo di recuperare la directory era un ripristino da backup dei files del db o uno slapadd da precedente slapcat, quindi da un .ldif
Stamattina, vinta la guerra burocratica che tutto rende difficile, ho messo in produzione l'ultima stabile di openldap, la 2.3.32, sistemato il file di configurazione slapd.conf , che a distanza di anni ha introdotto un paio di cambi sintattici (attrs==attributes e simili).
La procedura di migrazione è stata alquanto indolore e semplice, inoltre ho, come sempre, optato per un aggiornamento con installazione in parallelo di binari e database nuovo, in modo da poter tornare indietro in una manciata di secondi al verificarsi di problemi imprevisti (che ci sono sempre soprattutto quando hai una macchina che è in produzione e centinaia di utenti che aprono chiamate a /dev/random anche abbastanza imbufaliti.
I tests di creazione utente e cambio password sembrano essere andati a buon fine; dopo 6 ore che il nuovo demone lavora tutto sembra ok.
In un prossimo post la procedura di aggiornamento.
Visite
Nessun commento:
Posta un commento