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

A seguito di un aggiornamento di Asterisk e qui sono stato stupido per non aver prima fatto un backup , ricordate bambini, il backup è una cosa importante, più delle forbici dalla punta arrotondata!

Insomma, mi sono ritrovato con il mio centralino casalingo che non effettuava più chiamate uscenti da nessun account VOIP;

dato che prima funzionava, poi ha smesso, 2+2=3,5… la colpa è dell’aggiornamento!

Quindi, armato di pazienza e anche di tempo, perché ho perso 4 o 5 giorni dietro al problema bestemmiofero, sono giunto a riscrivere una configurazione funzionante anche nell’ultima relase di asterisk…

vado qui ad illustrare:

per completezza questo è quanto serve dentro extensions.conf affinché quanto scritto sopra funzioni:

[incoming]

exten => cheapnet,1,Dial(SIP/INTERNO)
exten => messagenet,1,Dial(SIP/INTERNO)

[outgoing]

exten => _53.,1,Dial(SIP/${EXTEN}@messagenet)
exten => _XXX.,1,Macro(dial-failover,SIP/${EXTEN}@messagenet,SIP/${EXTEN}@cheapnet)

[macro-dial-failover]

exten => s,1,Dial(${ARG1})
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-CONGESTION,1,Dial(${ARG2})

Appena installato Tunnelblick sul mac:

che bello che bello! Openvpn facile!

metto il file di configurazione dentro la cartella da lui suggeritami, permesso tutto come vuole lui e provo ad avviare la connessione…..

parte la rotellina arcobaleno e rimane lì spavaldamente bloccato senza segni di vita, tanto da averlo dovuto uccidere con kill -9

dopo un discreto impazzire, grazie anche al mo amico “AndydnA”, sono giunto alla difficile per quanto stupida soluzione:

da bravo linuxiano nel file di configurazione della mia VPN ho scritto:

log /var/log/openvpn/VPN_zazu.log

che c’è di strano? Voi direte…

beh, la cartella “openvpn” dentro /var/log” non esiste!!!!! Tunnelblick non può loggare dove gli abbiamo indicato e in barba al mondo, invece di segnalarlo si pianta!

soluzione:

mkdir /var/log/openvpn

d’ora in poi potrete fruire di tutte le VPN che vi pare e piace.

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

Effettuato l’aggiornamento a WP 2.9.2

il sistema di agigornamento automatico a funzionato in maniera eccellente, ho aggiornato pure il tema (sempre automaticamente)

cambiano alcune cose, dovrò editare di nuovo la grafica, non posso riciclare la precedente….

non temete, la mia faccia da Cazzo tornerà presto a troneggiare in cima al blog

Debricchiamo il WAP54G.

Sintomi:

luce rossa “Power” accesa;

collegando il cavo di rete la luce gialla “Link” si accende;

luce verde “Act” sempre spenta;

l’apparato non risponde nemmeno al ping.

Occorrente:

• linksys wap54g v3.1 brickato con chip: SST39VF160-70-4c-eke;
• un pezzo di filo telefonico leggermente spellato ai capi… anche un paio di puntali (se li avessi) sarebbero atti allo scopo  ;
• client tftp;
• nuovo firmware (originale Linksys o meno).

++++ PROCEDURA ++++

1. smontare il coso:

“stappiamo” i piedi di gomma dalla parte blu per poter rimuovere due viti nascoste;

ora strappiamo via la parte blu e abbiamo aperto il nostro Linksys.

2. Staccare la piastra madre dal suo supporto di plastica (la flash su cui operare si trova sotto):

3. Colleghiamo un capo del filo alla parte esterna del connettore TNC (per chi non sapesse cosè il TNC sto parlando del connettore delle antenne wifi, si tratta di un sicuro punto di terra)

4. poggiamo con molta precisione l’altro capo del laccetto sul piedino 16 della flash, se sbagliamo o ne tocchiamo un altro, possiamo buttare via il nostro Access point 

5. col ponticello effettuato attacchiamo l’alimentazione e dopo circa 2-3 secondi stacchiamo il filo dal piedino

a questo punto il Linksys si deve essere messo in ascolto per un nuovo firmware sul suo ip di default (192.168.1.245)
oltre ciò, se il resettone è andato a buon fine, risponderà anche al ping.

quindi assegniamo ip fisso della stessa classe alla nostra ethernet:

# ifconfig eth0 192.168.1.69 netmask 255.255.255.0 up

effettuiamo un ping, se l’Access Point ci risponde allora siamo a cavallo e procediamo al flashing.

6. Upload del nuovo firmware col seguente comando (io ho operato da OpenSUSE installando il pacchetto “tftp” e uploadando direttamente dd-wrt-micro):

# tftp -m binary 192.168.1.245 -c put dd-wrt.v24_micro_generic.bin

