Vai ai contenuti

Vita Da Zazu

Pensieri, idee strampalate, accrocchi e pazzie

Qlogic controllerMi è 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 :roll:, 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:

sip.conf   pre-aggiornamento sip.conf post-aggiornamento
[general]
bindport=5060
context=incoming
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
disallow=all
allow=ulaw
qualify=yes
language=it
dtmfmode=info
localnet=172.16.10.0/24
rtptimeout=60
rtpholdtimeout=300

;messagenet
register => 5xxxxxx:YYYYYYYY@sip.messagenet.it:5061
/messagenet

;chepnet
register => 6969xxxxxx:YYYYYYYY@sip.cheapnet.it
/cheapnet

[cheapnet]
type=peer
defaultuser=6969xxxxxx
fromuser=6969xxxxxx
secret=YYYYYYYY
host=sip.cheapnet.it
port=5060
insecure=port,invite
context=incoming
nat=yes
srvlookup=yes
canreinvite=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
allow=g726
allow=ilbc

[messagenet]
type=peer
defaultuser=5xxxxxx
fromuser=5xxxxxx
secret=YYYYYYYY
host=sip.messagenet.it
port=5061
insecure=port,invite
context=incoming
nat=yes
srvlookup=yes
canreinvite=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
allow=g726
allow=ilbc

[general]
bindport=5060
context=incoming
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
disallow=all
allow=ulaw
language=it
dtmfmode=info
localnet=172.16.10.0/24
rtptimeout=60
rtpholdtimeout=300

;messagenet
register => 5xxxxxx:YYYYYYYY@sip.messagenet.it:5061
/messagenet

;chepnet
register => 6969xxxxxx:YYYYYYYY@sip.cheapnet.it
/cheapnet

[cheapnet]
type=peer
defaultuser=6969xxxxxx@sip.cheapnet.it
fromuser=6969xxxxxx
secret=YYYYYYYY
host=sip.cheapnet.it
fromdomain=sip.cheapnet.it
outboundproxy=sip.cheapnet.it
realm=sip.cheapnet.it
port=5060
regseconds=60
insecure=port,invite
context=incoming
qualify=yes
nat=yes
srvlookup=yes
canreinvite=no
directmedia=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
allow=g726
allow=ilbc

[messagenet]
type=peer
defaultuser=5xxxxxx@sip.messagenet.it
fromuser=5xxxxxx
secret=YYYYYYYY
host=sip.messagenet.it
fromdomain=sip.messagenet.it
outboundproxy=sip.messagenet.it
realm=sip.messagenet.it
port=5061
regseconds=60
insecure=port,invite
context=incoming
qualify=yes
nat=yes
srvlookup=yes
canreinvite=no
directmedia=no
disallow=all
allow=gsm
allow=ulaw
allow=alaw
allow=g726
allow=ilbc

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})

TunnelAppena 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 :D.

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 aggiornamento 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:

HOMER MARGE
iax.conf:

[general]

bindport=4569
bindaddr=0.0.0.0
language=it
bandwidth=medium
disallow=all
allow=gsm
allow=alaw
allow=ulaw
jitterbuffer=no
forcejitterbuffer=no
autokill=yes
requirecalltoken=no
;maxcallnumbers=512
mailboxdetail=yes

[marge]
type=friend
username=homer
secret=<password>
auth=plaintext
host=marge.mydomain.it
context=fromiax
peercontext=fromiax
qualify=yes
trunk=yes

iax.conf:

[general]

bindport=4569
bindaddr=0.0.0.0
language=it
bandwidth=medium
disallow=all
allow=gsm
allow=alaw
allow=ulaw
jitterbuffer=no
forcejitterbuffer=no
autokill=yes
requirecalltoken=no
;maxcallnumbers=512
mailboxdetail=yes

[homer]
type=friend
username=marge
secret=<password>
auth=plaintext
host=homer.mydomain.it
context=fromiax
peercontext=fromiax
qualify=yes
trunk=yes

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:

HOMER MARGE
extensions.conf

[outgoing]

[…]

exten => _99XXX,1,Dial(IAX2/marge/${EXTEN:2})

[…]

[fromiax]
exten => _X.,1,Goto(outgoing,${EXTEN},1)

extensions.conf

[outgoing]

[…]

exten => _99XXX,1,Dial(IAX2/homer/${EXTEN:2})

[…]

[fromiax]
exten => _X.,1,Goto(outgoing,${EXTEN},1)

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:

HOMER MARGE
extensions.conf

[outgoing]

[…]

exten => _99XXX,1,Macro(set-iax-callerid,IAX2/marge/${EXTEN:2})

[…]

[fromiax]
exten => _X.,1,Goto(outgoing,${EXTEN},1)

[macro-set-iax-callerid]

