techno


Dopo vari hackeraggi di fonera e linksys wrt54 non ho resistito alla tentazione e mi sono preso un Dlink DNS-323. E’ una vera figata poichè dentro c’è la solita debian embedded, che a saper metterci le mani da tanta soddisfazione.

La prima cosa da fare è quindi accedere via telent/ssh e dare un’occhiatina dentro! A tale scopo mi istallo un pò di sofware aggiuntivo (telnet, ssh, ntp, etc) per farlo eseguire al boot tramite il fun_plug.

Ottimo, appena entrato mi guardo i vari mount e scopro che i due dischi che ho configurato in RAID1 utilizzano ext2….uhm, beh no, meglio ext3, no? Casomai va via la corrente, sto un pò più tranquillo e il DNS-323 risale più veloce.

Bene, cominciamo con la teoria: per passare da ext2 a ext3 dobbiamo lavorare su partizioni “smontate”, altrimenti sono guai, quindi dobbiamo fare un bootstrap+telnet senza che i dischi nelle baie vengano montati automaticamente. Ci serve del sofware aggiuntivo, ma andiamo per gradi.

Ah, una premessa, la mia configurazione è con due dischi esterni in RAID1, per configurazioni diverse…..fate voi!

  1. Aggiorniamo il firmware alla versione 1.06 del 12/03/2008;
  2. istalliamo il Fonz fun_plug ver. 0.5 per avere telnet, ssh, ntp, mediatomb, etc;
  3. andiamo a cambiare EXT2 in EXT3 in tutti file che si chiamano raidtab2web che si trovano nelle partizioni /dev/sd[ab]4. Per far questo dobbiamo modificare il file raidtab2web che si trova sotto /mnt/HD_a4/.systemfile/raidtab2web (sda4) e /mnt/HD_b4/.systemfile/raidtab2web (sdb4). La modifica consiste nel cambiare la riga filesystem EXT2 con la riga filesystem EXT3;
  4. fare la modifica di cui sopra nel file /etc/raidtab2web;
  5. rendere le modifiche definitive nella flash ram con i comandi: mount -t minix /dev/mtdblock0 /sys/mtd1;cp /etc/raidtab2web /sys/mtd1/.;sync;umount /sys/mtd1 e mount -t minix /dev/mtdblock1/sys/mtd2;cp /etc/raidtab2web /sys/mtd2/.;sync;umount /sys/mtd2;
  6. istalliamo fsck per poter fare il bootstrap senza montare i dischi esterni;
  7. eseguiamo il boot come sopra, quindi, dopo esser entrati in telnet, lanciamo il comando /ffp/fsck/no-bash-reload.sh;
  8. rientriamo in telnet: stavolta non ci sono dischi esterni montati (verificate con il comando mount);
  9. effettuiamo un check sulle partizioni, compresa quella RAID1, se ne avete una. Vi consiglio di rispondere sempre “yes”, in modo da correggere gli eventuali errori, compresa la creazione del “lost+found”. Questi i comandi
    • e2fsck /dev/sda4
    • e2fsck /dev/sdb4
    • mdadm -A /dev/md0 /dev/sd[ab]2
    • e2fsck /dev/md0
  10. passiamo a ext3 sulla partizione RAID1 con il comando tune2fs -j /dev/md0;
  11. fermiamo il raid con il comando mdadm –stop /dev/md0 e finalmente
  12. reboot!

Al riavvio, entrando in telnet il mount dovrebbe dare:

/ # mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw)
proc on /proc type proc (rw,nodiratime)
/dev/loop0 on /sys/crfs type squashfs (ro)
/dev/md0 on /mnt/HD_a2 type ext3 (rw)
/dev/sda4 on /mnt/HD_a4 type ext2 (rw)
/dev/sdb4 on /mnt/HD_b4 type ext2 (rw)
none on /proc/bus/usb type usbfs (rw)
devpts on /dev/pts type devpts (rw)

che dire? Sto’ DNS-323 mi piace proprio!

P.S: chiaramente non è tutta farina del mio sacco, molte info le ho prese da questo articolo e dai README del Fonz e dell’fsck.

i comandi apt necessitano di una connessione attiva verso le fonti dei packages dei nostri sistemi debian/ubuntu, ma,  a volte, siamo costretti ad utilizzare un proxy http.

Le possibili soluzioni sono due:

1) utilizziamo la variabile d’ambiente http_proxy prima di lanciare i suddetti comandi, es. con il comando  ‘export http_proxy=http://proxy.foo.bar:port’;

