Archivi categoria: SysAdmin

Proteggiti da attacchi DoS e DDoS

APF-Firewall Server Protection

APF-Firewall Server Protection

Proteggere il server dagli attacchi DoS e DDoS 

Un attacco DoS (Denial of Service), ha come scopo il rendere inutilizzabile un determinato servizio sul web, inondandolo di richieste fittizie, quindi qualsiasi servizio esposto su internet che fornisce servizi di rete basati sul protocollo TCP/IP e soggetto al potenziale rischio di attacchi DoS. La differenza tra DoS e DDoS (Distributed Denial of Service) sta nel numero di macchine (PC, server, cellulari, in generale, qualsiasi dispositivo connesso ad internet che sia stato compromesso) utilizzate per lanciare l’attacco. Nel caso di un DoS l’attacco avviene da una sola macchina, mentre (nel ben piu difficile caso da bloccare) nel DDoS l’attacco puo avvenire contemporaneamente da centinaia di macchine diverse.

Come potrete quindi immaginare tutti i consigli contenuti in questo articolo non vi assicureranno una protezione totale contro i DDoS, perché quando sono ben organizzati e l’attacco arriva da un grande numero di macchine diverse, l’unico modo per cercare di bloccarlo o più realisticamente, mitigarlo, è agire a monte, direttamente sull’infrastruttura del vostro provider (che quindi dovrete contattare), a meno che non abbiate una vostra infrastruttura di rete.

Come riconoscere un attacco ?

Questa è sicuramente la prima cosa da imparare, ossia imparare a riconoscere un attacco DoS, perche’ tante volte si corre il rischio di pensare ad un attacco di questo tipo appena i servizi ospitati sul server risultano irraggiungibili, quando invece le cose più probabili sono ben altre.
Innanzitutto se siete sotto attacco vedrete sicuramente un picco (che può variare da pochi a diversi mbit/s) nei vostri grafici della banda utilizzata, ed un picco nelle connessioni netstat, anche per questo sarebbe bene generare dei grafici di tutto rispetto magari tramite Munin (di cui parleremo nel prossimo articolo) o con Vnstat, i servizi più importanti sul vostro server.

Una volta accertato che ci sono effettivamente picchi anomali nell’utilizzo della banda, usate questo comando per visualizzare lo stato di tutte le connessioni attive sul vostro server:

netstat -nat | awk ‘{print $6}’ | sort | uniq -c | sort –n

L’output sarà qualcosa del genere:

1 CLOSING

1 established

1 Foreign

7 LAST_ACK

25 FIN_WAIT1

26 LISTEN

69 FIN_WAIT2

484 TIME_WAIT

542 ESTABLISHED

Se notate che ci sono diverse connessioni in stato SYS_SENT siete sicuramente sotto attacco, a questo punto non resta altro da fare che individuare l’IP o gli IP dai quali arrivano più connessioni, potete farlo con questo comando:

netstat -atun | awk ‘{print $5}’ | cut -d: -f1 | sed -e ‘/^$/d’ |sort | uniq -c | sort –n

A questo punto avrete una lista ordinata per numero di connessioni aperte da ogni IP, ed alla fine, molto probabilmente, avrete gli IP delle macchine dalle quali vi stanno attaccando, ora non resta che bloccare questi IP.
Una utility molto utile per analizzare il traffico di rete e vederlo in tempo reale è tcptrack, una volta installata usate i seguenti comandi per avviare il monitoring:

tcptrack -i eth0 vi mostrerà tutto il traffico attivo sulla scheda di rete

tcptrack -i eth0 port 80 vi mostrerà tutto il traffico sulla porta 80

Es:

tcptrack -i eth0 src or dst 192.168.2.138

vi mostrerà tutto il traffico generato dall’ip specificato. In più tcptrack vi mosterà in tempo reale l’utilizzo della banda.

Bloccare un attacco

Ora che sappiamo individuare un attacco e capire da quali IP sta arrivando possiamo cercare di bloccarlo, vediamo come.
Premesso che la cosa migliore sarebbe comunicare gli IP degli attaccanti al vostro provider così che possano essere bloccati a monte e che non possano quindi influire neanche minimamente sulla vostra banda disponibile, esistono principalmente due metodi per bloccare questi IP sul vostro server: bloccarli con iptables, oppure metterli in nullroute (che è, secondo me, preferibile).

Per bloccare questi IP da itptables potete usare questo semplice comando:

