🥇IPFS senza dolore (ma non è sicuro)

Nonostante su Habr ci siano già diverse articoli su IPFS.

Voglio chiarire subito che non sono un esperto in questo campo, ma ho già manifestato interesse per questa tecnologia. Tuttavia, i tentativi di sperimentare con essa hanno spesso causato qualche difficoltà. Oggi ho deciso di riprendere gli esperimenti e ho ottenuto alcuni risultati di cui vorrei parlare. In breve, descriverò il processo di installazione di IPFS e alcune funzionalità (tutto eseguito su Ubuntu, non ho provato su altre piattaforme).

Se hai perso cosa sia IPFS, è descritto in dettaglio qui: habr.com/ru/post/314768

Installazione

Per la purezza dell'esperimento, propongo di installarlo su un server esterno, poiché analizzeremo alcune insidie relative al lavoro in modalità locale e remota. Poi, se desideri, sarà facile disinstallare, non richiede molto.

Installa Go

Documentazione ufficiale
Guarda l'ultima versione su golang.org/dl

Nota: è meglio installare IPFS con l'account utente che si prevede di utilizzare più frequentemente. Questo perché più avanti esamineremo l'opzione con il montaggio tramite FUSE e ci sono alcune peculiarità.

cd ~
curl -O https://dl.google.com/go/go1.12.9.linux-amd64.tar.gz
tar xvf go1.12.9.linux-amd64.tar.gz
sudo chown -R root:root ./go
sudo mv go /usr/local
rm go1.12.9.linux-amd64.tar.gz

Dopo è necessario aggiornare l'ambiente (maggiori dettagli qui: golang.org/doc/code.html#GOPATH).

echo 'export GOPATH=$HOME/work' >> ~/.bashrc
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrc

Verifichiamo che Go sia stato installato

go version

Installiamo IPFS

Mi è piaciuto di più il metodo di installazione tramite ipfs-update.

Lo installiamo con il comando

go get -v -u github.com/ipfs/ipfs-update

Dopo di che, puoi eseguire i seguenti comandi:

ipfs-update versions — per vedere tutte le versioni disponibili per il download.
ipfs-update version — per vedere la versione attualmente installata (finché non abbiamo installato IPFS, sarà none).
ipfs-update install latest — installare l'ultima versione di IPFS. Al posto di latest, puoi specificare qualsiasi versione desiderata dall'elenco delle versioni disponibili.

Installiamo ipfs

ipfs-update install latest

Controlliamo

ipfs --version

Per quanto riguarda l'installazione, è tutto.

Avvio di IPFS

Inizializzazione

Per iniziare, è necessario eseguire l'inizializzazione.

ipfs init

In risposta riceverai qualcosa di simile:

 ipfs init
initializing IPFS node at /home/USERNAME/.ipfs
generating 2048-bit RSA keypair...done
peer identity: QmeCWX1DD7HnXXXXXXXXXXXXXXXXXXXXXXXXxxx
to get started, enter:
	ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Puoi eseguire il comando consigliato

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Risultato

Ciao e benvenuto in IPFS!

██╗██████╗ ███████╗███████╗
██║██╔══██╗██╔════╝██╔════╝
██║██████╔╝█████╗  ███████╗
██║██╔═══╝ ██╔══╝  ╚════██║
██║██║     ██║     ███████║
╚═╝╚═╝     ╚═╝     ╚══════╝

Se stai vedendo questo, hai installato con successo
IPFS e ora stai interfacciandoti con l'ipfs merkledag!

 -------------------------------------------------------
| Attenzione:                                           |
|   Questo è un software alpha. Usalo a tuo rischio!   |
|   Molto è mancante o poco rifinito. Ci sono bug.     |
|   Non è ancora sicuro. Leggi le note di sicurezza per maggiori informazioni. |
 -------------------------------------------------------

Dai un'occhiata ad alcuni degli altri file in questa directory:

  ./about
  ./help
  ./quick-start     <--- esempi di utilizzo
  ./readme          <--- questo file
  ./security-notes

Qui inizia, a mio avviso, la parte interessante. I ragazzi già durante l'installazione cominciano a usare le loro stesse tecnologie. L'hash proposto QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — non è stato generato appositamente per te, ma è integrato nella release. Cioè, prima del rilascio, hanno preparato il testo di benvenuto, l'hanno caricato su IPFS e hanno aggiunto l'indirizzo all'installer. Secondo me, è davvero fantastico. E questo file (o meglio, l'intera cartella) ora può essere visualizzato non solo localmente, ma anche sul gateway ufficiale. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. In questo caso, si può essere certi che il contenuto della cartella non è cambiato, poiché se fosse cambiato, anche l'hash sarebbe cambiato.

