Sam & Micro

L’HP MicroServer offre un totale di 4 bay da 3.5″ per hardisk LFF e 1 bay per unità da 5.25″ (unità ottiche o a nastro). Normalmente solo un cassettino degli HDD è popolato, gli altri tre sono vuoti.

Qual’ora si volesse aggiungere ulteriori dischi HP fornisce tutti gli strumenti e i materiali necessari al montaggio. Dietro allo sportellino frontale infatti si trovano due set di viti (per 3.5″ e per 5.25″) e la brugola adatta all’utilizzo con le viti fornite (serve anche per poter smontare la mainboard ndr.).

Dal manuale:

Il post è dedicato a Michele

Oramai è prassi diffusa l’utilizzo di un front controller nelle applicazioni web. Per implementarlo correttamente è necessario che il web server effettui delle rewrite dell’URL.

Se si utilizza Apache non è un grosso problema poiché quasi tutti i software che richiedono l’esecuzione di una o più rewrite contengono il file .htaccess pronto all’uso.

Per nginx c’è l’utilissima funzione try_files

try_files $uri $uri/ /index.php?url=$uri;

Per lighttpd? E’ possibile implementare anche in lighttpd una funzione simile alla try_files di nginx tramite una rewrite

url.rewrite-once = ( "^/(.*)\.(.*)" => "$0", "^/([^.]+)$" => "/index.php?url=$1" )

Questa regola, alla pari di try_files, verifica che la risorsa richiesta esista: nel caso di esito positivo non avviene la rewrite, mentre se non esiste l’uri viene passata al front controller.

Per poterla utilizzare il modulo mod_rewrite deve essere caricato

server.modules  += ( "mod_rewrite" )

A volte può capitare la necessità di effettuare tunneling verso un altra rete, vuoi per la necessità di accedere alla rete stessa, vuoi per poter fare da ponte e utilizzare un altro gateway verso il web.

Il primo caso può essere utile ad esempio per accedere a un host in una rete locale non raggiungibile attraverso il NAT, che è quello che a me spesso capita.

Le soluzioni più eleganti e raffinate prevedono l’utilizzo di VPN, ma c’è una soluzione ancora più semplice. Avendo una macchina all’interno della rete a cui ci si vuole collegare ed avendo installato SSH raggiungibile dall’esterno è possibile utilizzare il tunneling (criptato) tramite il forwarding SOCKS5 con un semplice comando:

ssh -C2qTnN -D 8080 username@remotehost

Questo comando va eseguito sulla macchina locale (deve anche qui essere installato SSH). Per Windows è possibile utilizzare putty. Esso creerà una connessione SSH verso remotehost senza shell e rimarrà in ascolto sulla porta locale 8080. Si presume che la porta remota sia la 22, se così non fosse è possibile specificare con il flag -p la porta di SSH sull’host remoto.

E’ possibile attivare il farwarding e una shell remota contemporaneamente; per farlo vanno tolti i flag -T -n e -N.

Ora che il tunnel è creato è possibile attivare l’accesso ad esso: per i browser è sufficiente andare nella configurazione proxy ed attivare il proxy attraverso SOCKS5: i parametri saranno localhost come host e 8080 la porta (o quella definita dal parametro -D). Inserendo un indirizzo della rete locale a cui si è connessi in tunnel sarà possibile accedere ad esso.

Per le applicazioni che non supportano SOCKS, o per cui non esiste una gui apposita di configurazione, esiste in Linux un comodissimo wrapper: tsocks.

Per prima cosa bisogna provvedere ad installarlo: su Fedora è sufficiente un

yum install tsocks

per poi creare il file di configurazione /etc/tsocks.conf così impostato

server = localhost
server_port = 8080
server_type = 5
local = 127.0.0.0/255.0.0.0

infine per l’utilizzo sarà sufficiente dare da shell il comando

tsocks applicazione

(è possibile anche creare una nuova shell con attivo di default il wrapper eseguendo il solo comando tsocks).
Per verificare se è attivo il wrapping delle connessioni il comando

export | grep tsocks

deve restituire

declare -x LD_PRELOAD="libtsocks.so"

Per terminare il forwarding sarà sufficiente chiudere il processo ssh (con ctrl-c nel caso non sia stato allocato un tty).

Riferimenti

• man ssh
• man tsocks

Ecco il primo, breve, tutorial per la creazione di un array mirroring RAID.

Per prima cosa occorre preparare le partizioni che andranno in mirroring su ogni unità; non è indispensabile che i dischi coinvolti siano identici, ma è consigliato.
Per creare le partizioni è possibile utilizzare svariati tool quali fdisk, cfdisk e parted/gparted nel caso si stia creando un partizionamento MBR oppure gdisk e parted/gparted per il più evoluto partizionamento GPT.
Le partizioni vanno create della stessa dimensione (blocchi) per gli n dischi coinvolti.
Il tipo di partizione è 0xfd per l’MBR o fd00 per GPT.

A questo punto è possibile cominciare la vera è propria creazione del RAID mediante mdadm.

Per prima cosa assicurarsi che il superblocco che contiene le informazioni del RAID software sia vuoto (capita spesso con dischi già utilizzati in catene md che tale blocco contenga ancora informazioni vecchie).

Supponiamo che le partizioni da cui creare il RAID siano sdb1 e sdc1:

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdc1

Per creare la catena è sufficiente lanciare il comando

mdadm --create --verbose --assume-clean --level=1 --raid-devices=2 /dev/md0 /dev/sdb1 /dev/sdc1

In dettaglio:

• –create è autoesplicativo
• –verbose aumenta il dettaglio in output dal comando
• –assume-clean è importante, perché evita che l’array venga ricostruito e quindi fatto il resync. Su partizioni di grandi dimensioni può metterci molto tempo. E’ da utilizzare solo per la creazione di nuovi array vuoti
• –level=1 specifica che si tratta di un mirroring e quindi un RAID di tipo 1
• –raid-devices=2 numero dei devices da aggiungere all’array
• /dev/md0 è il nome del device che punterà al nuovo array
• /dev/sdb1 e /dev/sdc1 sono le partizioni che andranno a formare l’array

Al termine del comando l’array sarà attivo e pronto all’utilizzo.

# cat /proc/mdstat
Personalities : [raid1] 
 
md0 : active raid1 sdc1[1] sdb1[0]
      335543160 blocks super 1.2 [2/2] [UU]
 
unused devices: <none>

Ancora un paio di note: per prima cosa conviene attivare il supporto bitmap per poter ricostruire l’array più velocemente

mdadm --grow --bitmap=internal /dev/md0
Personalities : [raid1] 
 
md0 : active raid1 sdc1[1] sdb1[0]
      335543160 blocks super 1.2 [2/2] [UU]
      bitmap: 1/3 pages [4KB], 65536KB chunk
 
unused devices: <none>

Il comando

mdadm -Es >> /dev/mdadm.conf

è consigliato, ma tuttavia non necessario nel caso che il file /etc/mdadm.conf contenga già la riga

AUTO +imsm +1.x -all

Ho da qualche giorno acquistato due Western Digital Caviar Green da 2TB (modello EARS) da montare in un MicroServer (non mio, io ho due Seagate Barracuda LP).
Ho subito notato che non è possibile tramite hdparm gestire l’APM (advanced power management) e che il disco effettua spessissimo il parcheggio delle testine.
Il controllo con smartctl ha subito evidenziato un notevole aumento del valore load_cycle_count. Se il contatore raggiunge valori molto alti viene meno l’affidabilità del disco (sono garantiti 300.000 cicli, ma meno sono e meglio è).

Cercando con google ho scoperto che tali dischi hanno impostato a livello di firmware un timeout per il parcheggio di soli 8 secondi! Non mi è stato possibile effettuare l’override delle impostazioni con hdparm: se il parametro -B255 da errore (vedi sopra) il parametro -S240 (che imposta il timeout a 20 minuti) non sortisce effetti.

Ho scoperto che anche l’unità dell’HP Mini (sempre un WD, ma un Scorpio Blu) è soggetta allo stesso problema (qui addirittura ogni 4 secondi!): in questo caso mi ero accorto del comportamento troppo aggressivo del firmware, ma ero riuscito ad arginare il problema disabilitando l’APM con

hdparm -B255 /dev/sda

Sempre grazie a google ho trovato la soluzione definitiva sia per i Green che per lo Scorpio: si tratta dell’utility WDidle 3.1 che ufficialmente è per altri modelli sempre WD, ma che almeno con i miei esemplari funziona a meraviglia. Continue reading

Con mia piacevole sorpresa ho scoperto che l’HP MicroServer, pur non avendo EFI, supporta il boot da dischi partizionati con struttura GPT invece che MBR. Con Fedora 14 è stato sufficiente preparare i dischi formattati con gdisk; anaconda, l’installer, li riconosce correttamente; è quindi possibile utilizzare il disco.

I vantaggi di GPT sono molti, a partire dall’assenza di problemi di allineamento (soprattutto con dischi a settori di 4k) passando per il supporto a più di 4 partizioni primarie.

Riferimenti

https://wiki.archlinux.org/index.php/Advanced_Format

Ecco una semplice e veloce configurazione di lighttpd per l’esecuzione di awstats:

server.modules  += ( "mod_cgi", "mod_alias" )
 
$HTTP["host"] =~ "awstats.mydomain.tld" {
        alias.url += (
                "/awstats/"      => "/usr/share/awstats/wwwroot/cgi-bin/",
                "/awstatsicons/" => "/usr/share/awstats/wwwroot/icon/",
        )
 
        cgi.assign = (
                ".pl" => "/usr/bin/perl",
                ".cgi" => "/usr/bin/perl"
        )
        server.document-root = "/usr/share/awstats/wwwroot/"
}

La configurazione è consigliato salvarla in un file .conf (es. awstats.conf) in /etc/lighttpd/conf.d/ in modo da rendere la configurazione il più modulare possibile.

Sebbene ufficialmente l’HP ProLiant Microserver non supporti l’hotswap dei dischi è possibile con un kernel Linux recente eseguire la sostituzione (o la sola rimozione) di un’unità; ecco come:

Per prima cosa è ovviamente necessario smontare l’unità tramite il comando di base umount; supponendo che il disco da disconnettere sia sdc il comando è

sync && umount /dev/sdc

A questo punto è necessario mandare offline l’unità da rimuovere; è possibile farlo attraverso l’interfaccia kernel in /sys con il comando

echo 1 > /sys/block/sdc/device/delete

Una volta eseguito il comando l’unità verà rimossa dal subsystem scsi (sata) e spenta; il disco effettuerà lo spin-down.

E’ ora possibile rimuovere l’unità, operazione che sul MicroServer risulta molto semplice e rapida.

Per l’inserimento di una nuova unità è sufficiente connetterla al sistema. Linux provvederà in modo autonomo al riconoscimento del disco e alla connessione dello stesso al subsystem scsi. Sarà possibile ora montare l’unità od effettuare altre operazioni sul disco (partizionamento, etc.); se non si è sicuri del device associato alla nuova unità collegata è possibile controllare gli ultimi messaggi del kernel attraverso il comando dmesg.

Questa tecnica risulta estremamente comoda in caso di fault di un’unità disco parte di una catena RAID di mirroring.

UPDATE 29/03/2011

Per poter effetture tali operazioni di hot-swap il controller deve essere settato in modalità “AHCI”. L’opzione è modificabile, dove supportata, attraverso il BIOS.

Ecco il primo trucco per ridurre al minimo i consumi del già parco HP MicroServer:

con un kernel ≥ 2.6.34 (ma è consigliato almeno il 2.6.35) è possibile controllare il power management dell’AMD Radeon Mobility HD4200 integrata nel server.

Vista la natura di server e quindi l’impiego per lo più headless, o comunque in modalità testuale, è possibile intervenire impostando la GPU al massimo livello di risparmio energetico (e di conseguenza il minimo livello prestazionale).

Per attivarlo è sufficiente verificare che il metodo di gestione del power management sia settato su “profile” (e così dovrebbe essere di default)

cat /sys/class/drm/card0/device/power_method

Se fosse settato su “dynpm” eseguire il comando

echo profile > /sys/class/drm/card0/device/power_method

Infine forzare il profilo “low” per portare al minimo il clock della GPU e quindi abbassare drasticamente i consumi

echo low > /sys/class/drm/card0/device/power_profile

E’ possibile copiare i comandi 2. e 3. nel file /etc/rc.local in modo che che vengano eseguiti ad ogni riavvio del server. Su Fedora 14 è necessario solo il comando 3. Di default power_profile è impostato su “default”.

Riferimenti

https://wiki.archlinux.org/index.php/ATI#With_KMS_enabled
http://www.phoronix.com/scan.php?page=news_item&px=ODIyOA

Per fornire correttamente contenuti SVG e SVG compressi (.svgz) attraverso un server lighttpd è necessario aggiungere alcune righe alla configurazione di default.

Attivare il supporto al modulo compress nel file /etc/lighttpd/lighttpd.conf de-commentando la relativa riga in server.modules oppure aggiungendo il comando

server.modules  += ( "mod_compress" )

Aggiungere al gruppo

mimetype.assign   = ( [...] )

Il MIME corretto per SVG (image/svg+xml)

  ".svg"          =>      "image/svg+xml",
  ".svgz"         =>      "image/svg+xml",

E in ultimo aggiungere il supporto all’SVG compresso (e in questo caso anche anche al javascript compresso)

$HTTP["url"] =~ "\.(svg|js)z$" {
    setenv.add-response-header = (
    "Content-Encoding" => "x-gzip" ), compress.filetype = ("")
}

Per comodità è possibile salvare la configurazione in un nuovo file in /etc/lighttpd/conf.d/ (es. /etc/lighttpd/conf.d/svg.conf)

Riferimenti:

http://redmine.lighttpd.net/projects/lighttpd/wiki#Documentation