Linux - VirtualBox - Hit and Tricks

Come condividere un disco fra due macchine virtuali:

Consideriamo due macchine virtuali denominati rac1 e rac2 e vogliamo che entrambe le macchine possono accedere al disco denominato shared.

Innanzitutto creiamo il disco da condividere con il comando VBoxManage:

VBoxManage createhd --filename shared.vdi --size 10240 --format VDI --variant Fixed --type shareable --remember

Agganciamo le due macchine virtuali:

VBoxManage storageattach rac1 --storagectl "SATA Controller" --port 1 --device 0 --type hdd --medium shared.vdi

VBoxManage storageattach rac2 --storagectl "SATA Controller" --port 1 --device 0 --type hdd --medium shared.vdi

Come abilitare USB su Fedora 12 host:

La versione OSE di VirtualBox NON supporta l'USB, quindi è necessario scaricare la versione Oracle abilitando il seguente repository in /etc/yum.repos.d/virtualbox.repo:


[virtualbox]
name=Fedora $releasever - $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc


con i soliti comandi yum installate la versione Oracle di VirtualBox, dopo, naturalmente aver de-installato la versione OSE.


Vi ricordo che per la versione Oracle di VirtualBox, occorre aggiungere l'utente che utilizza VirtualBox al gruppo vboxusers nel file /etc/group:


vboxusers:x:501:paciucci


Per abilitare l'USB, occorre innanzitutto che il gruppo vboxusers possa accedere al filesystem usbfs, per far questo creiamo un mountpoint in /tmp:


mkdir /tmp/usbfs


e aggiungiamo a /etc/fstab la seguente riga:


none /tmp/usbfs usbfs devgid=501,devmode=664 0 0


dove il devgid è il gid del gruppo vboxusers.


A questo punto effetuiamo un reboot della macchina host: è necessario!!! Nella console di gestione potrete abilitare il supporto per USB.


Per vedere come vede le unità USB VirtualBox potete anche utilizzare il comando:


VBoxManage list usbhost

Come clonare un disco di VirtualBox:

Dal Virtual Media Manager effettuare il  RELEASE del disco e poi utilizzare il comando:

#VBoxManage clonevdi input.vdi output.vdi

Come abilitare uno Shared Folder fra macchine Linux:

Considerando un host linux e un sistema guest linux per abilitare fra l'host e il guest uno Shared Folder occorre:

1. Installare i Guest Additions
2. Spegnere la macchina e configurare dalla console grafica il path che dovrà essere condiviso (nel nostro caso la directory /home/paciucci verrà mappata come SharedFolder)
3. Avviare la macchina virtuale e montare il disco condiviso il comando:

 #mount -t vboxsf -o uid=1000,gid=1000 SharedFolder /media

Linux - JBoss - Configurazione JBoss con una Certification Authority

Nella precedente puntata abbiamo visto come generare in maniera semplice un certificato server per il nostro JBoss EAP.
Adesso complichiamoci un pò la vita cercando di capire come possiamo gestire una Certification Authority, crearci un certificato per il nostro server, creare certificati per i client in modo tale da poter verificare l'autenticità del browser che si collega al nostro portale e una Revocation List nel caso che qualche certificato non sia più autorizzato.

Iniziamo creandoci la nostra Certification Authority personale. Nel mio caso come utente "jboss" eseguo i seguenti comandi:

export SSLDIR=/home/jboss/personalCA
mkdir $SSLDIR
mkdir $SSLDIR/certs
mkdir $SSLDIR/crl
mkdir $SSLDIR/newcerts
mkdir $SSLDIR/private
touch $SSLDIR/index.txt
echo "0001" > $SSLDIR/serial
echo "0001" > $SSLDIR/crlnumber

cp /etc/pki/tls/openssl.cnf /home/jboss/personalCA

edito il file /home/jboss/personalCA/openssl.cnf andando a dichiarare che la directory contenente la mia Certification Authority è presente in  /home/jboss/personalCA .

Con il seguente comando creo la chiave privata (sarebbe bene questa non lasciarla sul filesystem, ma metterla su una chiavetta):

openssl genrsa -des3 -out ./personalCA/private/cakey.pem 2048

Con il seguente comando mi auto-segno il certificato della CA:

openssl req -new -x509 -key ./personalCA/private/cakey.pem -out ./personalCA/cacert.pem

Con il seguente comando mi genero una chiave. Occorre creare una chiave per ogni certificato emesso dalla CA:

openssl genrsa -des3 -out certificate-key.pem 1024

Con il seguente comando genero un chiave di richiesta (che potrei far firmare a qualche CA autorizzata):

openssl req -new -key certificate-key.pem -out certificate-req.pem

Con il seguente comando mi auto-segno il certificato:

openssl ca -config /home/jboss/personalCA/openssl.cnf -in certificate-req.pem -out certificate.pem -notext

