Vita Da Zazu

Lavorando col nuovo Xen 3.4 su Debian Lenny e su openSUSE 11.2, mi sono imbattuto in una problematica che personalmente ho dovuto affrontare molto ma molto di rado:

Assegnare un device fisico ad una macchina virtuale (domU).

Seguendo le vecchie procedure per il vecchio Xen, apparentemente al boot della dom0 la risorsa fisica veniva riservata, ma poi non funzionava nulla, ovvero, la macchina virtuale non partiva restituendo il seguente errore:

Error: pci: 0000:0d:08.0: non-page-aligned MMIO BAR found.

ho cercato soluzioni in lungo e in largo, senza giungere a nulla, finché non mi sono imbattuto in una patch del sorgente di Xen 3.4….
ebbene, leggendo il codice sorgente della patch è saltato fuori che con il nuovo Xen la sintassi per assegnare una risorsa è cambiata e nessuno lo sa!

Vengo quindi ad illustrare la procedura corretta:

per prima cosa, nella dom0 rifare l’initrd includendo il modulo “pciback“;

adesso con lspci andiamo a trovare l’ID della nostra scheda fisica:

# lspci

08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

08:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

0d:08.0 Communication controller: Digium, Inc. Wildcard TE220 dual-span T1/E1/J1 card 3.3V

0f:0d.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)

come parametro aggiuntivo del kernel xen, al grub si deve inserire questo:

guestdev=0000:0d:08.0 reassign_resources

nel file di configurazione della macchina virtuale basta aggiungere questa riga:

pci = [ '0d:08.0' ]

fatto adesso basta riavviare la nostra dom0 e la pci verrà riservata per la macchina virtuale…

Happy Xen

Sto provando Pardus 2009.2 sul mio eee-PC 900

Pardus è un mio vecchio amore a prima vista e dato che l’ho sempre ricordata come distribuzione piuttosto leggera, ho deciso di testarla sul mio eee-PC

il problema dell’eee-PC è che essendo un po’ limitato di risorse, con firefox va a fatica; siccome ho notato che ChromePlus comunque ci funziona bene, mi interessava poterlo usare anche su questa distro che nei repository non lo prevede… detto fatto, mi sono messo all’opera,

sono andato sul sito di ChromePlus e dato che Pardus è a 32 bit ho scaricato quanto disponibile per linux a 32 bit:

la versione “Debian/Ubuntu” e quella “Suse/Fedora”, vi dico subito di lasciar stare la versione per Debian che mi ha dato problemi, scaricate la versione “Suse/Fedora”

appena finito di scaricare, sono andato nella cartella “Scaricati” e con ark ho scompattato il tar.gz in una sottocartella;
fatto ciò, sono andato semplicemente di terminale:

$ su
# cd /home/zazu/Scaricati/chromeplus-1.3.3.3_suse_fedora_i686
# mkdir /opt/chromeplus
# cp -a * /opt/chromeplus
# cd /opt/chromeplus
# chown -R root:root *

con questi comandi sovrastanti ho copiato ChromePlus dentro opt e gli ho conferito i giusti permessi; opt è la cartella linux in cui si può mettere tutto ciò che è opzionale, per evitare problemi e conflitti col software pacchettizzato è sempre bene che quel che viene installato a mano, venga messo dentro opt.
Adesso andiamo a creare un link simbolico per l’eseguibile di Chromeplus:

# cd /usr/bin
# ln -s /opt/chromeplus/chrome-wrapper chromeplus

ora, manca un lanciatore per il menù di avvio e per il desktop:

# touch /usr/share/applications/chromeplus.desktop

dentro questo file appena creato dobbiamo metterci questo testo:

[Desktop Entry]
Name=ChromePlus
Exec=chromeplus %u
Icon=/opt/chromeplus/product_logo_48.png
Categories=Network;WebBrowser;
GenericName=Browser Web
Terminal=false
Type=Application
StartupNotify=true

io ho editato il file con vim:

# vi /usr/share/applications/chromeplus.desktop

ciò non toglie che se non si è capaci, lo si possa fare con l’editor che si preferisce (nano, kwrite, o altri);
per sempio, si potrebbe usare kwrite lanciandolo da utente normale (come root non si avvia):

$ xhost + && sudo kwrite /usr/share/applications/chromeplus.desktop

comunque, l’importante è creare, quel file, una volta salvato, tempo qualche secondo e nel menù di kde apparirà ChromePlus

Ultimo passaggio, i plugin:

siccome il pacchetto installato è pensato per openSUSE / Fedora, questo va a cercare i plugin nel percorso di default di uno dei due sistemi

Pardus usa una struttura differente, quindi i plugin non sembrano funzionare;

la soluzione è creare un link simbolico alla cartella dei plugin in modo da creare una posizione fittizia come se fosse la struttura di opensSUSE:

# cd /usr/lib
# ln -s nsbrowser/plugins/ browser-plugins

ora, abbiamo creato un percorso simbolico “usr/lib/browser-plugins” che punta a “usr/lib/nsbrowser/plugins” la cartella reale è la seconda, ma è raggiungibile anche dal link, questo basta a ChromePlus per ritrovare i necessari plugin e funzionare correttamente

Mi è capitato di dover connettere ad un server con openSUSE 11.2 un’AX150, il collegamento avviane via fibra ottica e ho un controller Qlogic a doppia porta

quindi, dato che anche lAX ha due porte in fibra, ho ben pensato di mettere in piedi una configurazione in failover cosicché il collegamento col server è ridondato….

ma veniamo al sodo:

