nerdrug

introduzione a Open vSwitch

Thu, 08 Mar 2012 23:00:00 GMT

AOpen vSwitch è uno stack switch virtuale nato per gestire gli ambienti di virtualizzazione multi-server (dato che il classico bridging in questi casi non è sufficiente) che può essere usato, in concomitanza con OpenFlow, come control stack per gli switch hardware.

Ecco alcune della funzionalità più importanti:

migrazione delle VM da host ad host (compresa la migrazione della delle sessioni attive e delle configurazioni, ad es. policy di routing, ACL, QoS, ecc)
pieno supporto alle VLAN (standard 802.1q)
supporto OpenFlow 1.0 con numerose estensioni
QoS anche per singola VM
tunnel GRE per connettere le VM anche in diversi data center (anche attraverso IPsec)
visibilità del traffico e statistiche avanzate grazie al supporto NetFlow, sFlow, SPAN, ecc
layer di compatibilità per il modulo bridge di linux (in questo modo tutti i software che già utilizzano il bridge non necessitano di alcuna modifica per utilizzare Open vSwitch)

Proviamo subito a sporcarci le mani…

Installazione

Debian way

Da debian wheezy sono disponibili i pacchetti di openvswitch…

aptitude install openvswitch-controller openvswitch-datapath-dkms openvswitch-brcompat

I pacchetti si occuperanno, inoltre, di inizializzare il database di Open vSwitch e avviare i vari servizi. Ricordiamo però che bisogna avviare manualmente il demone ovs-brcompatd:

ovs-brcompatd --pidfile --detach

Da sorgenti

Una volta scaricati i sorgenti assicuriamoci di compilare e caricare il modulo necessario per far lavorare Open vSwitch direttamente in kernel space (aumentando in modo esponenziale la velocità) e il modulo di compatibilità per il layer bridge di linux (brcompat):

./configure --with-linux=/lib/modules/`uname -r`/build
make && make install

insmod datapath/linux/openvswitch_mod.ko

rmmod bridge
insmod datapath/linux/brcompat_mod.ko

creazione del database di Open vSwitch

mkdir -p /usr/local/etc/openvswitch
ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema

avvio del database server

ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \
                     --remote=db:Open_vSwitch,manager_options \
                     --private-key=db:SSL,private_key \
                     --certificate=db:SSL,certificate \
                     --bootstrap-ca-cert=db:SSL,ca_cert \
                     --pidfile --detach

inizializzazione del database

ovs-vsctl --no-wait init

avvio del demone ovswitchd

ovs-vswitchd --pidfile --detach

avvio del demone per la compatibilità con il modulo bridge e con brctl

ovs-brcompatd --pidfile --detach

Casi d’uso

Open vSwitch viene impiegato soprattutto per centralizzare ed automatizzare la gestione delle policy, delle VLAN, i tunnel, ecc, nelle realtà con più sedi/data-center che devono gestire molti server di virtualizzazione.

Vediamo qualche utilizzo pratico con KVM.

Isolare il traffico delle VM utilizzando le VLAN

L’utilizzo più comune di Open vSwitch è quello di far dialogare 2 VM su host diversi, configurati entrambi sulla stessa VLAN.

Per fare questo test è necessario collegare i 2 host con uno switch che supporti il protocollo 802.1q con la VLAN 9 configurata, oppure collegare direttamente gli host (con una punto-punto).

La nostra piccola rete è composta da:

reti
- VLAN 9 (A) -> 192.168.9.0/24
- VLAN 19 (B) -> 192.168.19.0/24

listend

host
- server 1 -> 192.168.0.1
- server 2 -> 192.168.0.2

listend

VM
- VM A1 -> 192.168.9.1
- VM A2 -> 192.168.9.2
- VM A3 -> 192.168.9.3
- VM B1 -> 192.168.19.1

Il nostro obiettivo è far dialogare la VM A1 con la VM A2.

Questi passi vanno eseguiti su entrambi i server:

creiamo il bridge aggiungendogli la scheda di rete (fisica) che utilizzeremo per il test:
```
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
```
creiamo la scheda di rete virtuale (tap)
```
tunctl -t tap0
ifconfig tap0 up
```
aggiungiamola al bridge con il tag della VLAN 9
```
ovs-vsctl add-port br0 tap0 tag=9
```

assegniamo un indirizzo ip al bridge

# sul server 1:
ifconfig br0 192.168.0.1

# sul server 2:
ifconfig br0 192.168.0.2

avviamo una live con kvm sugli host

RANDOM_MAC=`openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'`

kvm -cdrom grml64_2011.12.iso -m 512 -boot d -net nic,macaddr=$RANDOM_MAC \
  -net tap,ifname=tap0,script=no,downscript=no

A questo punto assegniamo alle VM l’ip 192.168.9.1 e 192.168.9.2 ed il gioco è fatto. Le VM dovrebbero dialogare senza problemi.

Far dialogare le VM nella stessa VLAN in data-center differenti

Questo caso è molto simile al precedente, con l’unica differenza che i 2 host sono collegati con un tunnel GRE (non criptato) perché risiedono in data-center diversi.

IP pubblici
- server 1 -> 1.1.1.1
- server 2 -> 2.2.2.2

Una volta eseguite tutte le operazioni del caso precedente, prima di avviare la VM, aggiungiamo la configurazione per il tunnel GRE:

server 1:

ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=2.2.2.2

server 2:

ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=1.1.1.1

A questo punto le nostre solite VM A1 e A3 riusciranno nuovamente a dialogare, utilizzando il tunnel GRE.

Ovviamente Open vSwitch prevede l’utilizzo di VPN IPsec (racoon) tramite dei tool che ne semplificano la creazione e il monitoraggio.

Gestione tramite OpenFlow

Open vSwitch viene utilizzato anche come “semplice” switch gestito da OpenFlow.

In questo modo le potenzialità dell’architettura di rete diventano veramente notevoli.

Ma di questo, magari parleremo un’altra volta.

Risorse utili.

btrfs in debian con apt-btrfs-snapshot

Wed, 30 Nov 2011 23:00:00 GMT

Da qualche giorno mi sono (finalmente) deciso ad utilizzare btrfs come filesystem predefinito per il mio portatile.

In questo post vedremo come utilizzare il programma apt-btrfs-snapshot con Debian GNU/Linux e qualche piccolo trucchetto per btrfs.