2) rendiamo la configurazione durevole. A tale scopo si deve creare il file /etc/apt/apt.conf/80proxy con le seguenti righe:

Acquire {
Retries “0”;
HTTP {
Proxy “http://ip_address:port“;
};
};

dove ip_address e port sono rispettivamente l’IP del proxy e la porta (di solito la 8080).

enjoy!

Di seguito i pochi, semplici passi per “aggregare” le schede ethernet secondo il meccanismo di bonding (teaming per windows), ovvero gestire una o più schede ethernet fisiche tramite un unico device logico, come ad esempio /dev/bond0.

Per prima cosa ….. un server pinguino, nel mio caso si tratta di Ubuntu 8.04 🙂

Quello che serve è istallare un package e un pò di righe di configurazione, vediamo come:

1) istalliamo l’utility ifenslave, necessaria per il bonding e l’unbonding (permettetemi il newlogismo) delle schede ethernet:

apt-get install ifenslave-2.6

2) creare il file /etc/modprobe.d/bond contenente, per ogni interfaccia bond da creare, le riga:

alias bondx bonding

options bondx mode=0 miimon=100

dove x=0,1,2,3… a seconda dell’interfaccia bond. Per il significato dei valori mode, miimon e degli eventuali altri consultate questo link.

3) Configuriamo i parametri di rete modificando il file /etc/netwok/interfaces.

Attenzione: Per prima cosa DOBBIAMO ELIMINARE qualsiasi configurazione delle schede ethernet poichè queste fanno parte dei nuovi device bond.

configuriamo un device bond (es. bond0) che “ragruppa” due schede ethernet (es. eth0 e eth1), inserendo le seguenti righe ( i valori sono casuali, metteteci i vostri):

auto bond0

iface bond0 inet static

address 192.168.1.2

netmask 255.255.255.0

network 192.168.1.0

broadcast 192.168.1.255

gateway 10.184.250.1

post-up ifenslave bond0 eth0 eth1

pre-down ifenslave -d bond0 eth0 eth1

ottimo! Diamo un bel /etc/init.d/networking restart.

quante volte è capitato di voler copiare/clonare una macchina virtuale vmware per implementare ad esempio un cluster a più nodi, o più semplicemente per non dover fare daccapo l’istallazione?

A me è capitato con Ubuntu 8.04 e così mi sono messo a cercare e provare una procedura semplice da eseguire.

A meno che non si possegga vmware server esx, la procedura consiste in alcuni (semplici) passi, vediamo come:

1) istalliamo una virtual machine che poi “cloneremo”, aggiungendo tutti i package di base e la configurazione di rete;

2) effettuiamo la procedura di clonazione;

3) agiungiamo la virtual machine clonata al server vmware;

4) boostrappiamo il clone ottenuto effettuando le necessarie modifiche alla sua configurazione (hostname e networking);

Dato per scontato il punto 1), eseguiamo la procedura del punto 2) secondo quanto scritto in questo link e aggiungiamo la nuova virtual machine al server vmware (punto 3).

Passiamo ora alla riconfigurazione della nuova virtual machine. Poichè questa ha le impostazioni clonate rispetto a quella di partenza, dobbiamo modificarle per non avere conflitti nell’esecuzione contemporanea delle due virtual machine.

Come suddetto, si tratta di riconfigurare almeno l’hostname della macchina e la configurazione di rete, vediamo come:

a) modifichiamo il file /etc/hostname con il nome della nuova virtual machine;

b) modifichiamo il file /etc/hosts con il nuovo IP e hostname;

c) modifichiamo il file /etc/network/interfaces con gli indirizzi IP e le configurazioni di network delle schede di rete;

d) apriamo il file /etc/udev/rules.d/70-persistent-net.rules che contiene i parametri delle schede ethernet, il mio ad esempio è

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:0c:29:33:95:cf”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″

e modifichiamo il MAC address con quello che ci assegna il vmware server. La modifica va effettuata per tutte le schede di rete che vogliamo utilizzare.

Reboot!

Stavolta l’idea fissa è quella di realizzare un servizio di hotspot wifi soltanto con apparati wrt (dispongo di due fonera 2200, un linksys wrt54gl ed un linksys wap54g), senza dover aggiungere server per la parte di captive portal.

L’hotspot mi deve offrire due tipi di connettività (un pò sul modello fonera): il primo di tipo internet per utenti guest, e il secondo invece per l’accesso alla lan privata per gli utenti “interni”.

