🥇IPFS utan smerte (men dette er ikkje sikkert)

Selv om det allerede har vært mer enn én artikkel om IPFS.

Jeg vil med en gang presisere at jeg ikke er ekspert på dette området, men jeg har hatt interesse for denne teknologien. Mine forsøk på å eksperimentere med den har ofte vært smertefulle. I dag har jeg igjen begynt med eksperimentene og fått noen resultater jeg gjerne vil dele. Kort sagt vil jeg beskrive prosessen med å installere IPFS og noen funksjoner (alt ble utført på Ubuntu, jeg har ikke prøvd andre plattformer).

Hvis du har gått glipp av hva IPFS er, er det skrevet ganske detaljert her: habr.com/ru/post/314768

Installasjon

For eksperimentets renhet foreslår jeg å installere det på en ekstern server, ettersom vi skal se på noen fallgruver med arbeid i lokal modus og fjernmodus. Senere, om ønskelig, kan du enkelt slette det, det tar ikke lang tid.

Installer go

Den offisielle dokumentasjonen
Den nyeste versjonen finner du på golang.org/dl

Merk: Det er bedre å installere IPFS som den brukeren som skal bruke det mest. Grunnen til dette er at vi senere skal se på alternativet for å montere via FUSE og der er det noen detaljer.

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

Deretter må du oppdatere miljøet (mer om dette her: 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

Sjekk at go er installert

go version

Installer IPFS

Jeg likte mest installasjonsmetoden via ipfs-update.

Installer det med kommandoen

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

Etter dette kan du utføre slike kommandoer:

ipfs-update versions — for å se alle tilgjengelige versjoner for nedlastning.
ipfs-update version — for å se den nåværende installerte versjonen (siden IPFS ikke er installert, vil den være none).
ipfs-update install latest — installer den nyeste versjonen av IPFS. I stedet for latest kan du angi hvilken som helst ønsket versjon fra listen over tilgjengelige.

Installer ipfs

ipfs-update install latest

Sjekk

ipfs --version

Når det gjelder installasjonen er det i grove trekk alt.

Kjøre IPFS

Initialisering

For å begynne må du utføre initialiseringen.

ipfs init

Som svar vil du få noe som dette:

 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

Du kan utføre den foreslåtte kommandoen

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultatet

Hei og velkommen til IPFS!

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

Hvis du ser dette, har du installert
IPFS og er nå i ferd med å bruke ipfs merkledag!

 -------------------------------------------------------
| Advarsel:                                           |
|   Dette er alfavare. Bruk på egen risiko!          |
|   Mye mangler eller har ikke fått polering. Det finnes feil. |
|   Ikke sikkert enda. Les sikkerhetsnotatene for mer. |
 -------------------------------------------------------

Sjekk ut noen av de andre filene i denne katalogen:

  . /about
  . /help
  . /quick-start     <-- bruks eksempler
  . /readme          <-- denne filen
  . /security-notes

Her begynner det interessante etter min mening. De begynner allerede i installasjonsfasen å bruke sine egne teknologi. Den foreslåtte hashen QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv er ikke spesialgenerert for deg, men integrert i utgivelsen. Det betyr at de forberedte velkomstteksten før utgivelsen, lastet den opp til IPFS og la til adressen i installasjonen. Jeg synes dette er veldig kult. Og denne filen (eller rettere sagt, hele mappen) kan nå ses ikke bare lokalt, men også på den offisielle porten. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samtidig kan man være trygg på at innholdet i mappen på ingen måte har blitt endret, for hvis det hadde blitt endret, ville hashen også ha endret seg.

For øvrig har IPFS i dette tilfellet noen likheter med en versjonskontrollserver. Hvis du endrer kildefilene i mappen og laster opp mappen til IPFS igjen, vil den få en ny adresse. Den gamle mappen vil imidlertid ikke forsvinne så lett og vil være tilgjengelig på sin tidligere adresse.

Direct launch

ipfs daemon

Du bør få et svar som dette:

ipfs daemon
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm listening on /ip4/x.x.x.x/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Åpner dørene for Internett

Legg merke til disse to linjene:

WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080

Hvis du har installert IPFS lokalt, vil du ha tilgang til IPFS-grensesnittene via lokale adresser og alt vil være tilgjengelig for deg (for eksempel, localhost:5001/webui/). Men når den installeres på en ekstern server, er gatewayene som standard lukket for internett. Det er to gatewayer:

Adminpanelet webui (github) på port 5001.
Eksternt API på port 8080 (read-only).

For eksperimentering kan begge porter (5001 og 8080) åpnes, men på en produksjonsserver bør port 5001 selvsagt lukkes av brannmuren. Det finnes også port 4001, som er nødvendig for at andre peers skal kunne finne deg. Den bør holdes åpen for forespørselen.

Åpner for redigering ~/.ipfs/config og finner disse linjene:

"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"
}