Non potendo migrare facilmente il filesystem di root, data la mia configurazione con LVM + dm-crypt, ho deciso di installare ex-novo Debian Sid (unstable).

Utilizzare btrfs come fs di root in Debian

Al primo boot si presenta subito un fastidioso problemino.

Ovvero l’init si avvia in maintenance mode perché non riesce a trovare il binario “fsck.btrfs”. Il modo più semplice per aggirare il problema, in attesa della chiusura del bug, è impostare a 0 il sesto campo (pass) relativo al root file system nel file /etc/fstab.

Montiamo il root file system in lettura-scrittura e modifichiamo il file.

mount -o remount,rw /

file: /etc/fstab

# <file system> <mount point>   <type>  <options>    <dump>  <pass>

# root fs
/dev/sda2       /               btrfs   ssd,noatime  0       0

[...]

Installare ed abilitare apt-btrfs-snapshot

Questo programma si occupa di eseguire uno snapshot del root file system ad ogni modifica relativa alla gestione locale dei pacchetti (installazioni/aggiornamenti/rimozioni), tramite gli hook messi a disposizione da APT.

Purtroppo il pacchetto apt-btrfs-snapshot non è stato ancora incluso nei repository di debian, probabilmente perché l’installer non inizializza il pool btrfs in maniera compatibile con apt-btrfs-snapshot.

Il pacchetto in questione richiede che il root file system non sia nella root del pool btrfs ma in un sotto-volume nominato @.

Per copiare tutto il contenuto della root nel nuovo sotto-volume, creiamo semplicemente uno snapshot:

btrfs subvolume snapshot / /@

In questo modo avremo una copia di tutti i file in pochi millisecondi ;).

Una volta creato il sotto-volume @ andiamo a modificare il file fstab e la configurazione di grub, in modo da utilizzare come root file system il sotto-volume @ e non più la root del pool:

file: /etc/fstab

# <file system> <mount point>   <type>  <options>             <dump>  <pass>

# root fs
/dev/sda2       /               btrfs   subvol=@,ssd,noatime  0       0

[...]

file: /etc/default/grub

[...]
GRUB_CMDLINE_LINUX="rootflags=subvol=@"
[...]

Aggiorniamo grub2:

update-grub2

Adesso possiamo fare un bel reboot, per essere sicuri che tutto sia andato bene.

Una volta riavviato controlliamo che l’attuale root file system sia veramente il sotto-volume @, semplicemente controllando se esiste il file @ nella root.

Se non esiste, possiamo montare la root del pool e cancellare tutto tranne la directory @:

mount /dev/sda2 /mnt

rm -r `ls /mnt/* | grep -v @`

A questo punto siamo pronti ad installare ed utilizzare apt-btrfs-snapshot:

wget http://launchpadlibrarian.net/82530974/apt-btrfs-snapshot_0.2.1_all.deb
dpkg -i apt-btrfs-snapshot_0.2.1_all.deb

Controlliamo manualmente se tutto è andato bene:

# questo comando dovrebbe riportare "Supported"
apt-btrfs-snapshot supported

# creiamo uno snapshot
apt-btrfs-snapshot snapshot

# controlliamo se lo snapshot viene listato
apt-btrfs-snapshot list

Adesso esegundo il mount della root del pool dovremmo vedere lo snapshot fatto poco prima:

# montiamo la root del pool btrfs
mount /dev/sda2 /mnt/

# facciamoci listare il contenuto
ls -lah /mnt/

# dovrebbero esserci dei file tipo:
# @ e @apt-snapshot-2011-12-01_11:56:42

snapshot automatici, manuali e pulizia

Questo script ci permette di automatizzare, in modo semplice, la creazione di snapshot, in base al tempo.

Se invece vogliamo qualcosa da lanciare una volta ogni tanto, possiamo utilizzare qualcosa di simile:

Inoltre potremmo snellire la lista dei backup automatici fatti da apt-btrfs-snapshot con uno script del genere, magari mettendolo in cron anziché usando gli hook di APT.

Conclusioni

Btrfs è un file system con delle grandissimi potenzialità. Speriamo riesca presto a consolidarsi ed a raggiungere le funzionalità del suo diretto concorrente, ZFS.

Risorse utili.

ganeti: gestore di cluster di macchine virtuali

Mon, 07 Nov 2011 23:00:00 GMT

Ganeti è un software scritto in Python, sviluppato e mantenuto da Google dal 2007, per gestire in maniera semplice e ridondata cluster di macchine virtuali.

Si basa sul concetto di ridondanza N+1, utilizzando DRBD per la replica dei dischi delle macchine virtuali.

Caratteristiche

utilizza come hypervisor KVM o Xen (PVM e HVM)
macchine virtuali in HA N+1
gestione dei dischi delle vm tramite LVM (consigliato) o file disco (raw o qcow2)
live migration (se si utilizza DRBD)
migrazione automatica in base a diversi parametri (ram disponibile, carico del nodo, ecc)
accesso diretto tramite VNC o virtual serial console
media scalabilità (è consigliato un numero di nodi non superiore a 40)

Una considerazione importante da fare è che l’HA di ganeti riguarda esclusivamente lo storage.

Al momento della creazione di una macchina virtuale ridondata, bisogna specificare il nodo primario e il secondario.

Nel primario sarà avviata l’istanza della vm, nel secondario verrà fatto un backup, tramite DRBD (protocollo C), dei dischi collegati alla vm. Quindi se il nodo in cui è avviata l’istanza cade, vengono fermate tutte le vm che avevano quel nodo come primario, e bisogna far partire manualmente le vm nel nodo secondario.

Purtroppo ganeti non prevede alcuna automazione in merito. Anche se è sempre possibile affiancargli un sistema come peacemaker o heatbeat.

Un’altra caratteristica importante del progetto è che gode di una comunità abbastanza attiva, anche se a volte un po’ rigida (vedi ad esempio il supporto a DRBD protocollo A).

Questo post è composto da vari appunti che ho preso nell’arco dell’utilizzo di questo ottimo programma. Il suo scopo è descriverne, a grandi linee, il suo funzionamento. Se si vuole approfondire è necessario leggere la documentazione ufficiale.

Installazione

