Quello che vi mostrerò è un pezzo di codice per extensions_custom.conf che non fa altro che rispondere a una chiamata e richiedere un pin.

[pin_auth]
exten => s,1,Answer
exten => s,n,Set(VALIDPIN=1234)
exten => s,n,Read(PIN,vm-password,,,,)
exten => s,n,Gotoif($[${PIN}=${VALIDPIN}]?valid)
exten => s,n,NoOp(PIN:NOK)
exten => s,n,Wait(1)
exten => s,n,Hangup
exten => s,n(valid),NoOp(PIN:OK)
exten => s,n,Wait(1)
exten => s,n,Hangup
exten => h,1,Hangup

Nel Dettaglio:

    • Risponde
    • Si mette in memoria il PIN (1234)
    • Parte una voce che dice “Password”
    • Aspetta il PIN digitato
    • Controlla se il PIN digitato è uguale a quello in memoria e di conseguenza risponde OK o NOK
    • Chiude la chiamata

Su asterisk poi si può agganciare questa “App” a un interno chiamabile, ovviamente il codice lo si può modificare a piacimento per effettuare altri tipi di servizi, io l’ho applicato per fare una “Strong Authentication”:

    • l’utente si logga su una pagina web, se l’utente e la password sono riconosciuti, viene chiamato il telefono dell’utente e richiesto il PIN (diverso per ogni utente), se il PIN è corretto vieni autenticato se no ricevi un bel “Access Denied”.

Per far si che il servizio web faccia scaturire la chiamata uso un file “numero.call generato dalla pagina in php con owner e gruppo asterisk e che viene messo dentro /var/spool/asterisk/outgoing

Il contenuto del file è questo:

Channel: DAHDI/0/123456789
Context: from-internal
Extension: 1000
Priority: 1

Cosa avviene:

    • asterisk vede il file e occupa il canale DAHDI 0 per chiamare il numero 123456789 e appena risponde ci cortocircuita l’interno 1000 che non è altro che l’“App” per la richiesta del PIN.

See you! Bye! :-)

Linux: Montare un disco di un Raid1 Software

L’altro giorno in azienda ci è scoppiato il processore del nostro firewall secondario per cui da un “PC” un po’ carrozzato siamo passati a un serverino decente con almeno il raid hw, ma avevo bisogno di alcune configurazioni che si trovavano sul vecchio disco.

Il problema è sorto quando ho collegato il disco, un normale SATA, a un altro pc e facendolo bootare con una Debian Live Rescue, ovviamente il mount non me lo faceva fare perchè il disco faceva parte di un RAID1, questo l’errore:

root@debian:~# mount /dev/sda1 /mnt/
mount: unknown filesystem type 'linux_raid_member'

ovviamente ci ho ragionato un po’ e ho provato a creare un array md0 con un solo disco per provare a montarlo:

root@debian:~# mdadm -A -R /dev/sda1 /dev/md0

Vediamo nello specifico cosa significano le opzioni usate:
-A : Assemble a pre-existing array, per cui crea l’array con un disco già configurato, era già un raid1
-R : Insist that mdadm run the array [...], per cui forza l’avvio dell’array senza fare ulteriori domande, di solito chiede delle conferme se trova componenti di altri array attivi.

Ora dato che non vi sono problemi di creazione, possiamo montare l’array:

root@debian:~# mount /dev/md0 /mnt

Se non vi ritrovate errori in fase di mount potete leggere tranquillamente il contenuto del disco.

Alla prossima!

Debian: dist-upgrade lenny to squeeze

Dopo aver visto il dist-upgrade da sarge a etch e quello da etch a lenny non poteva mancare il salto di release alla Squeeze

Ecco come fare, in pochi, semplici passi:

Per prima cosa sulla Lenny aggiornare all’ultimo patchlevel:

apt-get update
apt-get dist-upgrade
reboot

NB: Se l’apt-get update vi restituisce l’errore NO_PUBKEY, qua la soluzione.

Ora commentiamo i repository di Lenny ed aggiungiamo quelli di Squeeze:

deb http://debian.fastweb.it/debian/ squeeze main
deb-src http://debian.fastweb.it/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

Poi:

apt-get update
apt-get dist-upgrade

Ed infine:

reboot

E così dopo 2 anni di duro lavoro, da parte del team di Debian, abbiamo una release tutta nuova! :-)

Qualche tempo fa mi sono imbattuto in un problema che con Debian ho sempre risolto in una manciata di secondi con Red Hat ci ho dovuto pensare su un po’…