iptables -A INPUT -s IP-ATTACCANTE -j DROP

Invece, per mettere un IP in nullroute, dobbiamo lanciare questo comando:

route add IP-ATTACANTE gw 127.0.0.1 lo

Possiamo anche mettere in nullroute un’ intera subnet ad esempio così:

route add -net 192.168.2.0/24 gw 127.0.0.1 lo

Verifichiamo quindi che i settaggi siano stati effettivamente applicati con

netstat -nr

Per rimuovere il nullroute possiamo utilizzare il comando route delete IP

Per far sì che i nullroute impostati vengano mantenuti al reboot dovrete scrivere gli stessi comandi di prima nel file /etc/rc.local


Come prevenire gli attacchi

Fin’ora abbiamo visto come comportarci una volta sotto attacco, ora vediamo cosa possiamo fare per evitare di trovarci coi servizi down e doverli ripristinare.
Per prima cosa consiglio di installare APF (Advanced Policy Firewall), un firewall basato su iptables che bloccherà autonomamente molti degli attacchi conosciuti, confrontandone i pattern, in più, grazie alla sua semplice e versatile configurazione diventa un’ottimo sostituto di iptables che spesso risulta abbastanza macchinoso da mantenere.

Potete installare APF usando un packet manager tipo apt o yum, oppure compilando l’ultima versione :

Scaricate l’ultima versione stabile:

wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

Scompattate il file appena scaricato: tar -xvzf apf-current.tar.gz

Entrate nella directory creata ed eseguite ./install.sh

A questo punto APF va configurato a dovere e, per farlo, bastera’ editare il file /etc/apf/conf.apf .

Per prima cosa bisognera’ settare il parametro DEVEL_MODE a 1, così se sbagliate qualche settaggio e vi chiudete fuori dal server, dopo 5 minuti il firewall verrà automaticamente stoppato.

Questo parametro indica se apf è in modalità sviluppo (e quindi non applica le regole) o in modalità produzione e quindi rende effettive le regole del firewall, prima di impostarlo a 0 per renderlo attivo modifichiamo il resto delle regole altrimenti rischiamo di chiuderci fuori dal server

Impostiamo le porte in ascolto modificando il paramentro IG_TCP_CPORTS

# Common inbound (ingress) TCP ports
IG_TCP_CPORTS="22,21,20,80,25,53,110,143,443,2222,587,953,993,995,4949"

io utilizzo queste impostazioni che sono per i servizi ssh,ftp,web,mail (pop/imap/smtp), directadmin e munin

e queste sono le impostazioni per le porte in uscita
# Common outbound (egress) TCP ports
EG_TCP_CPORTS="21,25,80,443,43"

e poi più sotto impostiamo a “1″ le seguenti variabili che ci permettono di scaricare delle liste di ip conosciuti come malevoli in modo da filtrare a priori il loro traffico

DLIST_PHP="1"
DLIST_SPAMHAUS="1"
DLIST_DSHIELD="1"
DLIST_RESERVED="1"

Ricordatevi di rimettere su 0 questo parametro una volta terminata la configurazione, altrimenti il firewall funzionerà solo per 5 minuti ad ogni riavvio.

Settate su 1 tutti i parametri che abilitano le liste di network malefici dai quali le connessioni saranno rifiutate (DLIST_*).

Settate manualmente le porte TCP che devono rimanere aperte nella variabile IG_TCP_CPORTS (ad esempio la 80 per il traffico web, se avete modificato la porta di ssh come avreste dovuto fare ricordatevi di settarla qua, altrimenti vi chiuderete fuori dal server), tutte le altre risulteranno chiuse.

Stessa cosa per le porte UDP subito sotto, se ne fate uso.

Impostando il parametro SYSCTL_SYNCOOKIES su 1, vi proteggerà dagli attacchi di tipo syn flood.

salviamo ed avviamo apf con

apf -s

#Proteggiti#AttacchiDoSeDDoS

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

DevOps: la metodologia che unisce IT e Business

DevOps

DevOps

DevOps (da development + operations) è una metodologia di sviluppo del software che punta alla comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle attivita’ di gestione dell’information technology (IT). DevOps vuole rispondere all’interdipendenza tra sviluppo software e IT operations, e punta ad aiutare le aziende a sviluppare in modo più rapido ed efficiente i loro prodotti e servizi software.

