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
Iscriviti a:
Post (Atom)