A proposito, in questo caso IPFS ha alcune somiglianze con un server di controllo versione. Se si apportano modifiche ai file originali della cartella e si carica di nuovo la cartella in IPFS, essa riceverà un nuovo indirizzo. Tuttavia, la vecchia cartella non scomparirà e sarà disponibile al suo indirizzo precedente.

Avvio del daemon

ipfs daemon

Si dovrebbe ricevere una risposta di questo tipo:

ipfs daemon
Inizializzazione del daemon...
versione go-ipfs: 0.4.22-
versione repo: 7
versione sistema: amd64/linux
versione Golang: go1.12.7
Swarm in ascolto su /ip4/x.x.x.x/tcp/4001
Swarm in ascolto su /ip4/127.0.0.1/tcp/4001
Swarm in ascolto su /ip6/::1/tcp/4001
Swarm in ascolto su /p2p-circuit
Swarm annuncia /ip4/127.0.0.1/tcp/4001
Swarm annuncia /ip6/::1/tcp/4001
Server API in ascolto su /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Server Gateway (solo lettura) in ascolto su /ip4/127.0.0.1/tcp/8080
Daemon pronto

Apriamo le porte a Internet

Si prega di notare queste due righe:

WebUI: http://127.0.0.1:5001/webui
Server Gateway (solo lettura) in ascolto su /ip4/127.0.0.1/tcp/8080

Se avete installato IPFS localmente, accederete alle interfacce IPFS tramite indirizzi locali e avrete tutto a disposizione (ad esempio, localhost:5001/webui/). Ma quando si installa su un server esterno, per impostazione predefinita i gateway sono chiusi per Internet. Ci sono due gateway:

Pannello di amministrazione webui (github) sulla porta 5001.
API esterna sulla porta 8080 (sola lettura).

Per ora, per esperimenti, è possibile aprire entrambe le porte (5001 e 8080), ma sul server di produzione, naturalmente, la porta 5001 dovrebbe essere chiusa dal firewall. C'è anche la porta 4001, necessaria affinché altri peer possano trovarti. Questa deve rimanere aperta per le richieste esterne.

Apriamo per la modifica ~/.ipfs/config e troviamo queste righe:

"Addresses": {
  "Swarm": [
    "/ip4/0.0.0.0/tcp/4001",
    "/ip6/::/tcp/4001"
  ],
  "Announce": [],
  "NoAnnounce": [],
  "API": "/ip4/127.0.0.1/tcp/5001",
  "Gateway": "/ip4/127.0.0.1/tcp/8080"
}

Cambiamo 127.0.0.1 con l'IP del tuo server e salviamo il file, quindi riavviamo ipfs (fermiamo il comando in esecuzione con Ctrl+C e lo avviamo di nuovo).

Dovremmo ottenere

...
WebUI: http://ip_del_tuo_server:5001/webui
Gateway (sola lettura) server in ascolto su /ip4/ip_del_tuo_server/tcp/8080

Ora le interfacce esterne dovrebbero essere accessibili.

Controlla

http://dominio_o_ip_del_server:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Dovrebbe aprirsi il file README sopra riportato.

http://dominio_o_ip_del_server:5001/webui/

Dovrebbe aprirsi l'interfaccia web.

Se hai webui funzionante, puoi modificare le impostazioni di IPFS direttamente all'interno di esso, compresa la visualizzazione delle statistiche; però, di seguito esaminerò le opzioni di configurazione direttamente attraverso il file di configurazione, che in generale non è critico. È semplicemente meglio ricordare dove si trova il file di configurazione e cosa fare, altrimenti se l'interfaccia web non funziona, sarà più difficile.

Configuriamo l'interfaccia web per lavorare con il proprio server

Ecco il primo scoglio su cui sono stati spesi circa tre ore.

Se hai installato IPFS su un server esterno ma non l'hai installato o avviato localmente, quando accederai a /webui nell'interfaccia web dovresti vedere un errore di connessione:

Il punto è che, secondo me, il webui funziona in modo piuttosto ambiguo. Prima cerca di connettersi all'API del server dove è aperta l'interfaccia (ovviamente basandosi sull'indirizzo nel browser). Se non riesce, prova a connettersi al gateway locale. E se hai il IPFS avviato localmente, il webui funzionerà correttamente, ma lavorerai con il IPFS locale, non con quello esterno, anche se hai aperto il webui su un server esterno. Poi carichi i file, ma per qualche motivo non li vedi semplicemente sul server esterno…

Se non è avviato localmente, ricevi un errore di connessione. Nel nostro caso, l'errore è probabilmente dovuto a CORS, come indica anche il webui, suggerendo di aggiungere una configurazione.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_del_tuo_server:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Io ho semplicemente impostato un wildcard

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Tutti gli header aggiunti possono essere trovati nello stesso ~/.ipfs/config. Nel mio caso è

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },

Riavviamo ipfs e vediamo che webui si è connesso con successo (dovrebbe farlo, se hai aperto i gateway per le richieste esterne, come descritto sopra).

Ora puoi caricare direttamente cartelle e file tramite l'interfaccia web, oltre a creare le tue cartelle.

Montaggio del file system FUSE

Questo è un aspetto piuttosto interessante.

Possiamo aggiungere file (così come cartelle), non solo tramite l'interfaccia web, ma anche direttamente nel terminale, ad esempio

ipfs add test -r
aggiunto QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
aggiunto QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test

L'ultimo hash è l'hash della cartella radice.

Con questo hash possiamo aprire la cartella su qualsiasi nodo ipfs (che può trovare il nostro nodo e ottenere il contenuto), possiamo farlo nell'interfaccia web sulla porta 5001 o 8080, oppure localmente tramite ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Ma si può anche aprire come una cartella normale.

Creeremo due cartelle nella radice e concederemo i permessi al nostro utente.

sudo mkdir /ipfs /ipns
sudo chown USERNAME /ipfs /ipns

e riavvieremo ipfs con il flag —mount

ipfs daemon --mount

È possibile creare cartelle anche in altre posizioni e specificare il percorso tramite i parametri ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

La lettura da questa cartella è un po' insolita.

ls -la /ipfs
ls: lettura della directory '/ipfs': Operazione non consentita
totale 0

Questo significa che non c'è accesso diretto alla radice di questa cartella. Ma si può ottenere il contenuto conoscendo l'hash.

ls -la /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx
totale 0
-r--r--r-- 1 root root 10 31 Ago 07:03 test.txt

cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt
test
test

All'interno della cartella, l'autocompletamento funziona anche quando si specifica il percorso.

Come ho già detto, ci sono delle peculiarità con questo montaggio: per impostazione predefinita, le cartelle montate tramite FUSE sono accessibili solo all'utente attuale (anche root non potrà leggere da tale cartella, per non parlare di altri utenti nel sistema). Se vuoi rendere queste cartelle accessibili ad altri utenti, devi modificare 'FuseAllowOther': false in 'FuseAllowOther': true nel file di configurazione. Ma non è tutto. Se esegui IPFS come root, va tutto bene. Ma se come utente normale (anche se con sudo), otterrai un errore.

mount helper error: fusermount: l'opzione allow_other è consentita solo se 'user_allow_other' è impostato in /etc/fuse.conf

In tal caso, è necessario modificare /etc/fuse.conf, decommentando la riga #user_allow_other.

Dopo di ciò, riavviamo IPFS.

Problemi noti con FUSE

È stato notato frequentemente un problema: dopo il riavvio di ipfs con montaggio (o forse in altri casi), i punti di montaggio /ipfs e /ipns diventano inaccessibili. Non sono accessibili, e il comando ls -la /ipfs mostra ???? nella lista dei permessi.

Ho trovato questa soluzione:

fusermount -z -u /ipfs
fusermount -z -u /ipns

Dopo di che, riavviamo ipfs.

Aggiungiamo il servizio

Naturalmente, l'avvio nel terminale è valido solo per test iniziali. In un ambiente di produzione, il demone dovrebbe avviarsi automaticamente all'avvio del sistema.

A nome di root, creiamo il file /etc/systemd/system/ipfs.service e scriviamo al suo interno:

[Unit]
Description=IPFS Daemon
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/home/USERNAME/work/bin/ipfs daemon --mount
User=USERNAME
Restart=always

[Install]
WantedBy=multi-user.target

USERNAME deve ovviamente essere sostituito con il proprio utente (e potrebbe essere necessario che il percorso completo al programma ipfs sia diverso per voi (deve essere indicato il percorso completo)).

Attiviamo il servizio.

sudo systemctl enable ipfs.service

Avviamo il servizio.

sudo service ipfs start

Controlliamo lo stato del servizio.

sudo service ipfs status

Per la correttezza dell'esperimento, in futuro si potrà riavviare il server per verificare che ipfs parta automaticamente.

Aggiungiamo i peer che conosciamo