Il certificato appena segnato viene trasformato in formato PKCS12 che sarà poi installabile in un browser come Internet Explorer o Firefox:

openssl pkcs12 -export -in certificate.pem -inkey certificate-key.pem -certfile ./personalCA/cacert.pem -out client.p12 -name "Certificato Client"

Creaiamo una Revocation List vuota che ha da 365 giorni:

openssl ca -config /home/jboss/personalCA/openssl.cnf -gencrl -crldays 365 -out ./personalCA/crlFile.pem

Verifichiamo che sia vuota:

openssl crl -in ./personalCA/crlFile.pem -text -noout

A questo punto abbiamo configurato la nostra Certification Authority, iniziamo a configurare il nostro JBoss. Avremo bisogno di 3 tipologie di certificati:
- Certificato per il server che chiameremo server.keystore
- Chiave della Certification Authority che abilita i certificati dei client che chiameremo server.truststore
- Revocation List per disabilitare i certificati dei client che chiameremo server.crlFile

Con il seguente tool generiamo il certificato per il server:

keytool -genkey -alias tomcat -keyalg RSA -keystore server.keystore -storepass "jboss123"

e lo copiamo nella opportuna directory:

cp server.keystore /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/

Con il seguente comando importiamo la CA:


keytool -import -v -keystore server.truststore -storepass 123456 -file ./personalCA/cacert.pem

e la copiamo nell'opprtuna directory:

cp server.truststore /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/


A questo punto ci copiamo la Revocation List creata precedentemente nella directory di JBOSS:

cp ./personalCA/crlFile.pem /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/server.crlFile

Riconfiguriamo oppurtamento il file server.xml in /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/deploy/jbossweb.sar


<Connector port="8443" address="${jboss.bind.address}" protocol="HTTP/1.1" SSLEnabled="true" scheme="https" secure="true" clientAuth="true" sslProtocol = "TLS" keystoreFile="${jboss.server.home.dir}/conf/server.keystore" keystorePass="jboss123" keyAlias="tomcat" truststoreFile="${jboss.server.home.dir}/conf/server.truststore" truststorePass="123456" crlFile="${jboss.server.home.dir}/conf/server.crlFile"  />


A questo punto avremo:
- keystoreFile che è il file che contiene il certificato per il server
- truststoreFile che contiene il certificato della CA che permette a tutti i certificati client di connettersi con il server
- crlFile che contiene i certificati client revocati

Attivando JBoss con la configurazione precedente non sarà più possibile connettersi alle applicazioni finchè non verrà installato sul browser il certificato client.p12.

Con il seguente comando potremo revocare il certificato:

openssl ca -config /home/jboss/personalCA/openssl.cnf -revoke certificate.pem

e dopo aver aggiornato la revocation list con il comando:

cp ./personalCA/crlFile.pem /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/server.crlFile

non sarà più possibile entrare nelle applicazioni JBoss.

Linux - JBoss - Configurazione SSL e gestione Certification Authority

Questa guida vuole far chiarezza su come si devono creare dei certificati SSL da utilizzare con la JBoss Enterprise Application Platform (EAP) di Red Hat.

La versione di JBoss di Red Hat si discosta per certi versi dalla versione Comunity. La versione da me utilizzata per questo tutorial è la 5.0.1-CR2 su Red Hat Enterprise Linux 5.5 con la SUN JDK 6 update 21 il tutto a 32 bit.

Facciamo i seguenti assunti:

• JBoss è installato con l'utente "jboss" nella directory /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as
• la SUN JDK è installata in /usr/java/jdk1.6.0_21
• per questi test utilizziamo il profilo "all" di JBoss

Per abilitare il supporto SSL in JBoss EAP ci sono due strade che si discostano sostanzialmente dall'utilizzo che si deve fare dei certificati:

1. Strada semplice: certificato autofirmato necessario semplicemente per il server
2. Strada complicata: gestione di una Certification Authority, con certificato per il server, certificati per i client e Revocation List

Iniziamo con la strada semplice. Per fare in modo che il nostro Application Server possa creare delle connessioni crittografate con un certificato autofirmato possiamo utilizzare l'utility "keytool" presente nella jdk di SUN.

Con questo comando generiamo una chiave per il server con l'algoritmo RSA denominata "tomcat", la salviamo nel file secure.keystore con la password "jboss123":

keytool -genkey -alias tomcat -keyalg RSA -keystore /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/secure.keystore -storepass "jboss123"

Dopo aver risposto alle domande verrà generata la chiave che potremmo vedere con il comando:

keytool -list -keystore /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/secure.keystore
Enter keystore password: 

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entries

tomcat, Sep 7, 2010, PrivateKeyEntry,
Certificate fingerprint (MD5): 1B:AF:B5:A8:A3:6E:84:96:0F:43:8A:AC:1F:5D:99:32