L’architettura che creeremo è composta da un piccolo cluster ridondato, formato da 2 nodi:

nodo1 - sarà il nodo master dell’intero cluster
nodo2 - un nodo normale, configurato in modo da prendere il posto del nodo master, in caso di fault di quest’ultimo.

Come sistema operativo dei vari nodi utilizzeremo Debian squeeze GNU/Linux.

Entrambi i nodi dispongono di 1 HD da 1TB, così partizionato:

20 GB - per l’OS dell’host (partizionato a piacimento)
16 GB (o più) - per lo swap dell’host e dei vari guest, tramite l’overcommitting di kvm
200 GB - per i template ed i backup
il resto - LVM per i dischi delle vm

Le seguenti operazioni vanno effettuate su tutti i nodi.

Assicuriamoci di avere come locale predefinito *en_US.UTF-8*, e di utilizzare lo stesso timezone in tutti i nodi.

dpkg-reconfigure locales
dpkg-reconfigure tzdata

Installazione dei pacchetti base

apt-get install qemu-kvm drbd8-utils lvm2 ssh bridge-utils iproute iputils-arping \
                python python-pyopenssl openssl \
                python-pyparsing python-simplejson \
                python-pyinotify python-pycurl socat \
                build-essential python-paramiko \
                dump kpartx

Configurazione del modulo drbd

Assicuriamoci di avere un kernel con il supporto per drbd, e disabilitiamo l’helper di default:

echo "drbd minor_count=128 usermode_helper=/bin/true" >> /etc/modules
depmod -a
modprobe drbd

Configurazione della rete

In questo post adotteremo una classica configurazione con bridge virtuali, per poter semplicemente instradare il traffico alle vm. Per una configurazione avanzata è consigliabile utilizzare delle VLAN.

Per prima cosa dobbiamo impostare tutti gli ip e gli hostname che verranno utilizzati nel nostro cluster. Ganeti per i nomi host utilizza il “fully qualified host name”, in modo da evitare la chiamata di sistema alla libreria del resolver. Questo è fondamentale, ad esempio, se si virtualizza all’interno dell’infrastruttura il/i server DNS che verranno utilizzati dalla stessa.

nodo1:

file: /etc/hostname

nodo1.ganeti.test

nodo2:

file: /etc/hostname

nodo2.ganeti.test

Inoltre bisogna impostare un hostname per il cluster di ganeti, in modo che se cambiamo il ruolo del nodo2, da normale a master, il sistema configurerà automaticamente un alias dell’interfaccia di rete, del nodo2, con l’ip del cluster.

Impostiamo il file hosts in entrambi i nodi:

file: /etc/hosts

127.0.0.1       localhost.localdomain localhost

10.0.0.1        cluster.ganeti.test   cluster

10.0.0.11       nodo1.ganeti.test     nodo1
10.0.0.12       nodo2.ganeti.test     nodo2

10.0.0.101      vm1.ganeti.test       vm1
10.0.0.102      vm2.ganeti.test       vm2
10.0.0.250      template.ganeti.test  template

Dopodiché è necessario configurare il bridge virtuale.

file: /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vbr0
iface vbr0 inet static
        address 10.0.0.11
        netmask 255.255.255.0
        network 10.0.0.0
        broadcast 10.0.0.255
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

Stessa cosa per il nodo2, cambiando solamente l’ip.

Reinizializziamo le interfaccie e la configurazione di rete:

/etc/init.d/networking restart
/etc/init.d/hostname.sh start

Configurazione LVM

Per poter sfruttare la ridondanza sui deschi delle vm, è necessario configurare LVM:

# inizializziamo una partizione per l'utilizzo di LVM
pvcreate /dev/sdb1

# aggiungiamo la partizione ad un VG
vgcreate ganeti /dev/sdb1

Assicuriamoci di aggiungere i device drbd alla direttiva filter:

file: /etc/lvm/lvm.conf

filter = ["r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" ]

Installazione di ganeti

Dopo tutte le operazioni preliminari, possiamo passare all’installazione del software:

cd /usr/local/src
wget http://ganeti.googlecode.com/files/ganeti-2.4.5.tar.gz
tar zxf ganeti-2.4.5.tar.gz
cd ganeti-2.4.5
./configure --localstatedir=/var --sysconfdir=/etc
make && make install

# assicuriamoci di creare tutte le directory necessarie
mkdir -p /etc/ganeti /srv/ganeti/os /srv/ganeti/export

# copiamo tutti i file *accessori* nelle giuste directory
cp doc/examples/ganeti.default /etc/default/ganeti
cp doc/examples/ganeti.initd /etc/init.d/ganeti
cp doc/examples/ganeti-kvm-poweroff.initd /etc/init.d/ganeti-kvm-poweroff
cp doc/examples/ganeti.cron /etc/cron.d/ganeti
cp doc/examples/gnt-config-backup /etc/cron.daily/
cp doc/examples/bash_completion /etc/bash_completion.d/ganeti
chmod +x /etc/init.d/ganeti /etc/init.d/ganeti-kvm-poweroff /etc/cron.daily/gnt-config-backup

# attiviamo gli script di init
update-rc.d ganeti defaults 20 80
update-rc.d ganeti-kvm-poweroff defaults 20 70

Per fare il deployment delle vm, ganeti mette a disposizione un tool esterno (ganeti-instance-debootstrap), basato su debootstrap, che permette di installare vm con un sistema debian minimale, per poi clonarlo per la varie vm.

Noi invece utilizzeremo un tool diverso, ganeti-instance-image, che ci permette di lavorare più facilmente con le vm, indipendentemente dall’OS utilizzato.

Questo tool utilizza il programma qemu-img per lavorare con le immagini delle vm, visto che in Debian il pacchetto kvm installa il programma con il nome kvm-img, è sufficiente creare un alias per risolvere il problema:

ln -s /usr/bin/kvm-img /usr/local/bin/qemu-img

Installiamo ganeti-instance-image:

cd /usr/local/src
wget http://code.osuosl.org/attachments/download/2163/ganeti-instance-image-0.5.1.tar.gz
tar zxf ganeti-instance-image-0.5.1.tar.gz
cd ganeti-instance-image-0.5.1/
./configure --prefix=/usr --localstatedir=/var \
  --sysconfdir=/etc \
  --with-os-dir=/srv/ganeti/os
make && make install

