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 
Archivi categoria: Computer
Avere più pattern per la stessa servlet
A volte capita che si voglia mappare una servlet su più URL che non sono facilmente descrivibili con una sola espressione; difatti questa possibilità è stata prevista nella strutturazione del file web.xml.
Normalmente la mappatura avviene in questo modo:
<servlet-mapping>
<servlet-name>fred</servlet-name>
<url-pattern>/john</url-pattern>
</servlet-mapping>
che equivale a dire che se viene richiamato l’URL http://nomehost/context/john allora si deve richiamare la servlet fred.
Al posto di pattern costanti, si posso utilizzare delle espressioni, come ad esempio in:
<servlet-mapping>
<servlet-name>fred</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
Nel caso che si voglia fare richiamare la stessa servlet su due diversi url, si deve fare in questo modo:
<servlet-mapping>
<servlet-name>fred</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>fred</servlet-name>
<url-pattern>/altrourl</url-pattern>
</servlet-mapping>
Almeno, questa è la sintassi che funziona con tomcat 5.5. Notare che la sintassi alternativa:
<servlet-mapping>
<servlet-name>fred</servlet-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>/altrourl</url-pattern>
</servlet-mapping>
viene accettata da tomcat, ma solo l’ultimo url-pattern viene utilizzato, il che è in genere è una brutta scoperta quanto il file web.xml non è stato scritto a mano, ma realizzato da uno strumento automatico come netbeans…
La specifica servlet 2.5 dice, al paragrafo SRV.19.0.3 intitolato «Multiple Occurrences of Servlet Mappings»:
Previous versions of the servlet schema allows only a single url-pattern or servlet name per servlet mapping. For servlets mapped to multiple URLs this results in needless repetition of whole mapping clauses.
il che vuol dire che in effetti il comportamento di tomcat5.5, che accetta più url-pattern all’interno dello stesso servlet-mapping, è sbagliato poiché tomcat 5.5 aderisce alla specifica 2.4 e non alla 2.5.
Ho aperto una segnalazione agli autori di tomcat. Vediamo come va.
Sull’importanza di monitorare i backup
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.
pam_unix2 and call_module
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