Adesso configuriamo il tomcat embedded in JBoss per accettare connessioni SSL sulla porta 8443. Nel mio caso nella directory /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/deploy/jbossweb.sar editeremo il file server.xml:

     <!-- SSL/TLS Connector configuration using the admin devl guide keystore -->
      <Connector protocol="HTTP/1.1" SSLEnabled="true"
           port="8443" address="${jboss.bind.address}"
           scheme="https" secure="true" clientAuth="false"
           keystoreFile="${jboss.server.home.dir}/conf/secure.keystore"
           keystorePass="jboss123" keyAlias="tomcat" sslProtocol = "TLS" />


Con la versione JDK 6, il programma keytool è in grado di gestire anche keystore in formato PKCS12, quindi se abbiamo un certificato in questo formato nel nostro caso mycert.p12 lo possiamo andare a gestire anche con il keytool:

keytool -list -keystore mycert.p12 -storetype pkcs12
Enter keystore password: 

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

tomcat, Sep 7, 2010, PrivateKeyEntry,
Certificate fingerprint (MD5): 73:21:5D:3E:B9:5D:B1:98:C7:C3:5F:C3:49:83:BF:33
copiandolo nella directory del nostro profilo con il comando:

cp mycert.p12 /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/conf/

e poi modificando il server.xml in /home/jboss/EnterprisePlatform-5.0.1.CR2/jboss-as/server/all/deploy/jbossweb.sar:


     <!-- SSL/TLS Connector configuration using the admin devl guide keystore -->
      <Connector protocol="HTTP/1.1" SSLEnabled="true"
           port="8443" address="${jboss.bind.address}"
           scheme="https" secure="true" clientAuth="false"
           keystoreFile="${jboss.server.home.dir}/conf/mycert.p12"
           keystorePass="jboss123" keyAlias="tomcat" sslProtocol = "TLS" keystoreType="PKCS12" />

potremo far gestire a JBoss EAP anche direttamente certificati PKCS12.



Nella prossima puntata vedremo la soluzione più complicata.

Giacomo Agosto 2010

Questo è mio figlio Giacomo, nato da pochi giorni e già fan sfegatato di Torre Orsina. Quando è nato pesava 3Kg ed era lungo 50 cm.

Oracle - Analizzare un processo PID Unix Oracle che genera carico sulla macchina.

Con il comando top o con il comando ps individuiamo il processo che carica maggiormente la macchina in termini di CPU utilizzata.

Se il PID del processo Oracle incriminato sul sistema operativo UNIX è ad esempio 27335:

select USERNAME, PID, SPID, ADDR from v$process where spid='27335';


USERNAME       PID SPID ADDR
--------------- ---------- ------------ --------
oracle       210 27335 7D4E1E1C

individuiamo ADDR che ci permette di risalire alla sessione:

column MACHINE format a20
SELECT s.sid, s.command, s.serial#, s.username, s.osuser,  s.machine,  s.program FROM v$session s where s.paddr ='7D4E1E1C';


       SID    SERIAL# USERNAME     OSUSER    MACHINE     PROGRAM
---------- ---------- ------------------------------ ------------------------------ ---------------------------------------------------------------- -----------------------
      2217 43510 SCHEDULER     root    Blade01-Encl1-6     java@Blade01-Encl1-6 (TNS V1-V3)

individuiamo il SID che ci permette di capire quale Query sta impegnado il processo Oracle:

column SQL_TEXT format a60
select s.sid,sq.sql_text from v$session s, v$sqlarea sq where s.SQL_ADDRESS = sq.ADDRESS and s.sql_hash_value=sq.hash_value and s.sid=2217;


       SID SQL_TEXT
---------- ------------------------------------------------------------
      2217 SELECT thes_code, categories_id, thes_id from when_where_has
  _thesaurus_del WHERE thes_code >= :1 AND thes_code < :2 AND
  pico_id = :3 ORDER BY (thes_code) ASC

Oracle - Query più pesanti in termini di lettura su disco

column SQL_TEXT format a20


select sql_text, disk_reads, loads, optimizer_cost, parsing_user_id, serializable_aborts, au.username from gv$sql, all_users au where disk_reads > 10000 and parsing_user_id = au.user_id order by disk_reads desc;

Linux - Filesystem superiori a 2 TeraByte

Red Hat Enterprise Linux 5.1 e successive supportano singoli filesystem fino a 16 Terabyte.

Per creare un filesystem EXT3 superiore a 2 Terabyte bisogna utilizzare il normale LVM e il comando mkfs.ext3 per la formattazione come di seguito spiegato:

pvcreate /dev/sdc
vgcreate VG_Grande /dev/sdc
lvcreate -L 8000G -n LV_Grande VG_Grande
mkfs.ext3 /dev/VG_Grande/LV_Grande

Questo esempio crea un filesystem da 8 Terabyte EXT3 sul device /dev/sdc. ATTENZIONE occorre usare l'intero device, poichè i sistemi di partizionamento come ad esempio fdisk NON supportano partizioni superiori a 2.1 Terabyte.

