Esiste un tool grafico per creare chiavette USB bootabili con varie distribuzioni Linux, ma mi sembra molto più veloce utilizzare la linea di comando:
livecd-iso-to-disk --format --reset-mbr Fedora-13-i686-Live.iso /dev/sdb1
25 aprile 2011
Linux - Multipath - Supporto multipath.conf per Storage SUN/ORACLE
Questa è la configurazione del multipath.conf per i seguenti storage:
ATTENZIONE nella RHEL 6 alcuni comandi sono cambiati!!!
multipath.conf :
defaults {
udev_dir /dev
polling_interval 5
selector "round-robin 0"
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker rdac
rr_min_io 1000
rr_weight uniform
user_friendly_names no
bindings_file "/var/lib/multipath/bindings"
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
devices {
device {
vendor "SUN"
product "STK6580_6780"
product_blacklist "Universal Xport"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_rdac /dev/%n"
features "0"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry queue
rr_min_io 1000
path_checker rdac
}
device {
vendor "STK"
product "OPENstorage D280"
product_blacklist "Universal Xport"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_rdac /dev/%n"
features "0"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry queue
rr_min_io 1000
path_checker rdac
}
}
- StorageTek - SUN - Oracle FlexLine 240/280
- StorageTek - SUN - Oracle 6580/6780
Il device multipath è la tecnologia di multipath verso lo Storage di Red Hat Enterprise Linux 5.x e altre distribuzioni Linux.
ATTENZIONE nella RHEL 6 alcuni comandi sono cambiati!!!
multipath.conf :
defaults {
udev_dir /dev
polling_interval 5
selector "round-robin 0"
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker rdac
rr_min_io 1000
rr_weight uniform
user_friendly_names no
bindings_file "/var/lib/multipath/bindings"
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
devices {
device {
vendor "SUN"
product "STK6580_6780"
product_blacklist "Universal Xport"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_rdac /dev/%n"
features "0"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry queue
rr_min_io 1000
path_checker rdac
}
device {
vendor "STK"
product "OPENstorage D280"
product_blacklist "Universal Xport"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_rdac /dev/%n"
features "0"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry queue
rr_min_io 1000
path_checker rdac
}
}
02 novembre 2010
Linux - VirtualBox - Hit and Tricks
Come condividere un disco fra due macchine virtuali:
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
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:
- Installare i Guest Additions
- 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)
- Avviare la macchina virtuale e montare il disco condiviso il comando:
#mount -t vboxsf -o uid=1000,gid=1000 SharedFolder /media
04 ottobre 2010
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
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.
10 settembre 2010
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:
Per abilitare il supporto SSL in JBoss EAP ci sono due strade che si discostano sostanzialmente dall'utilizzo che si deve fare dei certificati:
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.
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:
- Strada semplice: certificato autofirmato necessario semplicemente per il server
- 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.
17 agosto 2010
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.
15 agosto 2010
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
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;
26 luglio 2010
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
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
20 maggio 2010
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:
Per avviare i servizi di lustre sarà sufficiente montare i relativi filesystem, prima ci creiamo l'alberatura di mount su entrambi i nodi:
e quindi montiamo:
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.
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.
13 maggio 2010
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:
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:
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
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:
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à :
Devo ringraziare per la collaborazione Roberto.
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 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 --forcee 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
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à :
- dal client: umount /prova
- dal server: umount /lustre/ost1_prova
- dal server: umount /lustre/ost0_prova
- dal server: umount /lustre/mdt_prova
- dal server: umount /lustre/mgs_prova
Devo ringraziare per la collaborazione Roberto.
03 aprile 2010
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
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
09 marzo 2010
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:
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
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:
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
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"/>
<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
27 gennaio 2010
Linux - Lustre - Gestire una corruzione del filesystem Lustre
Considerando il filesystem lustre montato su /lustrefs e che i server sono così organizzati:
Smontare lustre da tutti i client con il comando:
se il filesystem risulta busy lanciare il comando:
Smontare dai server tutte le componenti OST, MDT, MGS:
eseguire il comando e2fsck -f sui relativi device:
rimontare le componenti di lustre:
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
MGS -> /dev/sdb1 -> /lustre/mgs
MDT -> /dev/sdc1 -> /lustre/mdt
OST -> /dev/sdd1 -> /lustre/ostSmontare 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
26 gennaio 2010
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:
Creare un nuovo target denominato nas:storage.disk1:
Verificare la creazione del nuovo target:
Associare il device /dev/hdb al target denominato nas:storage.disk1 con LUN 1, la LUN 0 è del controller iSCSI:
Permettere a chiunque (ALL) di connettersi al target:
Verificare che la porta 3260 sia accessibile da host remoti.
Per rendere persistente ai reboot la configurazione:
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:
Verifichiamo quali target vengono esportati dalla nostro server "nas" (occorre sostituire >ip server< con l'ip della macchina "nas"):
La configurazione viene automaticamente salvata e ad ogni riavvio viene importato il target.
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 startCreare un nuovo target denominato nas:storage.disk1:
# tgtadm --lld iscsi --op new --mode target --tid=1 --targetname nas:storage.disk1Verificare la creazione del nuovo target:
# tgtadm --lld iscsi --op show --mode targetAssociare 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/hdbPermettere a chiunque (ALL) di connettersi al target:
# tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALLVerificare 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<
#iscsiadm -m node -T >target name< -p >ip server< -lLa configurazione viene automaticamente salvata e ad ogni riavvio viene importato il target.
24 gennaio 2010
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!
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!
17 gennaio 2010
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.
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.
21 dicembre 2009
Cucina - Salmi di cinghiale
Per 4 persone:
- 1 kg di cinghiale tagliato a pezzi medio-grandi
- 1 litro di vino rosso meglio se Barbera
- 1 cipolla, 1/2 aglio, alloro, chiodi di garofano (pochi), 1 ramo di rosmarino, 1 costa di sedano, 2 carote, timo, salvia
- burro
Far frollare per almeno 12 ore il cinghiale con cipolla, aglio, alloro, chiodi di garofano, rosmarino, sedano, carote, timo, salvia e coprite il tutto con il vino. Dopo la frollatura estrarre i pezzi di cinghiale, asciugarli e rosolarli con burro per qualche minuto.
Rimettere il cinghiale nella pentola e far andare per almeno 2 ore a fuoco lento.
Finita la cottura è possibile prendere tutto il sugo e frullarlo per far diventare una salsa fluida, oppure lasciare così com'è il sugo e servire con lenticchie o polenta.
Buon appetito!!!
- 1 kg di cinghiale tagliato a pezzi medio-grandi
- 1 litro di vino rosso meglio se Barbera
- 1 cipolla, 1/2 aglio, alloro, chiodi di garofano (pochi), 1 ramo di rosmarino, 1 costa di sedano, 2 carote, timo, salvia
- burro
Far frollare per almeno 12 ore il cinghiale con cipolla, aglio, alloro, chiodi di garofano, rosmarino, sedano, carote, timo, salvia e coprite il tutto con il vino. Dopo la frollatura estrarre i pezzi di cinghiale, asciugarli e rosolarli con burro per qualche minuto.
Rimettere il cinghiale nella pentola e far andare per almeno 2 ore a fuoco lento.
Finita la cottura è possibile prendere tutto il sugo e frullarlo per far diventare una salsa fluida, oppure lasciare così com'è il sugo e servire con lenticchie o polenta.
Buon appetito!!!
22 novembre 2009
Cucina - Linguine al tartufo - Autunno umbro!!!
Le linguine al tartufo o gli spaghetti al tartufo sono uno dei quei piatti semplici della mia terra: la Valnerina.
In questa ricetta consigliamo il tartufo nero "estivo" detto anche scorzone per due buoni motivi fondamentali: il costo e l'odore. Il tartufo nero "estivo" costa circa un decimo di quello nero "invernale" ed inoltre ha un sapore molto molto forte di quest'ultimo e quindi lo possiamo somministrare a chiunque. Chiaramente l'estimatore di quest'ultimo potrà sempre sostituire il tartufi "estivo" con quello invernale.
Per 2 persone (con abbondanza) occorrono:
- aglio, meglio se rosso della zona di Trapani
- olio, meglio se Umbro della Valnerina o della zona di Trevi
- prezzemolo fresco
- tartufo "estivo"
- 300g di linguine o spaghetti meglio se lavorati al bronzo
Il procedimento viene effettuato tutto esclusivamente a freddo. Occorre grattuggiare finemente il tubero, si taglia a pezzettini l'aglio e il prezzemolo, si fanno insaporire insieme all'olio che deve ricoprire il tutto per almeno 3 ore (meglio se tutto il giorno). Si fanno bollire le linguine in tanta acqua con sale grosso, scolando la pasta si mantiene un po' di acqua di cottura. Si manteca la pasta con il tartufo e l'acqua di cottura a fuoco vivace. Il risultato è notevole.
In questa ricetta consigliamo il tartufo nero "estivo" detto anche scorzone per due buoni motivi fondamentali: il costo e l'odore. Il tartufo nero "estivo" costa circa un decimo di quello nero "invernale" ed inoltre ha un sapore molto molto forte di quest'ultimo e quindi lo possiamo somministrare a chiunque. Chiaramente l'estimatore di quest'ultimo potrà sempre sostituire il tartufi "estivo" con quello invernale.
Per 2 persone (con abbondanza) occorrono:
- aglio, meglio se rosso della zona di Trapani
- olio, meglio se Umbro della Valnerina o della zona di Trevi
- prezzemolo fresco
- tartufo "estivo"
- 300g di linguine o spaghetti meglio se lavorati al bronzo
Il procedimento viene effettuato tutto esclusivamente a freddo. Occorre grattuggiare finemente il tubero, si taglia a pezzettini l'aglio e il prezzemolo, si fanno insaporire insieme all'olio che deve ricoprire il tutto per almeno 3 ore (meglio se tutto il giorno). Si fanno bollire le linguine in tanta acqua con sale grosso, scolando la pasta si mantiene un po' di acqua di cottura. Si manteca la pasta con il tartufo e l'acqua di cottura a fuoco vivace. Il risultato è notevole.
Iscriviti a:
Post (Atom)