La complessità delle strutture e infrastrutture It ha alimentato negli ultimi anni conflitti inter-organizzativi impoverendo l’It service delivery. Situazione che non risulta però più sostenibile rispetto al contesto economico in cui operano le aziende ‘servite’ dall’It in cerca di maggior flessibilità, dinamicità e velocità di risposta, senza però perdere in qualità e sicurezza. Ecco perché sta crescendo ed evolvendo la metodologia DevOps che mira a migliorare l’It service management.

Le aziende che tipicamente potrebbero avere maggiori benefici da un orientamento DevOps sono quelle con rilasci di software frequenti. Flickr, ad esempio, ha utilizzato la metodologia DevOps per supportare la necessità di dieci rilasci al giornalieri; ma tali cicli di rilasci potrebbero essere anche più frequenti in aziende che producono applicazioni multi-focus o multi-funzione, spesso indicati come deployment continuo, e associato spesso alla metodologia Lean Startup.

La metodologia DevOps aiuta dunque le aziende nella gestione dei rilasci, standardizzando gli ambienti di sviluppo. Le aziende con problemi di automazione dei rilasci solitamente hanno già un processo automatico in essere ma lo vorrebbero più flessibile e controllabile, senza per questo dover agire da riga di comando per ottenere ciò. Idealmente tale automazione potrebbe essere utilizzata anche da risorse non operative (non appartenenti all’IT Operations) su ambienti non di produzione. In questo modo gli sviluppatori avrebbero a disposizione un maggiore controllo degli ambienti, dando all’infrastruttura una visione più incentrata sull’applicazione.

L’integrazione DevOps ha come obiettivo il rilascio del prodotto, il collaudo del software, l’evoluzione e il mantenimento (bug fixing e “minor release”) in modo tale da aumentare affidabilità e sicurezza e rendere più veloci i cicli di sviluppo e rilascio. Molte delle idee che costituiscono DevOps provengono dalla gestione di sistemi aziendali e dalla “Metodologia Agile“.

Il termine “devops” è stato coniato da Patrick Debois e reso popolare attraverso una serie di “DevOps Days” iniziati nel 2009 in Belgio. Da allora si sono svolte conferenze “DevOps Days” in India, USA, Brasile, Australia, Germania e Svezia.

Le metodologie di sviluppo (ad esempio la Metodologia Agile) che vengono attuate nelle organizzazioni tradizionali mediante distinte divisioni tra IT operations e QA da un lato, sviluppo e rilascio dall’altro, sono prive di una profonda integrazione interdipartimentale. DevOps promuove invece un’ insieme di processi e metodi indirizzati alla comunicazione e collaborazione tra le divisioni.

L’adozione della metodologia DevOps è guidata da diversi fattori, come:

  • Utilizzo della metodologia agile e altre metodologie di sviluppo del software
  • Necessità di incrementare la frequenza dei rilasci in produzione
  • Ampia disponibilità di un’infrastruttura virtualizzata e in cloud
  • Incremento nell’uso di data center automatizzati e strumenti di configuration management

La metodologia DevOps è cosi’ descrivibile come “una relazione più collaborativa e produttiva tra i gruppi di sviluppo e quelli di operation”. Ciò incrementa l’efficienza e riduce i rischi di frequenti modifiche in produzione.

Invece, in molte organizzazioni, lo sviluppo del software e la gestione dei sistemi sono in divisioni differenti e poiché lo sviluppo è generalmente guidato dalle necessità dell’utente, per continue modifiche e conseguenti rilasci, i gruppi operativi invece sono concentrati sulla disponibilità e affidabilità dei servizi, nonché sulla gestione dei costi. Ciò produce un “gap” tra sviluppo e gestione dei servizi che rallenta il passaggio in produzione.

Impatto sui rilasci applicativi
In molte aziende i rilasci applicativi sono eventi ad alto impatto e rischio, coinvolgendo più gruppi di lavoro. Con la metodologia DevOps tale rischio si riduce per i seguenti motivi:

  • Numero ridotto di modifiche : L’adozione del modello agile o modello incrementale, in contrasto con il tradizionale modello a cascata, comporta minori modifiche, anche se più frequenti, con minore impatto e rischio.
  • Accresciuto coordinamento dei rilasci : La presenza di una coordinazione del rilascio riduce le distanze tra sviluppo e gestione.
  • Automazione : Una completa automazione assicura la facile ripetibilità dei rilasci e riduce gli errori nell’operazione.

I processi chiave che caratterizzano le metodologie DevOps sono quindi:

Cloud e Virtualizzazione: la necessità di avere a disposizione servizi e strumenti che offrono una modalità veloce di verifica e gestione della complessità di un’applicazione. Esempi di tali strumenti sono le API di cloud provisioning quali Amazon EC2, o servizi SaaS quali New Relic e Loggly, che offrono capacità operazionali cloud, oppure strumenti di gestione della configurazione quali Chef, Puppet e Ansible.

Continuous Delivery (letteralmente consegna continua): significa miglioramento continuo, significa testing ad ogni modifica, significa costruire molti prototipi, e non andare avanti finché non si abbia la certezza che ciò che abbiamo finora sviluppato è stato verificato a livello di qualità e compatibilità, se non addirittura di user testing. Le attività prettamente ingegneristiche coinvolte per assicurare uno sviluppo caratterizzato da continuous delivery sono: controllo codice sorgente, versioning configuration, integrazione continua, testing di unità e testing integrato e deployment automatizzato.

Considerazione finale
Dietro questa cura maniacale dell’organizzazione e della fase di testing c’è l’idea che sia meglio affrontare nella realizzazione di un prodotto tanti piccoli cambiamenti continui causati dal dialogo tra sviluppatori e sistemisti, che non dover validare un’intera applicazione solo alla fine di un’intero ciclo di sviluppo, o peggio ancora offrire al cliente un prodotto di cui non abbiamo la minima certezza su bug e qualità del funzionamento. Quest’ultima pratica deleteria porta poi a sostenere costi di supporto al cliente e di assistenza che in passato hanno costituito la causa maggiore del collasso di aziende e business IT.

#Devops#MetodologiaAgile

Rsync e la sincronizzazione dei contenuti Web

rsync aggiornamento web

Rsync aggiornamento Web

Supponiamo che ci tocchi gestire in produzione un numero X di frontend Web dietro un bilanciatore e che quindi, ad ogni nuova release, si renda necessario caricare i contenuti su ciascuno di essi (rendendo la vita difficile agli sviluppatori).

Certo il mercato e’ ricco di software di Configuration Manager, ma in questo caso ho deciso di usare come esempio l’automazione mediante l’uso di rsync, del resto non serve una Ferrari per fare la spesa. In pratica, i contenuti Web verranno caricati manualmente su un’unico frontend (che servirà da server) mentre le altre macchine fungeranno da client (ovvero aggiorneranno i loro contenuti ogni X minuti consultando direttamente la macchina server).

Configurazione della macchina server

Tale attività si articola in due fasi: la prima consiste nell’installazione e nella corretta configurazione del demone xinetd (evoluzione del celebre inetd), mentre la seconda riguarda solo ed esclusivamente rsync.

Procediamo dunque con l’installazione di xinetd:

[root@server ~]# yum install xinetd

ed impostiamo l’avvio automatico del demone in questione per i diversi runlevel:

[root@server ~]# chkconfig --levels 2345 xinetd on

Posizioniamoci nella dir /etc/xinetd.d ed apriamo in scrittura il file rsync, sostituendo la direttiva:

disable = yes

con

disable = no

In definitiva, il suddetto file, dovrà avere il seguente contenuto:

service rsync
{
        disable = no
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID
}

Passiamo ora al secondo step relativo alla configurazione della macchina server, ovvero la creazione del file rsyncd.conf nella directory /etc:

[root@server ~]# touch /etc/rsyncd.conf

All’interno del suddetto file creeremo dei moduli ad-hoc contenenti tutte le direttive necessarie per la sincronizzazione dei contenuti tra server e client, ad esempio:

log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
[images]
   path = /var/www/html/images
   uid = root
   gid = root
   read only = no
   list = yes
   host allow = 10.11.12.0/24

Salviamo il file ed avviamo xinetd:

[root@server ~]# service xinetd start

Configurazione delle macchine client

Tale configurazione consiste esclusivamente nella creazione di una entry crontab del tipo:

*/1 * * * *  root rsync -agruv root@10.11.12.1::images /var/www/html/images/

ovvero ogni minuto viene contattato il server (10.11.12.1, modulo images che punta a/var/www/html/images/) e viene sincronizzato il contenuto della Dir del client /var/www/html/images/.

Bene, l’aggiornamento e’ servito!

#RsyncSincronizzazione#AmbientiWeb

Crea la tua TV Online gratuitamente

La tua TV On Air con Google+

La tua TV On Air con Google+

Google+ e sei in diretta su Youtube