Per creare un filesystem da 16 Terabyte o comunque superiore a 8 Terabyte occorre utilizzare un blocksize da 4k. Questa è la procedura:

pvcreate /dev/sdc
vgcreate VG_Grande /dev/sdc
lvcreate -L 16000G -n LV_Grande VG_Grande
mkfs.ext3 -F -b 4096 /dev/VG_Grande/LV_Grande

Linux - Lustre - Clustering e Failover

Nel precendete articolo abbiamo implementato una soluzione con un singolo server Lustre, chiaramente questa è una soluzione puramente didattica, poiche' nella realtà dobbiamo prevedere un alta affidabilità del sistema in modo tale da garantire ai Client la continua accessibilità.

Lustre non ha alcun sistema di alta affidabilità, ma si affida a software di clusterware per implementarla, come ad esempio Heartbeat o meglio PaceMaker. Molti clienti però adottando il sistema operativo Red Hat preferiscono utilizzare Red Hat Cluster Suite per l'alta affidabilità, quindi adotteremo quest'ultimo come infrastruttura di clusterware.

Dobbiamo dividere l'implementazione in due parti, la prima riguarda la configurazione da fare al cluster Lustre per dichiarare dei volumi in Failover, la seconda riguarda la configurazione di RHCS.

Dallo schema in figura possiamo desumere che la configurazione sarà effettuata fra due server (192.168.2.20 e 192.168.2.22) sui cui avremo installato preventivamente i pacchetti lustre lato server. La configurazione finale sarà attiva/attiva cioè sul primo nodo denominato cln01 saranno presenti i servizi MGS, MDS e OST0, mentre nel secondo nodo deominato cln02 sarà presente l'OST1. Questo permetterà al client non solo di accedere al filesystem "prova" da due canali iSCSI paralleli, ma anche da due server paralleli aumentando ancora di più il trhoughput.

Configuriamo il nostro filesystem con i seguenti comandi, l'opzione reformat permette di sovrascrivere eventuali precedenti configurazioni:

• dal nodo1: mkfs.lustre --mgs --failnode=192.168.2.22 --reformat /dev/sdb1
• dal nodo1: mkfs.lustre  --reformat --mdt --mgsnode=192.168.2.20 --fsname=prova --failover=192.168.2.22 /dev/sdb4
• dal nodo1: mkfs.lustre  --reformat --ost --mgsnode=192.168.2.20 --failover=192.168.2.22 --fsname=prova /dev/sdb2
• dal nodo2: mkfs.lustre  --reformat --ost --mgsnode=192.168.2.20 --failover=192.168.2.20 --fsname=prova /dev/sdb3

Per avviare i servizi di lustre sarà sufficiente montare i relativi filesystem, prima ci creiamo l'alberatura di mount su entrambi i nodi:

• mkdir -p /lustre/mgs_prova
• mkdir -p /lustre/mdt_prova
• mkdir -p /lustre/ost0_prova
• mkdir -p /lustre/ost1_prova

e quindi montiamo:

• dal nodo1: mount -t lustre /dev/sdb1 /lustre/mgs_prova
• dal nodo1: mount -t lustre /dev/sdb4 /lustre/mdt_prova
• dal nodo1: mount -t lustre /dev/sdb2 /lustre/ost0_prova
• dal nodo2: mount -t lustre /dev/sdb3 /lustre/ost1_prova

dal client la nuova stringa di connessione sarà:

modprobe lustre
mount -t lustre 192.168.2.20@tcp:192.168.2.22@tcp:/prova /prova

Facciamo una prova di switch ad esempio del'ost0 dal nodo1 al nodo2, tenendo sempre il client montato:

dal nodo1: umount -fl /lustre/ost0_prova

attendiamo qualche secondo

dal nodo2: mount -t lustre /dev/sdb2 /lustre/ost0_prova

attendiamo qualche secondo e dal client potremo continuare tranquillamente ad accedere ai nostri file. Nella prossima parte potremo automattizare il processo di failover utilizzando RHCS.


Devo ringraziare per la collaborazione Roberto.

Linux - Lustre - Installazione del Filesystem Lustre

Lustre è un filesystem parallelo distribuito, è in grado di gestire filesystem fino a 10PByte con un thrghtoup aggregato di 100 Gbyte/sec. Supporta nativamente reti Ethernet, 10 GbE, Infiniband, Elan, Myrinet. E' il filesystem più utilizzato fra i Top500 cluster più potenti al mondo. Lustre è un progetto Open Source basato su licenza GPL che gira su sistema operativo Linux.

Le componenti principali di una soluzione Lustre sono:

• MGS - E' il servizio che tiene conto di tutte le configurazioni di un cluster Lustre
• MDS - E' il servizio che gestisce i metadati di un singolo filesystem distribuito
• OSS - E' il servizio che gestisce gli storage server dove vengono salvati i dati
• Client - E' la componente che permette l'accesso al cluster
• LNET - E' il sottosistema di rete nativo di Lustre

