Linux - Creare una chiavetta USB bootable con Fedora

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

Linux - Multipath - Supporto multipath.conf per Storage SUN/ORACLE

Questa è la configurazione del multipath.conf per i seguenti storage:

• 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
       }
  }

Linux - VirtualBox - Hit and Tricks

Come condividere un disco fra due macchine virtuali:

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

Innanzitutto creiamo il disco da condividere con il comando VBoxManage:

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

Agganciamo le due macchine virtuali:

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

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

Come abilitare USB su Fedora 12 host:

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


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


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


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


vboxusers:x:501:paciucci


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


mkdir /tmp/usbfs


e aggiungiamo a /etc/fstab la seguente riga:


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


dove il devgid è il gid del gruppo vboxusers.


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


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


VBoxManage list usbhost

Come clonare un disco di VirtualBox:

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

#VBoxManage clonevdi input.vdi output.vdi

Come abilitare uno Shared Folder fra macchine Linux:

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

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

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

Linux - JBoss - Configurazione SSL e gestione Certification Authority

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

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

Facciamo i seguenti assunti:

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

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

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

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

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

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

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

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

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entries

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

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

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


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

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

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

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

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

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


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

potremo far gestire a JBoss EAP anche direttamente certificati PKCS12.



Nella prossima puntata vedremo la soluzione più complicata.

Linux - Filesystem superiori a 2 TeraByte

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

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

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

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

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

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

Linux - Lustre - Clustering e Failover

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

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

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

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

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

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

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

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

e quindi montiamo:

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

dal client la nuova stringa di connessione sarà:

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

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

dal nodo1: umount -fl /lustre/ost0_prova

attendiamo qualche secondo

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

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


Devo ringraziare per la collaborazione Roberto.

Linux - Lustre - Installazione del Filesystem Lustre

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

Le componenti principali di una soluzione Lustre sono:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

e quindi montiamo:

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

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

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

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

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

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

La procedure corretta di stop del cluster Lustre sarà :

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

Devo ringraziare per la collaborazione Roberto.

Linux - Apache - Ottimizzazioni modulo mod_jk

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

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

Compiled in modules:

  core.c

  mod_authn_file.c

  mod_authn_default.c

  mod_authz_host.c

  mod_authz_groupfile.c

  mod_authz_user.c

  mod_authz_default.c

  mod_auth_basic.c

  mod_include.c

  mod_filter.c

  mod_log_config.c

  mod_env.c

  mod_setenvif.c

  mod_proxy.c

  mod_proxy_connect.c

  mod_proxy_ftp.c

  mod_proxy_http.c

  mod_proxy_ajp.c

  mod_proxy_balancer.c

  prefork.c

  http_core.c

  mod_mime.c

  mod_status.c

  mod_autoindex.c

  mod_asis.c

  mod_cgi.c

  mod_negotiation.c

  mod_dir.c

  mod_actions.c

  mod_userdir.c

  mod_alias.c

  mod_rewrite.c

  mod_so.c

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

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

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

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

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

Linux - JBoss - Ottimizzazioni, perfomance e tuning

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


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

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

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


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

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



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

root           soft    nofile          790598
root           hard    nofile          790598



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

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

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

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

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


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

# [ #420297 ] JBoss startup/shutdown for RedHat

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

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

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

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

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

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


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

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

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

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

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

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

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

esac

Linux - Lustre - Gestire una corruzione del filesystem Lustre

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

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

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

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


Smontare lustre da tutti i client con il comando:

#umount /lustrefs

se il filesystem risulta busy lanciare il comando:

#umount -fl /lustre

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

#umount /lustre/ost

#umount /lustre/mdt

#umount /lustre/mgs

eseguire il comando e2fsck -f sui relativi device:

#e2fsck -f /dev/sdb1

#e2fsck -f /dev/sdc1

#e2fsck -f /dev/sdd1

rimontare le componenti di lustre:

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

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

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

effettuare l'abort recovery sugli ost.

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

lctl --device >n device< abort_device

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

Più informazioni si possono trovare Fsck_Support

Linux - iSCSI - Esportare un device iSCSI con Red Hat

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

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

Configurazione server iSCSI

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

Lanciare il demone tgt:

# service tgtd start

Creare un nuovo target denominato nas:storage.disk1:

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

Verificare la creazione del nuovo target:

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

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

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

Permettere a chiunque (ALL) di connettersi al target:

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

Verificare che la porta 3260 sia accessibile da host remoti.

Per rendere persistente ai reboot la configurazione:

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

Configurazione target iSCSI

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

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

#service iscsid start
#chkconfig iscsid on

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

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

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

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

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

Linux - PS3 - Conversione filmati compatibili con PS3

Carissimi,
dopo una domenica di prove sono riuscito a trovare il formato audio e video testato e funzionante per la mia PS3. Il mio obiettivo era quello di trasformato un filmato in formato avi e similare, in un filmato compatibile e leggibile da una PS3 slim (da poco acquistata).
Il fedele ffmpeg mi è stato di grandissimo aiuto e ha risolto il problema!!!

ffmpeg -i filmato.avi -g 300 -bf 2 -vcodec mpeg2video -sameq -acodec ac3 -ac 2 -ab 384000 -f vob -copyts filmato.vob

Tanto per commentare le varie opzioni:
-g 300 -bf 2 : servono per migliorare la qualità del encoding mpeg
-vcodec mpeg2video : è il tipo di encoding video scelto (ho provato xvid e mpeg4 senza successo)
-sameq : stessa qualità del video di partenza (il file risultante diventa grande!!!)
-acodec ac3 -ac 2 : codec audio di tipo ac3 a 2 canali (funziona anche il 5.1 mettondo l'opzione -ac 6)
-ab 384000 : l'audio è a 384kbit/s (ottima qualità)

Dato che il file di uscita sarà sicuramente grande, vi conviene utilizzare una chiavetta USB per trasferire il file e ricordatevi di trasferirlo sul HD della PS3 prima di riprodurlo.

Saluti

Linux - YouTube - Download e conversione dei filmati di youtube

Scaricare e convertire i filmati di youtube è molto semplice se hai una distribuzione Fedora Linux. Occorre scaricare i pacchetti youtube-dl e ffmpeg.

Il primo serve per scaricare il file flash dal sito di youtube e il secondo per convertirlo in formato avi o mpeg.
Tali software si trovano nei repository "Fusion" di Fedora, quindi è necessario abilitarlo e usare il mitico "yum" per installare i pacchetti.
Per scaricare un video è sufficiente eseguire il seguente comando:

youtube-dl -d -b http://www.youtube.com/watch?v=897lIVkRmVM

l'opzione -d permette di scaricare il video in formato HQ, l'opzione -b abilita la massima qualità possibile.

Per convertire in AVI sarà poi sufficiente lanciare il comando:

ffmpeg -i 897lIVkRmVM.flv sensation.avi

Saluti e buona visione

Linux - SAN - Aggiunta di una LUN a caldo con multipath

Carissimi lettori, 

un piccolo post per indicare i passi necessari per aggiungere una LUN a caldo ad un server Linux con Red Hat Enterprise Linux 4 o 5 agganciato a una Storage Area Network che supporti il device mapper multipath.

Iniziamo con effettuare il rescan delle HBA, considerando che le HBA sono gli scsi host 6 e 7 questa sarà il comando da lanciare come utente root:

#echo "- - -" > /sys/class/scsi_host/host6/scan
#echo "- - -" > /sys/class/scsi_host/host7/scan

automaticamente il sistema se già presente e configurato crearà i device associati alle nuove LUN con la sintassi tradizionale del device mapper multipath, ad esempio:

/dev/mapper/mpath5

a questo punto se vogliamo avere una nomenclatura più userfriendly possiamo editare il file

/etc/multipath.conf andando ad associare il wwid con la nomenclatura da noi scelta.

A questo punto effettuiamo un flush dei device multipath con il comando:

#multipath -F

Tale comando eliminerà tutti i device multipath NON utilizzati, quelli utilizzati da qualche applicazioni non verranno toccati.

Riagganciamo i device alle LUN utilizzando la nomenclatura configurata con il comando:

#multipath -v2

Nella directory /dev/mapper troveremo i device con la denominazione (alias) impostata nel file multipath.conf.

Saluti