In questi giorni, avendo un pochino di tempo a disposizione mi sono deciso a dedicarne una parte al blog che da un po’ di tempo giaceva abbandonato.
Mentre davo un’occhiata alle statistiche generate da “Statpress” ho notato che i dati venivano estratti con estrema lentezza e nonostante il server sul quale risiede attualmente Mysql non sia un fulmine (devo decidermi a mettere in produzione la nuova VM) non era sicuramente una situazione “accettabile”.
Fatta una piccola analisi alla tabella di Statpress (wp_statpress) ho notato un indice solo sul campo “id” che da un’occhiata veloce al codice del plugin sembra anche essere inutile, anzi un indice sul campo “date” e sul campo “time”, seppur contenente valori non univoci, avrebbe giovato.
Ho provveduto quindi alla creazione degli indici.

Per il campo “date”:

Per il campo “time”:

Per verificare:

Risultato: Un quarto, circa, del tempo precedente per estrarre le statistiche.

Come trarre vantaggio dalla virtualizzazione annidata?
Probabilmente molti di voi si chiederanno che senso può avere creare più strati di virtualizzazione, la risposta è semplice: NON HA NESSUN SENSO…o quasi!.
Se osserviamo la cosa dal punto di vista “utilizzo delle risorse” non ha appunto nessun senso, se non quello di complicarsi la vita, ma se la osserviamo dal punto di vista “analisi e troubleshooting” probabilmente potrebbe averne.
Avere la responsabilità della gestione del server ESX comporta anche avere la responsabilità delle macchine virtuali ivi ospitate, occorre quindi prestare molta cura alla salute dell’host ESX.
Il rinnovo tecnologico, l’evoluzione della tecnologia della virtualizzazione stessa, generano inevitabilmente delle complicazioni che spesso si traducono nella necessità di installare upgrade oppure fix dell’hipervisor, che al loro volta introducono ulteriori complicazioni, infatti non sempre le procedure di fix o di upgrade di un sistema sono indolori.
Da tutto ciò, nasce la necessità di compiere analisi e verifiche in tal senso.
Ecco come installare un Virtual ESX (vESX):

Create una VM “custom”
Operative System: Linux Red Hat Enterprise 5 (64 bit)
Virtual Processors: 1 (o anche più, avendo cura di impostare l’affinity di ciascun Virtual Processor su altrettanti Phisical Processor)
Memory Size: 2048 MB
Network Adapter: 2 (E1000)
SCSI controller type: LSI Logic parallel
Disk Size: Quanto basta
Montate la iso di VMWare ESX 4 e procedete con l’installazione come fareste per qualsiasi altra VM.

Terminata l’installazione, per accedere al vESX, dovete apportare qualche modifica alla configurazione del “vero” hypervisor, in particolare è necessario impostare la scheda di rete al quale è “bindato” il virtal switch che ospita linterfaccia di rete oppure la VLAN del vESX in modalita “promisqua” (promiscuous mode) affinche possa ricevere tutto il traffico di rete e propagarlo a sua volta al virtual switch del vESX stesso.

Attraverso il client vSphere, potrete adesso accedere al vESX e configurarlo per eseguire tutte le prove desiderate.

Nel prossimo articolo spiegherò come creare Virtual Machines all’interno del vESX appena installato.

Dovendo installare due firewall (Checkpoint) su hardware Sun, ho dovuto “rispolverare” le mie ormai sepolte conoscenze del sistema operativo Unix proprietario di casa Sun Microsystem (di recente acquisizione Oracle).
Devo dire, una volta terminato, che l’operazione non è poi stata così ardua, anzi il risultato ottenuto si presenta pulito e ordinato.
I server utilizzati sono due Netra T1 105 con processory UltraSPARC-II 440MHz (hardware di del 2002 o giù di lì) 512 MB di RAM 2 dischi da 18 GB, 2 schede di rete onboard, una scheda di rete “qfe” (Quad Fast Ethernet) e ovviamente NESSUN lettore cdrom.
Per coloro non avvezzi a questo tipo di hardware, è bene specificare che la famiglia Netra in genere viene fornita SENZA cdrom e non ha (nel senso che NON ESISTE) scheda grafica; l’output video viene inviato alle (2) “LOM” (Lights Out Manager) in pratica, delle porte seriali.
Per l’installazione, non potendo utilizzare la rete vicino ai server per il “Jumpstart” (installazione da rete), ho optato per un lettore CDROM collegato alla posta scsi esterna e una volta installato il sistema operativo minimale (poichè si tratta di firewall) avendo necessità di accedere ai packages necessari ad installare il resto dei servizi “essenziali”, ho realizzato tre immagini ISO dei cdrom (2 per l’OS + 1 per la patch “recommended”), che ho poi trasferto sui dischi interni servendomi del servizio FTP.
Avendo quindi necessità di “saltare” da un disco all’altro, alla ricerca di quanto necessario, per “montare” e “smontare” le ISO velocemente, senza dovermi preoccupare di quale immagine fosse in uso al momento, ho realizzato questo script, che permette di montare l’immagine al “volo” senza dovermi preoccupare di verificare se e quale delle tre fosse in uso.
Lo script è “essenziale”, ovviamente è possibile migliorarlo introducendo qualche controllo di errore, ma sicuramente svolge bene il proprio compito anche così.