Tutte le componenti sono state sviluppate come moduli del kernel, le configurazioni vengono scritte durante la fase di formattazione del filesystem e passate al MGS, non esistono a livello del filesystem alcun file da configurare o configurazione da gestire.

Lustre necessita per le componenti MGS, MDS e OSS il patching del kernel partendo dai sorgenti, per il client è possibile scegliere tra un client patched o patchless, la differenza è in qualche punto percentuale di degrado delle performance. Se non si desidera ricompilare il kernel, vengono resi disponibili gli RPM pre-compilati e già  pronti per le distribuzioni Oracle Linux, Red Hat Enterprise Linux e Suse Linux.

A titolo didattico partiamo con una soluzione, rappresentata in figura, con un unico server Lustre contenente le componenti MGS, MDS e OSS. Tale server dotato di una distribuzione Red Hat Enterprise Linux con kernel 2.6.18-164.11.1.el5 è agganciata a uno storage esterno iSCSI dove verranno ricavate 4 partizioni secondo il seguente schema:

• Target del MGS: partizione /dev/sdb1 da 1 GB
• Target del MDS: partizione /dev/sdb4 da 1 GB
• Due target per la componente di Storage: OST0 /dev/sdb2 da 10GB e OST1 /dev/sdb3 da 10GB

La configurazione appena proposta permetterà  al client di accedere ad un unico filesystem di 20GB composto da due Storage Target in Striping che quindi aggregheranno la banda dei due canali iSCSI e permetteranno migliori performance al client.

La versione di Lustre utilizzata è la 1.8.3, sul client utilizzeremo la configurazione patchless.

Lato server installeremo i seguenti pacchetti con il comando:
rpm -ivh e2fsprogs-1.41.10.sun2-0redhat.rhel5.i386.rpm 

kernel-2.6.18-164.11.1.el5_lustre.1.8.3.i686.rpm  

lustre-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3.i686.rpm  

lustre-ldiskfs 3.0.9-2.6.18_164.11.1.el5_lustre.1.8.3.i686.rpm 

lustre-modules-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3.i686.rpm  --force

e aggiungeremo al file /etc/modprobe.conf la seguente riga per abilitare il sistema LNET su ethernet:
options lnet networks=tcp

riavviamo il server con il kernel appena installato e iniziamo a formattare / configurare Lustre con i seguenti comandi:

• MGS:  mkfs.lustre --mgs /dev/sdb1 
• MDS:  mkfs.lustre --mdt --mgsnode=192.168.2.20 --fsname=prova /dev/sdb4
• OSS0: mkfs.lustre --ost --mgsnode=192.168.2.20 --fsname=prova /dev/sdb2
• OSS1: mkfs.lustre --ost --mgsnode=192.168.2.20 --fsname=prova /dev/sdb3

Per avviare i servizi di lustre sarà  sufficiente montare i relativi filesystem, prima ci creiamo l'alberatura di mount:

mkdir -p /lustre/mgs_prova
mkdir -p /lustre/mdt_prova
mkdir -p /lustre/ost0_prova
mkdir -p /lustre/ost1_prova

e quindi montiamo:

mount -t lustre /dev/sdb1 /lustre/mgs_prova
mount -t lustre /dev/sdb4 /lustre/mdt_prova
mount -t lustre /dev/sdb2 /lustre/ost0_prova
mount -t lustre /dev/sdb3 /lustre/ost1_prova

ATTENZIONE: I filesystem appena montati NON devono essere acceduti, questa operazione serve solamente per avviare i moduli dei servizi server di Lustre.

Lato client installeremo i seguenti pacchetti:
rpm -ivh lustre-client-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3.i686.rpm lustre-client-modules-1.8.3-2.6.18_164.11.1.el5_lustre.1.8.3.i686.rpm

e aggiungeremo al file /etc/modprobe.conf la seguente riga per abilitare il sistema LNET su ethernet:
options lnet networks=tcp

per maggiore sicurezza facciamo un bel reboot del client e proviamo ad accedere al nostro filesystem "prova":
mkdir /prova
modprobe lustre
mount -t lustre 192.168.2.20@tcp:/prova /prova

dovreste vedere il vostro filesystem /prova montato e delle dimensioni di 20GB.

La procedure corretta di stop del cluster Lustre sarà :

1. dal client: umount /prova
2. dal server: umount /lustre/ost1_prova
3. dal server: umount /lustre/ost0_prova
4. dal server: umount /lustre/mdt_prova
5. dal server: umount /lustre/mgs_prova

Devo ringraziare per la collaborazione Roberto.

Cucina - Pesto alla trapanese

Grazie alla mia amica Caterina e soprattutto a suo padre, dopo una serie di tentativi ecco finalmente la ricetta del pesto alla trapanese.

