Archivi tag: linux blog

HTML 5 & JS per le Mobile Apps

Html5 & Mobile AppOrmai l’HTML 5 è una realtà di fatto. Si aprono dunque nuove possibilità di sviluppo, l’HTML5 supporta una serie di nuove funzionalità che l’ormai collaudato e conosciutissimo HTML 4.x non può avere.
HTML 5 è dunque, di fatto, un linguaggio nuovo; sorge spontanea a questo punto una domanda: è possibile sviluppare applicazioni e siti web compatibili per smartphone e tablet usando l’HTML5?

 

In effetti se si prova a fare un breve quadro generale, vediamo che nel mondo degli Smartphone e dei Tablet il predominio si divide in soli due sistemi operativi iOS (per iPhone & iPad) ed Android. Come forse alcuni di voi gia’ sanno, sviluppare una App per iPhone/iPad richiede la conoscenza dell’Objective C++, mentre per Android serve avere una qual certa conoscenza di Java. Seppure Java e l’Objective C++ siano parenti, i metodi di programmazione sono sostanzialmente diversi. Quindi se la nostra esigenza è quella di sviluppare un’ applicazione per entrambi i sistemi operativi, perchè c’interessa coprire il 90% del mercato, saremmo costretti a programmare due differenti apps: questo vorra’ dire impiegare il doppio del tempo nello sviluppo, doppia manutenzione ed altre problematiche che non affronteremo adesso.

E’ a questo punto che l’HTML5 ci puo’ venire prontamente in aiuto: ossia perchè sviluppare due interfacce grafiche quando invece possiamo realizzarne una in HTML5 e javascript e ridurre cosi’ il core (o la Business Logic) dell’ applicazione a poche “righe di codice”? Se infatti un’ app per smartphone, non fa nient’altro che interrogare una base di dati (magari su XML) e visualizzare i vari risultati delle interrogazioni, l’HTML5 e Javascript saranno più che sufficienti per tutti i nostri scopi.

Lo sviluppo per HTML5+Javscript per dispositivi mobile è già una realtà e, a tale proposito, vi vorrei indicare due interessanti framework adatti anche allo sviluppo per mobile:

Jquery Mobile

Ext Js Touch

Se decidete di provare le demo di questi due framework javascript, ricordatevi di utilizzare un dispositivo Touch, altrimenti non funzionerà quasi nulla! Come potrete vedere dalle demo dei due framework le interfacce realizzate non hanno nulla da invidiare a quelle delle app programmate con Objective C++ e Java.

Nel caso in cui dobbiate installare un webserver sul vostro Android, vi consiglio di provare il seguente prodotto:

i-jetty

In questo modo potrete fare girare la vostra app in HTML 5 + Javascript senza dover essere collegati ad Internet.

Buon divertimento !

CouchDB conosciamolo meglio

couchDBQuesto articolo e’ la continuazione della precedente “Introduzione a CouchDB” per cui riprenderemo alcune informazioni di base gia viste per poi allargare alcuni importanti concetti ed aspetti che riguardano questo interessantissimo documentale via HTTP.


Apache CouchDB e’ un moderno documentale, document-oriented, richiamabile semplicemente con l’HTTP e che al tempo stesso offre le piu’ avanzate funzionalita’ di replicazione dati e di ricerca in parallelo (Map/Reduce).

Caratteristiche

Scritto in: Erlang
Punto principale: Consistenza DB consistency, facilità d’uso
Licenza: Apache
Protocolli: HTTP/REST
Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
MVCC – le operazioni di scrittura non bloccano le letture
Sono disponibili le versioni precedenti dei documenti
Progettazione crash-only (reliable)
Necessità di compattazioni nel tempo
Viste: embedded map/reduce
Viste formattate: lists & shows
Possibilità di validazione server-side dei documenti
Possibile autenticazione
Aggiornamenti real-time attraverso _changes (!)
Gestione degli allegati e, CouchApps (standalone js apps)
libreria jQuery inclusa
Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

In CouchDB non esistono tabelle. Il contenuto informativo è suddiviso in diversi database che fungono da contenitori di documenti con strutture potenzialmente disomogenee tra di loro. Il documento è il fulcro di questo software (e di quelli che come lui condividono l’approccio document-oriented).
Un documento è formato da un insieme di coppie chiave-valore.
A differenza dei database relazionali CouchDB non possiede il concetto di schema e quindi ogni documento in ogni database può essere strutturato in modo diverso dagli altri.