;aggiunge un TAG di riconoscimento al CID dei chiamanti
; ARG1 è l’estensione da chiamare

exten => s,1,Set(CALLERID(name)=${CALLERID(name)} – Homer)
exten => s,2,Dial(${ARG1})

extensions.conf

[outgoing]

[…]

exten => _99XXX,1,Macro(set-iax-callerid,IAX2/homer/${EXTEN:2})

[…]

[fromiax]
exten => _X.,1,Goto(outgoing,${EXTEN},1)

[macro-set-iax-callerid]

;aggiunge un TAG di riconoscimento al CID dei chiamanti
; ARG1 è l’estensione da chiamare

exten => s,1,Set(CALLERID(name)=${CALLERID(name)} – Marge)
exten => s,2,Dial(${ARG1})

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…..

Come faccio a verificare il funzionamento? Dovrei accenderla….  non posso lavorare in macchina e non mi va di smontare la mia…

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!

è fatta! La collegherò all’alimentatore ATX e l’accenderò!

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:

GXP2000-pic

Ok, se sei arrivato qui hai tentato di aggiornare il firmware di un GXP-2000 e qualcosa è andato storto. :(

Non è detto che un aggiornamento fallito comporti l’aver “brickato” definitivamente il telefono…

come capire se il nostro telefono è recuperabile?

i sintomi di un brick reversibile sono:

  • led tutti accesi e luce MWI lampeggiante;
  • una scritta sullo schermo ci informa che sta tentando il recovery del firmware via TFTP.

In queste condizioni il nostro telefono può essere resuscitato;

armati di buona volontà iniziamo ad allestire la sala operatoria:

personalmente uso OpenSUSE come sistema operativo, quindi alcuni dei comandi usati saranno prettamente validi solo su questa distribuzione.

Ci occorrerà un server TFTP:

# zypper in atftp

ora dobbiamo configurare ed attivare il server TFTP;

per prima cosa occorre creare la cartella “root” del nostro server (per comodità io l’ho creata sul mio desktop):

$ mkdir /home/zazu/Scrivania/tftp

ora scarichiamo dal sito della Granstream l’ultimo firmware disponibile per il GXP2000 e scompattiamo il tutto dentro la nostra cartella “tftp”, i files strettamente necessari sono: “boot55.bin” e “gxp2000.bin” ma per sicurezza meglio metterli tutti 😉

adesso dobbiamo avviare il server, lo facciamo molto semplicemente con questo comando:

# atftpd --daemon /home/zazu/Scrivania/tftp/

per verificarne il funzionamento, con “netstat -natup | grep 69″ possiamo verificare l’esistenza del server tftp in ascolto.

PASSO 2

Configuriamo la rete e abbassiamo SuSEfirewall.

Consiglio di mettere uno switch tra noi e il telefono per evitare di perdere le configurazioni della nostra scheda di rete;

i parametri da impostare sono i seguenti:

# rcSuSEfirewall2 stop
# ifconfig eth0 168.75.215.188 netmask 0.0.0.0 up
# route add default gw 168.75.215.188

Adesso accendiamo il nostro Grandstream (collegato allo switch) e se tutto è corretto questo inizierà il recovery  TFTP  e sarà in grado di recuperare il firmware dal nostro computer

quando avrà finito sarà diventato nuovamente funzionante :)

Mi capita spesso di usare dischi USB per spostare o condividere ogni genere di file, usando quotidianamente sistemi Linux uso ovviamente dischi rigidi formattati in ext3 e fin qui nessun problema, finché oggi non mi è servito usarne su un Mac…..

Documentandomi per il web sono arrivato ad una buona soluzione opensource e gratuita:

usare MacFUSE con un apposito modulo ext2: fuse-ext2

per prima cosa scarichiamo ed installiamo MacFUSE

poi scarichiamo ed installiamo fuse-ext2 (ovviamente dovremo scaricare il file dmg per mac) :).

Finito di installare il tutto ancora non siamo pronti per poter usare dischi ext3, adesso se colleghiamo un disco con tale filesystem questo sarà montato in sola lettura, quindi il supporto è ancora parziale.

Come ovviamo a ciò?

molto semplicemente basta aggiungere un parametro aggiuntivo in un file di configurazione

apriamo quindi un terminale e scriviamo:

$  sudo vi /system/library/filesystems/fuse-ext2.fs/fuse-ext2.util

ci spostiamo all linea 207 del file e nella variabile “OPTIONS” aggiungiamo il parametro “force” oltre quelli già presenti.

fatto ciò salviamo, chiudiamo e finalmente il nostro disco USB ext3 sarà fruibile anche sul Mac!

Buon lavoro a tutti :)

WordPress SEO fine-tune by Meta SEO Pack from Poradnik Webmastera