# copiamo il file della configurazione predefinita
cp defaults /etc/default/ganeti-instance-image

# creiamo un link su /usr/share per evitare qualche
# script con scolpito il path sbagliato
ln -s /srv/ganeti /usr/share/ganeti

Configurazione

Ganeti utilizza diversi comandi per gestire i vari aspetti dell’architettura. I più importanti sono:

gnt-cluster - per gestire il cluster ganeti
gnt-node - per gestire i nodi
gnt-instance - per gestire le instanze delle vm
gnt-backup - per importare ed esportare la vm (dati e configurazione)
gnt-os - per gestire i tool esterni che si occupano del deploy dell vm

Iniziamo a configurare il cluster.

Ganeti permette di avere un solo nodo con privilegi di cluster manager, in grado di gestire tutti gli aspetti dell’architettura, ed N nodi come suoi “backup”.

Scegliamo il nodo1 come cluster master ed inizializziamo il cluster:

gnt-cluster init --vg-name ganeti --master-netdev eth0 --nic-parameters link=vbr0 \
  --enabled-hypervisors=kvm --maintain-node-health yes \
  --hypervisor-parameters kvm:vnc_bind_address=0.0.0.0,kernel_path=,initrd_path= \
  --backend-parameters vcpus=2,memory=512M \
  cluster.ganeti.test

Analizziamo i vari parametri:

vg-name ganeti : impostiamo il VG da utilizzare, quello predefinito è “xenvg”.
master-netdev eth0 : l’interfaccia sulla quale attivare l’ip per l’host cluster.ganeti.test (tramite alias). Ogni nodo impostato come “slave” dovrà utilizzare l’interfaccia, con quel nome, in modo da poterlo utilizzare in caso di failover del nodo master.
nic-parameters link=vbr0 : impostiamo il tipo (bridge, in modo predefinito) ed il nome dell’interfaccia del nodo.
enabled-hypervisors kvm : utilizziamo solamente kvm come hypervisor.
maintain-node-health yes : abilitiamo la manutenzione automatica, ad esempio alla disattivazione di un link drbd viene automaticamente spenta l’istanza associata.
hypervisor-parameters … : impostiamo i valori predefiniti dell’hypervisor. Disabilitiamo il path del kernel e dell’initrd, in modo da caricare il kernel dalla vm e non dall’hypervisor.
backend-parameters … : impostiamo i valori predefiniti per le vm.
cluster.ganeti.test : hostname riservato al nodo master del cluster.

Adesso dovremmo avere i processi ganeti-noded, ganeti-masterd, ganeti-confd e ganeti-rapi attivi.

Aggiungiamo il nodo2 al cluster, specificando che potrà prendere il posto del nodo master:

gnt-node add --master-capable=yes zeniba2.libreit.org

Controlliamo che tutto sia andato liscio e che ganeti abbia configurato correttamente il device eth0:0 sul nodo1 con:

gnt-cluster verify
ifconfig eth0:0

Creazione di una vm come template

Se non abbiamo in precedenza realizzato un template della vm, con virtualbox, vagrant o qualsiasi altro sistema, possiamo farlo direttamente da ganeti.

Utilizziamo il tool ganeti-instance-image per creare la vm che useremo come template. Modifichiamo il file /etc/ganeti/instance-image/variants.list aggiungendo la voce “template” e creiamo il file template.conf:

file: /etc/ganeti/instance-image/variants/template.conf

ARCH="x86_64"
IMAGE_NAME="template"
IMAGE_TYPE="qemu"
IMAGE_DEBUG=1

Copiamo i file appena modificati su tutti i nodi utilizzando il comando:

gnt-cluster copyfile /etc/ganeti/instance-image/variants.list
gnt-cluster copyfile /etc/ganeti/instance-image/variants/template.conf

Assicuriamoci di aver aggiunto in modo corretto la nostra configurazione dell’os:

gnt-os list

Installazione del template

Creiamo una nuova istanza, ed impostiamo il boot da cdrom passandogli l’iso che vogliamo utilizzare:

gnt-instance add -t plain -n nodo1.ganeti.test -o image+template --no-install \
  --disk 0:size=5G --net 0:ip=10.0.0.250
  -H kvm:boot_order="cdrom",cdrom_image_path="/isos/debian-6.0.3-amd64-netinst.iso" \
  template.ganeti.test

I vari parametri sono abbastanza autoesplicativi, quelli più importanti sono:

-t indica il tipo di backend utilizzato per il disco della vm, con “plain” utilizziamo un volume LVM non replicato. Altre opzioni sono “drbd” (LVM replicato), “file” e “diskless”.
-o indica la il tool per il deploy della vm da utilizzare, con la relativa configurazione separata da “+”.
-n indica il nodo in cui verrà eseguita l’instanza e creato il disco (se è una vm ridondata vanno inseriti 2 host, separati da “:“).
–no-install serve per non far partire il deploy automativo di ganeti-instance-image. Anziché usare questo parametro avremmo potuto aggiungere la direttiva CDINSTALL nel file template.conf.

Avviamo la vm e vediamo le informazioni relative all’istanza:

gnt-instance start template.ganeti.test
gnt-instance info template.ganeti.test

Colleghiamoci al guest tramite VNC alla porta riportata dal comando gnt-instance info, alla voce “Allocated network port”:

vncviewer cluster.ganeti.test:11001

Installiamo regolarmente il guest, non impostando la partizione di swap.

Una volta che il nostro template è pronto possiamo creare l’immgine:

/srv/ganeti/os/image/tools/make-qemu-img template.ganeti.test

Utilizziamo il formato qcow2 e non dump, per il salvataggio dell’immagine, perché è più semplice da trattare (è come se usassimo un dispositivo raw) e non ci limita nel partizionamento della vm. Con questo formato, però, il deploy delle vm diventa sensibilmente più lento e soprattutto poco personalizzabile (ip, hostname, ecc). Se si vogliono utilizzare altri formati (dump, tar) si consulti la documentazione.

Adesso che abbiamo l’immagine possiamo creare le nostre macchine virtuali.

deploy delle virtual machine

Modifichiamo il file di configurazione predefinito di ganeti-instance-image:

file: /etc/default/ganeti-instance-image

ARCH="x86_64"
IMAGE_NAME="template"
IMAGE_TYPE="qemu"
NOMOUNT="yes"