Consideriamo la situazione in cui abbiamo nodi IPFS installati sia su un server esterno sia localmente. Su un server esterno aggiungiamo un file e cerchiamo di ottenerlo tramite IPFS localmente usando il CID. Cosa succede? Certamente, il server locale probabilmente non sa nulla del nostro server esterno e cercherà semplicemente di trovare il file usando il CID «chiedendo» a tutti i peer IPFS disponibili (con cui è già riuscito a «conoscersi»). Questi a loro volta chiederanno ad altri. E così via, finché il file non verrà trovato. Fondamentalmente, lo stesso accade quando cerchiamo di ottenere un file tramite il gateway ufficiale. ipfs.io. Se tutto va bene, il file verrà trovato in pochi secondi. E se non viene trovato, non sarà reperito nemmeno dopo alcuni minuti, il che influisce molto sul comfort operativo. Ma noi sappiamo dove apparirà prima di tutto questo file. Allora perché non dire subito al nostro server locale «Cerca prima di tutto lì»? A quanto pare, è possibile farlo.

1. Accediamo al server remoto e nel file di configurazione ~/.ipfs/config cerchiamo

"Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuxxxxxxxxxxxxxxxx",

2. Eseguiamo sudo service ipfs status e cerchiamo le voci Swarm, ad esempio:

Swarm announcing /ip4/ip_vaostro_server/tcp/4001

3. Creiamo da questo un indirizzo generale del tipo «/ip4/ip_del_tuo_server/tcp/4001/ipfs/$PeerID».

4. Per una maggiore affidabilità, proveremo ad aggiungere questo indirizzo ai peer tramite la nostra webui locale.

