lvm: gli appunti

lvm fa’ tanto, lvm e’ complesso, lvm ha un mare di comandi: questo e’ certo.

intanto come ottenre qualche info:

lvs -o +devices

lvs -o +devices,seg_pe_ranges

visualizza l’elenco dei volumi logici e affianco su quali dischi i volumi vanno a posizionarsi. Nota: nell’elenco che viene visualizzato puo’ darsi che non sia segnalato qualche volume fisico: no problems, potrebbe essere semplicemente il caso che quel volume e’ vuoto e pertanto non ci sia nulla da visualizzare. Potete verificare la correttezza della cosa con pvs. mettendo l’opzione deq_pe_ranges, abbiamo modo di sapere anche quanto esattamente e’ stato allocato.

pvs (ma anche pvscan)

visualizza informazioni circa i volumi fisici. lanciato cosi’, visualizza lo stato di occupazione dei volumi.

pvmove: consente di spostare l’insieme dei volumi logici presenti su un disco fisico su un altro disco. e’ un’operazione lenta e bisogna attendere. Il vantaggio e’ che si puo’ continuare a lavorare anche se leggeremente piu’ lenti.

Da ricordarsi, ogni volta che si gioca con i volumi fisici, di fare un update-grub e verificare la corretta configurazione di grub stesso. Altrimenti, al prossimo boot non si parte. Se appare un errore del tipo che non viene trovato un volume fisico PVX, significa che /boot/grub/device.map non e’ corretto. Stesso discorso se viene visualizzato un errore relativo proprio a device.map mentre viene effettuato un update-grub. Soluzione spiccia: rimuovere device.map e di nuovo update-grub. Se invece il danno e’ stato fatto e siamo gia’ incasinati al riavvio, basta risolvere avviando velocemente con un cd di emergenza e fare le stesse cose.

link:

http://www.datadisk.co.uk/html_docs/redhat/rh_lvm.htm

 

 

Post collegati:

  • Nessun post correlato
Pubblicato in disk, lvm | Lascia un commento

Raid e gpt e grub: tripletta infernale.

Mi son trovato a dover risolvere un piccolo problema di incompatibilita’ tra partizioni tradizionali, partizioni gpt, raid e lvm.

Il server in questione e’ nato inizialmente con due dischi in raid software suddivisi in una piccola partizione di boot e il restante con volume lvm.

La partizione iniziale dei due dischi e’ stata fatta nella classica via MBR.

Durante la sostituzione di un disco guasto, il nuovo disco e’ stato erroneamente partizionamento con GPT.

Apperentemente tutto ha continuato a funzionare correttamente. Riavvi del sistema senza problemi, ripristino del raid ok, installazione grub ok.

Il problema serio e’ saltato fuori quando si e’ presentata la necessita’ di sostituire il disco ancora partizionato BSD. La macchina non ne voleva sapere di fare il boot dal disco GPT.

Un po’ di analisi ed e’ venuto fuori che indipendentemente dalla presenza o meno di errori, grub si installava correttamente ma ignorava – senza segnalarlo che il disco GPT non andava bene in quanto e’ ormai noto che senza una partizioncina dedicata, il fetente non si installa su questo dipo di disco (tenete presente anche la presenza del RAID).

Ravanando in giro ho trovato il tool gdisk che consente di convertire allegramente una partizione GPT in MBR e viceversa senza danni e piagnistei. Il tool e’ semplicissimo da installare e da usare.

Per inciso, opzione “r” per i backup e i cambiamenti e “g” per passare da un tipo all’altro.

Il resto dei comandi ve li lascio a Voi. Ovviamente, per precauzioni fatevi prima un backup delle vostre partizioni, che la cacchiata e’ sempre dietro l’angolo. gdisk consente anche di fare salvataggi e ripristini, quindi la cosa e’ oltremodo facilitata’. Occhio pure che i comandi vengono eseguiti immediatamente, quindi una volta premuto il tasto di un’eventuale conversione, l’operazione viene immeditamente fatta sul disco.

Una volta fatto il cambiamento da GPT a MBR, e’ importante anche reinstallare grub in modo che il bimbo acquisisca i cambiamenti fatti.

Nel caso qualcosa vada storto – nei miei esperimenti, la macchina virtuale non e’ partita un paio di volte – le operazioni relative a grub-install, gdisk e soci le ho fatte avviando da cd.

 

Post collegati:

Pubblicato in boot, Debian, disk, linux, lvm, raid, tools | Contrassegnato , , , , , | Lascia un commento

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 su Arduino 2: il led che cambia…

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 su E venne il primo esperimento

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