IPFS utan smärta (men detta är inte korrekt)

Trots att Habré redan var det mer än en artikel om IPFS.

Jag ska genast klargöra att jag inte är någon expert på detta område, men jag har visat intresse för den här tekniken mer än en gång, men att försöka leka med den orsakade ofta en del smärta. Idag började jag experimentera igen och fick några resultat som jag skulle vilja dela med mig av. I korthet kommer IPFS-installationsprocessen och vissa funktioner att beskrivas (allt gjordes på ubuntu, jag har inte provat det på andra plattformar).

Om du har missat vad IPFS är så skrivs det i detalj här: habr.com/en/post/314768

Installation

För experimentets renhet föreslår jag att du omedelbart installerar det på någon extern server, eftersom vi kommer att överväga några fallgropar med att arbeta i lokalt läge och fjärrkontroll. Sedan kommer det om så önskas inte att rivas på länge, det är inte mycket.

Installera go

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

Obs: det är bättre att installera IPFS på uppdrag av användaren som ska använda det oftast. Faktum är att vi nedan kommer att överväga möjligheten att montera via SÄKRING och det finns finesser.

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

Sedan måste du uppdatera miljön (mer information 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

Kontrollera att go är installerad

go version

Installera IPFS

Jag gillade installationsmetoden mest ipfs uppdatering.

Installera den med kommandot

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

Efter det kan du köra följande kommandon:

ipfs-uppdateringsversioner - för att se alla tillgängliga versioner för nedladdning.
ipfs-uppdateringsversion - för att se den för närvarande installerade versionen (tills vi har IPFS installerat, kommer det att vara ingen).
ipfs-update installera senaste - installera den senaste versionen av IPFS. Istället för senaste, respektive, kan du ange vilken version som helst från listan över tillgängliga.

Installerar ipfs

ipfs-update install latest

Kontroll

ipfs --version

Direkt med installationen i allmänna termer allt.

Starta IPFS

initiering

Först måste du utföra initiering.

ipfs init

Som svar får du något i stil med detta:

 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

Hello and Welcome to IPFS!

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

If you're seeing this, you have successfully installed
IPFS and are now interfacing with the ipfs merkledag!

 -------------------------------------------------------
| Warning:                                              |
|   This is alpha software. Use at your own discretion! |
|   Much is missing or lacking polish. There are bugs.  |
|   Not yet secure. Read the security notes for more.   |
 -------------------------------------------------------

Check out some of the other files in this directory:

  ./about
  ./help
  ./quick-start     <-- usage examples
  ./readme          <-- this file
  ./security-notes

Här börjar enligt min mening det intressanta. Killarna på installationsstadiet börjar redan använda sin egen teknik. Den föreslagna hashen QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv genereras inte specifikt för dig, utan sys in i releasen. Det vill säga, innan releasen förberedde de en välkomsttext, hällde den i IPFS och la till adressen till installationsprogrammet. Jag tycker det är väldigt coolt. Och den här filen (mer exakt, hela mappen) kan nu ses inte bara lokalt utan också på den officiella gatewayen ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samtidigt kan du vara säker på att innehållet i mappen inte har förändrats på något sätt, för om det hade ändrats så hade även hashen ändrats.

Förresten, i det här fallet har IPFS vissa likheter med versionskontrollservern. Om du gör ändringar i mappens källfiler och återigen häller mappen i IPFS, kommer den att få en ny adress. Samtidigt kommer den gamla mappen inte att hamna någonstans bara så och kommer att finnas tillgänglig på sin tidigare adress.

Direkt lansering

ipfs daemon

Du bör få ett svar så här:

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

Öppnar dörrarna till Internet

Var uppmärksam på dessa två rader:

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

Nu, om du har installerat IPFS lokalt, kommer du att komma åt IPFS-gränssnitt med hjälp av lokala adresser och allt kommer att vara tillgängligt för dig (till exempel, lokalvärd:5001/webui/). Men när de installeras på en extern server är gateways som standard stängda för Internet. Gateways två:

1. webui admin (github) på port 5001.
2. Externt API på port 8080 (skrivskyddat).

Än så länge kan båda portarna (5001 och 8080) öppnas för experiment, men på en stridsserver ska givetvis port 5001 stängas med en brandvägg. Det finns också port 4001, som behövs för att andra kamrater ska hitta dig. Det bör lämnas öppet för externa förfrågningar.

Öppna ~/.ipfs/config för redigering och hitta dessa rader i den:

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

Ändra 127.0.0.1 till din servers ip och spara filen, starta sedan om ipfs (stoppa det körande kommandot med Ctrl+C och starta om det).

Borde få

...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080

Nu ska de externa gränssnitten vara tillgängliga.

Kontrollera

http://домен_или_ip_сервера:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Ovanstående readme-fil bör öppnas.

http://домен_или_ip_сервера:5001/webui/

Webbgränssnittet bör öppnas.

Om webui fungerar för dig kan IPFS-inställningarna ändras direkt i den, inklusive visning av statistik, men nedan kommer jag att överväga konfigurationsalternativ direkt genom konfigurationsfilen, vilket i allmänhet inte är kritiskt. Det är bara bättre att komma ihåg exakt var konfigurationen är och vad man ska göra med den, annars om webbansiktet inte fungerar blir det svårare.

Konfigurera ett webbgränssnitt för att fungera med din server

Här är den första fallgropen, som tog cirka tre timmar.

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

Faktum är att webui, enligt min mening, fungerar väldigt tvetydigt. Först försöker den ansluta till serverns API där gränssnittet är öppet (baserat på adressen i webbläsaren, förstås). och om det inte fungerar där försöker den ansluta till den lokala gatewayen. Och om du har IPFS som körs lokalt, kommer webui att fungera bra för dig, bara du kommer att arbeta med lokal IPFS, och inte extern, även om du öppnade webui på en extern server. Sedan laddar du upp filerna, men av någon anledning ser du dem inte bara så på en extern server...

Och om det inte körs lokalt får vi ett anslutningsfel. I vårt fall beror felet troligen på CORS, vilket också indikeras av webui, vilket tyder på att du lägger till en konfiguration.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_вашего сервера:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Jag registrerade precis ett jokertecken

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

De tillagda rubrikerna kan hittas i samma ~/.ipfs/config. I mitt fall är det så

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

Vi startar om ipfs och vi ser att webui har anslutit framgångsrikt (i alla fall bör det, om du öppnade gateways för förfrågningar utifrån, som beskrivits ovan).

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

Montering av FUSE-filsystemet

Här ä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 sista hashen är hashen för rotmappen.

Med hjälp av denna hash kan vi öppna en mapp på valfri ipfs-nod (som kan hitta vår nod och hämta innehållet), vi kan i webbgränssnittet på port 5001 eller 8080, eller vi kan lokalt via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men du kan fortfarande öppna den som en vanlig mapp.

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

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

och starta om ipfs med --mount flaggan

ipfs daemon --mount

Du kan skapa mappar på andra ställen och ange sökvägen till dem genom ipfs-demonparametrarna -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Att nu läsa från den här mappen är något ovanligt.

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

Det vill säga, det finns ingen direkt åtkomst till roten av denna mapp. Men du kan få innehållet genom att känna till 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

Samtidigt fungerar även autokomplettering inne i mappen när sökvägen är angiven.

Som jag sa ovan, det finns finesser med sådan montering: som standard är monterade FUSE-mappar endast tillgängliga för den aktuella användaren (även root kommer inte att kunna 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 i konfigurationen ändra "FuseAllowOther": false till "FuseAllowOther": true. Men det är inte allt. Om du kör IPFS som root är allt OK. Och om på uppdrag av en vanlig användare (även sudo), kommer du att få ett fel

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

I det här fallet måste du redigera /etc/fuse.conf genom att avkommentera raden #user_allow_other.

Efter det, starta om ipfs.

Kända problem med FUSE

Problemet har uppmärksammats mer än en gång att efter omstart av ipfs med montering (och kanske i andra fall) blir monteringspunkterna /ipfs och /ipns otillgängliga. Det finns ingen tillgång till dem, och ls -la /ipfs visar ???? i listan över rättigheter.

Hittade den här lösningen:

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

Starta sedan om ipfs.

Lägga till en tjänst

Naturligtvis är körning i terminalen endast lämplig för initiala tester. I stridsläge bör demonen starta automatiskt vid systemstart.

På uppdrag av sudo, skapa filen /etc/systemd/system/ipfs.service och skriv till den:

[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

ANVÄNDARNAMN måste naturligtvis ersättas med din användare (och kanske kommer hela sökvägen till ipfs-programmet att vara annorlunda för dig (du måste ange den fullständiga sökvägen)).

Vi aktiverar tjänsten.

sudo systemctl enable ipfs.service

Vi startar tjänsten.

sudo service ipfs start

Kontrollera status för tjänsten.

sudo service ipfs status

För experimentets renhet kommer det att vara möjligt att starta om servern i framtiden för att kontrollera att ipfs startar automatiskt.

Lägga till kända för oss högtider

Tänk på en situation där vi har IPFS-noder installerade både på en extern server och lokalt. På en extern server lägger vi till någon fil och försöker få den via IPFS lokalt med CID. Vad kommer att hända? Naturligtvis vet den lokala servern med största sannolikhet ingenting om vår externa server och kommer helt enkelt att försöka hitta filen med CID genom att "fråga" alla IPFS-kamrater som är tillgängliga för den (som den redan har lyckats "bekanta sig med"). De i sin tur kommer att fråga andra. Och så vidare, tills filen hittas. I själva verket händer samma sak när vi försöker få filen genom den officiella gatewayen ipfs.io. Om du har tur kommer filen att hittas på några sekunder. Och om inte, kommer det inte att hittas ens om några minuter, vilket i hög grad påverkar arbetskomforten. Men vi vet var den här filen först kommer att visas. Så varför säger vi inte omedelbart till vår lokala server "Sök där först"? Tydligen kan detta göras.

1. Vi går till fjärrservern och tittar i ~/.ipfs/config-konfigurationen

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

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

Swarm announcing /ip4/ip_вашего_сервера/tcp/4001

3. Vi lägger till den allmänna adressen för formuläret "/ip4/ip_din_server/tcp/4001/ipfs/$PeerID".

4. För pålitlighetens skull kommer vi att försöka lägga till den här adressen till kamrater via vår lokala webbui.

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

Starta om IPFS.

Låt oss nu lägga till filen på den externa servern och försöka begära den på den lokala. Borde flyga snabbt.

Men den här funktionen är ännu inte stabil. Såvitt jag förstår, även om vi anger adressen till en peer i Bootstrap, ändrar ipfs listan över aktiva anslutningar med peers under drift. Diskussionen om detta och önskemål om möjligheten att ange permanenta högtider är i alla fall igång här och det verkar som förment lägga till lite funktionalitet [e-postskyddad]+

Listan över aktuella peers kan ses både i webui och i terminalen.

ipfs swarm peers

Och här och där kan du lägga till din fest manuellt.

ipfs swarm connect "/ip4/ip_вашего_сервера/tcp/4001/ipfs/$PeerID"

Tills denna funktionalitet har förbättrats kan du skriva ett verktyg för att söka efter en anslutning till önskad peer och, om inte, för att lägga till en anslutning.

Resonemang

Bland de som redan är bekanta med IPFS finns det både argument för och emot IPFS. I princip igår diskussion och fick mig att gräva i IPFS igen. Och när det gäller diskussionen som nämns ovan: Jag kan inte säga att jag starkt motsätter mig något argument från dem som talade (jag håller bara inte med om att en och en halv programmerare använder IPFS). I allmänhet har båda rätt på sitt eget sätt (särskilt kommentar om kontroller får dig att tänka). Men om vi förkastar den moraliska och juridiska bedömningen, vem kommer att ge en teknisk bedömning av denna teknik? Själv har jag någon slags inre känsla av att "det här måste göras otvetydigt, det har vissa utsikter". Men varför exakt, det finns ingen tydlig formulering. Som, om man tittar på de befintliga centraliserade verktygen, så ligger de i många avseenden långt fram (stabilitet, hastighet, hanterbarhet, etc.). Ändå har jag en tanke som verkar vettig och som knappast kan genomföras utan sådana decentraliserade system. Självklart svänger jag för hårt, men jag skulle formulera det så här: principen om informationsspridning på internet måste ändras.

Låt mig förklara. Om du tänker på det, nu har vi information distribuerad enligt principen "Jag hoppas att den som jag gav den till kommer att skydda den och den kommer inte att gå förlorad eller tas emot av dem som den inte var avsedd för." Som ett exempel är det lätt att överväga olika e-posttjänster, molnlagringar osv. Och vad slutar vi med? På Habré nav Informationssäkerhet är på första raden och nästan varje dag får vi nyheter om ytterligare en global läcka. I princip finns alla de mest intressanta sakerna listade i <ironi> underbart artikel Sommaren är nästan över. Det finns nästan ingen oläckt data kvar. Det vill säga att de största internetjättarna blir större, de samlar på sig mer och mer information, och sådana läckor är ett slags informationsatomexplosioner. Detta har aldrig hänt förut, och här är det igen. Samtidigt, även om många förstår att det finns risker, kommer de att fortsätta att lita på sin data till tredjepartsföretag. För det första finns det inte så mycket alternativ, och för det andra lovar de att de har lappat alla hål och det här kommer aldrig att hända igen.

Vilket alternativ ser jag? Det förefaller mig som att data initialt bör distribueras öppet. Men öppenhet i det här fallet betyder inte att allt ska vara lätt att läsa. Jag talar om öppenheten i lagring och distribution, men inte total öppenhet i läsning. Jag antar att information ska distribueras med publika nycklar. När allt kommer omkring är principen om offentliga / privata nycklar redan gammal, nästan som Internet. Om informationen inte är konfidentiell och avsedd för en bred krets, så läggs den ut omedelbart med en offentlig nyckel (men fortfarande i krypterad form, vem som helst kan dekryptera den med den tillgängliga nyckeln). Och om inte, så läggs den ut utan en publik nyckel, och själva nyckeln överförs till det som ska ha tillgång till denna information. Samtidigt ska den som ska läsa den bara ha en nyckel, och var man kan få tag i denna information ska han inte riktigt sväva - han bara drar den från nätverket (detta är den nya principen för distribution efter innehåll, inte efter innehåll adress).

För en massattack kommer alltså angripare att behöva skaffa ett stort antal privata nycklar, och detta är osannolikt att göras på ett ställe. Denna uppgift, som jag ser det, är svårare än att hacka en viss tjänst.

Och här är ett annat problem stängt: bekräftelse av författarskap. Nu på Internet kan du hitta många citat skrivna av våra vänner. Men var är garantin att det var de som skrev dem? Nu, om varje sådan post åtföljdes av en digital signatur, skulle det vara mycket enklare. Och det spelar ingen roll var denna information ligger, det viktigaste är signaturen, som naturligtvis är svår att förfalska.

Och här är det som är intressant här: IPFS har redan krypteringsverktyg (det är trots allt byggt på blockchain-teknik). Den privata nyckeln anges omedelbart i konfigurationen.

  "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äkerhetsspecialist och kan inte veta exakt hur man använder det korrekt, men det verkar som om dessa nycklar används på nivån för utbyte mellan IPFS-noder. Och även js-ipfs och exempelprojekt som t.ex orbit-dbsom det fungerar på orbit.chat. Det vill säga teoretiskt sett kan varje enhet (mobil och inte bara) enkelt utrustas med sina egna krypterings-dekrypteringsmaskiner. I det här fallet återstår det bara för alla att ta hand om att spara sina privata nycklar, och alla kommer att ansvara för sin egen säkerhet, och inte vara gisslan för en annan mänsklig faktor på någon superpopulär internetjätte.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Har du hört talas om IPFS förut?

• Jag har aldrig hört talas om IPFS, men det verkar intressant

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

• Hört men inte intresserad

• Hörde, men förstod inte, men nu verkar det intressant

• Jag har aktivt använt IPFS under lång tid.

69 användare röstade. 13 användare avstod från att rösta.

Källa: will.com