Android Bug su Darky’s Rom 10.1

Dopo qualche giorno dall’installazione della Darky’s 10.1, mi sono reso conto che c’era un “piccolo” problema; il Galaxy S non è certo un apparecchio parsimonioso nell’uso della batteria, però il consumo era davvero divenuto esagerato: farsi fuori una batteria carica in 3-4 ore forse è un po’ troppo.

Dopo qualche ricerca mi sono reso conto che il mio telefono era affetto dal cosidetto “Android Bug”: per capire a cosa mi riferisco, andate in “impostazioni” -> “Applicazioni” -> “Uso batteria”: se la voce “Sistema Operativo Android” (Android OS in inglese) è particolarmente alta – la mia era al 56% – , anche il vostro telefono è affetto dal bug.

Cosa fare per non essere costretti a viaggiare con un pacco di batterie in borsa?

Innanzi tutto, bisogna ripetere l’operazione di flash del telefono partendo dalla rom Ficeto standard come spiegato in questo articolo. Quindi, al termine dell’operazione di flash, installiamo subito l’applicazione “Titanium Backup”.
Attraverso questa applicazione, cancelliamo due applicazioni standard “incriminate”: Samsung Account e Software Update e riavviamo. A questo punto possiamo procedere al ripristino di tutte le applicazioni con Titanium Backup, ma non procediamo al ripristino completo: scegliamo solo le applicazioni necessarie in modo da escludere eventuali file del vecchio sistema Android non più necessari.

Ultimo trucchetto: abilitate e disabilitate per tre volte consecutive la modalità aereo. Così facendo l’applicazione “Standby Cella” consumerà un po’ di meno. Inoltre andate in “Impostazione” -> “Wireless e rete” -> “Impostazioni Wi-Fi”. Premete il tasto “Menu” e scegliete “Avanzate”. Come “Criterio modalità sospensione Wi-Fi” scegliete “Mai”.

Ovviamente restano validi tutti i trucchi “standard” per consumare meno: disabilitare l’aggiornamento automatico delle applicazioni via rete, disabilitare le animazioni (scegliendo “alcune” rimarrà comunque funzionante l’animazione di spegnimento dello schermo), abbassare la luminosità dello schermo o metterla in automatico.

NFS per ospitare la directory web di apache

E’ da qualche giorno che sto sbattendo la testa su un setup di NFS.

L’idea è quella di creare un server NFS (in realtà sono due macchine ridondate tramite DRBD/HeartBeat) che esporta la directory /var/www con tutti i siti web, verso quattro server Apache dietro ad un load balancer.
Questo setup mi serve come termine di paragone per testare la velocità e l’affidabilità di NFS rispetto ad una situazione in cui la partizione con i dati viene esportata sui web server tramite iSCSI e gestita attraverso il filesystem cluster OCFS2: questo setup garantiva performance estremamente importanti, però risulta un po’ complesso nella gestione dei guasti in quanto i quattro server web parlano tra loro per sincronizzare le operazioni sul disco condiviso e ho rilevato situazioni in cui l’intero cluster si trova in uno stato di incoerenza a causa di un solo nodo con problemi.

So per certo che le prestazioni di NFS non saranno paragonabili a quelle di OCFS2, però voglio capire quanto ciò va ad incidere nel caso di un semplice web server e quanto (e se) migliora la stabilità del sistema.

Una volta ultimata la configurazione di default, ecco sorgere il primo problema: Apache diventa instabile. Sarà un caso che a me sia successo subito, però vi giuro che è così.

Inizio a googleare in giro e scopro che esistono due funzionalità di apache attive di default che servono a migliorare le performance, che però sono incompatibili con NFS. Quindi agisco sul file di configurazione di apache per disattivarle:

EnableSendfile Off
EnableMMAP Off

Ok, ora Apache sembra stabile… ma è presto per cantar vittoria.
Mentre mi sto gustando un buon caffè, arriva la telefonata di un Geek a cui ho chiesto di aiutarmi nel testare il sistema che mi fa notare un problema di “sincronismo” tra i server. Rimango basito perchè non c’è alcun sincronismo, tutti i server pescano dallo stesso filesystem. Però il problema evidentemente c’è: quando effettuo una modifica ad un file su un server, passano 5-10 secondi perchè il demone apache sugli altri server se ne accorga. E’ come se apache avesse una sorta di cache interna…

Inizialmente tendo a pensare ad un problema legato ad apache, visto che ero appena stato scottato dalle due direttive che lo bloccavano. Ma qui il problema è diverso e, evidentemente, in una situazione simile con il filesystem ocfs2 tale problema non si presenta… quindi non c’è alcuna cache in apache, è evidente. Difatti faccio la prova a leggere il file direttamente da filesystem e il problema è analogo: quindi è NFS che fa cache.

Let’s google un altro po’ e trovo due impostazioni che possono creare questo tipo di problema una: su server NFS (no_wdelay) e una su client (noac). La prima, nel caso di un export sincrono, diabilita il wdealy attivo di default che serve per ritardare l’ack di completa scrittura in modo da verificare se esistono altre scritture in coda per eseguirle tutte assieme e migliorare le preformance; la seconda serve per disabilitare qualsiasi tipo di cache sul client in modo da costringerlo ogni volta ad accedere al server NFS.

In sostanza, alla fine, il mio export è:

/var/www        192.168.50.*(rw,sync,no_root_squash,no_wdelay)

Mentre il mountpoint in fstab è:

192.168.50.253:/var/www     /var/www                nfs   rsize=32768,wsize=32768,intr,noac,noatime,_netdev 0 0

Ora resta da vedere la velocità di NFS nell’utilizzo quotidiano in una situazione in cui sono state disabilitate tutte le funzionalità di cache del sistema: dopo qualche prova diciamo che la differenza di prestazioni senza cache è notevole e, in caso di siti particolarmente visitati, il carico di lavoro sul server NFS aumenta a livelli tali per cui non è possibile mantenere un simile livello di “online”; anche una taratura “di fino” sulla cache non aiuta più di tanto a migliorare le prestazioni.
In sostanza, abbiamo dimostrato che NFS senza cache è inutilizzabile per gli scopi prefissi, al pari di qualsiasi altro filesystem “server” come GlusterFS (vedi il paragone tra OCFS2 e GlusterFS di questo articolo).

Sia ben chiaro: non esiste LA soluzione, esistono diverse soluzioni con caratteristiche diverse che di volta in volta si adattano meglio o peggio alle esigenze. Nel caso in cui si ospitasserro solamente siti che non operano scritture su disco, la soluzione di NFS con cache è sicuramente la più semplice da implementare offrendo contemporaneamente un ottimo livello di velocità; nel caso di siti che scrivono dinamicamente e in cui si ha la necessità di accedere immediatamente ai file (ad esempio un worpress con il plugin nextgen gallery), bisognerebbe disabilitare la cache e quindi questa soluzione non è adatta: meglio “tornare” alla più complessa iSCSI/OCFS2.

2 Xen con datastore locale su drbd

In questo articolo creeremo un setup formato da due server con hypervisor Xen e datastore locale su partizione LVM replicata sui due server in realtime utilizzando DRBD.
Questo sistema, non è certo adatto ad essere un vero e proprio cloud, ma è il metodo che preferisco per creare un sistema di virtualizzazione aziendale efficiente, performante e poco costoso… a scapito di una gestione non proprio semplicissima

In questo articolo assumeremo di avere due server con indirizzo IP 192.168.255.1 (xen1) e 192.168.255.2 (xen2) con una installazione standard di Debian e Xen secondo quanto spiegato in questo precedente articolo. Inoltre, su entrambi i server, dovrà essere creato un Volume Group LVM chiamato “vg” per ospitare i dischi delle macchine virtuali; ammettendo che la partizione che ospiterà i volumi LVM per le macchine virtuali sia /dev/sda4, creiamo il setup di LVM con questi comandi da lanciare su entrambi i server:

pvcreate /dev/sda4 
vgcreate vg /dev/sda4
lvcreate -L 1G -n meta vg

Infine, su entrambi i server, bisognerà installare DRBD 8 secondo quanto spiegato in questo articolo.

A questo punto siamo pronti a configurare il sistema per gestire l’alta affidabilità che utilizzerà HeartBeat, per cui procedete pure su entrambi i server ad installare il pacchetto e ad operare la classica configurazione di ha.conf e authkeys: in questo articolo ci soffermeremo solo su come configurare correttamente il file haresources in modo da distribuire le VM sui due server e migrarle all’interno di una sola macchina in caso di guasto.

Debian mette a disposizione uno script di avvio per far partire in automatico i DomU di xen che si trova in /etc/init.d/xendomains: si tratterà di lavorare su questo per far si che gestisca due server al posto di uno soltanto.

Copiamo questo script all’interno della directory /etc/ha.d/resource.d:

cp /etc/init.d/xendomains /etc/ha.d/resource.d/xendomainsHA1
cp /etc/init.d/xendomains /etc/ha.d/resource.d/xendomainsHA2

Modifichiamo lo script /etc/ha.d/resource.d/xendomainsHA1:

LOCKFILE=/var/lock/xendomainsHA1
XENDOM_CONFIG=/etc/default/xendomainsHA1

e lo script /etc/ha.d/resource.d/xendomainsHA2:

LOCKFILE=/var/lock/xendomainsHA2
XENDOM_CONFIG=/etc/default/xendomainsHA2

Quindi andiamo ad eseguire la medesima operazione sul file /etc/default/xendomains:

cp /etc/default/xendomains /etc/default/xendomainsHA1
cp /etc/default/xendomains /etc/default/xendomainsHA2

Modifichiamo il file /etc/default/xendomainsHA1:

XENDOMAINS_MIGRATE="xen2X --live"
XENDOMAINS_SAVE=
XENDOMAINS_SHUTDOWN_ALL=
XENDOMAINS_RESTORE=false
XENDOMAINS_AUTO=/etc/xen/auto/xen1
XENDOMAINS_AUTO_ONLY=true

e il file /etc/default/xendomainsHA2:

XENDOMAINS_MIGRATE="xen2X --live"
XENDOMAINS_SAVE=
XENDOMAINS_SHUTDOWN_ALL=
XENDOMAINS_RESTORE=false
XENDOMAINS_AUTO=/etc/xen/auto/xen2
XENDOMAINS_AUTO_ONLY=true

Creiamo il file /etc/ha.d/haresources con queste righe

xen1    xendomainsHA1
xen2    xendomainsHA2

e creiamo le due directory citate nella configurazione:

mkdir -p /etc/xen/auto/xen1
mkdir -p /etc/xen/auto/xen2

Ovviamente tutte queste operazioni andranno eseguite su entrambi i server. A questo punto la configurazione dei due hypervisor xen è ultimata. Il funzionamento è semplice: per ogni macchina virtuale creeremo su entrambi i server due volumi logici LVM: uno per il disco di root e uno per lo swap; quindi configureremo DRBD8 in modalità attivo-attivo per replicare i dati tra i due server, creeremo il file di configurazione della VM che utilizzerà il driver drbd di xen per gestire i dischi e, infine, creeremo un link simbolico all’interno della directory /etc/xen/auto/xen1 o /etc/xen/auto/xen2 a seconda del server fisico all’interno del quale girerà la nostra macchina virtuale.

Questa la procedura per creare una nuova VM:

Creare i dischi attraverso lvm su entrambi i server:

lvcreate -n vm-disk --size 10g vg
lvcreate -n vm-swap --size 2g vg

Quindi, sempre su entrambi i server, aggiungere alla configurazione di drbd una sezione apposta:

<strong>/etc/drbd.conf</strong>
# VM
resource vm-disk {
protocol C;
startup {
wfc-timeout 120; ## 2 min
degr-wfc-timeout 120; ## 2 minutes.
}
disk {
on-io-error detach;
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;

timeout 60;
connect-int 10;
ping-int 10;
max-buffers 2048;
max-epoch-size 2048;
}
syncer {
}

on xen1 {
address 192.168.255.1:7801;
device /dev/drbd1;
disk /dev/vg/vm-disk;
meta-disk /dev/vg/meta[1];

}

on xen2 {
address 192.168.255.2:7801;
device /dev/drbd1;
disk /dev/vg/vm-disk;
meta-disk /dev/vg/meta[1];
}
}

resource vm-swap {
protocol C;
startup {
wfc-timeout 120; ## 2 min
degr-wfc-timeout 120; ## 2 minutes.
}
disk {
on-io-error detach;
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;

timeout 60;
connect-int 10;
ping-int 10;
max-buffers 2048;
max-epoch-size 2048;
}
syncer {
}

on xen1 {
address 192.168.255.1:7802;
device /dev/drbd2;
disk /dev/vg/vm-swap;
meta-disk /dev/vg/meta[2];
}
on xen2 {
address 192.168.255.2:7802;
device /dev/drbd2;
disk /dev/vg/vm-swap;
meta-disk /dev/vg/meta[2];
}
}

Bisogna prestare particolare attenzione alla configurazione di DRBD in quanto ogni disco dovrà avere il proprio nome univoco (vm-disk e vm-swap nell’esempio), la propia porta univoca (7801 e 7802), il proprio identificativo progressivo di device (/dev/drbd1 e /dev/drbd2) e il proprio metadata univoco (/dev/vg/meta[1] e /dev/vg/meta[2]).

Creiamo quindi i metadata di drbd e ricarichiamo drbd su entrambi i server:

drbdadm create-md vm-disk
drbdadm create-md vm-swap
/etc/init.d/drbd reload

Ora sul server principale forziamo la sincronizzazione di DRBD, formattiamo il disco, montiamolo e installiamo il sistema operativo base:

drbdadm -- --overwrite-data-of-peer primary vm-disk
drbdadm -- --overwrite-data-of-peer primary vm-swap
mkfs.xfs /dev/drbd1
mkdir /tmp/mnt
mount /dev/drbd1 /tmp/mnt
debootstrap lenny /tmp/mnt/ http://ftp.it.debian.org/debian