Per 4 persone:
- 100 gr di mandorle
- 3 spicchi di aglio (meglio se aglio rosso IGP di Trapani)
- 150 gr basilico fresco
- pecorino o (se non volete proprio morire) parmigiano
- pomodori pachino
- capperi (meglio se di pantelleria)

Il pesto dovrebbe essere fatto sul mortaio, ma se usate un frullatore viene bene ugualmente e la cosa è più pratica!!! Scottate su un tegamino le mandorle e frullatele. Frullate separatamente anche l'aglio e il basilico. Mettete tutto in una terrina dove insieme con pepe, sale (meglio se proveniente dalle saline di Trapani!!!), il pecorino, abbondante olio e i capperi, mescolerete. Lasciate riposare per un oretta e poi aggiungente i pomodori pachino tagliuzzati, mentre in acqua abbondante fate cuocere la pasta.
Alla fine con un po' di acqua di cottura mantecate il tutto... naturalmente ricetta per ALITI FORTI!!!!

P.S: La foto è stata presa dal sito http://www.sanvitolocapoville.it

Linux - Apache - Ottimizzazioni modulo mod_jk

Al fine di rendere più reattivo un server Apache au Linux a 32 bit, utilizzato come Load Balancer per una infrastruttura di Application Server come ad esempio Tomcat o JBoss possiamo effettuare le operazioni di ottimizzazione sotto descritte.

Occorre innanzitutto determinare la modalità di esecuzione di Apache, in questo caso con il comando apachectl -l determiniamo quali moduli sono caricati, nel nostro caso:

Compiled in modules:

  core.c

  mod_authn_file.c

  mod_authn_default.c

  mod_authz_host.c

  mod_authz_groupfile.c

  mod_authz_user.c

  mod_authz_default.c

  mod_auth_basic.c

  mod_include.c

  mod_filter.c

  mod_log_config.c

  mod_env.c

  mod_setenvif.c

  mod_proxy.c

  mod_proxy_connect.c

  mod_proxy_ftp.c

  mod_proxy_http.c

  mod_proxy_ajp.c

  mod_proxy_balancer.c

  prefork.c

  http_core.c

  mod_mime.c

  mod_status.c

  mod_autoindex.c

  mod_asis.c

  mod_cgi.c

  mod_negotiation.c

  mod_dir.c

  mod_actions.c

  mod_userdir.c

  mod_alias.c

  mod_rewrite.c

  mod_so.c

Quindi notiamo che la modalità di esecuzione è "prefork", andiamo quindi a ottimizzare l'apposito file di configurazione: httpd-mpm.conf

<IfModule mpm_prefork_module>
    StartServers         50
    MinSpareServers      10
    MaxSpareServers      50
    MaxClients          500
    MaxRequestsPerChild 250
</IfModule>
Per quanto concerne il modulo mod_jk effettuiamo le seguenti ottimizzazioni nel file workers.proprieties:

worker.node1.ping_mode=A
worker.node1.ping_timeout=20000
worker.node1.connection_pool_timeout=600
 
per tutti i nodi gestiti dal Load Balancer.

Naturalmente questo tuning lato Apache dovrà essere accompagnato dal tuning sul sistema operativo, quindi nel file /etc/sysctl.conf inseriamo i parametri di ottimizzazione del kernel

net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 20
kernel.shmmax=2147483648
kernel.sem=250 32000 100 128
fs.file-max=794598
net.ipv4.ip_local_port_range=1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144

Linux - JBoss - Ottimizzazioni, perfomance e tuning

Considerando una installazione di JBoss in ambiente Linux a 32 bit. L'utente che esegue JBoss è "root", l'installazione è in /usr/local/jboss-4.0.4.GA


Questo è il file contenente i parametri di ottimizzazione di JBoss: /usr/local/jboss-4.0.4.GA/bin/run.conf in cui sostituiremo la seguente stringa:

JAVA_OPTS="-server -Xms1048m -Xmx1048m -XX:ThreadStackSize=128 -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dfile.encoding=ISO-8859-1 -Duser.timezone=Europe/Rome"

Le opzioni selezionate servono a bilanciare la quantità di Heap Size e il numero di Threads Disponibili, infatti in un ambiente a 32 bit la quantità totale disponibile di memoria per singolo processo è di circa 1.5Mbyte, se l'Heap Size (Xms e Xmx) è troppo alta, la memoria disponibile per i Thread (ThreadStackSize) limita il numero di Thread disponibili.


Nel file /etc/sysctl.conf inseriamo i parametri di ottimizzazione del kernel

net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 20
kernel.shmmax=2147483648
kernel.sem=250 32000 100 128
fs.file-max=794598
net.ipv4.ip_local_port_range=1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144



Nel file /etc/security/limits.conf aumentiamo il numero di file che possono essere aperti, naturalmente se l'utente con cui viene fatto girare JBoss è diverso dovrà essere modificato di conseguenza:

root           soft    nofile          790598
root           hard    nofile          790598



