Sam & Micro

Per creare una nuova macchina virtuale con KVM il consiglio è quello di utilizzare l’infrastruttura libvirtd e l’utilissimo virt-install.

Con Fedora è sufficiente il comando yum per installare entrambi:

yum install libvirt python-virtinst

Un esempio per installare Scientific Linux 6 (clone di RHEL 6) direttamente da un mirror (in questo caso il GARR):

virt-install -n sl6 -r 1024  --disk /var/lib/libvirt/images/sl6.qcow2,size=20,format=qcow2 --vcpus=1 --os-type linux --os-variant=rhel6 --network bridge=br0 --vnc --location='http://rm.mirror.garr.it/mirrors/scientific/6/x86_64/os/'  --vnclisten=192.168.1.254

E’ possibile anche effettuare l’installazione testuale senza utilizzare VNC grazie al comando console di virsh

virt-install -n sl6 -r 1024  --disk /var/lib/libvirt/images/sl6.qcow2,size=20,format=qcow2 --vcpus=1 --os-type linux --os-variant=rhel6 --network bridge=br0 --location='http://rm.mirror.garr.it/mirrors/scientific/6/x86_64/os/' --extra-args 'console=ttyS0,115200'
virsh console sl6

Aggiornamento: per installare Fedora 16 e successive in modalità console seriale è necessario specificare alcuni parametri extra da passare a –extra-args. Essi sono serial text.

virt-install -n f16-server -r 1024  --disk /var/lib/libvirt/images/f16_server.qcow2,size=40,format=qcow2 --vcpus=2 --os-type linux --os-variant=fedora16 --network bridge=br0 --location='http://mirror1.mirror.garr.it/mirrors/fedora/linux/releases/16/Fedora/x86_64/os/' --extra-args 'console=ttyS0,115200 serial text'
virsh console f16-server

Per montare un immagine RAW oppure una partizione e/o LV contenente una VM o un insieme di partizioni è sufficiente avere installato kpartx

yum -y install kpart

A questo punto è possibile sfruttare /dev/mapper per mappare le partizioni del volume

kpartx -av /path/to/file_or_lv

le partizioni compariranno sotto forma di devices

ls /dev/mapper/
file_or_lv1
file_or_lv2
file_or_lvN

a questo punto è possibile montare ogni singola partizione come consueto

mount /dev/mapper/file_or_lv1 /mn/ext

per rimuovere la mappatura è sufficiente eseguire

kpartx -d /path/to/file_or_lv

Cominciamo con questo breve articolo una serie dedicata a LXC.

LXC: http://lxc.sourceforge.net/

LXC is the userspace control package for Linux Containers, a lightweight virtual system mechanism sometimes described as “chroot on steroids”.
LXC builds up from chroot to implement complete virtual systems, adding resource management and isolation mechanisms to Linux’s existing process management infrastructure.

In pratica LXC sono un set di tools userspace per la creazione e la gestione di containers che permettono la creazione di un sistema di virtualizzazione leggero ed efficiente. Questo è reso possibile grazie ai “Control Groups” – cgroups implementati nella mainline del kernel dal 2.6.24. Ovviamente le VM non sono altro che dei processi isolati tra loro, ma che utilizzano fisicamente lo stesso kernel (che è pure lo stesso dell’host); è quindi ovvio che solo sistemi con kernel Linux potranno essere virtualizzati. Il vantaggio è nella mancata perdita di prestazioni rispetto ai sistemi di virtualizzazione completa (kvm, xen), poiché i processi sono eseguiti direttamente sulla sistema bare-metal.
Altri sistemi silimili sono le Jails di FreeBSD e OpenVZ. Il vantaggio di LXC rispetto a OpenVZ è il disporre di tutto il necessario già all’interno del kernel, quindi senza necessità di patch al kernel vanilla.

Va premesso che LXC è una tecnologia recente e quindi ancora in fase di pesante sviluppo. E’ tuttavia pienamente usabile.