I tipi di accessi si devono differenziare per la modalità di configurazione e di autenticazione, ovvero i guest non devono perder tempo a configurarsi i parametri della connettività wireless ma al massimo fornire una login e una password su una pagina web di benvenuto mentre gli interni devono utilizzare un meccanismo di autenticazione “forte” e una connessione wireless altrettanto fortemente cifrata.

Per i guest va benissimo il modello hotspot pubblico, ovvero wireless in chiaro più autenticazione UAM (Universal Access Method) tramite pagina web: in questo modo l’utente si connette ad una rete wireless di tipo open e, non appena accede ad internet, viene rediretto su una pagina di benvenuto che lo invita a fornire le proprie credenziali (username e password). Solo in seguito all’autenticazione l’utente può navigare liberamente, uscendo dal cosiddetto “walled garden”.

Per gli utenti interni si usa invece IEEE 802.1x, in modo da fornire ad ogni uente una coppia di credenziali (login e password) piuttosto che un secret condiviso, che risulterebbe scomodo gestire tra più utenti (senza parlare poi delle implicazioni di sicurezza/riservatezza/privacy/etc). Per l’utilizzo dell’802.1x c’e’ bisogno di un server radius, vi consiglio freeRADIUS, che oltre ad essere molto potente ed estensibile ha un’ottima comunità di utenti e un wiki molto utile.

Come captive portal posso scegliere tra il rodatissimo chillispot o il nuovo CoovaChilli, che è un fork del primo con qualche cosetta in più.

Bene, consideriamo ora come e dove “piazzare” il nostro chilli. Normalmente il captive portal viene piazzato su una macchina dual-homed (doppia interfaccia di rete) che funge da gateway e firewall per tutti i wrt, realizzando quel “walled garden” che ospita tutti gli utenti collegati al wireless ma che devono ancora autenticarsi. Ora, non disponendo di un server con doppia scheda di rete l’alternativa è di mettere il captive portal direttamente su ogni wrt…..non mi piace. Troppo lavoro di istallazione, configurazione, gestione e poi ad ogni minimo cambiamento devo andare a rimettere le mani su ogni wrt, no.

Pensandoci bene il linksys wrt54gl è un apparato “dual homed” poichè ha due schede di rete, più propriamente una scheda di rete, denominata wan e uno switch di rete a quattro porte, che figata! Ma allora posso piazzare il captive portal sul wrt54gl è collegare gli altri wrt sulle porte dello switch! Eureka!

Uhm…..ripensandoci non è proprio corretto perchè in questo modo mi ritroverei che anche le connessioni di tipo 802.1x sarebbero “assoggettate” al captive portal….no, devo riuscire a separare la lan dello switch in due sotto-lan, in modo da mettere nella prima il wireless di tipo “open” che va sul captive portal e nella seconda il wireless di tipo 802.1x.

Bene, teoricamente mi sembra tutto corretto, ma come posso separare la lan in due sotto-lan, in modo che ogni wrt possa far transitare in ognuna un tipo di connessione wireless e basta?

Pensa che ti ripensa m’e’ venuto in mente il meccanismo delle VLAN normalmente utilizzato sugli switch, che, grazie ad un piccolo “tag” inserito nei frame ethernet riescono a smembrare una lan in sotto-lan facendo passare tutti i pacchetti così etichettati nello stesso “pertuso” (una porta ethernet detta trunk che connette gli switch tra di loro), per poi ridistribuire i pacchetti nelle giuste reti una volta giunti a destinazione.

Bene, ma sarà possibile? Beh, cercherò di provarci nei prossimi giorni, di sicuro i wrt vanno “sbrandizzati” e rigenerati con delle distro che mi permettano di configurare più connessioni wifi contemporaneamente e che supportino lo standard IEEE 802.1q, ovvero il trunking delle reti ethernet.

Inutile dirlo, sui wrt ci metterò openwrt, così mi ritrovo tutti i pacchetti pronti, compreso il chillispot.

Alla prossima puntata, speriamo di farcela!

nel precedente articolo avevo consigliato di istallare Firefox versione 32 bit per utilizzare il plugin flash, ma io sono un purista, se la distro è a 64 bit…deve andare tutta a 64!

Allora, cerca che ti cerca noto che il problema si risolve con il mitico nspluginwrapper e con i soliti smanazzamenti manuali, vediamo come:

0. Premetto che io utilizzo una mandriva 2008 x86_64 e che quindi ho fatto riferimento a questo post di mandrakeitalia.org, apportando le dovute modifiche;

1. istalliamo firefox x86_64, nspluginwrapper e il plugin flash di Adobe;