Le uniche due chiavi obbligatorie sono:
_id serve per identificare univocamente il documento (è comparabile, semanticamente, alla chiave primaria dei database relazionali)
_rev viene utilizzata per la gestione delle revisioni, ad ogni operazione di modifica infatti la chiave “_rev” viene aggiornata (questo meccanismo è alla base della prevenzione dei conflitti
in fase di salvataggio su CouchDB).

Questo accorgimento permette inoltre di poter interrogare il DBMS su versioni del documento non più attuali in quanto, con un approccio simile a quello di Subversion, CouchDB mantiene memoria di ogni revisione, da quella iniziale alla più recente.

L’altra grande differenza rispetto ai tradizionali RDBMS è il meccanismo di gestione delle query. Nei database relazionali una volta specificate e popolate le tabelle è possibile eseguire query utilizzando un linguaggio conosciuto come SQL (ne esistono vari dialetti ma il concetto non cambia nell’essenza);
a fronte di una query il RDBMS utilizza indici interni e le proprie relazioni per costruire in tempo reale una tabella di risultato (che può, nelle query più semplici, essere un sottoinsieme della tabella di partenza).

Questa soluzione riesce ad essere performante in quanto i dati sono strutturati con questo preciso scopo; inoltre il database non deve conoscere a priori le query che verranno eseguite ma può rispondere a qualsiasi interrogazione, purché sia stilata usando SQL valido.

Consistenza dei dati e replicazione

CouchDB non utilizza alcun meccanismo di locking ma sfrutta l’MVCC (Multiversion Concurrency Control): ogni modifica di un oggetto ne crea una nuova versione. Le versioni precedenti non vengono cancellate. Se due modifiche vanno in conflitto poiche’ accedono allo stesso documenti, la seconda riceve un errore in save. L’applicazione deve riprendere l’ultima versione del documento e rieseguire l’UPDATE.
L’isolamento e’ mantenuto solo a livello di un singolo documento, questa e’ una notevole semplificazione, rispetto alla complessa logica transazionale di altri database, ma consente l’ottimizzazione, la parallelizzazione e la distribuzione dei dati in modo semplice. A livello di accesso al file di dati ogni singola modifica ad un documento rispetta le proprieta ACID (Atomic Consistent Isolated Durable) con la serializzazione delle modifiche sui documenti e la scrittura sincrona sul disco.

Piu’ database CouchDB possono essere collegati tra loro in modo molto semplice. I database vengono aggiornati tra loro con una replicazione peer-to-peer incrementale implementata nativamente nell’engine. CouchDB permette una replicazione bidirezionale asincrona, utilizza un meccanismo automatico di risoluzione dei conflitti e fornisce una eventual consistency tra i database. Se i database sono ospitati su nodi differenti si ottiene con questo la distribuzione dei dati.
La replicazione di CouchDB puo’ essere utilizzata sia per sincronizzare database locali che per complesse configurazioni con sharding dei dati.

Per lavorare su CouchDB esiste anche la possibilita’ di installare CouchApp, in pratica una serie di script che permettono di costruire completi applicazioni stand-alone per il database usando solo HTML e JavaScript. Poiche’ il database stesso risponde in HTTP e’ possibile concentrare su un solo nodo (eventualmente replicabile) la classica pila applicativa web a tre livelli.

CouchDB si e’ cosi’ rapidamente imposto sul mercato, diventando uno tra i piu’ usati database non relazionali. In pratica i due piu’ diffusi NoSQL documentali sono CouchDB e MongoDB: entrambi sono velocissimi (memorizzano i dati in BSON/JSON), sono scalabili in modo nativo su piu’ nodi e non forniscono un’interfaccia SQL.

Per una documentazione piu’ dettagliata si rimanda al sito ufficiale di Apache CouchDB.

 

Per ora e’ tutto, alla prossima e, buon divertimento!

Rimuovere un pacchetto appeso

apt-getOk, oramai avete acquisito una certa confidenza con la vostra distribuzione Linux preferita, avete imparato ad utilizzare i tanti tool di gestione dei pacchetti compresa l’installazione dei nuove chiavi e source list ma, improvvisamente succede l’imprevisto ed un pacchetto che volevate disinstallre od anche solo aggiornare vi ritorna un messaggio di errore dal tipo :

” E: <nome pacchetto>: il sottoprocesso installato script di post-installation ha restituito lo stato di errore 1 ”

e, nonostante ogni tentativo provato, tra comandi di ogni sorta (apt-get purge ecc…) e pacchetti di gestione (es. synaptic) , nulla funziona.

che cosa fare adesso ??? come togliersi da questo impiccio ???

Bene, una soluzione esiste ed anche piuttosto semplice, bastera’ seguire questi pochi passi :

  • spostarsi nella directory /var/lib/dpkg/info/   # e’ qui che trovate tutti ipacchetti installati
  • cercate il nome del vostro pacchetto con estensione .postrm (es. <nome_pacchetto.postrm>
  • editatelo e, scrivete exit 0 nella seconda riga del file dopo #!/bin/sh
  • ultima operazione # apt-get remove <nome_pacchetto>

….. salvo strani inconvenienti dovreste aver cancellato il pacchetto incriminato.

Buon lavoro !

Postgrey e le Greylist alleati per la lotta allo spam

postgreyLa posta indesiderata è un vero flagello per tutti, peggio ancora lo e’ per le aziende. Adesso, però esiste una nuova arma.

Nonostante la raffinatezza e l’efficacia raggiunte da numerosi sistemi antispam, sempre più spesso questi strumenti si rivelano insufficienti per risolvere il problema della posta indesiderata. I disagi provocati dall’attacco di uno “spammer” riguardano tutti, senza alcuna differenza di sorta, ma assumono proporzioni esagerate in ambito aziendale. Per provare a risolvere il problema ci viene incontro un nuovo strumento, le cosiddette Grey-List. Vediamo di cosa si tratta e come usarle per arginare il fenomeno spam.

Il concetto delle Greylist

Le greylist basano il loro funzionamento sul fatto che la maggior parte degli spammer provano l’invio di un messaggio una volta sola e, in caso di errore, non eseguono le richieste di rinvio del messaggio previste dal protocollo SMTP, in quanto, così facendo, le code di invio delle e-mail crescerebbero a dismisura. Sfruttando questo comportamento, quando un server dotato di greylist riceve un messaggio, per prima cosa controlla se in passato ha già ricevuto dall’indirizzo IP del server corrispondente e dal mittente indicato un’e-mail per il destinatario richiesto. Se il controllo riscontra uno dei valori appena indicati  il server interrompe il collegamento e genera un errore che causa la richiesta di ritrasmissione del messaggio, mentre in caso negativo l’e-mail viene inoltrata normalmente al destinatario. In caso di collegamento interrotto, i server “mittente” correttamente configurati, ritentano l’invio del messaggio (in genere dopo un’attesa di 10 minuti). Questo comporta un ritardo nella consegna del messaggio dell’ordine di qualche decina di minuti solo per il primo messaggio proveniente da un determinato mittente, esclusi quelli in arrivo da alcuni domini di uso abituale che sono già approvati all’interno delle greylist, mentre i messaggi successivi non subiranno alcun ritardo.

Postgrey

In questa piccola guida parleremo di postgrey, un’ implementazione delle greylist per postfix (ma può essere usata con un qualsiasi altro server di posta).

Per installarlo è sufficiente eseguire il comando

# apt-get install postgrey

una volta terminata l’installazione, il demone postgrey sarà in ascolto sulla porta 60000.

Postfix

Per integrare il servizio in Postfix è sufficiente modificare il file /etc/postfix/main.cf. All’interno del file è necessario cercare la direttiva smtpd_recipient_restrictions ed aggiungere, alla fine, la seguente stringa:

check_policy_service inet:127.0.0.1:60000

Nota:
le varie voci relative a smtpd_recipient_restrictions dovranno essere separate da una virgola, e se smtpd_recipient_restrictions non dovesse esistere, sarà necessario aggiungerla nel seguente modo:

smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:60000

Una volta terminato sara’ sufficiente riavviare Postfix:

# /etc/init.d/postfix restart

e controllare nel file di log /var/log/mail.log le email in arrivo. Si vedrà che alcune verranno rifiutate con un messaggio di postgrey.

Postgrey configurazione

La configurazione di postgrey è modificabile tramite tre file:

1) /etc/defaults/postgrey # che permette la modifica delle opzioni di avvio del demone:

--inet 
permette di specificare l’indirizzo e la porta su cui sarà in ascolto il demone;
--delay 
l’intervallo, in secondi, di durata del rigetto;
--max-age 
dopo quanto tempo rimuovere gli indirizzi che sono stati visti (memoria storica del programma).

Le opzioni vanno inserite nella variabile POSTGREY_OPTS, separate da uno spazio.

2) whitelist_clients

Contiene una lista dei domini da cui greylist non bloccherà la posta.

3) whitelist_recipients 

Contiene una lista di destinatari verso cui non bloccare la posta (ad esempio il postmaster oppure abuse). Normalmente non richiede modifiche.

Conclusione

Sebbene questo sistema sia veramente molto semplice, è in grado di bloccare una buona quantità di spam.

Inoltre, cosa da tenere molto in considerazione, questo è un metodo che difficilmente genera dei falsi positivi (in quanto la risposta del server mail corrisponde ad un “ripassa più tardi”) e non aumenta di molto il carico del sistema.

 

Proxmox Virtual Environment

 

 

logo_proxmoxProxmox VE è un software open source, ottimizzato per le prestazioni e l’usabilità a cui viene aggiunta´ anche la massima flessibilità, grazie alla possibilita` di utilizzo di ben due tecnologie di virtualizzazione – KVM (per la Full Virtualization) e OpenVZ (per la Paravirtualization).

Proxmox VE si basa su Debian 5 e non necessita di particolari prerequisiti software. Dal punto di vista hardware richiede i 64 Bit e c’è una ampia lista di hardware ufficialmente supportato.

Con Proxmox VE possiamo migrare phisical machine (PM) su virtual machine (VM) oppure VM su altre VM, possiamo inoltre aggiungere degli storage e gestire il backup delle macchine virtuali. Il Cluster di Proxmox VE ci permette anche di migrare VM tra nodi e di amministrare da un’unica console centrale i vari nodi e, le VM distribuite nei vari nodi.

New Virtual Environment 3.3

Il 15 Settembre 2014 Proxmox Server Solutions ha annunciato l’uscita  della versione 3.3 di Proxmox Virtual Environment (VE).
Questa versione e` molto interessante poiche’ aggiunge diverse novita’ , in particolare questa versione ha come focus la sicurezza dell’infrastruttura virtuale, e introduce tra le altre cose il Proxmox Ve Firewall e la doppia autenticazione (two-factor authentication).
E’ stata  implementata inoltre una console in HTML5, un plug-in per lo storage ZFS e un’interfaccia ottimizzata per l’utilizzo con il mobile, ovvero la Mobile touch interface.

Ma vediamo nel dettaglio in cosa consistono le principali novità:

Proxmox VE Firewall
E’ stato progettato per proteggere l’ infrastruttura IT, ed è completamente integrato nell’interfaccia web, permettendo cosi’ all’utente di creare regole per gli host, i cluster e le singole macchine virtuali e containers.  Per semplificare la gestione sono state introdotte macro, security groups, settaggi per IP e aliases.
La configurazione del firewall viene salvata a livello di cluster e le regole sono valide e applicate per tutti i nodi che compongono il cluster, permettendo l’isolamento completo  delle singole macchine virtuali.
Questo fa si che, al contrario delle soluzioni firewall centralizzate, Proxmox VE Firewall è un po’ piu’ dispendioso in termini di banda ma evita allo stesso tempo i single point of failure.

Two-factor authentication
Questa nuova feature aggiunge un’ ulteriore livello di sicurezza, introducendo una seconda fase di autenticazione per l’accesso all’interfaccia web amministrativa di Proxmox VE.
In aggiunta all’ inserimento del classico nome utente / password, viene utilizzata una one-time password (OTP) che sarà richiesta per ogni nuova sessione di login. Una volta generata rimarrà valida per 30 min (valore di default, modificabile a piacimento).

HTML5 Console 
E’ la nuova console di default di Proxmox VE, multi piattaforma (Windows/Linux/Osx), utilizzabile anche su piattaforme mobile e, sostituisce l’installazione del plug-in Java e dello Spice viewer.

Proxmox VE mobile
E’ una interfaccia touch progettata specificamente per l’uso su dispositivi mobili (cellulari e tablet). E ‘ un app realizzata in HTML5 (sviluppato con Sencha touch) e funziona su qualsiasi cellulare con un browser moderno.
Comprende molte funzionalità necessarie all’amministratore per la gestione da remoto dell’infrastruttura virtuale, compresa la console SPICE (Software per la gestione della connessione alla console della macchina virtuale), ma non è sostitutiva della full admin console stessa.
Proxmox VE Mobile supporta anche la two-factor authentication con Yubykey con protocollo NFC.
Nota : per tutti coloro che fossero gia in possesso della versione 3.2 l’upgrade alla 3.3 si effettua con due semplici comandi :
NB : ( prima di aggiornare un host spegnere o migare tutte le vm/containers)

~root # apt-get update
~root # apt-get dist-upgrade

 

Se l’articolo ha stuzzicato la vostra curiosita’ e volete saperne ancora di piu’ potete visionare questo Video che illustra tutte le novita’ di cui sopra:

Proxmox VE Video