In questo primo articolo creeremo un container con Debian Squeeze su di una Fedora 14 (64bit).

Per prima cosa occore installare i tool necessari all’operazione:

yum install -y lxc debootstrap

A questo punto occore, se già non sono presenti, montare i cgroup: in Fedora 14 essi sono gestiti dallo script /etc/init.d/cgconfig con una precisa struttura gerarchica. Allo stato attuale LXC non supporta tale struttura e quindi procederemo al montaggio di /cgroup in maniera classica. Dopo aver disattivato gli script di avvio (tramite ntsysv o chkconfig) si procede a montare /cgroup manualmente e ad inserirlo nell’fstab:

mount -t cgroup cgroup /cgroup
echo "cgroup /cgroup cgroup rw 0 0" >> /etc/fstab

Creiamo anche le impostazioni base per la rete dei container. Esistendo già il bridge di rete br0 per kvm basterà creare il file /etc/lxc/container.conf (il path è arbitrario):

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 0.0.0.0

Ora recuperiamo il template di installazione per Debian dal pacchetto sorgente di LXC poiché nella versione RPM di Fedora 14 essi non sono distribuiti. Per comodità è possibile scaricare i template pronti per Fedora 14 a 64bit (lxc-templates-0.7.4.tar.gz). Essi vanno scompattati in  /usr/lib64/lxc/templates/.

Passiamo alla creazione del container con il comando lxc-create -n [nome_container] -t  [template] -f  [config_base_rete]

lxc-create -n debian01 -t debian -f /etc/lxc/container.conf
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-squeeze-amd64 ...
Downloading debian minimal ...
I: Retrieving Release
W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libbz2-1.0 libdb4.8 libslang2
I: Found additional base dependencies: adduser debian-archive-keyring gnupg gpgv isc-dhcp-client isc-dhcp-common libbsd0 libdb4.7 libedit2 libgdbm3 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libncursesw5 libreadline6 libssl0.9.8 libusb-0.1-4 libwrap0 openssh-blacklist openssh-client perl perl-modules procps readline-common
I: Checking component main on http://cdn.debian.net/debian...
I: Retrieving libacl1
I: Validating libacl1
I: Retrieving adduser
I: Validating adduser
I: Retrieving apt
I: Validating apt
I: Retrieving libattr1
I: Validating libattr1
I: Retrieving base-files
I: Validating base-files
I: Retrieving base-passwd
I: Validating base-passwd
...

Al termine della creazione sarà sufficiente avviare la VM

lxc-start -n debian01 -d

E connettersi via console al container appena creato

lxc-console -n debian01

(per fare il detach della console premere ctrl-q a)

– Fine prima parte –

Riferimenti

• http://lxc.sourceforge.net/man/lxc.html
• http://en.gentoo-wiki.com/wiki/LXC
• http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg02151.html

Attenzione! Il post non è più aggiornato poiché il bug è stato risolto nella release 3.4.10 di apcupsd.

3.14.10 -- 13 September 2011         (Maintenance Release)
 
BUG FIXES
 
  * Fix missing status and spurrious incorrect status on newer BackUPS CS
    models using USB interface.
  [...]

APCUPSD è un comodissimo software per chi possiede un UPS della APC.
Esso permette di monitorare lo stato dell’UPS, inviare alert e email in caso di blackout, avviare lo spegnimento dei server collegati a seguito di un blackout prolungato, ecc…

Dall’ultima versione, la 3.14.8, è stato introdotto un bug che si viene a verificare nel caso di utilizzo del software in abbinamento ad un UPS APC BackUp CS collegato tramite USB: ogni qualvolta che il demone effettua il polling dell’unità viene generato un errore di controllo nel subsystem USB

[...]
USB disconnect, address 6
usb 3-2: ctrl urb status -62 received
[...]

causando tra l’altro la disconnessione e riconnessione della periferica HID (viene vista dal kernel come una HID). Continue reading