Proviamo a creare una vm:

gnt-instance add -t drbd -n node1.ganeti.test:node2.ganeti.test -o image+default \
  --disk 0:size=5G --net 0:ip=10.0.0.101 vm1.ganeti.test

Se tutto è andato bene adesso possiamo avviare dei test più approfonditi includendo anche lo storage ridondato (drbd):

# rimuoviamo la vm di prova
gnt-instance remove vm1.ganeti.test

# avviamo il test utilizzando un tool incluso con ganeti
/usr/local/lib/ganeti/tools/burnin -v -o image+default -t drbd \
  -n node1.ganeti.test:node2.ganeti.test  --disk-size=5G \
  vm{1,2}.ganeti.test

Importare macchine virtuali

Ganeti ci permette di importare facilmente vm provenienti da altri ambienti. L’importante è che abbiamo i dischi salvati in un formato supportato da qemu-img.

Come esempio, importiamo una vm windows con 16 GB di disco, nella nostra bella architettura con storage ridondato:

# creiamo la configurazione per la vm, senza far partire il deploy
# ed utilizzando il nodo2 come primario
gnt-instance add -t drbd -n node2.ganeti.test:node1.ganeti.test -o image+default \
  --no-install --no-start --disk 0:size=16G --net 0:ip=10.0.0.102 \
  vm2.ganeti.test

# recuperiamo l'id del disco associato alla vm, nella voce "Disks" -> "on primary"
gnt-instance info vm2.ganeti.test

# copiamo l'immagine del disco nel dispositivo ridondato
kvm-img convert -f qcow2 -O host_device /tmp/winzoz-x86_64.img \
  /dev/ganeti/9259bb19-f0ed-4c1a-9d0e-864477605e39.disk0

# se nel sistema operativo non sono installati i driver virtio
# sarà necessario riconfigurare l'istanza per utilizzare i driver ide
gnt-instance modify -H disk_type=ide -B memory=2048 w.libreit.org

# avviamo l'istanza
gnt-instance start vm2.ganeti.test

Tuning

Per migliorare le prestazioni delle vm, è possibile istruire kvm ad utilizzare la cpu dell’host così com’è, senza emularne caratteristiche aggiuntive.

# informiamo APT che stiamo rinominando il binario di kvm
dpkg-divert --add --rename --divert /usr/bin/kvm.real /usr/bin/kvm

# creiamo un wrapper
cat <<EOF > /usr/bin/kvm
#!/bin/sh
/usr/bin/kvm.real -cpu host "$@"
EOF

# e lo rendiamo eseguibile
chmod +x /usr/bin/kvm

Un ulteriore miglioramento, di circa il 6%, si ottiene semplicemente disabilitando la console VNC:

gnt-instance modify -H vnc_bind_address= vm{1,2}.ganeti.test

Altre caratteristiche

Ganeti offre molte altre caratteristiche non descritte in questo post, le più importanti, a mio avviso, sono:

gnt-backup - permette di effettuare i backup dei dischi e della configurazione associata ad una vm. Una limitazione di questo tool è che mantiene solo 1 backup per vm.
hooks
- comodo sistema per eseguire tool esterni in base ai vari stati del
cluster, nodo, vm.
gnt-instance console vm - abilitando nel guest una console fisica (solitamente nel file /etc/inittab), è possibile utilizzarla al posto della, spesso scomoda, console VNC.

Conclusione

Ganeti rimane uno dei pochi gestori di macchine virtuali a non adottare i paradigmi del cloud computing.

Nei prossimi post cercheremo di trattare anche quelli.

Risorse utili.

gestione delle credenziali

Sun, 09 Oct 2011 22:00:00 GMT

L’autenticazione è da sempre, uno degli aspetti fondamentali dell’informatica. Spesso però la gestione delle credenziali viene trascurata, sia dai singoli utenti (power-user inclusi) che da molte realtà aziendali.

In questo post esamineremo alcuni sistemi per gestire in modo sicuro, le credenziali per accedere a risorse locali (pc, laptop, NAS, ecc), risorse remote (siti web, email, ftp, ecc) e dati sensibili in generale.

Requisiti e caratteristiche

La maggior parte dei sistemi operativi includono dei sistemi di autenticazione che si basano unicamente sul concetto di password o passphrase. Questo fattore di autenticazione si è rivelato debole e relativamente e semplice da aggirare.

Per superare questa limitazione utilizzeremo la Strong authentication

Strong authentication

È un metodo che combina più fattori di autenticazione:

Una cosa che conosco - una password, un pin, una risponda ad una domanda generica (2+2=?)
Una cosa che ho - un token fisico, una carta di credito, un cellulare
Una cosa che sono - l’impronta digitale, l’iride, DNA

In questo modo incrementeremo, in maniera sensibile, la sicurezza complessiva del sistema.

Caratteristiche

I criteri adottati per la realizzazione del sistema, sono i seguenti:

libertà:
- sia il software che l’hardware devono essere completamente accessibili ed aderenti alla filosofia del free software.

listend

flessibilità:
- per poter integrare facilmente al sistema, applicazioni, servizi, dispositivi, ecc.

listend

praticità:
- se un sistema di autenticazione risulta poco pratico, con molta probabilità, non verrà mai utilizzato.

listend

costo:
- forse per proteggere un semplice servizio web, non vale la pena spendere troppi soldi.

Scelta del supporto

I dispositivi che ritengo più aderenti alle caratteristiche sopra descritte, sono sostanzialmente due:

YubiKey
- diverse modalità di utilizzo
  - modalità YubiKey One-Time Password (OTP)
  - modalità OATH-HOTP
  - modalità static password (password classica + password forte generata dalla yubikey)
- indipendente dalla piattaforma utilizzata
- facilmente integrabile con sistemi di crittografia dati (dm-crypt, ecryptfs) e per l’autenticazione locale

GPF Crypo Stick
- utilizzo dello standard OpenPGP
- integra il chip della OpenPGP card con un lettore USB
- supporta 3 chiavi RSA, indipendenti, a 2048 bit
- PIN di sicurezza con lunghezza da 6 a 32 caratteri
- supporta (con limitazioni) i certificati X.509
- elimina l’ingombro di doversi portare sempre dietro il lettore di smartcard e la carta stessa
- difficilmente integrabile per l’autenticazione locale

