Archivi categoria: linux

Versioni multiple di Node.js: installazione e gestione

Per postazioni dedicate allo sviluppo od ambienti di staging, o più semplicemente riuscire ad utilizzare versioni multiple di Node.js su una macchina o si crea una soluzione personale oppure si adotta un approccio condiviso dalla comunità. Essendo l’argomento di esigenza diffusa, sono già presenti delle proposte che possiamo utilizzare per le nostre esigenze, potendo ulteriormente dare un contributo comunicando la nostra esperienza e pubblicare le nostre migliorie se riusciamo ad ottimizzare il software che abbiamo adottato.

Gestire versioni multiple di Node.js con nvm

Node Version Manager è un software scritto in Bash che semplifica la gestione di versioni multiple di Node.js in modo minimale su Linux ed OSX. L’installazione e l’aggiornamento possono essere lanciati con

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.32.0/install.sh | bash

verificando l’esito in una nuova sessione, che renderà disponibile nvm come funzione di shell (ed in background recupererà i file dal repository di origine per utilizzarli in ~/.nvm).

Per conoscere l’elenco delle versioni installabili, si può lanciare la sintassi

nvm ls-remote

e vedere la vasità delle diverse versioni disponibili.

versioni multiple di node.js disponibili in remoto

Ad esempio, se sulla macchina voglia installare la versione LTS più recente (al momento della prima stesura dell’articolo v4.6.0) è possibile lanciare il comando

nvm install 4.6.0

che si preoccuperà di recuperare la versione richiesta, ed in caso di prima installazione, di creare anche l’alias predefinito. Quindi lanciando node -v sarà tornata il codice di versione appena installata; con nvm ls saranno tornate le versioni e gli alias disponibili globalmente e gestibili attraverso nvm.

Per attivare versioni differenti, l’opzione da usare è use: se quindi nel frattempo abbiamo installato la versione v6.7.0 contenente delle funzionalità più recenti rispetto alla precedente, in comando da utilizzare è

nvm use 6.7.0

dato che il supporto è anche valido per alias e visto che per questo scenario la versione v4.6.0 è l’ultima stabile, si può tornare alla versione precedente lanciando

nvm use stable

Essendo un prodotto opensource, è possibile contribuire al miglioramento di nvm attraverso GitHub.

Spostare posta POP3 in IMAP con script Perl

Quando non si può scegliere IMAP per alcuni scenari di migrazione, e l’accesso per spostare posta POP3 è l’unica opzione, le informazioni dell’articolo Migrare posta tra server, via IMAP e POP3 possono essere integrate utilizzando un ulteriore software.

spostare posta pop3 con script perl

Spostare posta POP3 con pop3toimap.pl

Prendiamo in esame il kit fornito da IMAP Tools che consiste di una raccolta di programmi in Perl per la gestione della posta elettronica.

Tra i software messi a disposizione, quello da dover utilizzare è pop3toimap.pl che accetta da linea di comando le opzioni dove specificare direttamente le credenziali della casella POP3 e quelle per l’accesso IMAP:

pop3toimap.pl -p pop.server.com/utente@server.com/passPOP3 -i imap.server.com/utente@server.com/passIMAP

La sintassi alternativa da utilizzare è prevista attraverso il supporto di un file contenenti una coppia o più di credenziali, indicata in righe separate all’interno di un file di testo semplice con una sintassi fissa

popUsername password imapUsername password

che ovviamente è utile in caso di migrazioni multi utenza, con gli stessi server

pop3toimap.pl -p pop.server.com -i imap.server.com -u file_credenziali_utenti

Alcune versioni precedenti possono presentare un errore logico del codice Perl (correggibile mediante un piccolo fix a parte del codice che cicla la lettura delle mailbox), ma potendo contare sulla versione aggiornata del team di sviluppo il problema non si presenta.

Oltre il singolo script, può essere interessante consultare la guida completa all’uso: infatti visto i diversi software disponibili può essere interessante richiedere la suite completa nel caso durante la propria attività quotidiana si possa avere bisogno di soluzioni già messe a disposizione e pronte per l’utilizzo.

Raggiungibile con tono libero: verifica automatica di un’utenza mobile

Analizzando uno scenario applicativo reale, è possibile incontrare tra le specifiche una esigenza di dover automaticamente telefonare ad un numero ed assicurarsi che risponda con tono libero, in dettaglio riconducibile al seguente estratto:

