IPFS utan smärta (men det är inte säkert)

Trots att det redan finns flera artiklar om IPFS på Habré.

Låt mig genast klargöra att jag inte är expert inom detta område, men jag har visat intresse för denna teknik flera gånger. Mina försök att experimentera med den har ofta orsakat viss frustration. Idag har jag återigen gett mig in på experiment och har fått några resultat som jag skulle vilja dela med mig av. Kort sagt kommer jag att beskriva installationsprocessen för IPFS och några funktioner (allt har genomförts på Ubuntu, jag har inte prövat på andra plattformar).

Om du missade vad IPFS är, så är det beskrivet ganska utförligt här: habr.com/ru/post/314768

Installation

För att säkerställa en ren experimentupplevelse föreslår jag att du installerar på en extern server, eftersom vi kommer att titta på vissa fallgropar när vi arbetar i lokalt läge och på distans. Sen kan du lätt rensa bort det om du vill, det tar inte lång tid.

Installerar Go

Officiell dokumentation
Se den aktuella versionen på golang.org/dl

Notera: Det är bäst att installera IPFS under den användare som det är tänkt att användas mest av. Anledningen är att vi nedan kommer att diskutera alternativet att montera via FUSE och där finns det vissa 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

Därefter måste miljön uppdateras (mer info här: 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

Kontrollerar att Go är installerat

go version

Installerar IPFS

Jag föredrar installationen via ipfs-update.

Installera det med kommandot

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

Efter detta kan följande kommandon köras:

ipfs-update versions — för att se alla tillgängliga versioner för nedladdning.
ipfs-update version — för att se den aktuella installerade versionen (eftersom vi inte har installerat IPFS än, kommer det att vara none).
ipfs-update install latest — installera den senaste versionen av IPFS. Istället för latest kan du naturligtvis ange vilken version som helst från listan över tillgängliga.

Installerar IPFS

ipfs-update install latest

Kontrollerar

ipfs --version

När det gäller installationen är allt ganska klart.

Starta IPFS

Initiering

Först måste du initiera det.

ipfs init

Som svar får du något liknande:

 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 köra det föreslagna kommandot

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultat

Hej och välkommen till IPFS!

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

Om du ser detta har du framgångsrikt installerat
IPFS och interagerar nu med ipfs merkledag!

 -------------------------------------------------------
| Varning:                                             |
|   Detta är alpha-programvara. Använd på eget ansvar! |
|   Mycket saknas eller är oputsat. Det finns buggar.  |
|   Inte säkert ännu. Läs säkerhetsnoterna för mer.    |
 -------------------------------------------------------

Kolla gärna in några av de andra filerna i denna katalog:

  .\/about
  .\/help
  .\/quick-start     <-- användningsexempel
  .\/readme          <-- den här filen
  .\/security-notes

Här börjar det bli intressant, enligt min mening. Killarna börjar använda sina egna teknologier redan under installationssteget. Den föreslagna hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — inte speciellt genererad för dig, utan inbäddad i releasen. Det betyder att de förberedde välkomsttexten innan releasen, laddade upp den till IPFS och lade till adressen i installatören. Jag tycker att det är riktigt coolt. Och den här filen (eller snarare hela mappen) kan nu ses inte bara lokalt, utan även på den officiella gatewayen. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Man kan vara säker på att mappens innehåll inte har ändrats, eftersom om det hade ändrats skulle hash också ha ändrats.

För övrigt har IPFS här vissa likheter med en versionskontrollserver. Om du gör ändringar i originalfilerna i mappen och laddar upp mappen igen till IPFS, får den en ny adress. Samtidigt kommer den gamla mappen inte att försvinna utan kommer att vara tillgänglig på sin tidigare adress.

Direkt start

ipfs daemon

Du bör få ett svar som det här:

ipfs daemon
Initierar daemon...
go-ipfs version: 0.4.22-
Repo version: 7
Systemversion: amd64/linux
Golang version: go1.12.7
Swarm lyssnar på /ip4/x.x.x.x/tcp/4001
Swarm lyssnar på /ip4/127.0.0.1/tcp/4001
Swarm lyssnar på /ip6/::1/tcp/4001
Swarm lyssnar på /p2p-circuit
Swarm meddelar /ip4/127.0.0.1/tcp/4001
Swarm meddelar /ip6/::1/tcp/4001
API-server lyssnar på /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (skrivskyddad) server lyssnar på /ip4/127.0.0.1/tcp/8080
Daemon är redo

Öppnar dörrarna för Internet

Observera dessa två rader:

WebUI: http://127.0.0.1:5001/webui
Gateway (skrivskyddad) server lyssnar på /ip4/127.0.0.1/tcp/8080

Om du har installerat IPFS lokalt kommer du att nå IPFS-gränssnitten via lokala adresser och allt kommer att vara tillgängligt för dig (till exempel, localhost:5001/webui/). Men när du installerar på en extern server är standardportarna stängda för internet. Det finns två portar:

1. Adminpanelen webui (github) på port 5001.
2. Extern API på port 8080 (readonly).

För experiment kan båda portarna (5001 och 8080) hållas öppna, men på en produktionsserver bör port 5001 så klart stängas av brandväggen. Det finns också port 4001, som behövs för att andra peers ska kunna hitta er. Den bör hållas öppen för externa förfrågningar.

Öppna för att redigera ~/ .ipfs/config och hitta dessa rader:

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

Byt ut 127.0.0.1 mot er servers IP och spara filen, efter vilket ni startar om ipfs (stoppa den körande kommandot med Ctrl+C och kör det igen).

Ni bör få

...
WebUI: http://ip_ert_servers:5001/webui
Gateway (readonly) server lyssnar på /ip4/ip_ert_servers/tcp/8080

Nu bör de externa gränssnitten vara tillgängliga.

Kontrollera

http://domen_eller_ip_server:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Den ovan nämnda readme-filen bör öppnas.

http://domen_eller_ip_server:5001/webui/

Webbgränssnittet bör öppnas.

Om webui fungerar kan ni ändra IPFS-inställningarna direkt där, inklusive att visa statistik. Men nedan kommer jag att gå igenom konfigurationsalternativ direkt via konfigurationsfilen, vilket i stort sett inte är kritiskt. Det är bara bättre att komma ihåg var konfigurationsfilen ligger och vad man ska göra med den, för om webbgränssnittet inte fungerar blir det svårare.

Ställ in webbgränssnittet för att arbeta med er server

Här är den första fällan, som det tog ungefär tre timmar att lösa.

Om ni har installerat IPFS på en extern server men inte installerat eller kört IPFS lokalt, bör ni se ett anslutningsfel när ni går till /webui i webbgränssnittet:

Anledningen till detta är att webui, enligt min åsikt, fungerar på ett ganska otydligt sätt. Först försöker den ansluta till API för den server där gränssnittet är öppet (utifrån adressen i webbläsaren). Om det misslyckas försöker den att ansluta till den lokala gatewayen. Om ni har IPFS körandes lokalt kommer webui att fungera bra, men ni kommer att arbeta med den lokala IPFS, inte den externa, även om ni har öppnat webui på den externa servern. Sedan laddar ni upp filer, men av någon anledning ser ni dem inte så enkelt på den externa servern…

Om det inte körs lokalt får vi ett anslutningsfel. I vårt fall beror felet sannolikt på CORS, vilket även webui påpekar och föreslår att vi lägger till konfigurationen.

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

Jag har bara registrerat wildcard på min.

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

De tillagda rubrikerna kan alla hittas på samma ställe i ~/.ipfs/config. I mitt fall är det

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

Vi startar om ipfs och ser att webui har anslutit framgångsrikt (i alla fall ska den göra det om du har öppnat gateways för externa förfrågningar, som beskrivits ovan).

Nu kan du direkt via webbgränssnittet ladda upp mappar och filer samt skapa dina egna mappar.

Montering av FUSE-filsystemet

Detta är en ganska intressant funktion.

Filer (liksom mappar) kan vi lägga till inte bara via webbgränssnittet utan även direkt i terminalen, till exempel

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

Den senaste hash är hash för rotmappen.

Genom denna hash kan vi öppna mappen på vilken ipfs-nod som helst (som kan hitta vår nod och få åtkomst till innehållet), antingen via webbgränssnittet på port 5001 eller 8080, eller lokalt genom ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men man kan även öppna den som en vanlig mapp.

Låt oss skapa två mappar i roten och ge vår användare rättigheter till dem.

sudo mkdir /ipfs /ipns
sudo chown ANVÄNDAREN /ipfs /ipns

och starta om ipfs med flaggan —mount

ipfs daemon --mount

Det går att skapa mappar på andra platser och ange sökvägen till dem genom parametrarna ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Nu är läsningen från denna mapp något ovanlig.

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

Det finns ingen direktåtkomst till roten av denna mapp. Men man kan få tillgång till innehållet om man vet 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

Inuti mappen fungerar till och med autocompletion vid angivande av sökväg.

Som jag nämnde tidigare finns det detaljer med denna montering: som standard är monterade FUSE-mappar endast tillgängliga för den aktuella användaren (även root kan inte läsa från en sådan mapp, för att inte tala om andra användare i systemet). Om du vill göra dessa mappar tillgängliga för andra användare måste du ändra "FuseAllowOther": false till "FuseAllowOther": true i konfigurationsfilen. Men det är inte allt. Om du kör IPFS som root fungerar allt bra. Men om du kör det som en vanlig användare (även med sudo) kommer du att få ett felmeddelande.

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

I så fall måste du justera /etc/fuse.conf genom att avkommentera raden #user_allow_other.

Efter detta startar vi om ipfs.

Kända problem med FUSE

Problemet har observerats flera gånger, där efter omstart av ipfs med montering (och kanske även i andra fall) blir monteringspunkterna /ipfs och /ipns otillgängliga. Ingen åtkomst till dem, och ls -la /ipfs visar ???? i listan över rättigheter.

Jag fann en lösning:

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

Därefter startar vi om ipfs.

Lägg till tjänst

Självklart är körning i terminalen bara bra för första tester. I produktionsläge bör demon startas automatiskt när systemet startas.

Som sudo skapar vi filen /etc/systemd/system/ipfs.service och skriver in:

[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åste självklart ersättas med din användare (och eventuell fullständig sökväg till programmet ipfs kan vara annorlunda hos er (du måste ange den exakta fullständiga sökvägen)).

Aktivera tjänsten.

sudo systemctl enable ipfs.service

Starta tjänsten.

sudo service ipfs start

Kontrollera tjänstens status.

sudo service ipfs status

För att hålla experimentet rent kan du senare starta om servern för att verifiera att ipfs startar automatiskt.

Lägg till de kända peers vi har.

Låt oss överväga en situation där vi har IPFS-noder installerade både på en extern server och lokalt. På den externa servern lägger vi till en fil och försöker hämta den via IPFS lokalt med CID. Vad kommer att hända? Självklart vet den lokala servern förmodligen ingenting om vår externa server och kommer helt enkelt att försöka hitta filen via CID genom att "fråga" alla tillgängliga IPFS-noder (som den redan har lyckats "bekanta sig" med). Dessa i sin tur kommer att fråga andra. Och så fortsätter det tills filen är hittad. Det är faktiskt detsamma som händer när vi försöker få filen via den officiella gatewayen. ipfs.io. Om vi har tur kan filen hittas på några sekunder. Om inte, kan det ta flera minuter innan den hittas, vilket verkligen påverkar arbetskomforten. Men vi vet ju var den här filen kommer att dyka upp först. Så varför säger vi inte till vår lokala server direkt "Sök först där"? Det verkar som om detta kan göras.

1. Logga in på den externa servern och leta i konfigurationsfilen ~/.ipfs/config

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

2. Kör sudo service ipfs status och leta efter posterna i Swarm, till exempel:

Swarm announcing /ip4/ip_era_server/tcp/4001

3. Sätt ihop en fullständig adress av typen "/ip4/ip_era_server/tcp/4001/ipfs/$PeerID".

4. För säkerhets skull ska vi via vår lokala webui försöka lägga till denna adress i noder.

5. Om allt är OK, öppna den lokala konfigurationen ~/.ipfs/config, hitta "Bootstrap": […
och lägg först till den erhållna adressen i arrayen.

Starta om IPFS.

Nu lägger vi till en fil på den externa servern och försöker begära den lokalt. Den ska laddas ner snabbt.

Men denna funktionalitet är fortfarande instabil. Såvitt jag förstår, även om vi anger en nodadress i Bootstrap, ändrar IPFS aktiva anslutningar med noder under drift. I vilket fall som helst pågår diskussioner om detta och önskemål om att kunna ange permanenta noder. här och det verkar som om det planeras att lägga till någon funktionalitet i ipfs@5.0+

Lista över aktuella noder kan ses både i webui och i terminalen.

ipfs swarm peers

Och där kan man manuellt lägga till sin nod.

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

Tills de förbättrar denna funktionalitet, kan man skriva ett verktyg som kontrollerar anslutningen till en specifik nod och, om det inte finns någon, lägger till denna anslutning.

Resonemang

Bland de som redan känner till IPFS finns både argument för och emot. I princip, häromdagen diskussion och fick mig att gräva djupare i IPFS. Och angående den nämnda diskussionen: jag kan inte säga att jag är starkt emot något av de anförda argumenten från de som uttryckt sig (jag är bara oense om att en och en halv programmerare använder IPFS). I allmänhet har både sidor sina poänger (speciellt kommentaren om kvitton får en att fundera). Men om man bortser från den moraliska och juridiska bedömningen, hur skulle man tekniskt bedöma denna teknologi? Personligen har jag en inre känsla av att "detta är nödvändigt, det har vissa framtidsutsikter". Men varför exakt, finns det ingen tydlig formulering. Typ, om man ser på de redan existerande centraliserade verktygen, så ligger de långt före i många avseenden (stabilitet, hastighet, hanterbarhet osv.). Ändå har jag en tanke som verkar meningsfull och som troligen inte kan realiseras utan sådana decentraliserade system. Naturligtvis tänker jag stort, men jag skulle formulera det så här: principen för informationsspridning på Internet måste förändras.

Låt mig förklara. Om man tänker efter, så sprider vi just nu information enligt principen "Jag hoppas att den som jag överlämnar den till skyddar den och att den inte går förlorad eller når dem den inte är avsedd för". För att ge ett exempel kan man enkelt se på olika e-posttjänster, molnlagring osv. Och vad får vi i slutändan? På Habr står Informationssäkerhet på första plats och nästan varje dag får vi nyheter om ytterligare en global läcka. I princip är allt det mest intressanta uppradat i <ironi>den fantastiska</ironi> artikeln Sommaren är nästan slut. Nästan ingen data har läckt ut. Det vill säga, de stora internetjättarna blir allt större, de ackumulerar mer och mer information, och sådana läckor är en slags informationsatombomber. Sådant har aldrig hänt förut, och här är vi igen. Samtidigt, även om många förstår att riskerna finns, kommer de att fortsätta att lita på sina uppgifter till tredje företag. För det första finns det knappt några alternativ och för det andra lovar de att de har tätat alla hål och att sådant aldrig kommer att hända igen.

Vilken variant ser jag? Jag anser att data från början ska spridas öppet. Men öppenhet innebär inte att allt måste vara lättläst. Jag pratar om öppenheten för lagring och spridning, men inte total öppenhet för läsning. Jag föreslår att informationen ska spridas med öppna nycklar. Principen för öppna/stängda nycklar är gammal, nästan lika gammal som Internet. Om informationen inte är konfidentiell och riktar sig till en bred publik, kan den publiceras direkt med en öppen nyckel (men ändå i krypterad form, så att vem som helst kan dekryptera den med den tillgängliga nyckeln). Om det inte är fallet, publiceras den utan öppen nyckel, och själva nyckeln överlämnas till den som ska ha tillgång till denna information. Den som ska läsa den måste bara ha nyckeln, och var man hittar informationen ska inte vara ett problem — han drar bara ner den från nätet (detta är den nya principen för spridning baserat på innehåll och inte på adress).

Således måste angripare för en massattack få tag på ett enormt antal stängda nycklar, och det är osannolikt att det går att göra på en enda plats. Denna uppgift, som jag ser det, är svårare än att hacka en specifik tjänst.

Här stänger även ett annat problem: bekräftelse av upphovsrätt. Just nu kan man hitta många citat på internet skrivna av våra bekanta. Men vad är garantin för att det verkligen var de som skrev dem? Om varje sådan post skulle åtföljas av en digital signatur skulle det vara mycket enklare. Och oavsett var informationen ligger, är det viktigaste signaturen, som är svår att förfalska.

Och här är det intressant: IPFS har redan inbyggda krypteringsmedel (det är ju byggt på blockchain-teknologi). I konfigurationen anges en privat nyckel direkt.

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

Jag är ingen säkerhetsexpert och kan inte säga exakt hur detta används korrekt, men jag tror att dessa nycklar används på nivån av utbytet mellan IPFS-noder. Och dessutom js-ipfs och sådana projekt-exempel som orbit-db, som driver orbit.chat. Det innebär att varje enhet (mobil och andra) teoretiskt kan utrustas med sina egna krypterings- och avkrypteringsmaskiner. I så fall är det upp till varje person att ta hand om sina privata nycklar och var och en kommer att vara ansvarig för sin egen säkerhet, istället för att vara fånge under en annan mänsklig faktor hos någon superpopulär internetjätte.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Har du hört talas om IPFS tidigare?

• Aldrig hört talas om IPFS, men det verkar intressant

• Har inte hört och vill inte höra

• Har hört, men blev inte intresserad

• Har hört, men förstod inte, och nu verkar det intressant

• Har länge aktivt använt IPFS

69 användare har röstat. 13 användare avstod.

Källa: habr.com