osx impostazioni di rete manuali

ok… radunando i vari comandi che di tanto in tanto tornano comodi:

settaggio schede di rete da console:

networksetup -setmanual “service” “ip” “mask” “gw”

networksetup -setdnsservers “service” “dns1″ “dns2″

per “service” si intende l’interfaccia su cui si deve lavorare. Per visualizzare le interfacce:

networksetup -listallnetworkservices

per il resto…. san google

Post collegati:

  • Nessun post correlato
Pubblicato in Uncategorized | Lascia un commento

E il doppio arduino…

Stavolta ho deciso di provare come viaggiano due arduino tra di loro.

Nella documentazione di base scopro che gli arduino supportano la comunicazione i2c. Tale protocollo fatto solo di 3 fili (dati, clock e gnd), consente di avere a disposizione un bus su cui collegare piu’ apparecchiature in grado di comunicare tra loro in modo semplice e diretto.

La libreria che consente questa meraviglia si chiama Wire.

Il sistema e’ abbastanza semplice:

Chi deve trasmettere, inizializza la libreria (Wire.begin()), apre il canale di comunicazione indicando il destinatario (Wire.beginTrasmission(x)), invia quello che deve inviare (Wire.write(xx)), e chiude il canale (Wire.endTransmission()).

Il modulo che riceve, e’ leggermente piu’ complesso: inizializza il canale indicando pero’ l’id di riconoscimento (Wire.begin(x)).

La parte interessante, e’ la gestione degli eventi: la libreria Wire include la giusta funzione proprio per permettere di associare un evento nel momento in cui i dati sono disponibili: Wire.onReceive(evento).

la funzione indicata in onReceive: evento(int qualchecosa), deve in primo luogo verificare se ci sono i dati sul canale: while(Wire.available() >0).
se ci sono dati disponibili, si possono prelevare con Wire.read().

In questa fase non ci sono da aprire canali. La funzione si attiva nel momento giusto.

Morale: in questo modo e’ possibile pilotare piu’ di un arduino affinche’ possano svolgere al meglio specifiche’ funzionalita': p.es.: il primo arduino effettua i rilevamente di alcuni sensori. Il secondo si occupa magari di svolgere attivita’ su led e rele’. Alla fine, un Raspberry o qualche altra cosa, potrebbe ricevere i dati dei sensori, elaborarli e trasmetterli al secondo arduino che provvedera’ ad attivare determinati compiti. Nel mio test, ho collegato un led e un buzzer, attivandoli e disattivandoli in base ai valori 0 e 1 inviati dal primo arduino.

alcuni riferimenti:

la funzionalita’ che ho usato e’ meglio descritta qui:
http://arduino.cc/en/Tutorial/MasterWriter e
http://arduino.cc/en/Reference/Wire.

una nota, nel primo link, alla riga dove viene indicato il while: while(1<Wire.available()) credo che l’uno debba essere uno zero. A me funziona solo con zero. decidete voi.

Post collegati:

  • Nessun post correlato
Pubblicato in arduino | Lascia un commento

Arduino 2: il led che cambia…

Iniziamo a entrare nel merito, anche se siamo ancora lontani da qualcosa di utile.

Ho collegato un led e la sua resistenza (220 ohm) tra le uscite 3 (pwm) e la terra.

Da quanto ho capito le uscite PWM (ovvero quelle identificate come “~”) possono assumere una serie di valori variabili che vanno da 0 a 255.

Ho scritto poche righe di codice che definiscono quanto segue:

#define LEDV 3
int value = 1;
int livello = 0;

void setup()
{
pinMode(LEDV,OUTPUT);
}

void loop()
{
if (livello < 10) { value = 1; }
if (livello > 200) { value = -1; }
livello += value;
analogWrite(LEDV,livello);
delay(15);
}

in pratica:

ho definito quale porta usare: #DEFINE ….
ho definito due interi: value (che puo’ assumere due valori: +1 e -1),
ho indicato come la porta deve agire: nel mio caso deve inviare una tensione in uscita (che poi tensione non e’ in quanto la tecnica e’ quella switching).