2. Copiamo i file libflashplayer.* nella directory usr/lib64/mozilla/plugins/;

2.5. non proprio necssario, ma dalla directory usr/lib64/mozilla/plugins/ ho rimosso il file libflashplayer.so e ho creato un link simbolico da questo al libflashplayer.so.0, in modo che:

lrwxrwxrwx 1 root root 19 2008-04-10 14:24 libflashplayer.so -> libflashplayer.so.0*
3. lanciamo il comando:
/usr/lib/nspluginwrapper/x86_64/linux/npconfig -i /usr/lib64/mozilla/plugins/libflashplayer.so.

fatto, enjoy youtube!

P.S. per gli amanti di konqueror (io per primo), fatta la procedura di cui sopra basta verificare che /usr/lib64/mozilla/plugins/ faccia parte delle cartelle di ricerca dei plugin. Nel caso in cui non vogliate far fare sempre la ricerca all’avvio, fatela almeno una volta ad ogni cambio di configurazione!

come promesso ho “debrickato” la mia fonera utilizzando la tecnica del cavo seriale.

La suddetta tecnica è da utilizzarsi quando il nostro amato wrt non è più raggiungibile da rete TCP/IP a seguito di chissà quali smanettamenti pindarici: nel mio caso avevo imputtanato le immagini di boot e successivamente, da dentro il RedBoot, impostato l’IP a 0.0.0.0…..una vera catastrofe!

Ok, fortunatamente il “brickaggio” e il conseguente “debrickaggio” è un’attività che va alla grande tra gli smanettoni, tant’è che su internet si possono trovare tonnellate di pagine web sull’argomento 🙂 ma il fattor comune di tutti i metodi di recupero sta nel fatto che il wrt “brickato” ci lascia sempre una possibilità quasi fosse un finto morto…..la porta seriale!

Già, questi apparatini, se li guardate bene da dentro, hanno spesso quanche pin buttato da una parte apparentemente inutilizzato….ragazzi, tre o quattro di quelli fanno una porta seriale ovvero un GND, TX, RX e, a volte, un Vcc.

Andiamo con ordine: la porta seriale in questione ci mette in comunicazione con la consolle del wrt dove possiamo effettuare le procedure di ripristino ma attenzione, spesso quei famigerati pin non si possono collegare direttamente alla porta seriale di un PC………..motivo? il solito: le seriali dei wrt sono in TTL mentre quelle dei PC sono le classiche RS232. Bene, la soluzione consiste nell’utilizzare un convertitore TTL/RS232 e il gioco è fatto. Di tali convertitori il mondo ne è pieno, tant’è che su ebay ve li tirano dietro (okkio che costa più la spedizione che il componente….) però al solito perchè non essere dei bravi ambientalisti, ovvero votati al riuso di tutta quella robaccia che giace inutilizzata da qualche parte a casa nostra? Cosi ho fatto, in sostanza ho utilizzato il cavetto seriale del mio vecchio cellulare Siemens Me45 che, guarda caso, contiene proprio un convertitore TTL/RS232.

Torniamo al Fonera. Il mio modello (FON2200) contiene all’interno, vicino all’alimentazione, un connettore maschio a quattro pin che fanno appunto la porta seriale TTL più una alimentazione da 3,3 volts.

Ottimo, googleggiando trovo la piedinatura corretta e, non si sa mai, utilizzo un tester per verificarla ovvero, partendo dall’alto abbiamo:

1 – GND (la massa)

2 – TX (trasmissione)

3 – RX (ricezione)

4 – Vcc (3,3 volts).

perfetto, taglio il cavo seriale dell’Me45 dalla parte del connettore cellulare e connetto i fili nero, verde, giallo e rosso rispettivamente all’1, 2, 3, 4 del Fonera (in realtà ho fatto una cosa più fina, ovvero ho preso un cavetto piatto a 4 fili con un connettorino femmina ad una estremità e ho collegato i fili dell’Me45 all’altra). A questo punto siamo pronti per andare in consolle! bene, sul mio fidato linux mi istallo il minicom e, con la classica configurazione i 9600 N81 entro nel RedBoot……fiu’…..ha funzionato……

ok, il resto è noia, riconfiguro l’ip ad un valore decente e riboostrappo…..ho circa 10 secondi per andare in telnet sulla porta 9000, dove il mio amato Fonera mi sta aspettando per essere riflashato 🙂 stavolta con openwrt.

Tutto è bene quel che finisce bene, adesso che ho il mio bel cavetto seriale “home made” mi sento dentro una botte di ferro :))))

Pagina successiva »