Kernel 3.2.0 della Debian unstable. Oggi ci sono stati quattro kernel panic in serie. Forse sono legati al problema relativo all’ACPI per il quale è stato subito rilasciato un nuovo kernel stabile. Ma poiché ieri ci sono stati tre rilasci di kernel stabili nel giro di dodici ore forse è il caso di attendere qualche giorno prima di provare un aggiornamento

Di norma chi si occupa dell’IT di un’azienda si preoccupa anche di avere un backup funzionante. A volte si tratta di semplici copie su nastro, altre di varie copie in parallelo su vari sistemi. Altre ancora di macchine intere che vengono replicate tramite snapshot del sistema di virtualizzazione.

In ogni caso, una volta che il tutto viene configurato e controllato per qualche giorno, la cosa passa per funzionante e nessuno la guarda più. Finché ovviamente non capita il disastro.

Questa volta, dopo che sono stato chiamato proprio a causa di un disastro, e dopo aver ripristinato il sistema (Solaris 10 su SunFire 880 con BaanIV e Oracle 10), mi è stato chiesto di controllare la procedura di backup.

Tra le varie operazioni svolte, c’è quella di copiare interamente le directory con i datafile di oracle tramite il comando tar. Il tutto avveniva tramite un job lanciato di notte dal cron di sistema, che mandava poi l’esito all’utente root del quale ovviamente nessuno controllava la casella di posta sul server.

Orbene, il comando tar copiava tutti i file eccetto uno (fortunatamente contenente solo indici), e dava questo messaggio d’errore

tar: /disc2/oradata/BAAN/indx700.dbf too large to archive. Use E function modifier.

che è un messaggio del tar di Solaris dovuto al file indx700.dbf che supera gli 8Gb e non è quindi archiviabile. Il tar di Solaris ha una opzione apposita per cambiare formato e gestire file molto grossi, oppure si può utilizzare gtar (GNU tar) che è già presente in Solaris 10.

Ma la cosa più importante è che le operazioni vanno sempre monitorate costantemente. Quindi la casella email di root va letta tutti i giorni, oppure si può inviare l’output del job ad un altro indirizzo email, magari apposito. Ed è molto importante che questi messaggi siano inviati ogni giorno, e non solo in caso di problemi. Perché il fatto che ogni giorno arrivi l’email vuol dire che la procedura di backup è stata eseguita. Se invece l’email non venisse inviata non si avrebbe la certezza dell’avvenuta esecuzione (con successo o meno) del backup.

So, I didn’t know about the call_module option of pam_unix2.so pam module. I spent one day trying to figure out why a pam stack would call pam_winbind without haveing “pam_winbind” in any file in /etc/pam.d and finally discovered that pam_unix2 was calling it because it was configured this way in /etc/security/pam_unix2.conf.
I learnt about pam_unix2 and I wish to know why anyone would use call_module instead of configuring PAM for calling the right module before pam_unix2.
Is there any advantage in letting pam_unix2 managing its own module stack instead of configuring pam files?

Thanks,
Giuseppe