attendiamo che finisca….

7. il coso ricomincia a funzionare. 
NB
Il tftp pacchettizzato in altre distribuzioni potrebbe avere sintassi e metodo di funzionamento differente da quello presente in OpenSUSE
quello di Windows sicuramente HA sintassi differente.

Lavorando in un’azienda multisede, dopo aver sostituito tutti i vecchi centralini analogici con Asterisk, la prima richiesta fatta è:

si può far sì che le nostre telefonate infra-sede siano gratuite?

La risposta è ovviamente si (a patto che le sedi da collegare abbiano una connessione adsl, o comunque a banda larga ma questo è un altro discorso)

dopo un minimo di studio della problematica sono arrivato alla scelta di IAX come protocollo di interconnessione asterisk to asterisk.

Oltre ad essere il protocollo nativo di asterisk, iax ha anche altri vantaggi; per esempio:

• può incapsulare tutto il traffico in un unico canale;
• usa una sola porta di comunicazione;
• l’attraversamento delle NAT è nativo, e non da problemi;
• permette di selezionare il punto di arrivo nel dialplan di destinazione  sin dall’origine….

…e comunque tante altre piccole funzionalità che nell’insieme lo rendono imbattibile.

INSOMMA COME SI INTERCONNETTONO DUE CENTRALINI IN MANIERA SEMPLICE?

la soluzione è stata più semplice del previsto e l’idea di base è paragonabile a quella su cui si basa una VPN

ma veniamo al sodo:

abbiamo due centralini (Homer e Marge) di cui vado ad illustrare iax.conf:

Le righe da inserire in extensions.conf a questo punto sono abbastanza semplici e logiche;

occorre una riga nel contesto di uscita con un prefisso di nostro gradimento (99) per chiamare gli interni dell’altro e una riga per le chiamate entranti:

Le chiamate “fromiax” le redirigo in outgoing perché nel mio caso questo è anche il contesto in cui si trovano gli interni.

Ora si pone un piccolo problema:

come distinguere chi chiama dall’altra sede?

Se la reception nella sede “Marge” chiama un interno nella sede “Homer” quest’ultimo vedrà arrivare una chiamata da “Reception”, indistinto dalla reception locale;

questo effetto collaterale può generare molta confusione e per ovviare a ciò ho pensato ad una piccola macro, questa imposta il CallerID a seconda della sede di provenienza, extensions.conf quindi andrà così modificato:

buon asterisk a tutti.

informazioni d base tratte da: astrecipes.net

Come tutti gli informatici d’Italia, vengo spesso chiamato da amici e colleghi per qualunque genere di problema.

Esempio:

La mia autoradio non fa più uscire il CD, quando premo il tasto di espulsione si sentono brutti rumori e non viene fuori! Come faccio? Puoi darci un’occhiata?

Dato che si trattava di un’autoradio di serie, coi comandi al volante e fuori garanzia, abbiamo convenuto sul fatto di tentare una riparazione prima di buttarla;

mi sono ritrovato quindi tra le mani quest’autoradio da riparare…..

Dopo averla aperta, dopo aver tentato di muovere manualmente la meccanica e dopo qualche minuto di elucubrazioni mi è venuto il lampo di genio:

da bravo informatico ho sempre un alimentatore ATX per pc da poter usare all’occorrenza, gli ATX producono anche 12 vdc e le autoradio funzionano a 12 vdc!

Dopo un po’ di studio sul connettore iso dell’autoradio e qualche prova col tester ho trovato la giusta combinazione delle cose.

IL CONNETTORE ISO DELL’AUTORADIO:

c’è poco da sapere sul connettore ISO per collegarlo all’alimentatore ATX:

• NERO è la massa o negativo, va collegato ad un qualunque cavo nero dell’alimentatore ATX
• ROSSO è il cavo di accensione/spegnimento autoradio sotto blocco chiave: 12 V, va collegato ad un cavo giallo dell’ATX
• GIALLO va sempre collegato al POSITIVO 12 V, anche questo va collegato ad un cavo giallo dell’ATX

io ho effettuato un collegamento provvisorio senza tagliare i cavi dell’alimentatore come si può vedere nelle seguenti pessime foto:

inoltre, per far sì che l’alimentatore si accenda è necessario ponticellare il cavo verde con un qualunque cavo nero, io per effettuare tale operazione ho usato un laccetto spellato alle estremità; di quelli con l’anima di ferro che legano i cavi degli apparecchi elettronici, oppure quei laccetti per i sacchetti del congelatore…. insomma, un qualunque pezzo di filo conduttore va bene ovviamente per accendere e spegnere “l’accrocco” useremo l’interruttore dietro l’alimentatore.

Ed ecco quindi il risultato finale, la nostra autoradio correttamente alimentata e funzionante con un alimentatore ATX per pc: