Ansible – automazione IT e Configuration Management (II parte)

Ansible + Vagrant Environment

Ansible + Vagrant Environment

 

 

 

 

 

 

Nel primo articolo “Ansible per l’automazione IT ed il Configuration Management” abbiamo descritto le caratteristiche principali di questo interessante prodotto per il Configuration Management. In questo secondo articolo descriveremo con degli esempi come utilizzare nel concreto Ansible.

Per preparare il nostro ambiente di lavoro sfrutteremo un’altro software, che rappresenta, anch’esso una delle grandi novita’ del Web degli ultimi mesi come Vagrant, di cui abbiamo parlato nell’articolo “Virtualizzazione e provisioning senza sforzo“.

configuriamoci l’ambiente Vagrant:

$ vagrant box add pre http://files.vagrantup.com/precise32.box
$ vagrant init precise32
$ vagrant up

a seguito dell’ultimo comando, vedremo dei messaggi come questi:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
Guest Additions Version: 4.2.0
VirtualBox Version: 4.3
[default] Mounting shared folders...
[default] -- /vagrant

Vagrant ha quindi scaricato e creato per noi una macchina virtuale Ubuntu Precise (32bit). Scorrendo i messaggi ci sono due cose importanti da notare: la prima è che il traffico sulla porta 2222 del nostro pc locale sarà inoltrato alla porta 22 della macchina virtuale; la seconda è che l’utente “vagrant” sulla macchina remota può connettersi con la password “vagrant” ed ha già i privilegi per diventare root con sudo. Aggiorniamo quindi l’inventario delle macchine che decidete di coinvolgere modificando il file /etc/ansible/hosts

Dopo aver preso confidenza con Vagrant iniziamo la configurazione dell’ambiente per Ansible, iniziando ad usarlo per automatizzare i compiti di ogni giorno.

Configuriamo il file /etc/ansible/hosts tramite comando:

# sudo bash -c 'echo [web] >> /etc/ansible/hosts'
# sudo bash -c 'echo 127.0.0.1:2222 ansible_ssh_user=vagrant ansible_ssh_pass=vagrant >> /etc/ansible/hosts'

Verifichiamo che ansible sia in grado di leggere correttamente i parametri inseriti nel file hosts usando il seguente comando:

# ansible -m ping all
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}

Ansible facts
come possiamo essere sicuri che la macchina a cui ci stiamo connettendo sia quella giusta ? Diamo un’occhiata ai “facts”, ovvero a tutte le informazioni che Ansible raccoglie…

# ansible web -m setup | less

otteniamo cosi’ una serie di dati in formato JSON tra cui notiamo che il nostro nuovo server ha come hostname ‘localhost’.
A titolo didattico scriveremo un playbook per installare un webserver nginx sul nuovo server.

Ora apriamo un editor per iniziare a scrivere il nostro playbook che si chiamera’ nginx.yml :

--- PLAYBOOK ottimizzato su Centos Linux
- name: installa NGINX e avvia il servizio
   remote_user: root
   sudo: yes
   hosts: web
   tasks:
   - name: installazione Nginx
     apt: pkg=nginx state=installed update_cache=true
     notify:
     - start nginx
   handlers:
     - name: start nginx
     service: name=nginx state=started

Come possiamo notare nel playbook abbiamo editato una lista di task, uno per ogni “step” del nostro compito.
Se stiamo usando virtualbox come hypervisor, dobbiamo aggiungere una riga al file (bastera’ solo decommentarla) di configurazione di vagrant perché attivi il forwarding della porta 80 della guest sulla porta 8080 del nostro pc.