livello, che contiene il valore da scrivere sulla porta PWM.
il codice e’ semplice:
la voce ‘livello’ aumenta o diminuisce in base a ‘value’ e successivamente viene inviato alla porta con la funzione analogWrite.
Ho aggiunto un piccolo delay affinche’ l’oscillazione del valore del led non sia troppo veloce.

aho! Il codice fara’ pure schifo, ma funziona.

Post collegati:

  • Nessun post correlato
Pubblicato in arduino | Contrassegnato , , | Commenti disabilitati

E venne il primo esperimento

senza attendere, ho subito voluto provare Arduino, tanto per darmi un’idea.

ho usato: un Arduino UNO, un potenziometro da 440 ohm (c’avevo questo!), un paio di fili.

Ho collegato il potenziometro al pin A0 e ai 5V.
Ho poi rimediato in rete questo sketch:

void setup() {
Serial.begin(9600);
}

void loop() {
int sensorValue = analogRead(A0);
Serial.println(sensorValue);
delay(1);
}

e l’ho caricato sull’arnese.

ha funzionato.

In sostanza in setup() viene configurata la porta seriale a 9600 bauds.
in loop viene letto il pin A0 e il valore spedito sulla seriale. Un piccolo ritardo e si riparte.

Per porta seriale, intendo la porta usb usata come seriale. Obvius.

Post collegati:

Pubblicato in arduino | Contrassegnato , , , , , | Commenti disabilitati

Dovecot, postfix, lda e sieve…. Facciamo st’ammucchiata

intanto un po’ di nomi e il loro compito:

Dovecot: gestisce il pop, l’imap, il protocollo sieve e puoi fare da LDA

postfix: MTA – gestisce la posta elettronica dall’smtp al delivery

MTA: Mail Transfer Agent – meccanismo che gestisce i flussi di posta

LDA: Local Delivery Agent – meccanismo che si occupa di prendere la posta dall’MTA e consegnarlo localmente.

Procmail: meccanismo che si occupa di gestire la distribuzione della posta locale a partire dall’lda fino alla casella vera e propria. Agisce in base a un set di regole impostabili dall’utente quali copie, spostamenti in particolare cartelle, forward e quant’altro.

Sieve: Lo stesso di procmail, ma piu’ evoluto, totalmente gestito all’interno di Dovecot attraverso appositi script e anche attraverso un apposito protocollo di rete.

Pigeonhole: Sieve per dovecot2

Era da tempo che cercavo di capire come gestire regole di posta elettronica (le stesse che troviamo nei normali client di posta come Outlook o Mail o chi per loro) attraverso le webmail dei sistemi che gestisco. Il punto fondamentale era come permettere agli utenti di crearsi le proprie voci senza stare a rompermi ogni giorno. La webmail che uso, roundcube, consente, attraverso appositi plugin la gestione di queste regole appoggiandosi, guarda caso, proprio al protocollo sieve.

Facendo un piccolo ragionamento, e confrontandoli con tutti gli howto pescati in giro, la posta in entrata sul server, presa in consegna da postfix, anziche’ dover essere infilata direttamente nella casella postale, sarebbe dovuta passare attraverso dovecot usato come LDA il quale smazzetta i messaggi in base alle regole sieve fornite attraverso le webmail e infine buttare tutto nelle caselle di psota indicate.

facile no?

vediamo come fare.

Una piccola premessa:

ho prima testato la configurazione sulla mia macchina virtuale installata nel mio portatile che mi gestisce in imap la posta locale – ebbene si, io NON USO UN NORMALE CLIENT DI POSTA, MI PORTO APPRESSO DIRETTAMENTE UN MAILSERVER . In questa configurazione, non vengono gestiti gli utenti virtuali e non c’e’ una vera e propria webmail. Tradotto: le regole sieve vengono scritte a mano in un file, al pari delle operazioni fatte con procmail. Non e’ attivo un server sieve, ma solo il suo esecutore di script. Postfix subisce un impatto minimo nelle configurazioni.

portero’ in evidenza, quindi, sia il caso di un delivery locale senza utenti virtuali, sia un delivery in ambienti piu’ complessi con delivery verso utenti virtuali.

