Archivi tag: http

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

Come controllare la rete dalla shell Linux

Monitoring dal Terminale

Monitoring dal Terminale

PREMESSA

Purtroppo rispetto a molte altre nazioni nel mondo e, nella stessa Europa, ci troviamo ad avere ancora delle connessioni ad Internet che, nella maggior parte del paese, sono a dir poco scandalose.

In precedenti articoli abbiamo provato a mettere un po’ di pepe al nostro pc lavorando sulla gestione della RAM oppure sulla modifica dei parametri del kernel tramite Sysctl, oppure accellerando la risoluzione degli indirizzi DNS tramite la creazione di un meccanismo di Cache usando, ad esempio, PDNSD.

Oggi vedremo come colmare quella parte di “monitoring” sulla velocita’ della nostra rete, presentando questo elenco di utilissimi tool, da riga di comando, che vi permetteranno di avere il polso della situazione in tempo reale. Troverete sicuramente quello che fa al caso vostro.

P.S. : I seguenti programmi sono tutti disponibili nei repository principali di Ubuntu, quindi per installarli bastera’ scrivere :

apt-get install nome del programma

NETWORK TOOL

IPTState : un’interfaccia simile a Top collegata alla vostra tabella connection-tracking di netfilter.
Utilizzando iptstate si può verificare in modo interattivo il traffico che attraversa il tuo firewall netfilter/iptables , ordinato per vari criteri, è possibile limitare la visualizzazione con vari criteri, ed e’ possibile cancellare gli stati dalla tabella.

Pktstat : visualizza un elenco in tempo reale delle connessioni attive viste su una interfaccia di rete, e quanta banda viene utilizzata. Parzialmente decodifica i protocolli HTTP e FTP per mostrare il nome del file che viene trasferito. Anche i nomi delle applicazioni X11 sono mostrate.

NetHogs : diversamente da altri, invece che “spacchettare” il traffico verso il “basso” per protocollo o per sottorete, come la maggior parte degli strumenti fanno, mostra la banda utilizzata dai vari programmi. NetHogs non si basa su un modulo del kernel speciale da caricare. Se c’è ad un tratto molto traffico di rete, si può lanciare subito NetHogs e vedere immediatamente quale PID è la causa. Questo rende facile individuare i programmi che sono impazziti e stanno improvvisamente prendendo tutta la vostra banda di rete.

IPTraf : un programma (storico) che raccoglie statistiche di rete per Linux. Anch’esso raccoglie una serie di dati come i pacchetti delle connessioni TCP e conteggio dei byte, le statistiche sulle interfaccie e gli indicatori di attività, dati TCP/UDP sul traffico, e traffico per LAN.

Bmon : bmon è un monitor di banda, destinato per il debug ed il monitoraggio real-time, in grado di recuperare le statistiche da vari tipi d’ingresso. Fornisce metodi di uscita vari tra cui un’interfaccia basata su librerie curses. L’insieme dei moduli per l’input sono specifici per ogni tipologia di architettura e prevedono un nucleo comune con l’elenco delle interfacce e dei loro contatori.

Il nucleo memorizza questi contatori e fornisce una stima della velocità ed una storia degli ultimi 60 secondi, minuti, ore e giorni ai moduli di uscita che li mostrano in base alla configurazione, durante l’esecuzione, è possibile selezionare l’interfaccia da controllare e premere il tasto “g” per vedere un grafico attivo come questo:

Speedometer : si tratta di un interessante progetto che permette di visualizzare e misurare la velocità dei dati attraverso una rete o dei dati che vengono memorizzati in un file,

Come potrete vedere, anche se si tratta di un tool basato sulla riga di comando, ha dei bei colori vivaci e altre cose che lo rendono uno strumento piuttosto user-friendly, ha la capacità di monitorare la velocità in tempo reale di download/upload delle connessioni di rete e può essere utilizzato anche per misurare la velocità di scrittura in un file system.

Nload : nload è un’applicazione da console che controlla il traffico di rete e l’utilizzo della larghezza di banda in tempo reale. Esso visualizza il traffico in entrata ed in uscita utilizzando due grafici e fornisce informazioni aggiuntive come quantità totale di dati trasferiti e min/max di utilizzo della rete.

 

La cosa migliore e’ sicuramente quella di testarli tutti, magari su macchine virtuali, per poter meglio decidere quali fanno esattamente al caso vostro.

 

#ControllalaRetedallaShell

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!

Firehol il firewall flessibile

fireholSi parla spesso di come proteggere il proprio PC/Server e la parola che sicuramente ricorre piu’ spesso e’ FIREWALL, non c’e’ dubbio.

Il problema che salta all’occhio di chiunque si sia mai cimentato con la “scrittura” delle regole di IPtables e derivati, e’ la non immediata semplicita’ nel comprendere la giusta sintassi da utilizzare e dunque nel capire il corretto posizionamento delle tante/tantissime variabili che rendono questi strumenti ottimi nel tenere lontani la maggior parte dei malintenzionati .

Uno strumento che potra’ certamente darvi una mano e’ il tool FireHol.