La shell utilizzata è la Bash, su Solaris 8 non si tratta di un package installato di default, va quindi installata manualmente dal cdrom #2.

#!/usr/bin/bash

MPOINT=/mnt/iso
LOOPDEV=""
ISOFILE=$2

showhelp() {

   echo "Usage:
                $0 { isomount isofile }
                $0 { isoumount }
                $0 { status }"
   echo

   exit 1

  }

checkavail() {

        AVAIL=`df -k "$MPOINT" |grep "$MPOINT"`
  }

isoumount() {

        checkavail
        if [ -n "$AVAIL" ]
        then
                LOOPDEV=`df -k "$MPOINT" |grep "$MPOINT" | awk
 '{ print $1 }'`
                umount $MPOINT
                lofiadm -d $LOOPDEV
        fi

  }

isomount() {

        if [ ! -d $MPOINT ]
        then
                mkdir -p $MPOINT
        fi

        x=1

        while [ $x -eq 1 ]
        do
                checkavail

                if [ -z "$AVAIL" ]
                then
                        LOOPDEV=`lofiadm -a $ISOFILE`
                        mount -F hsfs -o ro $LOOPDEV $MPOINT
                        echo `df -k "$MPOINT" |grep "$MPOINT"`
        else
                        isoumount
                        x=$(( $x + 1 ))
                fi
                x=$(( $x - 1 ))
        done

  }

status() {

        STATUS=`df -k "$MPOINT" |grep "$MPOINT"`
        if [ -n "$STATUS" ]
        then
                echo "$STATUS"
        else
                echo "Nothing Mounted on $MPOINT"
        fi

  }

if [[ "$1" == "isomount" && -z "$2" ]]
then
        showhelp
fi

case "$1" in
  isomount)
    isomount
    ;;

  isoumount)
    isoumount
    ;;

  status)
    status
    ;;

  *)
    showhelp
esac

exit $?

Dopo l’uscita di Microsoft Windows 7 era venuta l’ora di metterci un pò le mani.
Anticipo subito che lavoro principalmente ancora con il buon vecchio client WindowsXP, ed ho sempre cercato di evitare Vista, quindi ho poco confronto con il suo diretto predecessore ma ho subito trovato Seven molto veloce e molto più stabile di Vista.

Dopo alcune ore passate su di esso ho avuto la necessità di sposare, come di consueto per le mie installazioni, la folder Users al di fuori della partizione dedicata al sistema operativo C:
Per fare ciò sono disponibili anche in windows (cosa ben nota agli utenti unix) i link
si chiamano “juntion points” e con questi possiamo personalizzare al meglio senza rischi la nostra struttura Windows

Eccone la procedura seguita per spostare la cartella Users in un’altra partizione in Windows 7:

1- Instalare l’S.O.
2- Riavviate il PC con il DVD di Win7 o con una chiavetta di recovery win7 ed entrare nel prompt di ms-dos
3- digitate i seguenti comandi:
> diskpart
> list disk
> sel disk 0 (il disco principale)
> list part
> sel part 1 (di solito quella Riservata – 100Mb)
> Assign letter=Z (lettera a caso)
> sel part 2 (quella dove avete installato il sistema operativo)
> assign letter=C
> sel part 3 (quella dove volete creare la nuova Users Folder)
> assign letter=D
> exit
4- siete tornati a X:\Sources, eseguite questi comandi
> mkdir D:\Users
> robocopy C:\Users D:\Users /mir /e /xj
> rmdir /s /q C:\Users
> mklink /j C:\Users D:\Users
> mklink /j “C:\Documents and Settings” D:\Users
5- Riavviate

Così facendo avete spostato i dati in una cartella D:\Users e lasciata intatta la configurazione dei registri
Windows cercerà ancora di scrivere sulla partizione C: ma attraverso il juntion point verrà re-diretto sull’altra partizione.

Attenzione ad usare con cautela questa procedura e ricordatevi che in caso di reinstallazione/restore dovrete rimodificare la configurazione.

Queste tipo di directory/link sono utili anche in caso vogliate sposare altre cartelle, esempio la PROGRAM FILES o altro su cui non vi basta lavorare con le variabili di sistema