partiamo da freebsd:

installato dovecot2 senza particolari accorgimenti. Lo stesso per postfix.

Passo successivo, installazione di dovecot2-pigeonhole, che si occupa per l’appunto di gestiore sieve.

andiamo di modifiche:

iniziamo da postfix:

modifichiamo mailbox_command. Questo comando di default arriva impostato per l’uso di procmail. Passiamo quindi da

mailbox_command = /usr/local/bin/procmail -a “$EXTENSION” DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir/

(Questo e’ il mio schema locale, quindi posso immaginare che il vostro sia diverso.)

a:

mailbox_command = /usr/local/libexec/dovecot/dovecot-lda -f “$SENDER” -a “$RECIPIENT”

ovviamente accertatevi che dovecot-lda sia presente, oppure aggiornate la corretta posizione.

Il classico “postfix reload” e questa parte e’ conclusa. Volendo, nulla vieta che prima di mettere mano al nostro MTA, facciamo qualche prova a manella, tipo:

create un file di testo contenente lo schema di una mail tipo:

mail from: xxx@xxx.xxx
rcpt to: xxx@xxx.xxx
subject: prova spedizione email

prova prova prova
ciao

poi, un bel:

cat filediprovamail.txt | /usr/local/libexec/dovecot/dovecot-lda -f "xxx@xxx.xxx" -d "l'utente locale che usate"

se trovate il messaggio nella vostra casella, siete a cavallo.

fase 2, attivazione di sieve e soci:

nell’installazione standard di dovecot2 + pigeonhole non ho trovato gli script che mi servivano. Questi li ho trovati in /usr/ports/mail/dovecot2-pigeonhole/work/dovecot-2.2-pigeonhole-0.4.2/doc/example-config/conf.d/*.conf che ho prontamente copiato in /usr/local/etc/dovecot/conf.d. E’ probabile che abbia fatto qualche minchiata qua e’ la’ nella compilazione….

Una volta trasportati i files, ho modificato alcune cose in:

90-sieve.conf – sieve = ~/.dovecot.sieve (ovvero lo script utente con le regole)

15-lda.conf – postmaster_address = un’email da usare come postmaster.

15-lda.conf mail_plugins = $mail_plugins sieve (questa voce e’ contenuta nella sezione plugins del file).

fine delle modifiche principali. riavviare dovecot.

Un’occhiata ai file di log, non guasta mai.

a questo punto andate a crearvi il file .dovecot.sieve nella vostra home, con le regole sieve corrette. Non sto’ a spiegare cosa metterci dentro e come.

nota utile: e’ possibile testare il proprio file sieve lanciando il comando sieve-test indicando il file di script e un’eventuale mail di test configurata a dovere.

ora passiamo alla parte virtuale.

Sui server di produzione ho ancora debian squeeze. Non ho verificato su altre versioni di debian, quindi attenzione.

intanto, il caro comando dovecot-lda, cambia nome e posizione:

/usr/lib/dovecot/deliver

poi, le configurazioni. Ho imprecato un po’ di piu’ del normale, comunque:

dovecot.conf:

sezione lda da abilitare:

protocol lda {
  postmaster_address = email che fa da postmaster del dominio
  hostname = nome reale dell'host
  # log_path = /var/log/lda1.log
  # info_log_path = /var/log/lda2.log
  # debug = yes
  }

sezione auth default, abilitare:

socket listen {
  master {
    path = /var/run/dovecot/auth-master
    mode = 0660
    user = postfix
    group = postfix
    }
  }

Area Mail processing:

#mail_debug = yes

Le riga commentate sono relative ai log. torneranno comode per capire cosa funziona e cosa no.

ora sieve:

protocols = ... vostri protocolli ... managesieve
protocol managesieve {
}

sezione lda:

mail_plugins = sieve

nota: verificate con attenzione le configurazioni di dovecot e poi un buon reload.

per verificare che il delivering funziona, potete sempre usare il cat mailditest | /usr/lib….. di cui sopra.

passiamo a postfix. In realta’ ci sono poche cose da fare: Creare un servizio in master.cf che gestisca il delivery e poi dire a postfix di usarlo.

master.cf:

dovecot unix - n n - - pipe
 flags=DRhu user=dovecot argv=/usr/bin/sudo -u postfix /usr/lib/dovecot/deliver -f ${sender} -d ${recipient}

(notare l’uso di sudo)

main.cf:

dovecot_destination_recipient_limit = 1

poi possiamo optare per spingere tutti i nostri domini con la nuova soluzione:

virtual_transport = virtual

oppure, decidere di usare solo alcuni domini – magari inizialmente per fare delle prove tecniche:

indicando a transport_maps quali domini possono utilizzare la voce dovecot: creata in master.cf.

sudooers.d: in un file chiamato postfix:

dovecot ALL=(postfix) NOPASSWD: /usr/lib/dovecot/deliver

ok… soluzione da schifo, ma per il momento funziona.

tralascio la configurazione del plugin sulla webmail perche’ devo prima rifinire questa soluzione. In base ai vari log offerti dal mailserver, il fatto di avere postfix con un uid/gid e dovecot con altro uid/gid crea un po’ di casini, pertanto si deve fare riferimento alle soluzioni offerte per le soluzioni multi-uid.

hint:

a parte il sito di dovecot dove tutte le funzionalita’ sono perfettamente documentate,tante sono le indicazioni che ho trovato in giro. Qualche volta indicazioni contrastanti, ma comunque utili per capire che giri fa la posta.

http://wiki2.dovecot.org/LDA/Postfix

in questa pagina ci sono anche i suggerimenti per la problematica degli uid differenti.

http://www.stefan-seelmann.de/wiki/mailserver-postfix-dovecot#deliver-to-dovecot

https://workaround.org/ispmail/squeeze/postfix-dovecot

e via disquisendo….

 

Post collegati:

Pubblicato in bsd, Debian, mail, mail filtering, webmail | Contrassegnato , , , , , , , | Lascia un commento

Antispam

Finire in una blacklist e’ ormai cosa abbastanza semplice. Il problema, semmai e’ uscirne.

esistono in rete siti che concentrano il controllo su parecchi motori di controllo.

uno di quelli famosi e’ mxtoolsbox.net

oppure http://mail-blacklist-checker.online-domain-tools.com/.

anche http://www.dnsbltools.com/ rientra in questa lista.

mirapoint (http://miracare.mirapoint.com/checkip.html#reportIP) – utilizzato anche da provider come Libero.it.

barracuda networks (http://www.barracudacentral.org/lookups)
trendmicro (https://ers.trendmicro.com/reputations) utilizzato da molti enti pubblici italicy

spamcop.net, piuttosto suscettibile. No gli si puo’ richiedere la rimozione automatica, ma bisogna attendere circa 24 dall’ultima segnalazione prima che, automaticamente, si venga rimossi dalla black.list.

cisco con senderbase non consente di rimuovere da una blacklist il proprio ip, ma comunque consente di dare un’occhio sulla situazione.

uceprotect: che vogliono i soldini per toglierti prima dalle black list.

in caso di attacco spam, la migliore soluzione e':

blocca il dominio in uscita a meno di essere sicuri su quale account sta’ spammando.
verifica delle configurazioni, e soprattutto check di:

svuotare o congelare le code: se si riesce ad agire in velocita’ e’ possibile limitare i danni con le varie blacklist.

autenticazione smtp: alcuni giorni fa una macchina, senza apparente motivo ha smesso di verificare l’autenticazione smtp. Bastava una password qualsiasi e si passava. il bello che non veniva mostrato nessun errore.

Verificare la sorgente: sto scoprendo sempre piu’ spesso, che oltre alla ricerca bruta di password con tentativi continui – bloccabili tranquillamente attraverso prodotti come fail2ban – il trucco e’ appestare un pc vittima, fregarli le credenziali e usarle per autenticarsi sul sever di riferimento. Per essere esatti ho ricevuto anche la notifica di un cliente che ha ricevuto un virus – fortunatamente uno solo – attraverso la pec.

cambio di credenziali del cliente e prima di sbloccargli l’account, fargli controllare bene il pc.

per un certo periodo di tempo, una volta riabilitato l’account e’ meglio controllare se avvengono altre anomalie. Fidarsi e’ bene, non fidarsi fa dormire meglio.

Attenzione: lo spam e’ totalmente automatizzato e distribuito, quindi pensare di bloccare gli ip di provenienza e’ cosa fantasiosa e raramente valida.

Post collegati:

Pubblicato in mail, mail filtering, service | Contrassegnato , , , , , , , , , , , | Lascia un commento

Debian Stable/wheezy e Rails4 via fast-cgi

Vediamo passo passo come procedere. In realta’ la procedura e’ semplice. Cerchiamo le stranezze. Diciamo pure che per trovare tutti i riferimenti necessari ho girato un po’ come una trottola. Ma ora funziona.

Intanto, faccio notare, che nei repository e’ presente anche la versione 3.2 di rails.

Inoltre, sempre per onore della cronaca, apt-cache search riporta due versioni di ruby, la 1.8 e la 1.9 (1.9.1 – anche in versione -dev e 1.9.3).

Visto che l’installazione dei componenti di Rails richiede anche la compilazione di qualche modulo, ho installato sia ruby 1.9.1 che la controparte -dev oltre ai tools di compilazione standard di debian (build-essential)

A questo punto il passo successivo:

gem1.9.1 install rails

Nel mio caso, avendo anche la necessita’ di usare mysql, ho optato per ruby-mysql2. E’ possibile installare la gemma, sia con apt-get (vista la presenza nei repository ufficiali), sia attraverso gem, sia andando a modificare Gemfile aggiungendo il componente che ci interessa e lanciando poi “bundle install

Verificate che il vostro utente – sempre che non usiate la follia di accedere come root, abbia la possibilita’ di scalare i vertici con sudo. questo e’ utile a rails in fase di installazione delle gemme durante la creazione di una nuova applicazione.

creiamo la nostra prima applicazione:

rails new app -d=mysql

l’opzione supplementare ‘-d‘ specifica il database da usare. nel nostro caso, per l’appunto mysql, di cui, ovviamente risulteranno gia’ installate le librerie di include e il necessario per collegarsi al server db. nel caso, durante l’installazione di mysql2 (gem install mysql2) saltasse fuori un errore, e’ probabile che vadano installate le librerie libmysqlclient-dev

Ora, visto che sono masochista, volevo vedere quale webserver scegliere per far girare la baracca. Apache? no, troppo facile. Ho installato Lighttpd.

E ora vediamo come integrare i due.

Abilitiamo fastcgi (link in conf-enabled: 10-fastcgi.conf -> ../conf-available/10-fastcgi.conf)

ho deciso di usare rails in configurazione fastcgi per directory. Ovvero, ogni directory viaggia per cavoli suoi, con la propria applicazione bella e buona.

per fare questo, ravanando in giro ho trovato questo sito (http://blog.lighttpd.net/articles/2005/11/23/lighttpd-1-4-8-and-multiple-rails-apps/) che ci suggerisce di inserire in 10-fastcgi il seguente testo (per evitare confusione, ho creato un mio file personale con le impostazioni necessarie chiamato, con pochissima fantasia: rails.conf. Questo file e’ stato posizionato in conf-enabled):

$HTTP["url"] =~ "^/testapp/" {
 server.document-root = "/home/mauro/testapp/public/",
 alias.url = ( "/testapp/" => "/home/mauro/testapp/public/" ),
 server.error-handler-404 = "/testapp/dispatch.fcgi"
 fastcgi.server = ( "/testapp/dispatch.fcgi" =>
 (( "host" => "127.0.0.1",
 "port" => 8000,
 "strip-request-uri" => "/testapp/"
 )
 ))
}

Si capisce abbastanza facilmente che la directory public della nostra applicazione viene mappata e sostituita da “testapp”. Lighttpd toglie qualsiasi riferimenti alla posizione fisica dell’applicazione.

Questa configurazione si traduce in:: ogni richiesta che inizia con /testapp/ viene dirottata nella cartella public della nostra applicazione rails. al suo interno gira usando spawn-fcgi (che deve essere installata attraverso apt-get):

spawn-fcgi -p 8000 -n -U www-data -u mauro -- /home/mauro/testapp/public/dispatch.fcgi

il quale risponde alle richieste usando il protocollo fast-cgi. come e’ abbastanza facile vedere, spawn-fcgi risponde sulla porta 8000. ovviamente questo servizio deve essere attivo in modo da essere pronto a rispondere alle richieste di lighttpd. Nel caso non fosse attivo, il webserver non se la prende e riporta un laconico: service unavailable.

L’opzione -n che si vede nella riga di lancio di spwn-fcgi indicata che l’applicazione non deve andare in background. Lasciandola in foreground e’ possibile vedere i messaggi di operativita’ di rails durante le richieste. le opzioni -U e -u consentono di far girare spawn-fcgi con un utente scelto da noi e isolato dal webserver. Anche questo e’ un ottimo sistema per aumentare la sicurezza e isolare i diversi componenti.

Sempre restando su spwn-fcgi, nella documentazione viene riportato che in condzioni standard, ove non diversamente specificato vengono forniti 4 demoni pronti a rispondere alle richieste.

Se cercate tra le attivita spawn-fcgi, non lo troverete. Ps -A riporta ruby e non spawn-fcgi.

rimane da definire il file dispatch.fcgi (posizionato in applicazione-rails/public e con i diritti di esecuzione attivati):

!/usr/bin/env /usr/bin/ruby
ENV['GEM_HOME'] ||= '/home/mauro/.bundler/tmp/14124/gems'
require 'rubygems'
require 'fcgi'
ENV['RAILS_ENV'] ||= 'development'
# Set GEM_PATH and GEM_HOME ("user" is your dreamhost user)
ENV['GEM_HOME'] ||= '/home/user/.gems'
require 'rubygems'
Gem.clear_paths
require File.join(File.dirname(__FILE__), '../config/environment')
class Rack::PathInfoRewriter
 def initialize(app)
 @app = app
 end
def call(env)
 env.delete('SCRIPT_NAME')
 parts = env['REQUEST_URI'].split('?')
 env['PATH_INFO'] = parts[0]
 env['QUERY_STRING'] = parts[1].to_s
 @app.call(env)
 end
end
Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(PropriaApplicazioneTestApp::Application)

alcuni dettagli:

La riga ENV[‘GEM_HOME’] deve essere corretta in base al proprio repository gem riferito all’applicazione in analisi.

La riga ENV[‘RAILS_ENV’] deve essere correttamente impostata sul tipo di applicazione, ovvero, sviluppo, produzione o test (in inglese, obvius).

Nel file dispatch.fcgi, ultima riga, la parola Testapp, valida per il mio caso, va cambiata con il nome dell’applicazione generata. Il nome esatto e’ reperibile in config/envinroment.rb.

E’ importante installare con gem il modulo fcgi. Questo puo’ essere fatto a livello di sistema e a livello di singola applicazione rails, modificando e aggiungendo la voce “gem ‘fcgi’ in Gemfile.

Va fatta molta attenzione a come si scrive il file di configurazione di lighttpd. Ho scoperto che anche cambiare doppio apice con il singolo apice crea scompiglio.

Tutti i riferimenti, gli esempi dei file sono stati trovati ravando per siti ufficiali e forum.

alcuni di questi, ma ormai non ricordo nemmeno quanti, sono tra i seguenti:

dispatch.fcgi: https://www.ruby-forum.com/topic/67033

lighttpd fastcgi: http://redmine.lighttpd.net/projects/1/wiki/Docs_ModFastCGI

lighttpd logging: http://redmine.lighttpd.net/projects/1/wiki/Docs_ModAccesslog (per capire come e cosa accadeva durante le richieste da web – vi consiglio di attivare:

debug.log-request-handling = “enable”
debug.log-request-handling = “enable”

altro: come soluzione ho usato spawn-fcgi come servizio mappato su una specifica porta. Ho trovato molte soluzioni che indicavano di usare un socket; In nessuna di queste, pero’ ho trovato un meccanismo che impedisse a lighttpd di crashare in caso il socket non fosse presente.

Sempre su spawn-fcgi, ogni applicazione deve rispondere su un’apposita porta che deve essere riportata anche nella configurazione di lighttpd.

aggiornamento:

in un ambiente limitato, come una home senza accesso root, e’ possibile usare GEM_HOME per posizionare in una posizione arbitraria le gemme nel proprio spazio.

ovviamente tutti i file che hanno in qualche modo a che fare con le gemme, devono essere correttamente aggiornati.

per l’esattezza:

GEM_HOME=~/.gems rails new “propria applicazione”

GEM_HOME=~/.gems bundle install dopo aver aggiunto i propri moduli tra cui – importante – fcgi.

Post collegati:

Pubblicato in Debian, http, ruby, service, sviluppo | Contrassegnato , , , , , , , , | Lascia un commento

sms da pc a android

Ed eccoci qua’ con una nuova sfida: ho la necessita’ di spedire sms da pc cercando di usare un telefono android.
Una volta, quando i telefoni erano di legno, il sistema piu’ semplice era quello di collegare l’apparecchio con il suo bravo cavetto al pc. Il telefono disponeva di una interfaccia hayes e quindi, attraverso i canonici comandi AT si potevano fare parecchie cosette interessanti tra cui, soprattutto spedire sms da riga di comando, da terminale o comunque utilizzando un sistema minimale suscettibile di ampie implementazioni.
Ora sono arrivati i telefoni fighetti e i problemi – ovviamente – sono aumentati.
A forza di girare per siti, forum, pattumiere e quant’altro ho trovato un’applicazioni per Android dall’esoterico nome di easySMS che altri non e’ che un’app che contiene al suo interno un server http che attraverso pochi comandi consente di inviare via web un sms usando il proprio terminale telefonico da un pc connesso alla stessa rete. L’applicazione prevede anche la connessione via USB e via Bluetooth.
Una volta installata l’applicazione, liberamente scaricabile dallo store di Google (vuole una donazione d i un euro – ampiamente meritata), la si lancia e ci sono diverse opzioni disponibili, tra cui:

avvio automatico o manuale (fondamentale per l’uso che se ne deve fare). Nell’avvio automatico, il telefono deve essere predisposto per rimanere connesso alla rete anche in standby, altrimenti vi alzate di notte e lo accendete ogni volta che vi serve.
porta di servizio del server http: essendo un’applicazione che non gira con i diritti di root, ovviamente la porta sara’ piuttosto altina: il default e’ 2511.
username e password: consiglio di usarle, sai com’e’!

nota: tra le diverse opzioni ce n’e’ anche una che usa un metodo di invio dei messaggi diverso da quello di default. nel caso l’accesso via web non compia il proprio dovere, provate questa opzione: Alt. Send

Occhio pure, che e’ abilitata la richiesta di “delivery report”. Viene richiesto l’invio da parte della rete del destinatario di un sms che pagate Voi per la conferma di consegna. Se non vi serve la consegna, potete disattivarlo. Per chi paga, ricordo, che anche questo secondo sms viene addebitato al Vostro conto.

Una volta avviata la procedura, accedete dalla rete all’ip del Vostro terminale sulla porta 2511 o quella che avete scelto per l’occasione e vi ritroverete con la richiesta di una coppia di credenziali – quelle che avete messo nel pannellino dell’applicazione.

Dopo di che, click su “compose new message ” e al resto penso ci arriviate da soli.

Ma la cosa non finisce qua.

Avendo la necessita’ di spedire messaggi in modo automatizzato ho fatto un paio di prove con curl.

Premetto che per capire cosa passasse tra pc e telefono ho messo Wireshark a sniffare la connessione.

Il protocollo usato e’ molto semplice e si risolve in poche battute:

curl –user :<username>:<password> “http://<indirizzo ip>:<porta> /newmessage?text=<messaggio max 160car>&empf=<telefono>&type=send”

se tutto fila liscio, curl ritorna la pagina di risposta del webserver che corrisponde alla schermata che avete visto sul browser classico. altrimenti vi ritrovate con un errore che puo’ spaziare tra pagina non trovata, credenziali errato e non so’ che altro.

Presumo che dalla riga di comando a una piccola applicazione che faccia cose che Voi umani – pardon, questa e’ un’altra cosa – dicevo, che faccia cose utili, tipo avvertirvi quando i server esplodono o quando la temperatura dell’acquario supera la soglia di frittura, sia un gioco da ragazzi. due righe in Ruby o due in Python e via alla grande.

 

note:
il sito di riferimento dell’applicazione e’ fireblade.org

nota: da capire quanto il telefono influisca sull’affidabilita’. Sull’accrocco dove lo sto’ provando, un alps la cui durata delle batterie e inferiore a quella del Bosone di Higgs, ho disattivato i risparmi energetici, ho impostato che il telefono deve mantenere sempre la connessione. Pero’, dopo un po’ trovo sempre l’arnese sconnesso….. devo indagare.

 

Post collegati:

  • Nessun post correlato
Pubblicato in linux, Uncategorized | Contrassegnato , , , , , , , | Lascia un commento

Centos, aggiunta o modifica schede di rete

Ormai udev la fa da’ padrona. Anche Centos non si sottrae al demone e ogni volta che aggiungiamo o cambiamo una scheda di rete dobbiamo tenere presente diversi fattori:

a: le informazioni circa le schede di rete vengono memorizzate in primis da udev, ma ancora piu’ importante, vengono memorizzate anche in /etc/sysconfig/network-script:

tanti file nominati ifcfg-ethX dove la X identifica il numero di eth su cui lavorare.

b: ogni file ifcfg-ethX contiene una serie di informazioni circa la configurazione di rete, tra cui: i dati di ip, modalita’ di registrazione, l’indirizzo hardware della scheda e il maledetto UUID che ormai si trova ovunque.

c: se nel file ifcfg-ethX manteniamo l’indirizzo hw della scheda di rete, e’ importante che tale valore sia riportato anche nei file di configurazione di udev (70-persistent-network)

d: se abbiamo bisogno di indirizzi multipli appoggiati alla stessa scheda di rete, basta procedere copiando il file ifcfg-ethX su ifcfg-ethX:0. Modifichiamo ifcfg-ethX:0 cambiando la voce DEVICE e impostando lo stesso nome ethX:0 usato esternamente: es. ifcfg-ethX:110 = DEVICE=ethX:110

source:

http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-interfaces.html

 

 

 

 

Post collegati:

Pubblicato in centos, lan | Contrassegnato , , , , , | Lascia un commento

amavis mailscanner spamassassin e clamav

ho sempre usato MailScanner per il controllo antivirus e antispam. Ultimamente, pero’, ho notato un certo appesantimento della baracca e come la coda in attesa cresceva un po’, mailscanner iniziava a soffrire.

MailScanner, grossomodo funziona cosi':

postfix riceve la mail,
la mail viene messa nella cartella hold (vedi: #header_checks = regexp:/etc/postfix/header_checks: /^Received:/ HOLD).
Mailscanner cicla periodicamente nella cartella hold, quando trova qualcosa, lo processa e riaccoda la mail per il proseguo dell’operazione.

Postifix completa l’operazione.

Amavis, invece, lavora direttamente come demone comunicando su di una porta ben specifica.

In pratica, il messaggio arriva,
postfix lo gira ad amavis che in base alle configurazioni lo verifica con clamav e con spamassassi
completato il tutto, il messaggio viene ripassato a postfix che completa l’operazione.

In effetti, la cosa sembra piu’ veloce.

 

L’installazione e la messa in opera sono abbastanza tranquille e ben spiegate nei vari howto che ho inserito.

http://www.ijs.si/software/amavisd/README.postfix.html

http://www.server-world.info/en/note?os=Debian_6.0&p=mail&f=6

http://tutorials.section6.net/home/setting-up-postfix-spamassassin-amavisd-clamav

 

nota: se come me avete sostituito mailscanner ricordatevi di togliere la riga che lo utilizza all’interno di postfix e poi di fermare mailscanner.

 

Post collegati:

Pubblicato in linux, mail, mail filtering, Uncategorized | Contrassegnato , , , , , , , , , , , | Lascia un commento