(vedi https://docs.vagrantup.com/v2/networking/forwarded_ports.html)

config.vm.network "forwarded_port", guest: 80, host: 8080

e dare il comando per ricaricare la virtual machine con la nuova configurazione:

vagrant reload
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 80 => 8080 (adapter 1)
[default] Booting VM...
[default] Machine booted and ready!

Ora possiamo lanciare il playbook

# ansible-playbook nginx.yml

PLAY [installa NGINX e avvia il servizio] *****************************

GATHERING FACTS ***************************************************************
ok: [127.0.0.1]

TASK: [installazione Nginx] ***************************************************
changed: [127.0.0.1]

NOTIFIED: [start nginx] *******************************************************
changed: [127.0.0.1]

PLAY RECAP ********************************************************************
127.0.0.1 : ok=3 changed=2 unreachable=0 failed=0

sulla macchina virtuale potrete visualizzare, dal syslog, quello che sta accadendo:

ansible-apt: Invoked with dpkg_options=force-confdef,force-confold upgrade=None force=False package=[‘nginx’] purge=False state=installed update_cache=True pkg=nginx default_release=None install_recommends=True deb=None cache_valid_time=None
Mar 19 15:59:33 precise32 ansible-service: Invoked with name=nginx pattern=None enabled=None state=started sleep=None arguments= runlevel=default

ora sulla macchina virtuale mi ritrovo con l’nginx attivo e rispondente all’indirizzo 127.0.0.1:8080

Welcome to nginx!

Come gia accennato nel primo articolo la curva di apprendimento di questo ottimo strumento di Management dei server e’ davvero bassa e funzionale, ed in poco tempo si e’ in grado di gestire un ambiente ad alto volume di macchine.

Questa è solo una semplice introduzione al mondo di Ansible, e prima di concludere vi faccio inoltre presente che Ansible non è solo usufruibile da linea di comando ma presso il sito ufficiale è disponibile una web dashboard che permette di controllare i job, avere report, statistiche e così via.

Esiste anche Ansible Galaxy , che è invece un repository comunitario di “ricette”, playbooks, task moduli e tutto quello che si può immaginare … Quindi se doveste installare e configurare software come tomcat, oracle, mongodb, jenkins, drupal, rabbitmq e tanti altri, troverete già tutto pronto.
Di sicuro una base di partenza molto comoda per le vostre personalizzazioni!

Se tutto ciò non bastasse ancora, Ansible ha una API estremamente chiara e flessibile per scrivere moduli custom in Python o qualsiasi altro linguaggio, un esempio concreto

#AnsibleConfigurationManagement

HAPROXY – ed il bilanciamento di carico e’ servito

HAProxy Load Balancing

HAProxy Load Balancing

Bilanciamento, chi è costui?
Quando pensiamo a come implementare un servizio web, solitamente lo immaginiamo erogato da potenti server che, all’occorenza, sono in grado di scalare in automatico in modo da garantirne la continuità.
Ma con i nuovi servizi cloud ad alta frequentazione, la mole di accessi che deve essere trattata sara’ talmente elevata da mettere in crisi qualunque configurazione.

Come evitare una situazione del genere? Utilizzare ulteriore hardware, più potente, potrebbe non essere sufficiente, inoltre gestire una configurazione composta da sempre più server richiede l’introduzione di un “oggetto” capace di distribuire le connessioni su tutte le macchine installate.

L’oggetto a cui facciamo riferimento è un Load Balancer (bilanciatore di carico), capace di distribuire tutte le connessioni entranti tra i vari server assegnati alla funzionalita’ del nostro servizio.
Così facendo sara’ possibile:

  • migliorare l’alta affidabilità del servizio, perchè le richieste verranno sempre e solo, indirizzate ai server “attivi”;
  • migliorare la disponibilità del servizio, perchè le richieste verranno inviate ai server meno “carichi” in quel momento.

La soluzione: HAPROXY
Esistono molte soluzioni commerciali in tema di Load Balancing, ma può essere più interessante, sfruttabile, performante e conveniente, ricorrere a prodotti Open Source e, tra questi, c’è HAPROXY.
HAPROXY (http://www.haproxy.org/) è un bilanciatore in grado di gestire sia connessioni HTTP/HTTPS che connessioni di tipo TCP.

Utilizzo
Per prendere coscienza di quali siano le potenzialità di HAPROXY, proviamo a fare due esempi d’impiego delle funzionalità di bilanciamento, una dedicata ad un servizio di puro HTTP, e l’altra dedicata a bilanciare un servizio esclusivamente TCP.
Per provare le funzionalità di HAPROXY ho realizzato un ambiente virtuale con vagrant costituito da tre macchine virtuali:

  • 1 macchina Gentoo (molto leggera e performante) utilizzata come bilanciatore (loadbalancer)
  • 2 macchine Ubuntu utilizzate come server da bilanciare (web1 e web2)

Installiamo HAPROXY  sulla macchina Gentoo, attraverso il comando:

emerge haproxy

Mentre sulle macchine Ubuntu procediamo con l’installazione di Apache utilizzando il comando:

apt-get install apache2

Tutte le macchine sono state collegate alla stessa rete: 192.168.0.0/24:

  • loadbalancer: configurato con l’indirizzo fisico 192.168.0.254, e con due alias, per i servizi bilanciati, 192.168.0.253 e 192.168.0.252.
  • web1: indirizzo 192.168.0.31.
  • web2: indirizzo 192.168.0.32.

Si ricorre all’uso degli alias di rete per poter pubblicare i due servizi di bilanciamento su indirizzi distinti; in alternativa sarebbe stato possibile pubblicare tutti i servizi di bilanciamento sullo stesso indirizzo fisico del server loadbalancer, perché, nel nostro caso, le porte di ascolto dei due servizi sono comunque differenti; ovviamente, se si vogliono bilanciare più servizi che ascoltano sulla stessa porta l’impiego degli alias è inevitabile.

La configurazione di un servizio di bilanciamento in HAPROXY, può essere realizzata definendo una sezione di “frontend” ed una di “backend”; la prima serve per definire il punto di accesso dei client (internet), mentre la seconda viene utilizzata per definire l’insieme dei server a cui inviare le connessioni da bilanciare.
In alternativa, è possibile configurare un’unica sezione, “listen”, in cui vengono racchiuse sia le direttive che verrebbero utilizzate per configurare le sezioni di “frontend” e di “backend”.

Esempi di impiego di HAPROXY
Il file di configurazione del servizio si trova in /etc/haproxy/haproxy.cfg.

La configurazione di Haproxy è stata impostata per includere una sezione in cui inserire i parametri che agiscono a livello globale (“global”), nel nostro caso viene configurato il log degli eventi.
Viene poi configurata una sezione in cui riportare tutte quelle impostazioni che costituiranno la base di ciascun servizio bilanciato (sezione “defaults”).

global
log /dev/log local0
log /dev/log local1 notice

defaults
timeout client 5000
timeout connect 5000
timeout server 5000

Nella sezione “defaults” sono quindi impostati i valori dei timeout:

  • i timeout di inattività lato client mentre si attende una risposta dal server (timeout client);
  • i timeout di attesa di attivazione di una connessione al server (timeout connect);
  • il timeout di inattività lato server (timeout server).

Tutti i valori di timeout sono stati impostati a 5000 millisecondi (5 secondi); ma possono essere adeguati in base alle proprie necessità.

Esempio 1: bilanciare il web
In questo primo esempio, HAPROXY viene utilizzato per bilanciare le richieste indirizzate a due server web, configurati per pubblicare una semplice pagina HTML (index2.html) che visualizza una serie di immagini (differenti tra i due server web, così da rendere evidente all’utente su quale server si è stati bilanciati).

frontend webfront
bind 192.168.0.253:80
default_backend webback
backend webback
balance roundrobin
server web1 192.168.0.31:80 check inter 5000 rise 2 fall 3 weight 10
server web2 192.168.0.32:80 check inter 5000 rise 2 fall 3 weight 10
mode http
log global
option httplog
option httpchk GET /index.html

All’interno della sezione “frontend” viene specificato l’indirizzo su cui si pone in ascolto il bilanciatore per il servizio specifico, e viene poi incluso il riferimento alla configurazione di “backend”, contenente informazioni sui server da bilanciare.

Nella parte “backend”, si può specificare quale metodologia di bilanciamento da utilizzare, quindi con quale criterio distribuire le richieste dei client, in questo caso il bilanciamento è di tipo “round robin”, cioè le richieste vengono inviate alternativamente ai due server bilanciati 50 & 50 % .
Con la direttiva “server” vengono specificati tutti i server che si vogliono bilanciare, identificando ciascuno con un nome (non necessariamente corrispondente all’hostname del server), l’indirizzo IP e la porta su cui ascolta il servizio (in questo esempio, la porta TCP/80 per il web server).
Per ogni server, vengono poi specificati i criteri da seguire per controllare se questo è attivo (a livello di servizio web) o meno, in modo da poterlo escludere a fronte di un problema.
Con l’opzione “check” viene specificata la frequenza con cui controllare il server (“inter”, impostata a 5000 millisecondi), dopo quanti check falliti il server deve essere escluso dal bilanciamento (“fall”), oppure dopo quanti check andati a buon fine (“rise”), invece, deve essere reinserito nel bilanciamento, ed il peso (“weight”) di ciascun server, in modo da poter distribuire il carico in maniera proporzionale tra le varie macchine, cosi da poter meglio bilanciare lo sforzo dei server nel caso che questi avessero hadrware con prestazioni differenti, infatti impostando un server con un peso maggiore rispetto alle altre macchine, questo riceverà un numero di richieste maggiore.

Se non si specificheranno particolari direttive, Haproxy verificera’ solo la disponibilità del servizio su ciascun server, controllando se la porta TCP specificata è in ascolto o meno.
Nel caso di web server bilanciati, è possibile definire dei controlli specifici sul protocollo HTTP interrogando direttamente la parte web, cosi che, a fronte di una risposta HTTP diversa dal codice 200 (OK) , il server verra’ escluso (“option httpchk”).

Con l’opzione httplog si attiva anche un livello di log per tutte le richieste HTTP che arrivano al bilanciatore per quel determinato servizio.
Particolare attenzione va riservata alle impostazioni di “rise” e “fall”, per cercare il giusto equilibrio che consenta di evitare che un server venga escluso, o reinserito troppo velocemente dal bilanciamento.

Esempio 2: bilanciare un servizio TCP
Oltre a bilanciare servizi HTTP, Haproxy può bilanciare praticamente qualsiasi tipo di connessione TCP; nel nostro test, sui due server attivati e’ stato configurato in ascolto, un servizio sulla porta TCP/2222.
In queso caso, HAPROXY è configurato per restare in ascolto su un indirizzo IP diverso da quello del servizio web dell’esempio precedente, e diverso dall’indirizzo fisico del bilanciatore.

frontend sshfront
bind 192.168.0.252:2222
default_backend sshbe
backend sshback
balance roundrobin
server ssh1 192.168.0.31:2222 check inter 5000 rise 2 fall 3 weight 10
server ssh2 192.168.0.32:2222 check inter 5000 rise 2 fall 3 weight 10

Troubleshooting
All’interno dei log generati da haproxy è possibile rilevare gli eventi in cui un server viene escluso, oppure incluso, nel bilanciamento.
Nel caso in cui il server (o il servizio) bilanciato non sia disponibile verrà registrato il seguente evento:

Feb 22 10:30:50 localhost haproxy[23679]: Server webbe/web2 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

Nel momento in cui il server/servizio torna disponibile nei log di Haproxy si troverà, invece, questo evento:

Feb 22 10:32:10 localhost haproxy[23679]: Server webbe/web2 is UP, reason: Layer7 check passed, code: 200, info: "OK", check duration: 0ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

Conclusioni
Haproxy offre la possibilità di risolvere problemi di eccessivo carico, ma anche di realizzare un meccanismo di alta affidabilità per diverse architetture di server, con questo approccio si semplifichera’ quindi la gestione dei sistemi e dei servizi.
Le funzionalità di Haproxy non si fermano solo agli esempi trattati precedentemente, ma permettono di creare servizi di bilanciamento capaci di lavorare dal livello 3 al livello 7 della pila ISO/OSI.
Vedremo in un secondo tempo di approfondire le varie funzionalità avanzate che Haproxy mette a disposizione.

 

#Haproxy#Bilanciatoredicarico

Ansible per l’automazione IT ed il Configuration Management

Ansible e l’automazione IT

Ansible e l’automazione IT

Ansible e’ un tool di Configuration Management ed IT Automation che sta riscuotendo un notevole successo tra gli addetti ai lavori in virtu’ della sua immediatezza, della sua semplicita’ di utilizzo e del superamento delle limitazioni della tipica configurazione basata su “server & agent”.

Che cos’e’ Ansible

Ansible quindi e’ un tool di Configuration Management ed IT Automation che rientra nella sfera degli strumenti tipici del metodo DevOps.

DevOps e’ un movimento nato per abbattere il muro di gomma che nel corso degli anni si e’ innalzato tra Developer e Sysadmin. Per usare un’analogia, DevOps e’ una cultura che ha lo scopo di creare una pipeline (in pratica un ponte di comunicazione) tra sviluppatori ed amministratori di sistema.

L’obiettivo e’ uno solo: aumentare costantemente la soddisfazione del cliente producendo ed erogando software allo stato dell’arte con continue release correttive.

Per raggiungere un obiettivo cosi’ ambizioso e’ importante poter contare non solo sulle persone ma anche sugli strumenti. Cosi’ sono nati tool agili ed intuitivi che hanno lo scopo di automatizzare lo sviluppo, il testing e la configurazione di server ed applicazioni. Questa famiglia di tool per il Configuration Management comprende gia diversi nomi blasonati come ad esempio Puppet, Chef, Saltstack e CFEngine.

Configuration Management in breve

Il Configuration Management e’ un processo utilizzato per definire la configurazione delle applicazioni web e dei server in modo consistente, possibilmente sotto controllo di versione. Con il Configuration Management e’ possibile definire a priori come dovra’ essere configurato il server X o l’applicazione Y. Il tutto in linguaggio sorgente o sotto forma di meta-linguaggio.

I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o piu’ server, in modo automatico e prevedibile.

Esempio:

inizio configurazione
1 assicurati che apache2 sia installato
2 assicurati che php5 sia installato
3 assicurati che mysql sia installato
fine configurazione

Un tool di Configuration Management puo’ leggere queste istruzioni ed applicarle su uno o piu’ server. In questo modo l’operatore puo’ replicare la stessa configurazione su decine di server oppure ricostruire la stessa in pochi secondi quando uno o piu’ server vengono messi fuori uso.

Ansible, un po’ di storia

Lanciato nel 2012, Ansible  nasce da un’idea di Michael de Haan, creatore tra l’altro di Cobbler. De Haan un bel giorno sente la necessita’ di scrivere un software che potesse semplificare all’ennesima potenza le attivita’ di Configuration Management ed Automazione IT.

Fino a quel momento il panorama del Configuration Management era dominato da Puppet e Chef (che comunque mantengono e sicuramente manterranno  anche in futuro quote di mercato molto vaste). Ma seppure ottimi, sia Puppet che Chef hanno alcuni punti deboli, che fanno storcere il naso ai Sysadmin piu’ esigenti:

* Puppet e Chef funzionano principalmente in modalita’ server – agent

* Chef richiede anche la conoscenza del linguaggio Ruby

Anche se non si tratta di limitazioni insormontabili ci sono comunque alcuni svantaggi in questo tipo di approccio.

Prima di tutto non sempre e’ possibile installare un agent sul server di destinazione, poiche’ un agent e’ comunque un piccolo software che rimane in esecuzione permanente su uno o piu’ server ed ha lo scopo di attendere comandi e configurazioni impartite dal server master.

Sia Chef che Puppet utilizzano questo approccio che spesso non e’ possibile mettere in pratica.

Pensiamo ad esempio ad ambienti server che per ragioni di conformita’ o sicurezza non possono ospitare agenti o software estranei oppure a quei server con un discreto numero di anni sulle spalle, dove l’installazione di una versione aggiornata di Ruby (richiesta, ad esempio, da Puppet) potrebbe causare effetti imprevedibili.

I vantaggi di Ansible

Perche’ dunque adottare Ansibile ?
Se sei un Sysadmin o un Developer potrai trarre sicuramente grande beneficio dall’uso di questo tool: con Ansible non e’ mai stato cosi’ semplice definire lo stato di un server e delle tue applicazioni web.
Con Ansible quindi il risparmio di tempo e di codice e’ notevole rispetto a Puppet o Chef.

Curva di apprendimento bassa

Dalla lettura della documentazione alla scrittura dei primi Playbooks il passo sara’ breve, ed in pochi minuti vi sara’ possibile iniziare a lavorare con Ansible senza dover penare con configurazioni di server Master e agenti vari.

Non sono richieste capacita’ di coding

Puppet e Chef nascono entrambi da un team di sviluppatori follemente innamorati di Ruby. Per la definizione dello stato dei server e delle configurazioni Puppet adotta un linguaggio simile al codice Ruby mentre per definire lo stato di un server con Chef e’ addirittura essenziale conoscere il linguaggio, invece Ansible supera completamente questa limitazione.

In Ansible ad esempio e’ possibile definire che il server X dovra’ contenere Apache con due righe:
es:

Install Httpd
yum: name=httpd state=latest

Come si puo’ notare, a differenza di Puppet, Chef e Saltstack, Ansible non ha bisogno di nessun agente per applicare le configurazioni su un server. Ansible utilizza di default il trasporto SSH: questo elimina la necessita’ di installare software estraneo sui nodi.

Modulare e Open Source

Ansible e’ composto da numerosi moduli. Per analogia i moduli di Ansible hanno la stessa funzione delle risorse in Puppet. Ogni modulo svolge delle funzioni ben precise e gestisce un singolo aspetto di ogni sistema. Questa architettura consente di espandere Ansible praticamente all’infinito, senza contare che i moduli possono essere scritti in qualsiasi linguaggio di programmazione. Inoltre Ansible e’ Open Source e la comunita’ continua a crescere rapidamente.

Ansible, i concetti chiave

Prima di terminare con questa introduzione su Ansible vediamo quali sono i concetti chiave ed i componenti che ruotano attorno a questo software.

Ansible: l’inventario

L’inventario e’ una lista di server sui quali Ansible applica, a comando, le configurazioni di sistema e le istruzioni di automazione. L’inventario di solito e’ contenuto all’interno del file /etc/ansible/hosts anche se e’ possibile specificare una posizione a piacere.

All’interno dell’inventario l’operatore puo’ specificare la lista dei server “bersaglio”. E’ chiaramente obbligatorio che ogni server abbia una corrispondenza DNS anche se e’ possibile specificare ogni server con il proprio indirizzo IP . Un esempio di inventario:

[webservers]
webserver1.example.com
webserver2.example.com

[dbservers]
dbserver1.example.com
dbserver2.example.com

Ansible ed i Tasks

In Ansible i Tasks sono dei “compiti” ovvero una serie di istruzioni che Ansible esegue in ordine di apparizione. Ogni istruzione contiene la definizione e/o la configurazione che dovra’ essere applicata ad ogni sistema.

Ansible e gli Handlers

Gli Handlers in Ansible sono delle istruzioni che vengono eseguite a seguito di una determinata azione. Ad esempio dopo aver installato httpd un operatore puo’ voler avviare Apache automaticamente. Un esempio di Handler che avvia Apache su CentOS:

name: start httpd
service  : name=httpd state=started enabled=yes

Gli Handlers si basano sul modulo service di Ansible (questo modulo viene utilizzato per gestire i servizi di sistema).

Ansible ed i Playbook

In Ansible i Playbook sono delle collezioni di Tasks. Ogni Playbook puo’ contenere un determinato numero di Tasks e di Handlers. I Playbook devono essere definiti in linguaggio YAML.


Ansible ed i Moduli

Ansible e’ composto da numerosi moduli. Esistono moduli per gestire i servizi di Cloud Computing (EC2 su AWS), Rackspace e Google Compute Engine, esistono moduli per installare pacchetti software su server Linux con apt e yum, moduli per gestire file di configurazione e database e molto altro ancora.

Per una lista completa dei moduli puoi consultare la documentazione ufficiale: Ansible Modules.

#AnsibleConfigurationManagement

Pydio piattaforma di FileSharing

Pydio FileSharing Platform

Pydio FileSharing Platform

Pydio è un sistema open che ci consente di trasformare qualsiasi server in una potente piattaforma di condivisione.

Pydio su Ubuntu
Negli ultimi anni i servizi di web storage sono spuntati come funghi, tutti quanti ci consentono di avere a disposizione uno spazio online nel quale salvare e condividere i nostri file preferiti. Per tutti coloro, privati e non, che sono alla ricerca di un servizio di condivisione file sicuro e flessibile sono disponibili OwnCloud oppure anche AjaXplorer Pydio.

Pydio ci consente di poter integrare in qualsiasi server una potente piattaforma di condivisione file dotata di numerose funzionalità; potremo accedere ai nostri file multimediali come immagini, video, documenti ecc da qualsiasi pc o device mobile direttamente da browser o tramite applicazione dedicata e, si potranno inoltre condividere facilmente i nostri file, creare pagine web ecc.

Pydio è una soluzione molto interessante, ad oggi, scelta da molte aziende in grado di offrire una piattaforma di condivisione file, flessibile, scalabile e soprattutto sicura con la possibilità di accedere e operare sui file attraverso vari protocolli (e’ possibile creare anche plugin dedicati ecc) sincronizzare i file in servizi di cloud storage e molto altro ancora.

Possiamo inoltre includere molti plugin di terze parti come ad esempio Pixlr  (oppure Dropbox e molti altri), per editare le immagini digitali, player per riprodurre video, file audio, editor di testi, reader di documenti ecc.

INSTALLARE PYDIO
Possiamo installare facilmente Pydio in Ubuntu / Debian e derivate (sia server che desktop) grazie ai repository dedicati, ecco come fare.

Per prima cosa aggiungiamo i repository Pydio digitando:

sudo vim /etc/apt/sources.list

ed ora aggiungiamo:

deb http://dl.ajaxplorer.info/repos/apt stable main
deb-src http://dl.ajaxplorer.info/repos/apt stable main

salviamo il tutto cliccando su ctrl + x e poi s
ora dovremo installare la key d’autenticazione digitando sempre da terminale:

wget -O - http://dl.ajaxplorer.info/repos/charles@ajaxplorer.info.gpg.key | sudo apt-key add -

adesso possiamo aggiornare i repository ed installare Pydio digitando:

sudo apt-get update
sudo apt-get install pydio

Al termine dell’installazione dovremo inserire la configurazione di Pydio in Apache, in nostro aiuto possiamo utilizzare il file di conf  fornito dall’installazione tramite il seguente comando:

<pre?sudo ln -s /usr/share/doc/pydio/apache2.sample.conf /etc/apache2/sites-enabled/pydio.conf sudo php5enmod mcrypt

non ci resta che riavviare apache digitando:

sudo /etc/init.d/apache restart

a questo punto potremo finalmente accedere a Pydio dal nostro browser accedendo all’indirizzo

http://127.0.0.1/pydio/index.php               ### dove 127.0.0.1 è l'indirizzo ip (localhost) del nostro server.

Da adesso in avanti ci bastera’ seguire le ottime indicazioni che ci verranno mostrate man mano a video per poter arrivare a completare l’intera installazione.

Al primo avvio avremo di fronte una semplice schermata di login, una volta eseguita potremo già caricare e gestire i nostri file.

#Pydiofilesharing

Creare facilmente applicazioni Web su Linux

Fogger Web Linux in un clicTra le tante features incluse in Google Chrome / Chromium, Gnome Web, Rekonq ecc troviamo la possibilità di creare facilmente un’applicazione web da qualsiasi scheda. Questa funzionalità ci consente non solo di avviare velocemente il nostro sito web preferito ma anche risparmiare risorse dato che non andremo a caricare interamente il browser. Funzionalità tanto richiesta ma attualmente non inclusa in Mozilla Firefox, un’alternativa arriva proprio dai developer Linux attraverso un semplice software.

Per creare facilmente un’applicazione web con Linux possiamo utilizzare Fogger, software open source che ci consente di creare facilmente un’applicazione web da qualsiasi sito, blog, forum ecc attraverso una semplice interfaccia grafica.
Fogger ci consente di creare un’applicazione web da avviare velocemente nel nostro menu, una volta avviata avremo una finestra con solo il nostro sito web, non è inclusa alcuna barra degli strumenti ecc possiamo comunque ricaricare, andare avanti o indietro attraverso il menu contestuale o il menu dell’applicazione. Tutto questo ci consentirà di velocizzare l’avvio di social network, forum e altri siti preferiti senza utilizzare alcun browser richiedendo meno cpu e memoria ram.

– INSTALLARE FOGGER
N.B.: Fogger è un software che non viene aggiornato da alcuni anni ma che funziona correttamente anche con le attuali distribuzioni Linux.

Per installare Fogger in Ubuntu e derivate basta scaricare il pacchetto deb da questa pagina (per Ubuntu 14.04 e versioni successive basta scaricare il pacchetto per la release 13.10).

Prerequisiti: prima d’installare il pacchetto appena scaricato, accertarsi di avere i seguenti pacchetti :
python-xlib & gir1.2-rsvg-2.0 altrimenti installarli con un semplice

# sudo apt-get install python-xlib gir1.2-rsvg-2.0

Una volta installato, basta avviare Fogger da menu, ci si aprirà una finestra di dialogo nella quale inserire l’url, nome e icona dell’applicazione web da creare per poi cliccare sul tasto Create. Al termine basta avviare l’applicazione web da menu, per rimuoverla basta cliccare da file manager Ctrl + h .