Dopo un’attenta analisi ho deciso di utilizzare la YubiKey, per via della sua flessibilità e semplicità.

Magari in un post successivo tratterò come utilizzare il dispositivo GPF Crypo Stick, per gestire un portafoglio di chiavi GPG/PGP.

Casi d’uso

autenticazione locale

Per autenticarsi alla workstation (laptop, pc, tablet) si è optato per la modalità static password in modo da poter accedere anche senza connettività e per poterla integrare facilmente con eCryptfs

Ritengo l’uso della modalità static password un buon compromesso tra livello di sicurezza e praticità. A patto che venga aggiornata mensilmente e affiancata da un buon sistema di backup (criptato) della stessa.

gestione dei dati criptati

Si è scelto uno stacked cryptographic filesystem, innanzitutto perché si vuole essere indipendenti da partizioni criptate con dimensioni fisse, e poi perché si vogliono utilizzare le stesse credenziali di accesso al sistema (password classica + yubikey static password) per montare/decifrare in modo automatico la directory con i dati da proteggere.

Per evitare rallentamenti sulle prestazioni del disco, si è optato per la cifratura di una sotto-directory della home utente (~/Private).

Questa soluzione rende più agevoli le operazioni di backup, in quanto i file in forma cifrata restano disponibili nella directory (~/.Private).

autenticazione remota

Modalità One-Time Password tramite vari client

connessioni ssh tramite Yubico PAM module
servizi internet tramite mod_authn_yubikey e ruby client
servizi web per la gestione di credenziali tipo passpack o lastpass (non-free!)

Modalità static password

chiavi ssh salvate sul file system criptato (per host in cui non è installato il modulo PAM Yubico)
in generale applicazioni che utilizzano file sul file system criptato per autenticarsi (certificati SSL, chiavi GPG, ecc)

Configurazione

modalità OTP (Strong authentication)

openssh

Installiamo il modulo yubico-pam, compilando i vari sorgenti o tramite il pacchetto debian:

sudo echo "deb http://ppa.launchpad.net/fredrikt/yubico/ubuntu lucid main" >> /etc/apt/sources.list.d/yubikey-pam.list
sudo aptitude update
sudo aptitude install libpam-yubikey

Impostiamo il modulo pam come metodo di autenticazione predefinito. In questo modo possiamo autenticarci utilizzando la password dell’utente e l’OTP della yubikey.

Modifico il file /etc/pam.d/common-auth:

# aggiungo prima di pam_unix la regola per pam_yubico auth requisite
pam_yubico.so id=16 debug auth [success=1 default=ignore]
pam_unix.so nullok_secure try_first_pass

Creiamo il file in cui saranno inserite le informazioni di debug

sudo touch /var/run/pam-debug.log
sudo chmod go+w /var/run/pam-debug.log

Adesso è necessario creare un file che associa la chiave ad uno o più utenti unix. Si può creare il file, sia per utente ~/.yubico/authorized_yubikeys, che globalmente aggiungendo il parametro authfile=/etc/NOMEFILE alla direttiva di pam_yubico.so.

auth requisite pam_yubico.so id=16 authfile=/etc/yubikey_mappings

(l’ID della yubikey e l’OTP, presenti in questo post, sono falsi)

file: ~/.yubico/authorized_yubikeys

# username:yubikey ID 1:yubikey ID 2:yubikey ID N:...
kalos:cchehkifidig

Proviamo ad autenticarci con il nuovo sistema, inserendo la password unix, subito seguita (senza spazi) dal codice OTP creato tenendo premuta la yubikey per 1 secondo.

Il file di debug dovrebbe mostrare delle righe simili:

file: /var/run/pam-debug.log

[pam_yubico.c:parse_cfg(597)] called.
[pam_yubico.c:parse_cfg(598)] flags 1 argc 2
[pam_yubico.c:parse_cfg(600)] argv[0]=id=16
[pam_yubico.c:parse_cfg(600)] argv[1]=debug
...
[pam_yubico.c:pam_sm_authenticate(650)] get user returned: kalos
[pam_yubico.c:pam_sm_authenticate(754)] conv returned 62 bytes
[pam_yubico.c:pam_sm_authenticate(772)] Skipping first 18 bytes. Length is 62, token_id set to 12 and token OTP always 32.
[pam_yubico.c:pam_sm_authenticate(779)] OTP: cchehkifidighrhhehkifidighrhrhvifidighrhrhdd ID: cchehkifidig
[pam_yubico.c:pam_sm_authenticate(789)] Extracted a probable system password entered before the OTP - setting item PAM_AUTHTOK
[pam_yubico.c:pam_sm_authenticate(805)] ykclient return value (0): Success
[pam_yubico.c:check_user_token(141)] Authorization line: kalos:cchehkifidig
[pam_yubico.c:check_user_token(145)] Matched user: kalos
[pam_yubico.c:check_user_token(149)] Authorization token: cchehkifidig
[pam_yubico.c:check_user_token(152)] Match user/token as kalos/cchehkifidig

Se tutto è andato bene rimuoviamo il file di debug ed eliminiamo la direttiva debug nel file /etc/pam.d/common-auth.

lastpass (non-free!)

Lastpass offre un sistema per gestire le password dei siti web, che integra l’utilizzo della yubikey. Un video ci mostra un esempio di utilizzo.

modalità static password

configurazione della yubikey

La moderne yubikey, supportano due diverse configurazioni, utilizzabili nello stesso dispositivo.

La prima viene richiamata tenendo premuta la chiave per un lasso di tempo di 0.3 - 1.5 secondi.
La seconda viene richiamata tenendo premuta la chiave per un lasso di tempo di 2.5 - 5 secondi.

Normalmente la chiave viene fornita con una sola configurazione attiva, impostata per l’utilizzo dell’OTP. Per utilizzare la seconda configurazione è necessario installare il programma yubikey-personalization.

sudo aptitude install yubikey-personalization

Inseriamo la yubikey e impostiamo la seconda configurazione per l’utilizzo della modalità static password, con il seguente comando:

sudo ykpersonalize -2 -ofixed=ichkicichv -o-man-update

Vediamo brevemente i vari parametri:

-2 serve a selezionare la seconda configurazione.
-ofixed serve a dare un prefisso, di massimo 16 caratteri, che identifica la chiave statica. È possibile utilizzare il convertitore modhex per convertire una stringa al formato modhex, ad esempio la stringa “pippo” in formato modhex diventa “ichkicichv”.
-o-man-update disabilita la funzione che permette di generare una nuova password statica casuale, tenendo premuta la yubikey per un lasso di tempo di 8 - 15 secondi.

L’output del comando sarà simile a:

Firmware version 2.2.4 Touch level 1283 Program sequence 4

Passphrase to create AES key:
Configuration data to be written to key configuration 2:

fixed: m:ichkicichv
uid: h:000000000000
key: h:45c5846e7166928f1b00d131e868d90f
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: STATIC_TICKET|STRONG_PW1|STRONG_PW2
extended_flags:

Commit? (y/n) [n]: y

Se non si inserisce la passphrase per creare la chiave AES, questa viene generata casualmente.

È, inoltre, possibile proteggere la scrittura della configurazione con una sorta di password, chiamata access code. Per ulteriori informazioni si può consultare la manpage del programma o il manuale tecnico

cambiare la password utente

Una volta creata la chiave statica, è necessario cambiare la password utente, con un semplice:

passwd

Inseriamo un password relativamente semplice, e poi teniamo premuta la yubikey per 3 secondi.

configurazione ecryptfs

Assicuriamoci di caricare il modulo ecryptfs e installiamo il programma in user-space:

sudo modprobe ecryptfs
sudo aptitude install ecryptfs-utils

La configurazione è piuttosto semplice:

ecryptfs-setup-private

Basta inserire la nuova password utente e verranno create le directory ~/.Private ~/Private ed ~/.ecryptfs. La mount passphrase la lasciamo generare automaticamente.

Ecco l’output:

Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase THIS WILL BE
REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************

Done configuring.

Testing mount/write/umount/read...
Inserted auth tok with sig [a3aba160257a7eaa] into the user session keyring
Inserted auth tok with sig [059348b89995a646] into the user session keyring
Inserted auth tok with sig [a3aba160257a7eaa] into the user session keyring
Inserted auth tok with sig [059348b89995a646] into the user session keyring
Testing succeeded.

Logout, and log back in to begin using your encrypted directory.

La configurazione predefinita di ecryptfs cifra la directory ~/.Private utilizzando la password utente per decriptare la mount passphrase. Inoltre è abilitato, in maniera predefinita, il montaggio automatico di ~/Private e la cifratura dei nomi dei file.

Adesso basta ri-autenticarsi, chiudendo prima tutte le sessioni aperte con il nostro utente. Ora si può cominciare ad inserire i file sensibili nella directory ~/Private. Questi file verranno criptati in maniera trasparente nella directory ~/.Private.

aggiornare la password

Le password vanno aggiornate con una certa frequenza, e quella statica della yubikey non fa eccezione.

Per prima cosa salviamo la password attuale e la mount passphrase, decriptata, in variabili temporanee:

read -s old_pass # inseriamo la password vecchia password (inclusa la password della yubikey)
mount_pass=$(echo $old_pass | ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase -)

Generiamo una nuova password statica per la yubikey, magari con un nuovo prefix (pluto) :

sudo ykpersonalize -2 -ofixed=ichrigifhv -o-man-update

Cambiamo la password utente, utilizzando una classica password (anche quella vecchia) insieme alla nuova password generata dalla yubikey:

# utilizzo sudo per evitare di dover inserire la vecchia password
sudo passwd $USER

Cifriamo la mount passphrase con la nuova password utente:

read new_pass # inseriamo la nuova password
echo "$mount_passn$new_pass" | ecryptfs-wrap-passphrase ~/.ecryptfs/wrapped-passphrase

Eliminiamo le variabili:

unset old_pass mount_pass new_pass

Backup

Se non si vuole correre il rischio di perdere le credenziali per i propri sistemi (locali e remoti) ed l’accesso ai dati sensibili, è fondamentale stabilire una buona politica di backup.

credenziali remote

La soluzione migliore è quella di possedere 2 yubikey, una per tutti i giorni ed una da conservare in un posto sicuro. Ovviamente bisogna abilitare la seconda chiave per vari servizi web di gestione password, ssh, web (mod_authn_yubikey), ecc

Un’altra soluzione, soprattutto per le credenziali ssh, è quella di aggiungere all’host, un utente con accesso limitato e con una password forte, che possa solamente decriptare un file, con un’altra password forte, che contiene la password per poter accedere allo stesso sistema come un utente privilegiato.

Una sorta di backdoor con due livelli di protezione… l’ultima cosa che vogliamo è perdere il controllo dei nostri sistemi, non è vero? ;)

credenziali locali

Per salvaguardare le password classiche e quelle generate dalla yubikey, uno dei metodi più semplici è quello di farsi mandare via email un file criptato con tutte le credenziali.

Ecco un esempio di script da eseguire ad ogni aggiornamento della password:

Le possibili soluzioni sono infinite, si può criptare il file con le credenziali utilizzando l’OTP della yubikey di scorta, criptarlo con la propria chiave GPG, steganografarla, ecc…

Insomma basta solo un po’ di fantasia.

zsh the powerful shell

Sat, 01 Oct 2011 22:00:00 GMT

La shell è l’interfaccia per eccellenza degli smanettoni.

Quando si comincia a farne un utilizzo costante, si sente il bisogno di spingersi oltre, scoprendo/creando delle funzionalità che ci semplificano ulteriormente la vita.

Almeno questa è stata la mia reazione… un bel po’ di tempo fa.

Dopo aver provato a personalizzare la bash, mi resi conto che le mancavano molte funzionalità presenti in altre shell. Decisi di cambiare proprio tipo di shell ed iniziai ad utilizzare la tcsh, una versione migliorata di csh.

Ero abbastanza soddisfatto della mia configurazione, quando un amico mi parlò di zsh.

funzionalità

Questa potente shell, come moltissimi progetti informatici (vedi ruby), prende il meglio delle caratteristiche da altri progetti simili e aggiunge, tramite un ottimo collante, altre funzionalità originali.

Si può considerare questa shell come una sorta di superset di sh, ash, bash, csh, ksh, e tcsh.

Qualche anno fa avevo pure fatto un piccolo screencast che illustrava alcune caratteristiche di zsh…