nell’AX dall’interfaccia web Navisphere abilitiamo le connessioni dal nostro server, poi dentro opensuse occorre creare e “farcire” il file /etc/multipath.conf

ecco cosa inserire:

##
## This is a template multipath-tools configuration file
## Uncomment the lines relevent to your environment
##
defaults {

udev_dir              /dev
polling_interval      10
selector              “round-robin 0″
path_grouping_policy  multibus
getuid_callout        “/lib/udev/scsi_id –whitelisted –device=/dev/%n”
prio_callout          “mpath_prio_emc /dev/%n”
path_checker          emc_clariion
path_grouping_policy  failover
failback              immediate
user_friendly_names   yes

}
blacklist {

# ho aggiunto sda alla blacklist in quanto il disco di sistema
devnode “^(sda|ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*”
devnode “^hd[a-z][[0-9]*]”

}
multipaths {
multipath {

wwid                  600601608B861C00BC43DC9DC74BEF11
alias                 SambaShare
}

multipath {

wwid                  600601608B861C00BC43DC9DC74BEF11
alias                 Backup
}

}

una volta fatto ciò, occorre mettere in avvio il demone del multipath (anche da yast) col seguente comando:

# chkconfig multipathd on

riavviando poi il demone del multipath dovremmo poter vedere  i device nella nostra macchina:

# rcmultipathd restart

# multipath -l
mpathc (3600601608b861c002ab72276714cef11) dm-1 DGC,RAID 5
size=652G features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
`-+- policy=’round-robin 0′ prio=-2 status=active
|- 1:0:0:1 sdc 8:32 active undef running
`- 2:0:0:1 sde 8:64 active undef running
mpatha (3600601608b861c00bc43dc9dc74bef11) dm-0 DGC,RAID 5
size=690G features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
`-+- policy=’round-robin 0′ prio=-2 status=active
|- 1:0:0:0 sdb 8:16 active undef running
`- 2:0:0:0 sdd 8:48 active undef running

quando nel sistema vedremo una situazione del genere, dentro /dev/mapper troveremo i nostri device:

# ls -la /dev/mapper/
totale 0
drwxr-xr-x  2 root root     100 21 apr 18:23 .
drwxr-xr-x 15 root root    4520 21 apr 18:23 ..
crw-rw—-  1 root root  10, 58 21 apr 15:18 control
brw-r—–  1 root disk 253,  0 21 apr 15:18 mpatha
brw-r—–  1 root disk 253,  1 21 apr 15:18 mpathc

NB

se abbiamo appena creato i virtual disk dentro l’AX, nel sistema i device non appariranno MAI finché l’AX non ha finito al 100% l’operazione

finché il virtual disk starà nello stato di inizializzazione non viene passato alcun device alla macchina (questo, anche se potrebbe far pensare che il multipath non funzioni, è del tutto normale c’è solo da attendere

quando l’AX avrà finito il suo lavoro, allora riavviando il server, dentro di esso magicamente appariranno i nuovi device

Quando ci serve?

Se si hanno nella stessa rete due tipologie di apparati che si vuol tenere “separati”… diciamo così.

la situazione si è verificata passando dalla telefonia analogica al voip;

questo ha comportato l’introduzione di tanti telefoni IP, e per più motivi è bene che stiano su una classe a sé.

Si dovranno quindi gestire due tipologie di apparati:

i PC e i telefoni Grandstream, impossibile gestire i telefoni con ip fisso, sono troppi, per ogni eventuale modifica servirebbe uno schiavo per editarli tutti, quindi, dato che gli schiavi sono proibiti, bisogna fare tutto con DHCP .

La configurazione è più semplice del previsto:

DHCPD3 che già veniva usato per gestire la rete, prevede la possibilità di analizzare alcune informazioni fornite dai client quando richiedono un IP, nello specifico io ho focalizzato il mio interesse sul “vendor class identifier” che generalmente identifica il produttore/modello dell’apparecchio

tutti i telefoni Grandstream hanno come vendor class identifier una stringa del genere:  Grandstream [MODEL NAME]

da questa quindi si può facilmente operare una “discriminazione” rispetto ad un qualunque PC

nel file /etc/dhcp3/dhcpd.conf andranno definiti i pattern di controllo che a seconda del caso assegneranno un IP di pool differenti, in questo modo:

dhcpd.conf

ddns-update-style none;
authoritative;
log-facility local7;
option ntp-servers it.pool.ntp.org;

#matching classes
class “ip_phones” {

match if substring (option vendor-class-identifier, 0, 11) = “Grandstream”;
}

class “computers” {

match if not (substring (option vendor-class-identifier, 0, 11) = “Grandstream”);
}

shared-network exemple.local {

subnet 172.16.150.0 netmask 255.255.254.0

{
pool {

allow members of “ip_phones”;
option domain-name “phones.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 172.16.150.21 172.16.150.200;
option subnet-mask 255.255.254.0;
option broadcast-address 172.16.151.255;
option routers 172.16.151.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

subnet 10.10.20.0 netmask 255.255.255.0

{
pool {

allow members of “computers”;
option domain-name “computers.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 10.10.20.21 10.10.20.190;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.20.255;
option routers 10.10.20.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

}

Con la direttiva “allow members” possiamo gestire perfettamente tutto il traffico, questo ci permette di avere anche più di due pool, possiamo inoltre definire più pattern di verifica e accettare in un pool più tipologie:

se un giorno verranno introdotti dei telefoni Snom, potranno essere comunque assegnati alla LAN telefonica verificando sempre il loro vendor class identifier