In Debian mi capita spesso di fare due macchine identiche per un cluster in HA, e dopo che ne ho configurata una preparo l’altra e gli passo la lista dei pacchetti e li installo, come?

Ecco qua, dalla prima Debian estrapolo la lista dei pacchetti con “dpkg” e la metto su un file:

root@debian1:~# dpkg –get-selections > debian1-pkgs

poi bisogna copiare la lista sulla macchina secondaria, solitamente uso scp:

root@debian1:~# scp debian1-pkgs root@debian2:/root/.

ora che abbiamo la lista sulla secondaria, la carichiamo sempre usando “dpkg”:

root@debian2:~# dpkg –set-selections < debian1-pkgs

adesso non ci resta che fargli installare i pacchetti usando “apt”:

root@debian2:~# apt-get dselect-upgrade

Et voilà! Le jeux son fait!

E con Reh Hat?!?

per prima cosa recuperiamo tutti i pacchetti installati su un file, usando “yum” (il gestore dei pacchetto di RedHat et simili), e copiamolo sull’altro nodo:

[root@redhat1 ~]# yum list installed > redhat1-pkg
[root@redhat1 ~]# scp redhat1-pkg root@redhat2:/root/.

ora dovremmo dire a “yum” di installare la lista, ma sfortunatamente ha delle diciture in più che non ci servono, questo che segue è l’esempio di come si presenta il file:

Loaded plugins: rhnplugin, security
Installed Packages
Deployment_Guide-en-US.noarch             5.2-11                       installed
GConf2.i386                               2.14.0-9.el5                 installed
GConf2.x86_64                             2.14.0-9.el5                 installed
GConf2-devel.x86_64                       2.14.0-9.el5                 installed
MAKEDEV.x86_64                            3.23-1.2                     installed
NetworkManager.i386                       1:0.7.0-10.el5_5.2           installed
NetworkManager.x86_64                     1:0.7.0-10.el5_5.2           installed
NetworkManager-glib.i386                  1:0.7.0-10.el5_5.2           installed
NetworkManager-glib.x86_64                1:0.7.0-10.el5_5.2           installed
NetworkManager-gnome.x86_64               1:0.7.0-10.el5_5.2           installed

puliamo tutto con il comando “cut” e  prendiamo la prima parte di ogni riga, per cui il solo nome del pacchetto, e lo diamo in pasto a “yum” direttamente

[root@phbe2pr ~]# yum -y install $(cut -f 1 -d” ” < redhat1-pkg)

Ora inizierà il download e l’installazione di tutto.

Spero che vi sia stato utile :-)

Debian: inviare sms via bluetooth

Installiamo tutto ciò che ci serve:
apt-get install bluez-utils bluetooth libbluetooth2-dev build-essential

Modificare in /etc/bluetooth/hcid.conf la security da user ad auto.

Inserire la chiavetta bluetooth e rivviare la macchina

Associare il proprio telefono col server:
dal telefono dal menù bluetooth, nuova associazione, selezionare il server zabbix, password di default 1234

Scaricare il tool per inviare gli sms:
http://sourceforge.net/projects/bfsms

Scompattare, patchare, compilare e installare (nel nostro caso la v 0.11):
tar xvzf bfsms_v.0.11.tar.gz
cd bfsms_v.0.11
wget http://archives.alviano.com/patches/bfsms.c.patch (Questa Patch serve per avere il supporto agli sms più lunghi di 160 caratteri)
patch bfsms.c bfsms.c.patch
make
make install

Invio sms:
bfsms -s mac:address numero 'messaggio'

NB: Il mac address del bluetooth sui Nokia si trova digitando: *#2820#

Esempio:
bfsms -s 00:11:22:33:44:55 +390123456789 'messaggio'

Se si ha la necessità di usare questa funzionalità su una Virtual Machine di VmWare
bisogna che il virtualizzatore abbia caricato solo il modulo hci_usb per cui bisogna mettere in /etc/modprobe.d/blacklist i moduli rfcomm e l2cap

sulla VM invece deve avere tutti i moduli:
root@lenny:~# lsmod | grep blu
bluetooth 44996 7 rfcomm,l2cap,hci_usb

poi si può procedere con i passaggi descritti sopra.

Attenzione non tutti i telefoni funzionano.
Sul Nokia N70 non funziona.
Sul Nokia 2323 funziona.

A presto.

Un po’ di me


Omar on Twitter Omar on Facebook Omar on LinkedIn

Eventi


    ..Coming Soon..

Qualche foto da Flickr

Calendar

May 2012
M T W T F S S
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031