Copiamo i driver del kernel nel disco della VM:

cp -pR /lib64/modules/* /tmp/mnt/lib64/modules

Modifichiamo il file /etc/inittab per poter accedere in console locale:

1:2345:respawn:/sbin/getty 38400 hvc0

Entriamo in chroot, installiamo il server ssh e udev e modifichiamo la password di root:

chroot /tmp/mnt
apt-get update
apt-get install udev ssh
passwd
exit
umount /tmp/mnt

A questo punto la nostra vm è pronta per essere eseguita da Xen.

Su entrambi i server creiamo il file di configurazione di XEN all’interno di /etc/xen

<strong>/etc/xen/vm</strong>
kernel = "/boot/vmlinuz-2.6.26-2-xen-amd64"
ramdisk = "/boot/initrd.img-2.6.26-2-xen-amd64"
memory = 1024
name = "vm"
vif = ['bridge=xenbr0']
disk = ['drbd:vm-disk,sda1,w', 'drbd:vm-swap,sda2,w']
root = "/dev/sda1 ro"
extra = 'console=hvc'

Ed infine creiamo il link simbolico per farla avviare automaticamente all’avvio di HeartBeat, sempre su entrambi i server:

ln -s /etc/xen/vm /etc/xen/auto/xen1

A questo punto, sul server 1, possiamo avviare manualmente la VM:

xm create /etc/xen/vm -c

Darky’s ROM 10.1

Finalmente mi sono deciso: è da circa una settimana che è uscita la versione ufficiale della mia ROM preferita per il Galaxy S basata su Android 2.3.3 Gingerbred e procedere all’update del mio smartphone era diventata una questione di principio.
In passato avevo provaro la versione beta di questa ROM e, francamente, non mi sono trovato splendidamente per cui sono tornato alla versione 9.3 che soddisfava appieno le mie esigenze. Ammetto di essere stato combattuto sul procedere o meno all’update, però visto che oramai la maggior parte degli Android ha la possibilità di avere installato Gingerbread, penso che sia giunto il momento di fare il salto in maniera definitiva, adattandomi ad eventuali modifiche che possono “sconvolgere” le mie abitudini.

Operazioni prelimiari

Bene, voglio mettermi al sicuro da eventuali problemi: avendo già il telefono con Darky’s 9.3, riavvio in Recovery Mode e lancio un bel backup a basso livello, una sorta di “Disaster Recovery”.
Successivamente eseguo un bel backup dei dati e delle applicazioni con Titanium Backup in modo da non dover reinstallare tutto il mio ambiente.

Ora che mi sono messo al coperto da eventuali disastri, riavvio di nuovo il telefono in recovery mode e disabilito il Lagfix: è una operazione lunga ma necessaria in quanto il filesystem EXT4 non è compatibile con la ROM “provvisoria” che installeremo, per cui bisogna tornare provvisoriamente al lentissimo RFS di Samsung.

Installazione della ROM Gingerbread Default

A questo punto procediamo all’installazione della ROM Gingerbread di default attraverso Odin. Scarichiamo questo pacchetto che contiene tutto ciò che ci serve per il flash del telefono. Apriamo Odin, scegliamo il file PIT incluso nel pacchetto e come PDA scegliamo il file tar incluso nel pacchetto. Verifichiamo che sia selezionata l’opzione di Re-Partition, riavviamo il telefono in Download Mode e colleghimaolo al PC: dopo qualche secondo, il primo quardatone diventerà giallo e premiamo “Start” per flashare il telefono.

Il mio consiglio è di eseguire questa operazione con la batteria completamente carica e mantenendo il telefono collegato all’alimentazione USB: al primo avvio Android esegue la taratura dei sensori, compreso il livello di carica della batteria.

Al termine dell’operazione il nostro telefono avrà Gingerbread standard con il solo rootkit attivo. Il primo avvio è, come al solito molto lento.

Installazione di Darky’s ROM 10.1

Ora arriva il bello: scarichiamo questo pacchetto e copiamolo all’interno della memoria SDCard interna del telefono; riavviamo il telefono in Recovery Mode e scegliamo di installare il pacchetto zip dalla SDCard. Il prcesso di installazione dura qualche minuto.

Al termine scegliamo la voce Voodoo per riabilitare il lagfix e, dopo qualche minuto, il telefono si riavvierà e avremo la nostra nuova Dark’s installata e funzionante.

Prime impressioni

L’animazione all’avvio è quella del Samsung Galaxy S II: mi sento come uno che mette un alettone da Formula 1 su una Fiat 500.

Ho la mia tasstiera Swype!

La velocità sembra buona, niente da dire il team di Darky’s è una garanzia sotto questo punto di vista.

Particolari differenze sul funzionamento non ne trovo, non mi devo adattare a nulla.

Molto, molto bene!