Nel caso di connessioni verso un database Oracle occorre modificare e ottimizzare il seguente file /usr/local/jboss-4.0.4.GA/server/all/deploy/oracle-ds.xml per aumentare il numero di pool di connessioni.

<min-pool-size>100</min-pool-size>
<max-pool-size>100</max-pool-size>

Se JBoss viene indirizzato da un Load Balancer che verifica la disponibilità del servizio attraverso il protocollo AJP è necessario aumentare il tempo di timeout nel file server.xml del Tomcat embedded in JBoss:

 <!-- A AJP 1.3 Connector on port 8009 -->
      <Connector port="8009" address="${jboss.bind.address}"
         emptySessionPath="true" enableLookups="false" redirectPort="8443"
          connectionTimeout="600000" maxThreads="200" keepAliveTimeout="600000"
         protocol="AJP/1.3"/>

Script di start, stop e restart di JBoss da inserire in /etc/init.d/jboss


#!/bin/sh
#
# JBoss Control Script
#
# chkconfig: 3 80 20
# description: JBoss EJB Container
#
# To use this script
# run it as root - it will switch to the specified user
# It loses all console output - use the log.
#
# Here is a little (and extremely primitive)
# startup/shutdown script for RedHat systems. It assumes
# that JBoss lives in /usr/local/jboss, it's run by user
# 'jboss' and JDK binaries are in /usr/local/jdk/bin. All
# this can be changed in the script itself.
# Bojan

# [ #420297 ] JBoss startup/shutdown for RedHat

export JAVA_HOME="/usr/java/jdk1.5.0_10"
export LD_LIBRARY_PATH="/home/oracle/instantclient/lib"
export ORACLE_HOME="/home/oracle/instantclient"
export PATH="/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/java/jdk1.5.0_10/bin:/root/bin"
export TNS_ADMIN="/home/oracle/instantclient"

#define where jboss is
JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss-4.0.4.GA"}

#make java is on your path
JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.5.0_10/bin"}

#define the classpath for the shutdown class
JBOSSCP=${JBOSSCP:-"$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jbossall-client.jar"}

#define the script to use to start jboss
JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c all"}
if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then
  # ensure the file exists
  touch $JBOSS_CONSOLE
fi

if [ -n "$JBOSS_CONSOLE" -a ! -f "$JBOSS_CONSOLE" ]; then
  echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE"
  echo "WARNING: ignoring it and using /dev/null"
  JBOSS_CONSOLE="/dev/null"
fi


#define what will be done with the console log
JBOSS_CONSOLE=${JBOSS_CONSOLE:-"/dev/null"}
CMD_START="cd $JBOSS_HOME/bin; $JBOSSSH"

# inserire la password per lo shutdown
CMD_STOP="$JBOSS_HOME/bin/shutdown.sh -S -u admin -p admin"

# se l'utente è diverso da root inserire il comando su -
SUBIT=""
if [ -z "`echo $PATH | grep $JAVAPTH`" ]; then
  export PATH=$PATH:$JAVAPTH
fi
if [ ! -d "$JBOSS_HOME" ]; then
  echo JBOSS_HOME does not exist as a valid directory : $JBOSS_HOME
  exit 1
fi
echo CMD_START = $CMD_START

case "$1" in
start)
    cd $JBOSS_HOME/bin
    if [ -z "$SUBIT" ]; then
        eval $CMD_START >${JBOSS_CONSOLE} 2>&1 &
    else
        $SUBIT "$CMD_START >${JBOSS_CONSOLE} 2>&1 &"
    fi
    logger "Jboss Started"
    ;;

stop)
    if [ -z "$SUBIT" ]; then
        $CMD_STOP
    else
        $SUBIT "$CMD_STOP"
    fi
    logger "Jboss Stopped"
    ;;

restart)
    $0 stop
        sleep 10
    $0 start
    ;;

*)
    echo "usage: $0 (start|stop|restart|help)"

esac

Linux - Lustre - Gestire una corruzione del filesystem Lustre

Considerando il filesystem lustre montato su /lustrefs e che i server sono così organizzati:

MGS -> /dev/sdb1 -> /lustre/mgs

MDT -> /dev/sdc1 -> /lustre/mdt

OST -> /dev/sdd1 -> /lustre/ost


Smontare lustre da tutti i client con il comando:

#umount /lustrefs

se il filesystem risulta busy lanciare il comando:

#umount -fl /lustre

Smontare dai server tutte le componenti OST, MDT, MGS:

#umount /lustre/ost

#umount /lustre/mdt

#umount /lustre/mgs

eseguire il comando e2fsck -f sui relativi device:

#e2fsck -f /dev/sdb1

#e2fsck -f /dev/sdc1

#e2fsck -f /dev/sdd1

rimontare le componenti di lustre:

#mount -t lustre /dev/sdb1 /lustre/mgs

#mount -t lustre /dev/sdc1 /lustre/mdt

#mount -t lustre /dev/sdd1 /lustre/ost 