Dato un numero di utenza telefonica mobile, corrispondente alla SIM utilizzata all’interno di un terminale per telecontrollo, è possibile contattare lo stesso numero con una chiamata voce per verificare la disponibilità della rete mobile sul terminale remoto.

In caso positivo, lo stesso terminale attenderà il tempo equivalente ad uno squillo per poi rifiutare la chiamata, l’equivalente di una linea occupata.

Determinare se il terminale corrispondente al numero ha copertura GSM sufficiente per la gestione in entrata ed uscita di chiamate vocali e SMS.

L’utilizzo di ecosistemi tecnologici M2M più evoluti consentirebbe controlli più efficaci ed immediati, ma l’indicazione in questo caso è quella di rendere operativo un sistema automatico nel breve termine evitando gli interventi di recupero, aggiornamento e reinstallazione del parco terminali già in esercizio, molti dei quali collegati a macchine operatrici a lavoro in cantieri lontani dalla sede aziendale o comunque difficili da poter raggiungere.

Applicazione: controllo del tono libero su terminali installati in cantiere

Condizioni per il tono libero

Il modello del terminale, utilizza una sezione di radiocomunicazione GSM compatibile con rete e SIM ordinarie degli operatori italiani (TIM, Vodafone, Wind) che è possibile interrogare via SMS per ricevere indicazioni sullo stato di ingressi, uscite ed altri dati. L’installazione tipica è eseguita a bordo di macchine da cantiere, a volte la posizione delle stesse a malapena consente una copertura del segnale radiomobile (es. pala meccanica al lavoro in galleria); quindi è indispensabile che un’interrogazione dalla sede sia subordinata alla bontà del segnale di rete agganciato dal terminale, per poter garantire una risposta.

La condizione ideale è che a chiamata vocale diretta, il numero risulti agganciato alla rete (ovvero raggiungibile); il terminale si preoccuperà di attendere poco tempo e rifiutare la chiamata. Quindi al chiamante la centrale telefonica segnalerà almeno un tono libero.

Tutte le altre condizioni differenti sono da considerarsi come eventi che escludono il terminale come al momento raggiungibile.

Tutto questo deve rispondere a logiche programmabili, automatiche o sovrintese da personale aziendale.

FreeSWITCH e tone_detect

Dopo aver percorso alcune opzioni, incluse quelle dei test per il tono libero con modem voce PSTN, ho scelto l’uso di FreeSWITCH poiché consente un apprendimento relativamente rapido, un buon sviluppo di applicazioni personalizzate, non richiede hardware specifico e nonostante la documentazione non sia sempre chiara gli sforzi della comunità alla base della piattaforma sono enormi. Inoltre, con l’integrazione FreeSWITCH si apre il sistema verso scenari applicativi inediti.

Per poter effettuare delle chiamate in uscita, testando alcuni fornitori VoIP, ho integrato i servizi di Messagenet che è risultato quello meglio corrispondente alle aspettative.

Il componente su cui verge l’oggetto dell’articolo è tone_detect al quale passare la frequenza di riferimento del tono libero a 425 Hz ed altri parametri minori. La ricetta è contenuta come configurazione di una extension nel dialplan (prefisso 9900), che vado a richiamare in modo asincrono dal sistema con la riga

fs_cli -x "originate loopback/9900333123456 &echo()"

Proprio all’interno della extension, inserisco delle callback (come ulteriori extension) secondo le quali gestire i diversi casi; segue un estratto della configurazione:

<extension name="ctl_verifica">
 <condition field="destination_number" expression="^9900(\d+)$">
 <action application="set" data="continue_on_fail=true"/>
 <action application="set" data="hangup_after_bridge=true"/>
 <action application="set" data="ctl_chiamato=$1"/>
 <action application="set" data="tone_detect_hits=1"/>
 <action application="set" data="execute_on_tone_detect_1=log 1 *** ONTONEDETECT ***"/>
 <action application="set" data="execute_on_tone_detect_2=transfer ctl_tonolibero"/>
 <action application="set" data="execute_on_media_1=log 1 *** ONMEDIA ***" />
 <action application="set" data="execute_on_media_2=tone_detect tono1 425 w 0"/>
 <action application="set" data="execute_on_media_3=sched_hangup +30 alloted_timeout bleg"/>
 <action application="set" data="execute_on_answer_1=log 1 *** ONANSWER ***" />
 <action application="set" data="execute_on_answer_2=transfer ctl_risponde" />
 <action application="set" data="execute_on_ring_1=log 1 *** ONRING ***" />
 <action application="bridge" data="sofia/gateway/gw_messagenet/$1"/>
 <action application="transfer" data="ctl_inesitato" />
 <action application="log" data="1 B-leg hangup cause: ${bridge_hangup_cause}"/>
 <!--<action application="javascript" data="/opt/freeswitch/report2.js $1 ${bridge_hangup_cause}"/>-->
 </condition>
</extension>

Con la configurazione in uso, viene inoltre superato l’ostacolo della eventuale segreteria dell’operatore telefonico, contenendo le singole extension derivate il comando di hangup prima della chiusura.

Pertanto l’inconveniente relativo ad una singola chiamata è un consumo di 1 secondo nei rari casi che FreeSWITCH non riesca a terminare la chiamata, nell’istante immediatamente successivo all’avviso che introduce il servizio di voicemail dell’operatore di rete. Per evitare questo inconveniente, basta semplicemente che il servizio sia disattivo per ogni SIM della flotta.

MSMTP: usare GMail con la funzione mail() in PHP

Questo articolo può essere applicato a differenti scenari: una installazione Linux minimale, un’istanza virtuale o contenitore che non include un MTA, incompatibilità tra differenti interpreti, un desolante messaggio nella riga di comando da console tipo

sh: 1: /usr/sbin/sendmail: not found

In aggiunta, si può avere la necessità (anche dal punto di vista della comodità o per via di esigenze legate a razionalizzazione delle risorse) di voler utilizzare un servizio esterno all’host che si occupi dell’inoltro dei messaggi di posta elettronica, sfruttando un servizio SMTP con un profilo esistente (fornito anche all’esterno della sede locale, come per es. Google Apps for Work‎ od il comune Gmail), escludendo l’opzione di installare un servizio puro superfluo o inutile su una macchina non desinata a ricevere posta.

Sintesi: il software in questione deve occuparsi di smistare messaggi di posta elettronica, rappresentando il tratto di unione tra un interpretesendmail-compatibile ed un client SMTP. Esiste di già, ed è MSMTP.

MSMTP: requisiti ed installazione

Il progetto MSMTP manutenuto da Martin Lambers è rilasciato come codice libero in licenza GPLv3: i requisiti sono ristretti ad un compilatore e le funzioni per socket tipo Berkeley. Disponibile sui repository delle maggiori distribuzioni Linux, si può comunemente lanciare

apt-get install msmtp

per l’installazione in Debian od Ubuntu, mentre per le altre in base yum tipo RHEL / CentOS

yum install msmtp

Su Apple MacOS 10, MSMTP è disponibile con la formula homebrew

brew install msmtp

La configurazione si basa su file di testo semplici, con i percorsi predefiniti per sistema su /etc/msmtprc e ~/.msmtprc per le configurazione dei singoli utenti. Sul sito di riferimento è presente la documentazione completa (in inglese) ed un file di esempio. Davvero lineare.

google-gmail

Integrazione con PHP ed uso di account Gmail

Come riportato poco prima, MSMTP è sostituibile al comando sendmail, pertanto ci si può disporre a questo tipo di configurazione creando un file in /etc/msmtprc con la configurazione di un account SMTP esistente; il software supporta il TLS, quindi l’esempio Gmail è anche un buon esercizio per verificare questa opzione.

Contenuto del file /etc/msmtprc :

# Esempio msmtprc per Gmail
# 2014 Alessio Felicioni
# fonte: http://www.alessiofelicioni.it/msmtp-gmail-funzione-mail-php/

# valori predefiniti
defaults
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile /var/log/msmtp.log

# configurazione account
account default
host smtp.gmail.com
port 587
auth on
from utente@gmail.com
user utente@gmail.com
password La(TUA)Password_va_qui

Importante garantire che il file sia leggibile dall’utente che esegue il php via processo server (es. apache, www-data o equivalente): vale a dirsi

chown www-data /etc/msmtprc
chmod 600 /etc/msmtprc

Quindi il valore di sendmail_path in php.ini potrebbe essere sostituito con la seguente sintassi

sendmail_path = "/usr/bin/msmtp -C /etc/msmtprc -t"

MSMTP supporta anche la configurazione di account multipli anche sullo stesso file: il parametro che controlla questa opzione è -a con il significato che se invocato con valori differenti, lo smistamento avverrà attraverso profili (ed eventualmente tratte/server SMTP) differenti.

La sezione di documentazione del progetto all’indirizzo http://msmtp.sourceforge.net/documentation.html è il punto di riferimento per utilizzare al meglio il programma e ricca di esempi.

Ripristinare yum su CentOS 5, con RPM

A seguito dell’introduzione di una versione incompatibile dell’interprete python o per altri eventi che abbiano in qualche modo corrotto la corretta dimensione delle dipendenze, può essere necessario ripristinare yum su CentOS 5.

Pur non essendo nello specifico la macchina con dei servizi esposti ma facente parte di una rete attivamente utilizzata per lo sviluppo, è opportuno tornare ad avere yum in efficienza.

cat /etc/redhat-release
CentOS release 5 (Final)

Le necessità al momento non prevedono un upgrade di versione (sebbene preferibile), quindi la dimensione di intervento è quella circoscritta dal mantenersi nel perimetro di CentOS 5.

Ripristinare yum su CentOS 5, con RPM

Dove recuperare file RPM

I file rpm necessari per l’attività di ripristino di yum sono disponibili all’indirizzo http://mirror.centos.org/centos-5/5/os/i386/CentOS/ e pertanto possono essere recuperati ad esempio con wget. Nel mio caso ho recuperato la seguente lista:

python-2.4.3-56.el5.i386.rpm
python-libs-2.4.3-56.el5.i386.rpm
yum-3.2.22-40.el5.centos.noarch.rpm

Completati i download, siccome intendo forzare la sostituzione dei precedenti rpm, posso lanciare

rpm -Uvh --replacepkgs *.rpm

Non sufficiente per ripristinare yum su CentOS 5?

Tutto quanto anticipato sembrerebbe formalmente aver contribuito a sistemare l’installazione di yum per riprendere ad utilizzarlo.

Infatti

yum --version

torna la versione di yum presente e le informazioni sul parser utilizzato per comunicare con le fonti, ma già un

yum list installed

frena gli entusiasmi. Uno dei mirror è in HTTPS ed un componente python m2crypto solleva un’eccezione non gestita.

Ho individuato la soluzione riprendendo dal mirror di CentOS 5 un rpm m2crypto-0.16-9.el5.i386.rpm ed in effetti sono riuscito a superare anche l’ostacolo del repository in HTTPS.

Attivare un tunnel inverso per pubblicare un servizio dietro NAT

Spesso, con l’aggiunta di ulteriori opportuni accorgimenti, è utile poter utilizzare alcuni servizi disponibili all’interno di una rete locale in una sede remota. L’ostacolo in questo caso è costituito dalla funzione NAT che a meno di riconfigurazione dei nodi intermedi non consente un instradamento diretto al server oggetto di interesse: una possibile soluzione è quella di attivare un tunnel inverso.

Una delle funzionalità di OpenSSH è quella di poter attivare dei tunnel; per lo scopo prefissato l’unico prerequisito è poter avere accesso verso la macchina che intende consumare direttamente tale servizio, ovvero anche nel caso sia designato come macchina intermedia (l’idea è quella di attivare un proxy).

Esempio per tunnel inverso dietro NAT

Creare un tunnel inverso con SSH

Il caso più semplice può essere quello di pubblicare un servizio HTTP: l’opzione di nostro interesse è -R alla quale va indicato come parametro una stringa composta dalla porta sull’host remoto al quale il servizio verrà consumato, l’indirizzo della macchina che offre il servizio e la porta, separati da : pertanto la seguente sintassi riassume un classico esempio

ssh -R 10080:localhost:80 utente@macchina.esempio.it

Come anticipato, all’interno di macchina.esempio.it è disponibile alla porta 10080 il servizio HTTP che comunica con la macchina originale e rende disponibile attraverso il tunnel inverso il servizio che lì si trova alla porta 80.

Alternative

In alternativa all’utilizzo di ssh, esistono alcuni servizi che semplificano la configurazione e l’utilizzo, con dei piani introduttivi di primo utilizzo gratuiti.

Quasi sempre sono include delle funzionalità aggiuntive utili per la pubblicazione di demo o sviluppo di servizi web, console di monitoraggio delle richieste e utilità per l’analisi di webhook. I costi dei vari servizi sono piuttosto accessibili e convenienti per una disponibilità già pronta per queste necessita e con profili di offerta diversificati dal singolo utente ad entità più strutturate.

Aperto a segnalazioni per ulteriori alternative.