FireHOL è un linguaggio per esprimere le regole del firewall, non semplicemente uno script che produce un qualche tipo di firewall.” I file di configurazione di FireHOL sono script shell (ma di fatto non lo sembrano poiche’ sono semplici che più semplici non si può).

FireHOL viene fornito con firehol-wizard, che crea un file di configurazione che è poi necessario modificare a mano.

Il suggerimento migliore che posso dare rimane quello di utilizzare sempre, soprattutto all’inizio, le macchine virtuali, per  riuscire a prendere dimestichezza con la nuova tecnologia.

Si tratta dunque di un particolare software che, tramite un “semplice” file di configurazione, permette di impostare velocemente le regole del firewall per proteggere l’accesso dalla LAN verso Internet e viceversa. Il file in questione si trova in /etc/firehol/firehol.conf, quindi apriamolo con sudo vim /etc/ firehol/firehol.conf, cancelliamone il contenuto pre esistente e scriviamo quanto segue:

Anche l’installazione e’ semplice come bere un bicchier d’acqua

sudo apt-get install firehol

Questo e’ un piccolo esempio utile per dare un’idea della metodologia di configurazione del file:

#Imposto la LAN eth0 scheda di rete verso internet

interface eth0 internet

# Di default non accettare nessun pacchetto

policy reject

protection strong

#Accetta solamente questi servizi

server ssh accept

server ping accept

server http accept

server https accept

server dns accept

client ping accept

client http accept

client https accept

#Imposto eth1 come rete interna lan

interface eth1 lan

#Accetta tutto il traffico nella LAN interna

policy accept

#Imposto le tabelle di routing

#Il traffico dalla LAN (eth1) reindirizzato verso eth0

router lan2internet inface eth1 outface eth0

# Regola per il masquerade

masquerade

#Accetta tutto il traffico

router all accept

#In ingresso, invece, fai il contrario...

router internet2lan inface eth0 outface eth1

** Le righe precedute dal simbolo # sono commenti che possono essere omessi, ma che possono essere sempre di grande aiuto nel rileggere vecchie configurazioni. Dopo aver inserito tutte le regole, salviamo e usciamo dall’editor.

A questo punto, bastera’ impostare il firewall in modo che si attivi automaticamente all’avvio del server. Apriamo dunque il file firehol con sudo vim /etc/default/firehol e cambiamo la riga START_FIREHOL=NO in START_FIREHOL=YES.

Infine, avviamo il firewall con il comando sudo /etc/init.d/firehol start. Il nostro lavoro è quasi finito, ma mancano ancora alcuni passi.

Buone configurazioni!

I2P (Invisible Internet Project)

I2P-Anonymous2I2P, originariamente chiamata Invisible Internet Project, è un software libero e Open Source per la realizzazione di una rete anonima. La rete offre un livello in cui le applicazioni possono scambiarsi dati, messaggi, navigare e quant’altro. Tutti i dati sono avvolti con diversi livelli di crittografia.

I2P è un livello di comunicazione anonimo peer-to-peer distribuito, progettato per eseguire qualsiasi servizio Internet tradizionale (ad esempio, Usenet, E-mail, IRC, file sharing, Web hosting e HTTP, Telnet ecc…), così come le più tradizionali applicazioni distribuite.

I2P è ancora in sviluppo beta, quindi non ancora ritenuto idoneo per gli usi che necessitano di un anonimato forte.

N.B. : ” nessuna rete può essere perfettamente anonima “.

Che cosa puoi fare con I2P

  • Email: interfaccia web integrata per la posta elettronica, plugin per la posta elettronica senza server.
  • Navigazione web: siti web anonimi, gateway verso e dallInternet pubblica.
  • Blog e forum: plugin per gestire blog e per Syndie.
  • Host di siti web: web server anonimo integrato.
  • Chat in tempo reale: messaggistica immediata e client IRC.
  • File sharing: client ED2K e Gnutella, client BitTorrent integrato.
  • Deposito file decentralizzato: plugin per il filesystem distribuito Tahoe-LAFS

Installiamolo su Ubuntu e Debian

Ubuntu:

  1. sudo apt-add-repository ppa:i2p-maintainers/i2p
  2. sudo apt-get update
  3. sudo apt-get install i2p

Debian:

  1. sudo nano /etc/apt/sources.list.d/i2p.list
  2. Debian Squeeze: 
    deb http://deb.i2p2.no/ squeeze main
    deb-src http://deb.i2p2.no/ squeeze main
  3. Debian Wheezy: 
    deb http://deb.i2p2.no/ stable main
    deb-src http://deb.i2p2.no/ stable main
  4. Debian Jessie e SID: 
    deb http://deb.i2p2.no/ unstable main
    deb-src http://deb.i2p2.no/ unstable main
  5. Aggiungete quindi le key di autenticazione con: 
    wget http://www.i2p2.de/_static/debian-repo.pub
    sudo apt-key add debian-repo.pub
  6. Installiamo 
    sudo apt-get update && sudo apt-get install i2p i2p-keyring

… per avviarlo lanciamo il comando

@root # ip2router console

se non ci saranno stati problemi si aprira’ una pagina web con il seguente URL : http://127.0.0.1:7657/home

Per studiare meglio tutte le funzionalita’ potete utilizzare il link ufficiale della documentazione

Buon divertimento !