Andiamo a vedere nel dettaglio alcune delle funzionalità più importanti.

Command line completition

In zsh il completamento non si limita ai nomi dei programmi, ma include anche i vari argomenti ed i parametri degli stessi.

Costruendoli anche dinamicamente.

Il tutto completamente personalizzabile.

Tra le altre cose, questa funzionalità integra un sistema di caching, per i completamenti più dispendiosi (es: il completamento di tutti i nomi dei programmi disponibili nei repository debian)

Un’altra interessante caratteristica del sistema di completamento è il correttore ortografico.

File globbing

Il potentissimo file globbing di zsh permette di specificare una determinata categoria di file, facendo a meno di utilizzare programmi esterni come find/args.

Vediamolo in azione:

# tutti i file nella directory /tmp e nelle relative sottodirectory, di proprietà dell'utente kalos
ls -l /tmp/**/*(u:kalos:)

# tutti i file regolari (non symlink, dir, ecc)
ls -l /boot/*(.)

# tutti i file regolari ed eseguibili
ls -l /bin/*(.x)

# tutti i file che non hanno abilitata la scrittura per il gruppo di appartenenza
ls -l /tmp/**/*(.:g-w:)

# tutti i file piu' vecchi di 20 minuti
ls -l /tmp/.(mm+20)

# tutti i file vuoti
ls -l /tmp/*(.L0)

# tutti i file (comprese le directory) senza estenzione
ls -ld ^?/./(D)

Gestione avanzata di variabili e array

Sostituzione delle variabili

FILE="/home/kalos/doc/ruby/rspec.pdf"

# stampa il contenuto della variabile $FILE sostituendo le occorrenze di "kalos" con "marco"
echo ${FILE//kalos/marco} » /home/marco/doc/ruby/rspec.pdf

# stampa solo il nome del file (come il programma "basename")
echo ${FILE##*/} » rspec.pdf

# stampa solo il percorso del file (come "dirname")
echo ${FILE%//./} » /home/kalos/doc/ruby

# elimina l'estensione nella stringa salvata nella variabile
FILE="rspec.pdf" echo $FILE:r » rspec

# per ulteriori informazioni
man 1 zshexpn

Array ed array associativi

Questa funzionalità è molto utile se si stanno creando degli script non proprio banali.

array=(foo bar lillo boom)

# stampa l'ultimo elemento
echo $array[-1]
» boom

# stampa dal secondo al penultimo elemento
echo $array[2,-2]
» bar lillo

# dichiarazione di un array associativo
typeset -A array_ass

# inizializzazione dell'array
array_ass=(uno 1 due 2 tre 3 quattro 4)

# stampa solo le chiavi
print ${(k)array_ass}
» uno due tre quattro

# stampa i valori
print ${(v)array_ass}
» 1 2 3 4

# ordina le chiavi in base ai nomi
print ${(ok)array_ass}
» due quattro tre uno

# modifica il valore di un array associativo
array_ass[tre]='03'

# stampa l'array ordinato
print ${(o)array_ass}
» 03 1 2 4

Alias

Zsh amplia il concetto di aliasing introducendo:

alias globale

È un tipo di alias che può essere utilizzare in qualsiasi parte della riga di comando e non solo all’inizio.

# definizione degli alias
alias -g Il="| less"
alias -g N="&>/dev/null"

# manda in pipe il file letto con cat a less
cat /var/log/messages Il

# redirige lo standard output e lo standard error nel nulla
rm -rf /tmp N

alias dei suffissi

Se si esegue un file con un certo suffisso, viene automaticamente eseguito il programma associato

alias -s txt=$EDITOR
alias -s {mpg,mpeg,avi,ogm,wmv,m4v,mp4,mov,mkv}="mplayer"

# come un nerd guarda un film ;)
~FILM/totoro.avi

Modalità compatibilità

Zsh ha la possibilità di emulare il comportamento delle shell csh, sh e ksh (la sua parente più vicina).

Questo ci permette, ad esempio, di utilizzare la nostra shell come shell predefinita di sistema per tutti gli script di init, ecc.

Le modalità di compatibilità possono essere eseguite in due modi:

creando un link della shell da emulare che punta al binario di zsh (ln -s /bin/zsh /bin/csh). In questo caso si ottiene un’emulazione completa della shell.
abilitando selettivamente tutte le funzionalità da emulare, ad esempio con “setopt KSH_GLOB”

History condiviso da più sessioni contemporaneamente

Questa funzionalità può tornare utile, ad esempio, quando più persone stanno lavorando sullo stesso sistema e vogliono condividere i comandi lanciati

configurazione

La configurazione di zsh non è tra le più semplici.

Per facilitare le cose, è stato realizzato un bel progetto collaborativo.

oh-my-zsh

E’ un piccolo framework che fornisce una configurazione abbastanza completa ed un sistema di plugin aggiuntivi.

installazione

wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

utilizzo

Per utilizzarlo basta modificare il file ~/.zshrc per abilitare qualche plugin e configurare il tema del prompt preferito.

aggiornamento

Una delle funzionalità più importanti di questo framework è il costante aggiornamento effettuato dalla vasta comunità che ci lavora.

Di default il programma chiede di auto-aggiornarsi ogni settimana, attraverso il file oh-my-zsh/tools/upgrade.sh, che non fa altro che eseguire il comando “git pull origin master”.

come gestire un proprio fork di OMZ

Se si vuole gestire la propria configurazione di zsh attraverso OMZ, questi sono i semplici passi da compiere:

fare il fork del progetto su github
aggiungere al repository git l’url del repository ufficiale di OMZ

git remote add upstream git://github.com/robbyrussell/oh-my-zsh.git

modificare il file tools/install.sh sostituendo git pull origin master con git fetch upstream && git merge upstream/master

risorse utili

Altri rifetimenti in merito li potete trovare nei miei bookmark salvati su delicious

initial commit

Thu, 29 Sep 2011 22:00:00 GMT

Dopo diverso tempo ho deciso di utilizzare un blog per condividere le mia passione (spasmodica) per l’informatica.

In particolare tutte le cose che possono interessare un utilizzatore di sistemi unix-like dal lontano 1999: amministrazione di sistemi, programmazione, configurazione avanzata di workstation, ecc.

Spero possa essere utile a qualcuno.