Endrer 127.0.0.1 til IP-adressen til serveren og lagrer filen, deretter starter vi ipfs på nytt (stopper kommandoen med Ctrl+C og starter opp igjen).

Må få

...
WebUI: http://ip_adressen_til_serveren:5001/webui
Gateway (read-only) server lytter på /ip4/ip_adressen_til_serveren/tcp/8080

Nå bør de eksterne grensesnittene være tilgjengelige.

Kontroller

http://domene_eller_ip_til_serveren:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Den nevnte readme-filen bør åpne seg.

http://domene_eller_ip_til_serveren:5001/webui/

Den nevnte webgrensesnittet bør åpne seg.

Hvis webui fungerer, kan IPFS-innstillinger endres direkte i det, inkludert å se statistikken, men nedenfor vil jeg vurdere konfigurasjonsalternativer direkte via konfigurasjonsfilen, noe som ikke er kritisk. Det er imidlertid best å huske hvor konfigurasjonen ligger og hva som skal gjøres med den, for hvis webgrensesnittet ikke fungerer, blir det vanskeligere.

Konfigurerer webgrensesnittet for å fungere med sin egen server

Her er den første fallgruven, som tok omtrent tre timer.

Hvis du har installert IPFS på en ekstern server, men ikke har installert eller kjørt IPFS lokalt, bør du se en tilkoblingsfeil når du går til /webui i webgrensesnittet:

Poenget er at webui, etter min mening, fungerer ganske tvetydig. Først prøver den å koble til API-en til den serveren hvor grensesnittet er åpent (basert på adressen i nettleseren). Og hvis det ikke fungerer der, prøver den å koble til den lokale gatewayen. Og hvis du har IPFS kjørt lokalt, vil webui fungere fint, men da arbeider du med lokal IPFS, ikke ekstern, selv om du har åpnet webui på en ekstern server. Deretter laster du opp filer, men av en eller annen grunn ser du dem ikke bare på den eksterne serveren...

Hvis den heller ikke kjører lokalt, får vi en tilkoblingsfeil. I vårt tilfelle skyldes feilen mest sannsynlig CORS, noe som også webui indikerer ved å foreslå å legge til konfigurasjonen.

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

Jeg har bare skrevet wildcard selv.

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

De tilleggte overskriftene kan alle finnes i samme ~/.ipfs/config. I mitt tilfelle er dette

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

Vi restarter ipfs og ser at webui har koblet til (i det minste burde det gjøre det, hvis du har åpnet gatewayer for forespørselen utenfra, som beskrevet ovenfor).

Nå kan vi laste opp mapper og filer direkte gjennom webgrensesnittet, samt opprette egne mapper.

Montering av FUSE-filsystem

Dette er en ganske interessant funksjon.

Filer (som mapper) kan vi legge til ikke bare via webgrensesnittet, men også direkte i terminalen, for eksempel

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

Den siste hashen er hashen til rotmappen.

Ved hjelp av denne hashen kan vi åpne mappen på hvilken som helst ipfs-node (som kan finne noden vår og få innholdet), via webgrensesnittet på port 5001 eller 8080, eller lokalt via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men vi kan også åpne det som en vanlig mappe.

La oss lage to mapper i roten og gi vår bruker rettigheter til dem.

sudo mkdir /ipfs /ipns
sudo chown BRUKERNAVN /ipfs /ipns

og restarte ipfs med flagget --mount

ipfs daemon --mount

Vi kan opprette mapper også andre steder og spesifisere banen til dem via parametrene ipfs daemon --mount --mount-ipfs /ipfs_path --mount-ipns /ipns_path

Nå er lesegangen fra denne mappen litt uvanlig.

ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0

Det vil si at direkte tilgang til roten av denne mappen ikke er mulig. Men man kan få innhold ved å kjenne hashen.

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

cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt 
test
test

Samtidig fungerer til og med autofullføring når du angir banen inne i mappen.

Som eg sa før, når du monterer på denne måten, er det detaljer: som standard er FUSE-monterte mapper kun tilgjengelige for den nåværende brukeren (selv root kan ikke lese fra en slik mappe, for ikke å snakke om andre brukere i systemet). Hvis du ønsker å gjøre disse mappene tilgjengelige for andre brukere, må du endre «FuseAllowOther»: false til «FuseAllowOther»: true i konfigurasjonen. Men det er ikke alt. Hvis du kjører IPFS som root, er alt greit. Men hvis du kjører den som en vanlig bruker (selv med sudo), får du en feilmelding.

mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

I så fall må du endre /etc/fuse.conf ved å avkommentere linjen #user_allow_other.

Deretter starter vi ipfs på nytt.

Kjente problemer med FUSE

Det har ofte blitt observert et problem at etter omstart av ipfs med montering (eller kanskje i andre tilfeller), blir monteringspunktene /ipfs og /ipns utilgjengelige. Det er ingen tilgang til dem, og ls -la /ipfs viser ???? i rettighetslisten.

Jeg fant en slik løsning:

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

Deretter starter vi ipfs på nytt.

Legg til tjeneste

Selvfølgelig er oppstart i terminalen bare egnet for primære tester. I produksjonstilstand bør demon starte automatisk ved systemoppstart.

Som sudo oppretter vi filen /etc/systemd/system/ipfs.service og skriver inn:

[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 må selvfølgelig erstattes med din egen bruker (og kanskje vil den fullstendige banen til ipfs-programmet være annerledes hos deg (du må angi nøyaktig full bane)).

Aktiver tjenesten.

sudo systemctl enable ipfs.service

Start tjenesten.

sudo service ipfs start

Sjekk statusen til tjenesten.

sudo service ipfs status

For å opprettholde nøyaktigheten i eksperimentet kan du senere starte serveren på nytt for å sjekke om ipfs starter automatisk.

Legg til kjente noder

La oss se på en situasjon der vi har IPFS-noder installert både på en ekstern server og lokalt. På den eksterne serveren legger vi til en fil og prøver å hente den via IPFS lokalt ved hjelp av CID. Hva vil skje? Den lokale serveren vet mest sannsynlig ingenting om vår eksterne server og vil bare forsøke å finne filen ved å «spørre» alle tilgjengelige IPFS-noder (som den allerede har «møtt»). Disse nodene vil på sin side spørre andre. Og slik fortsetter det, til filen er funnet. Det samme skjer også når vi prøver å hente filen via den offisielle portalen ipfs.io. Hvis vi er heldige, vil filen bli funnet på noen sekunder. Men hvis ikke, vil den ikke bli funnet på flere minutter, noe som er veldig frustrerende. Men vi vet jo hvor denne filen først vil dukke opp. Så hvorfor ikke fortelle vår lokale server «Søk først der»? Det ser ut til at dette kan gjøres.

1. Vi logger inn på den eksterne serveren og i konfigurasjonen ~/.ipfs/config ser vi etter

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

2. Vi kjører sudo service ipfs status og ser etter Swarm-oppføringer, for eksempel:

Swarm announcing /ip4/ip_eller_serveren_din/tcp/4001

3. Vi setter sammen den generelle adressen som ser ut som «/ip4/ip_eller_serveren_din/tcp/4001/ipfs/$PeerID».

4. For ekstra sikkerhet prøver vi å legge til denne adressen i nodene via vårt lokale webui.

5. Hvis alt er OK, åpner vi den lokale konfigurasjonen ~/.ipfs/config, finner «Bootstrap»: […
og legger til den oppnådde adressen som det første elementet i matrisen.

Vi starter IPFS på nytt.

Nå legger vi til en fil på den eksterne serveren og prøver å forespørre den lokalt. Den bør komme raskt.

Men denne funksjonaliteten er fremdeles ustabil. Så langt jeg forstår, selv om vi angir adressen til noden i Bootstrap, endrer IPFS listen over aktive forbindelser med noder under kjøringen. I alle fall er det diskusjon om dette og ønsker om muligheten til å angi faste noder. her og tilsynelatende det forventes å legge til noe funksjonalitet i ipfs@5.0+

Du kan se listen over nåværende noder både i webui og i terminalen.

ipfs swarm peers

Både der og der kan du manuelt legge til din node.

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

Inntil vi forbedrer denne funksjonaliteten, kan vi skrive et verktøy som sjekker om forbindelsen med den aktuelle noden er aktiv, og hvis ikke, legger til forbindelsen.

Refleksjoner

Blant de som allerede er kjent med IPFS, er det både argumenter for og imot IPFS. I prinsippet er det en diskusjon fra i forgårs diskusjon og det fikk meg til å grave mer i IPFS. Når det gjelder den nevnte diskusjonen, kan jeg ikke si at jeg er sterkt imot noe av argumentene som har blitt fremsatt (jeg er bare uenig i at én og en halv programmerer bruker IPFS). Generelt har både de og de andre sine poenger (spesielt kommentaren om kvitteringer er tankevekkende). Men hvis vi ser bort fra den etiske og juridiske vurderingen, hva slags teknisk vurdering kan vi gi denne teknologien? Jeg har en slags indre følelse av at "dette er definitivt nødvendig, dette har visse perspektiver". Men hvorfor nettopp det, er det ingen klar formulering. Hvis vi ser på de eksisterende sentraliserte løsningene, er de på mange parametre langt foran (stabilitet, hastighet, håndterbarhet osv.). Likevel har jeg en tanke som ser ut til å gi mening, og som neppe kan realiseres uten slike desentraliserte systemer. Selv om jeg strekker meg langt, ville jeg formulert det slik: prinsippet for informasjonsdistribusjon på Internett må endres.

Jeg skal forklare. Hvis vi tenker etter, så sprer vi informasjon i henhold til prinsippet "Jeg håper at den som jeg har overlevert det til, vil beskytte det, og at det ikke går tapt eller blir mottatt av uønskede." Det er lett å se på ulike e-posttjenester, skybaserte lagringsløsninger osv. Og hva ender vi opp med? På Habré Informasjonssikkerhet står først på listen, og nesten hver dag får vi nyheter om den siste globale lekkasjen. I prinsippet er alt det mest interessante nevnt i den fantastiske artikkelen. Sommeren er nesten over. Det er nesten ingen data som er lekketAltså blir de store internettgigantene stadig større, de samler mer og mer informasjon, og slike lekkasjer er en slags informasjonseksplosjoner. Det har aldri vært slik før, og nå skjer det igjen. Samtidig, selv om mange forstår at det finnes risikoer, vil de fortsette å stole på at tredjeparts selskaper håndterer dataene sine. For det første finnes det ikke særlig mange alternativer, og for det andre lover de at de har tett igjen alle hullene og at dette ikke vil skje igjen.

Hva slags alternativ ser jeg for meg? Jeg mener at data i utgangspunktet bør deles åpent. Men åpenhet her betyr ikke at alt skal være lett å lese. Jeg snakker om åpenhet i lagring og distribusjon, men ikke total åpenhet i lesning. Jeg antar at informasjon må deles med åpne nøkler. For prinsippet med åpne/lukkede nøkler er allerede gammelt, nesten like gammelt som Internett. Hvis informasjonen ikke er konfidensiell og er ment for et bredt publikum, legges den ut med åpne nøkler (men likevel i kryptert form, slik at alle kan dekryptere den med den tilgjengelige nøkkelen). Men hvis ikke, legges den ut uten åpen nøkkel, og selve nøkkelen overføres til den som skal ha tilgang til denne informasjonen. Den som må lese det, skal bare ha nøkkelen, og hvor man finner denne informasjonen, skal ikke bekymre ham altfor mye — han henter det bare fra nettet (dette er det nye prinsippet for distribusjon basert på innhold, ikke på adresse).

Slik sett må angripere for en massiv angrep skaffe seg et enormt antall lukkede nøkler, og det er usannsynlig at de vil klare å gjøre det på ett sted. Denne oppgaven virker, etter min mening, mer komplisert enn å hacke en bestemt tjeneste.

Og her lukkes enda et problem: bekreftelse av forfatterskap. Nå for tiden kan man finne mange sitater på internett skrevet av folk vi kjenner. Men hvor er garantien for at det var nettopp de som skrev dem? Hvis hver slik opptegnelse ble ledsaget av en digital signatur, ville det vært mye lettere. Og det spiller ingen rolle hvor denne informasjonen ligger, det viktigste er signaturen, som på forhånd er vanskelig å forfalske.

Og det som er interessant her: IPFS inneholder allerede krypteringsverktøy (det er jo bygget på blokkjedeteknologi). I konfigurasjonen er den private nøkkelen allerede angitt.

  "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.................

Eg er ikkje sikkerheitsspesialist og kan ikkje vite akkurat korleis dette skal brukast, men eg trur at desse nøklane vert nytta på nivået for utveksling mellom IPFS-noder. Og så js-ipfs og slike prosjekt-eksempel som orbit-db, som orbit.chat . Så teoretisk kan kvar eining (mobil og anna) lett utstyrast med sine eigne krypterings- og dekrypteringsmaskiner. I så fall vil kvar enkeltperson måtte ta vare på sine private nøklar, og kvar vil sjølv vere ansvarleg for si eiga sikkerheit, snarare enn å vere ein brikke i eit menneskeleg faktum hos ein superpopulær internettgigant.Har du høyrt om IPFS før?

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.