effettuare l'abort recovery sugli ost.

con il comando lctl dl | grep obdfilter si verifica il numero della device (è la prima colonna), con il seguente comando si effetta l'abort:

lctl --device >n device< abort_device

occorre a questo punto far collegare un client che forzerà il recovery del client stesso, processo che necessita almeno di 300 secondi. Il count down lo troviamo nel /var/log/messages.

Più informazioni si possono trovare Fsck_Support

Linux - iSCSI - Esportare un device iSCSI con Red Hat

Vediamo come esportare un device iSCSI con Red Hat Enterprise Linux. Occorre innanzitutto procurarsi una Red Hat Enterprise Linux 5.3 o superiore, poichè solamente da questa versione è stato implementato in maniera stabile il sottosistema iSCSI.

Consideriamo di voler esportare il device /dev/hdb da un macchina RHEL 5.3 denominata "nas".

Configurazione server iSCSI

Installare i pacchetti scsi-target-utils e perl-Config che si trovano sotto la directory ClusterStorage del DVD della RHEL 5.3.

Lanciare il demone tgt:

# service tgtd start

Creare un nuovo target denominato nas:storage.disk1:

# tgtadm --lld iscsi --op new --mode target --tid=1 --targetname nas:storage.disk1

Verificare la creazione del nuovo target:

# tgtadm --lld iscsi --op show --mode target

Associare il device /dev/hdb al target denominato nas:storage.disk1 con LUN 1, la LUN 0 è del controller iSCSI:

# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/hdb

Permettere a chiunque (ALL) di connettersi al target:

# tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

Verificare che la porta 3260 sia accessibile da host remoti.

Per rendere persistente ai reboot la configurazione:

# tgt-admin --dump > /etc/tgt/targets.conf 
# chkconfig tgtd on 

Configurazione target iSCSI

Consideriamo di voler importare il device /dev/hdb da un macchina RHEL 5.3 denominata "oracle1".

Installare il pacchetto iscsi-initiator-utils che si trova sotto la directory Server del DVD della RHEL 5.3.
Avviamo il demone iscsid e attiviamo al boot:

#service iscsid start
#chkconfig iscsid on

Verifichiamo quali target vengono esportati dalla nostro server "nas" (occorre sostituire >ip server< con l'ip della macchina "nas"):

#iscsiadm -m discovery -t sendtargets -p >ip server<

Importiamo il target che desideriamo con il seguente comando (occorre sostituire >ip server< con l'ip della macchina "nas" e >target name< con il nome del target che desideriamo importare):

#iscsiadm -m node -T >target name< -p >ip server< -l

La configurazione viene automaticamente salvata e ad ogni riavvio viene importato il target.

Ristoranti - Italia - Dove vale la pena cenare !!!

Ecco alcuni ristoranti dove vale proprio la pena di cenare:

Ristorante Mediterraneo - Lungomare di Acciaroli - Salerno Tel. 0974904747
Cucina ottima di pesce tradizionale. Il posto è molto bello soprattutto se si cena all'ultimo piano con vista sul golfo, anche se il palazzo stesso è un pò un eco-mostro nel contesto del paesetto di Acciaroli. Lista dei vini limitata 35 EURI.

Restorant Alpenrose - Sils-Maria St. Moritz - Svizzera Tel.081 8338008

Cucina di carne rivista in chiave moderna, spettacolare la renna e l'agnello. Lista di vini limitata al locale, ma ottimi. Costo molto elevato!

Ristoranti - Autostrada - Dove mangiare quando si è in viaggio

Quando si viaggia, l'Autogrill è la sosta obbligata... ma è proprio così? Esistono dei ristoranti nelle vicinanze delle Autostrade che possono accoglierci per un buon pasto? Ecco alcuni consigli:

Ristorante Opera Ghiotta - Via bachelet 12 - San Giorgio di Mantova - Tel. 0376374248
Uscita Mantova Nord A22
E' un presidio  SlowFood, ottima la cucina, ottima la carta dei vini, buono il prezzo ed è proprio sull'uscita dell'Autostrada. 30 EURI.

Ristorante Genovese - Corso Roma 19 - Rapallo - Tel. 018561111
Uscita Rapallo A12 ‎
La cucina della signora è ottima. Si consigliano i primi, dato che la pasta la producono direttamente loro e freshissimo il pesce. 35 EURI.

Ristorante I Casolari - Via di Persignano - Terranuova Bracciolini - Tel. 055969390
Uscita Valdarno A1‎
Per provare la vera fiorentina... ma attenzione a non bere troppo Chianti... poi occorre guidare!!! 40 EURI.

Ristorante Il Boccone del Prete - Via E.Bellini, 12/14 - Porano - Tel. 0763374772
Uscita Orvieto A1‎
Ottimo locale con vista sulla cattedrale di Orvieto. Inserito in grotta, offre piatti della tradizione Ternana. 30 EURI.