Archivi categoria: Computer

Articoli che riguardano i computer: software, hardware e modi d’utilizzo.

XML/SQL e PostgreSQL: come recuperare due tag in parallelo da un dato XML in una sola SELECT

Tempo fa mi fu chiesto di lavorare ad una procedura interna a DB2 che si occupava di importare alcuni dati: un sistema esterno generava un testo XML con parecchi record da inserire, metteva tutto il testo tramite connessione ODBC in un campo XML di una tabella «di frontiera» e invocava questa procedura che doveva prendere quei dati e inserirli in varie tabelle. Il punto sul quale il DBA locale si era bloccato era che riusciva a fare query XML che  reperivano un singolo campo, ma non ci riusciva quando vi erano più campi da prendere allo stesso tempo (per inserirli nello stesso record).

Anche PostgreSQL è in grado di gestire un campo XML e di estrarre delle parti di XML da quei campi. Questa estensione del linguaggio segue uno standard chiamato SQL/XML. Vediamo come si può affrontare questo problema con PostgreSQL.

Continua a leggere

Autenticazione postgresql tramite PAM per winbind e shadow

A volte si vuole far sì che gli utenti del database postgresql siano autenticati su un sistema esterno al database stesso. Per questo postgresql permette di verificare le credenziali tramite LDAP o kerberos o altro ancora, ma quando non c’è un metodo direttamente implementato in postgresql è possibile utilizzare PAM, che ha svariati connettori. In questo esempio prendiamo in considerazione l’autenticazione sul sistema operativo (utenti in /etc/passwd e password in /etc/shadow) e su dominio Windows (tramite winbind).

Nel seguito verrà assunto che l’autenticazione tramite PAM sia già configurata e funzionante. I comandi sono riferiti ad un sistema Debian Jessie.
Continua a leggere

La dimensione delle directory

Ieri sono intervenuto su un server che aveva un load average parecchio alto e passava il 90% del tempo in modalità kernel. Usando il comando top ho visto che i processi in cima alla classifica erano dei server oracle ed exim. I processi oracle possono stare lì per parecchio tempo perché vi possono essere delle query particolarmente impegnative, ma il comando exim mi ha un po’ insospettito.

Ho quindi verificato che un certo job veniva lanciato dal cron ogni minuto e inviava un email con degli errori di sintassi. Exim avrebbe dovuto occuparsi della consegna dell’email, ma a causa di un errore nella configurazione del DNS, non vi riusciva e si riproponeva di riprovare più tardi, lasciando quindi quell’email in coda.

Tutti i messaggi della coda di Exim stanno nella directory /var/spool/exim/input. In questa directory c’erano circa 177000 file. I file di per sè sono tanti, ma rimangono gestibili. Visto che tutti quanti erano eguali e riportavano gli stessi errori, ho pensato di rimuoverli con piccolo ciclo shell che richiamasse il comando exim -Mrm NOMEFILE. Dopo circa mezz’ora erano stati cancellati solo 6000 file e il load average era raddoppiato. Allora ho fatto il tutto in maniera forse poco ortodossa, cancellando con il comando rm tutto il contenuto della directory.

Il load average è sceso, ma i nuovi messaggi generati dal cron (per il job in questione e per altri job) facevano comunque sì che il processo exim restasse in cima alla classifica. E soprattutto, la maggior parte del tempo CPU era sempre passata in modalità kernel anziché utente.

Ho allora verificato quanto fosse grande la directory /var/spool/exim/input:

# ls -ld /var/spool/exim/input
drwxr-x--- 2 Debian-exim Debian-exim 4643078144 dic 12 17:39 /var/spool/exim/input

che fa circa 4Gb per la sola directory. Ho quindi «clonato» la directory e tutto si è magicamente sistemato:

# mkdir /var/spool/exim/input2
# chown --reference /var/spool/exim/input{,2}
# chmod --reference /var/spool/exim/input{,2}
# mv /var/spool/exim/input{,.bak} && mv /var/spool/exim/input{2,}
# invoke-rc.d exim restart

Kernel bug

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 image

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.