Molte persone non hanno ancora compreso completamente Google+ bollandolo come una copia di Facebook, e di cui non c’è alcun bisogno.
Google+ però non è soltanto un luogo online in cui condividere stati e link ma anche una potentissima applicazione per la videochat, completamente gratuita e senza limitazioni.

Questa nuova funzionalità resa disponibile su scala globale ( Denominata Hangout On Air , o videoritrovi in diretta)  potrà aprire una serie di opportunità e,  sempre di più, mettere nelle mani di chiunque gli strumenti che fino a qualche anno fa erano solo a disposizione degli “old media” , infatti sara’ possibile videochiamare i parenti tramite webcam e microfono ed anche creare videoconferenze di livello professionale, in cui più persone si vedono tra loro e comunicano insieme.

La grande novità è che, dal videoritrovo di Google+, è possibile trasmettere video in diretta pubblicamente visibili da tutto il mondo. Questo significa che la piattaforma diventa un modo per creare una vera e propria trasmissione tv online, dove chiunque, senza spendere un soldo e, solo munito di computer, webcam e microfono, può aprire un canale tv via web.

Ogni trasmissione pubblica, ed ogni videoritrovo in diretta, potra’ essere visto da tutti su Youtube, non solo dagli iscritti su Google+.

Il videoritrovo pubblico diventa quindi un canale online visibile dal vivo in diretta su Youtube, da tutti, come se fosse un normale video.

Ovviamente, essendo una novità non da poco in termini di risorse da utilizzare ed implementare, sarà resa disponibile a tutti pian piano, e magari non sarà immediatamente impeccabile: quindi, se per caso non la vedi ancora disponibile non preoccuparti, si tratta soltanto di avere un po’ di pazienza e poi potrai anche tu trasmettere i tuoi show in diretta.

Per trasmettere in diretta via internet ed essere visibile in streaming su Youtube bisogna essere maggiorenni, per potersi iscrivere, ed accedere cosi’ a Google+ , con un account Google o Gmail ed avviare un videoritrovo premendo il pulsante Evento.
Nella pagina di configurazione del videoritrovo bisognera’ impostare la visibilità pubblica, dargli un titolo, un orario e poi barrare la voce Hangouts/evento online all’interno delle OpzioniEvento/Avanzate.

Ovviamente bisognera’ anche effettuare l’accesso su Youtube (con lo stesso account Google) ed accettare i termini di utilizzo.
La prima volta, potrebbe venir richiesto di abilitare la verifica dell’account Google in due passaggi confermando il proprio numero di cellulare (cosa questa che consiglio a tutti coloro che usano Gmail o altri servizi Google per evitare furti e problemi di sicurezza).
La conferma del numero di cellulare permette anche di eliminare il limite dei video caricabili su Youtube consentendo quindi di trasmettere dal vivo senza intoppi.

Dopo l’accesso al videoritrovo pubblico, ancora non sarete online, e visibili da tutto il mondo, fino a che non avrete premuto il tasto di inizio trasmissione “Partecipa all’ Hangouts“.
Prima di trasmettere, si può sistemare l’inquadratura, l’aspetto e preparare la trasmissione tv condividendo il link per la visione sui social network, su Facebook, su Twitter o sul proprio blog, inoltre sono disponibili diverse app che aggiungono effetti od utility come fotoritocco e molto altro.

Il video diventa pubblicamente visibile, dal vivo, sul proprio canale Youtube, inoltre e’ possibile incorporare il video in una pagina web come si può fare per qualsiasi video Youtube, tramite la funzione Embed.

Quando la trasmissione sara’ iniziata, si potrà vedere quante persone stanno guardando in diretta l’evento o il videoritrovo e vedere i loro messaggi nella chat.
Inoltre, con un livello massimo di interattività, chi sta guardando può anche farsi vedere o ascoltare, come se si fosse in videoconferenza.
Quando finisce la diretta, quanto trasmesso potra’ essere registrato e ripubblicato su Youtube e su Google+ per una visione successiva.
Tutto questo è chiaramente spiegato nel video introduttivo ai Google + HangOuts on Air.

Per cercare, vedere e partecipare alle trasmissioni dal vivo, si deve andare nella sezione dei videoritrovi di Google+ (https://plus.google.com/s/is/hangouts).
Google+ diventa quindi uno dei siti per Creare online un canale Web-TV con streaming da webcam come i famosi Justin TV, UStream e LiveStreaming.

 

#GooglePlusLiveStreaming