Ebbene si’, anche io, mio malgrado, sono passato a Windows 7.
Purtroppo era diventato impossibile lavorare con Windows Vista e Windows XP a 64 bit non e’ il massimo.
Appena terminata l’installazione ho cominciato a “destreggiarmi” tra i vari menu, installando per primi i programmi “utili” e proprio terminata l’installazione di “VMware vSphere Client”, provando ad accedere al Virtual Center, mi e’ comparso il seguente errore:

e successivamente:

Ovviamente, conscio che qualcosa non avrebbe funzionato con la nuova versione di Windows, mi sono messo alla ricerca di una possibile soluzione.
Il sito VMware propone l’aggiornamento a vSphere 4 Update 1 per supportare Windows 7 e Windows 2008 R2, ma in attesa di procedere con l’aggiornamento, prendendo vari spunti qua’ e la’ ecco il “Workaround”.

Fase 1

• Procuratevi il file “System.dll” da un sistema operativo diverso da Windows 7 sul quale e’ installato il framework 3.5 (il file lo trovate in %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\), considerando, qualora utilizziate un sistema a 64 bit, di prelevare la versione del file a 32 bit (il client vSphere e’ comunque a 32 bit)

Fase 2

• Copiate il file in una directory creata ad hoc (es. lib) in %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher

Fase 3

• Editate il file VpxClient.exe.config inserendo il blocco

  <runtime>
  <developmentMode developerInstallation="true"/>
  </runtime>

  appena prima del tag “</configuration>”

Fase 4

• Lanciate SystemPropertiesAdvanced.exe, premete il pulsante ‘Variabili d’ambiente‘ e create la variabile di sistema “DEVPATH” con riferimento alla directory contenente il file “System.dll” (Fase 2).

Dopo aver riavviato l’istanza di Explorer.exe oppure il computer, per rendere la variabile visibile al sistema, dovreste poter accedere al Virtual Center.

Può capitare a volte, per un motivo o per l’altro, di avere bisogno di un tunnel privato che ci colleghi ad un host remoto garantendo sicurezza e stabilità. Connessioni di questo tipo trovano largo impiego sia in ambito aziendale che privato, sebbene non tutte le soluzioni esistenti siano economiche o facili da realizzare.

Vediamo ora com’è possibile realizzare un tunnel fra due macchine senza necessità di agire su firewall per impostare regole di port forwarding.

Supponendo di volerci collegare alla macchina A alla macchina B, su cui sia già installato un server SSH, fra i vari client utilizzabili a tale scopo c’è Putty: leggero ed Open Source, non richiede installazione, e fa al caso nostro per risolvere la questione che ci siamo posti.

Aprendo Putty, inseriamo l’indirizzo della nostra macchina B verso cui vorremmo collegarci:

Spostiamoci poi nel menù a sinistra, verso il basso, aprendo il sottomenù Tunnels come in figura:

Qui, scegliamo Dynamic fra le scelte multiple in basso, immettiamo nel campo Source port la porta verso cui la macchina remota si collegherà alla nostra per aprire il tunnel (non è necessario che questa sia aperta verso l’esterno, poiché la connessione avverrà in reverse) e lasciamo bianco il campo Destination.

A questo punto, premendo Add dovrebbe comparire nell’elenco Forwarded ports la porta che abbiamo scelto, preceduta da una D:

La configurazione è finita, prememdo su Open si instaurerà la connessione, e una volta autenticatici nel server come di consueto avremo creato il nostro tunnel. Un esempio di utilizzo: proxy SOCKS – anche per accesso a servizi nella lan locale della macchina cui ci siamo collegati.

Impostando su FireFox come proxy SOCKS l’indirizzo localhost e come porta quella che abbiamo poc’anzi specificato, navigheremo usando la macchina remota come tramite.

Linux, da sempre, si è dimostrato essere un sistema operativo eccellente in termini di performance e parsimonioso in termini di risorse, ricco di evoluzioni e aggiornamenti da parte delle fitta schiera di sviluppatori che partecipano al progetto. Questi aggiornamenti, se riguardano i vari software o librerie, vengono rilasciati dalle varie comunità sotto forma di “package”, ma se un aggiornamento riguarda il kernel, questo viene rilasciato sotto forma di file .patch. Un file patch non è altro che un file contenente le istruzione codificate (in C oppure C++) che dovranno essere aggiunte e/o rimosse dal file originale.
Ma come applicare questi aggiornamenti al codice sergente del kernel?
Utilizzando il comando “patch”, come illustrato di seguito.

Assumendo che i sorgenti del kernel sul quale applicare le patch si trovino nella directory /usr/src/linux-2.6 oppure in /usr/src/linux, copiare il file .patch in /usr/src e digitare il seguente comando:

$ patch -p1 < /usr/src/file.patch

E' possibile simulare l'installazione della patch e verificare la presenza di errori indicando l'opzione —dry-run (nessun file sarà modificato).