5. Se va tutto bene, apriamo il file di configurazione locale ~/.ipfs/config, troviamo al suo interno «Bootstrap»: […
e aggiungiamo per primi nell'array l'indirizzo ottenuto.

Riavviamo IPFS.

Ora aggiungiamo un file su un server esterno e proviamo a richiederlo localmente. Dovrebbe arrivare rapidamente.

Ma questa funzionalità è ancora instabile. Per quanto ne so, anche se specifichiamo l'indirizzo del peer nel Bootstrap, durante il funzionamento ipfs modifica l'elenco delle connessioni attive con i peer. In ogni caso, si sta discutendo di questo e ci sono richieste riguardo alla possibilità di specificare peer fissi. qui E sembra che si suppone si possa aggiungere qualche funzionalità in ipfs@5.0+.

L'elenco dei peer attuali può essere visualizzato sia nella webui che nel terminale.

ipfs swarm peers

In entrambi i casi è possibile aggiungere manualmente il proprio peer.

ipfs swarm connect "/ip4/ip_del_tuo_server/tcp/4001/ipfs/$PeerID"

Fintanto che questa funzionalità non è migliorata, è possibile scrivere uno strumento che verifichi la connessione con il peer desiderato e, se non esiste, aggiunga la connessione.

Riflessioni

Tra coloro che conoscono già IPFS, ci sono argomentazioni sia a favore che contro. In linea di massima, ante ieri discussione mi ha spinto a esaminare nuovamente IPFS. E riguardo alla discussione menzionata: non posso dire di essere fortemente contrario a qualche argomento espresso (sono in disaccordo solo con l'affermazione che un paio di programmatori usino IPFS). In generale, entrambi hanno le loro ragioni (soprattutto il commento sui controlli fa riflette. Ma se si escludono le valutazioni morali e legali, chi può dare una valutazione tecnica di questa tecnologia? Personalmente, ho una sensazione interna che dico 'questo è decisamente necessario, ha delle prospettive'. Ma non ho una formulazione chiara sul perché. Se guardiamo già agli strumenti centralizzati esistenti, sono avanti sotto molti aspetti (stabilità operativa, velocità, gestibilità, ecc.). Tuttavia, ho un'idea che sembra sensata e che difficilmente può essere realizzata senza questi sistemi decentralizzati. Certo, sto puntando molto in alto, ma la formulerei così: bisogna cambiare il principio di diffusione delle informazioni su Internet.

Spiego. Se ci pensiamo, attualmente le informazioni si diffondono secondo il principio 'spero che chi le ha ricevute le protegga e che non vadano perse o siano ottenute da chi non dovrebbe averle'. Ad esempio, è facile considerare diversi servizi di posta, archiviazione cloud, ecc. E cosa otteniamo in definitiva? Su Habr... Sicurezza informatica occupano la posizione principale e quasi ogni giorno riceviamo notizie su un'altra grande fuga di dati. In sostanza, tutto il più interessante è elencato in una meravigliosa articolo. L'estate è quasi finita. I dati non persi sono quasi finitiCioè, i principali giganti di Internet stanno diventando sempre più grandi, accumulando sempre più informazioni, e simili fughe di dati rappresentano delle vere e proprie esplosioni atomiche informative. Non è mai successo prima, eppure eccoci di nuovo. Anche se molti comprendono che i rischi esistono, continueranno a fidarsi delle proprie informazioni a terzi. Prima di tutto, non ci sono alternative, e in secondo luogo, queste aziende promettono di aver riparato tutte le falle e che non accadrà mai più.

Qual è la mia visione del modello? Secondo me, i dati dovrebbero essere inizialmente distribuiti in modo aperto. Ma apertura, in questo caso, non significa che tutto debba essere facilmente leggibile. Parlo di trasparenza nella conservazione e nella distribuzione, non di totale accessibilità alla lettura. Ritengo che le informazioni debbano essere diffuse con chiavi aperte. Infatti, il principio delle chiavi aperte/chiuse è ormai obsoleto, praticamente quanto Internet. Se le informazioni non sono riservate e sono destinate a un pubblico ampio, vengono pubblicate immediatamente con una chiave aperta (ma comunque in forma crittografata, può essere decifrata da chiunque abbia la chiave). Se non è così, viene pubblicata senza la chiave aperta, e la chiave viene fornita a chi deve avere accesso a queste informazioni. In questo modo, chi deve leggerla deve avere solo la chiave, mentre da dove ottenere tali informazioni non dovrebbe preoccupare più di tanto — semplicemente le estrae dalla rete (è questo il nuovo principio di distribuzione basato sul contenuto e non sull'indirizzo).

Pertanto, per un attacco su larga scala, gli aggressori dovrebbero ottenere un'enorme quantità di chiavi private, e fare ciò in un singolo luogo risulterebbe difficile. Questa sfida, a mio avviso, è più complessa rispetto a quella di hackerare un servizio specifico.

Inoltre, si presenta un altro problema: la verifica dell'autenticità. Attualmente, si possono trovare in rete numerose citazioni scritte dai nostri amici. Ma come possiamo garantire che siano effettivamente loro a scriverle? Se ogni registrazione fosse accompagnata da una firma digitale, sarebbe molto più semplice. E non importa dove si trovi quell'informazione, ciò che conta è la firma, che di per sé è difficile da falsificare.

E ciò che è interessante qui è che IPFS porta già con sé strumenti di crittografia (dato che è costruito sulla tecnologia blockchain). Nella configurazione è già specificata la chiave privata.

  "Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuMxxxxxxxxxxxxxx",
    "PrivKey": "CAASqAkwggSkAgEAAoIBAQClZedVmj8JkPvT92sGrNIQmofVF3ne8xSWZIGqkm+t9IHNN+/NDI51jA0MRzpBviM3o/c/Nuz30wo95vWToNyWzJlyAISXnUHxnVhvpeJAbaeggQRcFxO9ujO9DH61aqgN1m+JoEplHjtc4KS5
pUEDqamve+xAJO8BWt/LgeRKA70JN4hlsRSghRqNFFwjeuBkT1kB6tZsG3YmvAXJ0o2uye+y+7LMS7jKpwJNJBiFAa/Kuyu3W6PrdOe7SqrXfjOLHQ0uX1oYfcqFIKQsBNj/Fb+GJMiciJUZaAjgHoaZrrf2b/Eii3z0i+QIVG7OypXT3Z9JUS60
KKLfjtJ0nVLjAgMBAAECggEAZqSR5sbdffNSxN2TtsXDa3hq+WwjPp/908M10QQleH/3mcKv98FmGz65zjfZyHjV5C7GPp24e6elgHr3RhGbM55vT5dQscJu7SGng0of2bnzQCEw8nGD18dZWmYJsE4rUsMT3wXxhUU4s8/Zijgq27oLyxKNr9T7
2gxqPCI06VTfMiCL1wBBUP1wHdFmD/YLJwOjV/sVzbsl9HxqzgzlDtfMn/bJodcURFI1sf1e6WO+MyTc3.................

Non sono un esperto di sicurezza e non posso sapere esattamente come utilizzare correttamente questi strumenti, ma mi sembra che a livello di scambio tra le nodi IPFS, queste chiavi vengano utilizzate. Inoltre, js-ipfs e progetti come orbit-db, su cui si basa orbit.chat. Quindi, teoricamente, ogni dispositivo (mobile e non) potrebbe essere facilmente dotato delle proprie macchine di crittografia e decrittografia. In tal caso, rimarrebbe a ciascuno prendersi cura della sicurezza delle proprie chiavi private, e ognuno sarebbe responsabile della propria sicurezza, piuttosto che essere ostaggio di qualche errore umano su un gigante di internet super popolare.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.