Il 6 aprile 2011 è (finalmente?) uscito Gnome 3: l’idea di desktop è stata in buona parte rivoluzionata; devo dire che tuttavia sul netbook non è così male la nuova impostazione.

La prima impressione che ho avuto con Gnome 3 è stata l’impossibilità di accedere a molte impostazioni per personalizzare almeno un poco il comportamento del desktop: infatti il pannello di controllo, almeno attualmente, molto limitante nella configurazione.

Tuttavia esistono due tool, a mio dire indispensabili, che permetto di aggirare parzialmente questo limite.
Essi sono:

gnome-tweak-tool

E’ una gui molto semplice per abilitare e/o modificare alcuni comportamenti e caratteristiche di base.

dconf-editor

Sostituisce il vecchio gconf-editor e permette una gestione più completa e raffinata delle impostazioni.

Per installarli, su Fedora 15 (beta), è sufficiente usare yum

yum install -y dconf-editor gnome-tweak-tool

Personalmente ho fatto le seguenti modifiche

• Attivata la data a fianco dell’orologio
• Attivato il pulsante di minimizzazione delle finestre
• Attivato il pulsante “power-off” nel menu utente (tramite il pacchetto gnome-shell-extensions-alternative-status-menu)

Attenzione! Per Fedora 15 sono necessari almeno 1GB di RAM per poter effettuare l’installazione.

Provando ad installare un webserver “minimo” su KVM, per testare le novità dell’ultima release, mi sono scontrato con un kernel panic in fase di boot dell’installer: il problema è che, almeno per la versione x86_64 soggetto del test, 512MB di RAM non sono sufficienti per scompattare l’initrd.img dell’installer poiché ora comprende anche l’immagine dell’installer install.img.

E’ necessario quindi, almeno per la fase di installazione, riservare alla VM almeno 1GB di RAM. Al termine dell’installazione è possibile tornare alla configurazione precedente.

Un’altra soluzione è definire la VM nel seguente modo

<memory>1048576</memory>
<currentMemory>524288</currentMemory>

Definendo quindi 512MB di RAM che in caso di necessità, su richiesta del guest possono essere estesi a 1024MB.

L’HP Mini 110-3100 monta un lettore di schede SD costruito da Realtek. Esso viene visto in linux come

01:00.1 Class ff00: Realtek Semiconductor Co., Ltd. Device 5288 (rev 01)

tuttavia allo stato attuale non è ancora disponibile, all’interno del kernel Linux, il driver che ne possa garantire il funzionamento.
Realtek fornisce sul proprio sito i sorgenti (GPL) per poter compilare il modulo e utilizzare così il reader. Tali driver sono in stato di “staging” per l’inclusione (essendo appunto GPL) direttamente upstream nel kernel ufficiale. L’inclusione è in corso e non è immediata, gli sviluppatori stanno integrando il codice del modulo riscrivendone alcune parti; infatti il driver Realtek, pur funzionando alla perfezione, è molto esoso di interrupt, causando tra le altre un uso di energia superiore: la cosa, non trascurabile su di un net/notebook è facilmente evidenziabile grazie all’ottimo tool Intel powertop.

Per compilare il modulo è necessario scaricare i sorgenti dal sito Realtek (sono 77kb) e disporre di gcc, degli header e dei sorgenti del kernel; con Fedora è sufficiente eseguire

yum install -y gcc kernel-headers kernel-devel

quindi scompattare il tar bz2

tar xjvf rts_pstor.tar.bz2

ed infine compilare ed installare il modulo

cd rts_pstor
make
make install
depmod

Al successivo riavvio il modulo sarà caricato automaticamente e il lettore SD funzionerà senza problemi.
Se si volesse disattivare il caricamento automatico è sufficiente creare il file /etc/modprobe.d/blacklist-rts.conf inserendo la riga

blacklist rts_pstor

In questo modo, qualora si volesse utilizzare il lettore, si dovrà prima eseguire da terminale il comando

modprobe rts_pstor

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

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