IPFS uden smerte (men det er ikke sikkert)

Selv om der allerede er flere artikler om IPFS på Habr.

Lad mig straks præcisere, at jeg ikke er ekspert på dette område, men jeg har ofte vist interesse for denne teknologi. Mine forsøg på at lege med den har ofte forårsaget en del frustration. I dag har jeg igen grebet fat i eksperimenterne og opnået nogle resultater, som jeg gerne vil dele. Kort fortalt vil jeg beskrive installationsprocessen for IPFS og nogle funktioner (alt blev udført på Ubuntu, jeg har ikke prøvet det på andre platforme).

Hvis du har misset, hvad IPFS er, er det skrevet ret detaljeret her: habr.com/ru/post/314768

Installation

For eksperimentets renhed foreslår jeg, at vi straks installerer på en ekstern server, da vi vil se på nogle faldgruber ved at arbejde i lokal og fjern mode. Senere vil det ikke tage lang tid at fjerne det, da der ikke er meget.

Installerer go

Officiel dokumentation
Se den aktuelle version på golang.org/dl

Bemærk: Det er bedst at installere IPFS som den bruger, der forventes at bruge det mest. Grunden til dette er, at vi senere vil se en mulighed med montering via FUSE og der er nogle nuancer.

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

Derefter skal miljøet opdateres (læs mere 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

Tjekker, at go er installeret

go version

Installerer IPFS

Jeg kunne bedst lide installationsmetoden via ipfs-update.

Installerer det med kommandoen

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

Efter dette kan du udføre sådanne kommandoer:

ipfs-update versions — for at se alle tilgængelige versioner til download.
ipfs-update version — for at se den nuværende installerede version (da vi endnu ikke har installeret IPFS, vil det være none).
ipfs-update install latest — installere den seneste version af IPFS. I stedet for latest kan du angive enhver ønsket version fra listen over tilgængelige.

Installerer ipfs

ipfs-update install latest

Vi tjekker

ipfs --version

Hvad angår installationen, så er det i grove træk det hele.

Kørsel af IPFS

Initialisering

Først skal du udføre initialiseringen.

ipfs init

Som svar får du noget 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 udføre den foreslåede kommando

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultat

Hej og velkommen til IPFS!

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

Hvis du ser dette, har du med succes installeret
IPFS og er nu i kontakt med ipfs merkledag!

 -------------------------------------------------------
| Advarsel:                                             |
|   Dette er alpha-software. Brug på eget ansvar!     |
|   Meget mangler eller er ikke poleret. Der er fejl.  |
|   Ikke sikkert endnu. Læs sikkerhedsnotaterne for mere.|
 -------------------------------------------------------

Tjek nogle af de andre filer i denne mappe:

  .\/about
  .\/help
  .\/quick-start     <-- brugseksempler
  .\/readme          <-- denne fil
  .\/security-notes

Her begynder det efter min mening at blive interessant. Drenge bruger allerede deres egne teknologier under installationen. Den foreslåede hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — er ikke genereret specielt til dig, men indbygget i udgivelsen. Det vil sige, at de inden udgivelsen forberedte velkomstteksten, uploadede den til IPFS og tilføjede adressen til installatøren. Jeg synes, det er virkelig sejt. Og denne fil (eller rettere sagt, hele mappen) kan nu ses ikke kun lokalt, men også på den officielle gateway. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. På den måde kan man være sikker på, at indholdet af mappen ikke er ændret, for hvis det var blevet ændret, ville hashen også have ændret sig.

For resten har IPFS i dette tilfælde en vis lighed med en versionskontrolserver. Hvis du laver ændringer i de oprindelige filer i mappen og uploader mappen på ny til IPFS, får den en ny adresse. Den gamle mappe forsvinder ikke bare, men vil være tilgængelig på sin gamle adresse.

Direct launch

ipfs daemon

Du bør få et svar som dette:

ipfs daemon
Initialiserer daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm lytter på /ip4/x.x.x.x/tcp/4001
Swarm lytter på /ip4/127.0.0.1/tcp/4001
Swarm lytter på /ip6/::1/tcp/4001
Swarm annoncerer /ip4/127.0.0.1/tcp/4001
Swarm annoncerer /ip6/::1/tcp/4001
API-server lytter på /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (kun læsning) server lytter på /ip4/127.0.0.1/tcp/8080
Daemon er klar

Åbner dørene til internettet

Bemærk disse to linjer:

WebUI: http://127.0.0.1:5001/webui
Gateway (kun læsning) server lytter på /ip4/127.0.0.1/tcp/8080

Hvis du har installeret IPFS lokalt, vil du have adgang til IPFS-grænsefladerne via lokale adresser, og alt vil være tilgængeligt for dig (for eksempel, localhost:5001/webui/). Men når det installeres på en ekstern server, er gatewayer som standard lukket for internettet. Der er to gatewayer:

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

I øjeblikket kan begge porte (5001 og 8080) åbnes til eksperimenter, men på en produktionsserver bør port 5001 naturligvis lukkes af en firewall. Der er også port 4001, den er nødvendig, så andre peer kan finde dig. Den bør holdes åben for anmodninger udefra.

Åbn for redigering ~/ipfs/config og find disse linjer:

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

Ændre 127.0.0.1 til IP-adressen på din server og gem filen, hvorefter du genstarter ipfs (stop den kørende kommando med Ctrl+C og start den igen).

Du bør få

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

Nu burde de eksterne grænseflader være tilgængelige.

Tjek

http://domenet_eller_ip_server:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Den ovenstående readme-fil skulle åbne.

http://domenet_eller_ip_server:5001/webui/

Den webbaserede grænseflade skulle åbne.

Hvis du har webui kørende, kan IPFS-indstillinger ændres direkte i den, inklusive at se statistik. Men jeg vil nedenfor gennemgå konfigurationsmulighederne direkte gennem konfigurationsfilen, hvilket i det store hele ikke er kritisk. Det er bare bedre at huske, hvor konfigurationsfilen ligger, og hvad man skal gøre med den, for hvis webgrænsefladen ikke virker, så bliver det sværere.

Konfigurer webgrænsefladen til at arbejde med din server

Her er der første faldgrube, som der blev brugt tre timer på.

Hvis du har installeret IPFS på en ekstern server, men ikke har installeret eller kørt IPFS lokalt, så skal du se en forbindelse-fejl ved adgang til /webui i webgrænsefladen:

Problemet er, at webui, efter min mening, fungerer temmelig tvetydigt. Først prøver det at oprette forbindelse til API'en på den server, hvor grænsefladen er åben (selvfølgelig baseret på adressen i browseren). Og hvis det ikke lykkes, prøver det at oprette forbindelse til den lokale gateway. Og hvis du har IPFS kørende lokalt, så vil webui fungere normalt, men du vil kun arbejde med lokal IPFS, ikke den eksterne, selvom du har åbnet webui på den eksterne server. Du uploader filer, men af en eller anden grund ser du dem ikke bare sådan på den eksterne server…

Og hvis den ikke engang er lanceret lokalt, får vi en forbindelsesfejl. I vores tilfælde skyldes fejlen sandsynligvis CORS, som også indikeres af webui, der foreslår at tilføje konfiguration.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_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"]'

Jeg har bare skrevet wildcard ind.

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

De tilføjede overskrifter kan findes alle i den samme ~/.ipfs/config. I mit tilfælde er det

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

Vi genstarter ipfs og ser, at webui har forbindt succesfuldt (i hvert fald skal den, hvis du har åbnet gateways for anmodninger udefra, som beskrevet ovenfor).

Nu kan vi direkte gennem webgrænsefladen uploade mapper og filer samt oprette vores egne mapper.

Montering af FUSE-filsystemet

Dette er en ret interessant funktion.

Vi kan tilføje filer (ligesom mapper) ikke kun gennem webgrænsefladen, men også direkte i terminalen, for eksempel

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

Den sidste hash er hashen af rodmappen.

Ved denne hash kan vi åbne mappen på enhver ipfs-node (som kan finde vores node og få indholdet), vi kan i webgrænsefladen på port 5001 eller 8080, eller vi kan lokalt gennem ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men den kan også åbnes som en almindelig mappe.

Lad os oprette to mapper i roden og give vores bruger adgang til dem.

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

og genstarte ipfs med flaget --mount

ipfs daemon --mount

Man kan oprette mapper andre steder og angive stien til dem via parametre ipfs daemon --mount --mount-ipfs /ipfs_path --mount-ipns /ipns_path

Nu er læsningen fra denne mappe lidt usædvanlig.

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

Det vil sige, at der ikke er direkte adgang til roden af denne mappe. Men man kan få indholdet, hvis man kender 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 autoudfyldning inden i mappen, når man angiver stien.

Som jeg nævnte før, er der detaljer ved sådan en montering: som standard er monterede FUSE-mapper kun tilgængelige for den nuværende bruger (selv root kan ikke læse fra en sådan mappe, for ikke at nævne andre brugere i systemet). Hvis du vil gøre disse mapper tilgængelige for andre brugere, skal du ændre "FuseAllowOther": false til "FuseAllowOther": true i konfigurationen. Men det er stadig ikke det hele. Hvis du kører IPFS som root, er alt OK. Men hvis du kører det som en almindelig bruger (selv med sudo), får du en fejl.

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

I så fald skal du rette /etc/fuse.conf ved at fjerne kommentarstregen #user_allow_other.

Derefter genstarter vi ipfs.

Kendte problemer med FUSE

Der er ofte blevet observeret et problem, at efter en genstart af ipfs med montering (og muligvis i andre tilfælde), bliver monteringspunkterne /ipfs og /ipns utilgængelige. Der er ingen adgang til dem, og ls -la /ipfs viser ???? i listen over rettigheder.

Jeg fandt en sådan løsning:

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

Derefter genstarter vi ipfs.

Tilføjer tjeneste

Selvfølgelig er kørsel i terminalen kun egnet til indledende tests. I driftstilstand skal dæmonen startes automatisk ved systemstart.

Som sudo opretter vi filen /etc/systemd/system/ipfs.service og skriver i 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

USERNAME skal selvfølgelig erstattes med din bruger (og muligvis har den fulde sti til programmet ipfs en anden placering (det er vigtigt at angive den præcise sti)).

Aktiverer tjenesten.

sudo systemctl enable ipfs.service

Starter tjenesten.

sudo service ipfs start

Tjekker tjenestens status.

sudo service ipfs status

For at bevare eksperimentets renhed kan du senere genstarte serveren for at kontrollere, at ipfs starter automatisk.

Tilføjer de kendte peer

Lad os overveje en situation, hvor vi har IPFS-noder installeret både på en ekstern server og lokalt. På den eksterne server tilføjer vi en fil og forsøger at få adgang til den via IPFS lokalt ved hjælp af CID. Hvad vil ske? Naturligvis ved den lokale server sandsynligvis ingenting om vores eksterne server og vil blot forsøge at finde filen via CID «ved at spørge» alle tilgængelige IPFS-peers (som den allerede har haft mulighed for at «lære at kende»). De vil i deres tur spørge andre. Og sådan fortsætter det, indtil filen findes. Faktisk sker det samme, når vi prøver at få adgang til filen via den officielle gateway. ipfs.io. Hvis vi er heldige, bliver filen fundet på et par sekunder. Hvis ikke, vil den ikke blive fundet selv efter flere minutter, hvilket påvirker arbejdskomforten betydeligt. Men vi ved, hvor denne fil først vil dukke op. Så hvorfor fortæller vi ikke straks vores lokale server: «Søg først der»? Tilsyneladende er det muligt.

1. Gå ind på den eksterne server og find i konfigurationen ~/.ipfs/config

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

2. Udfør sudo service ipfs status og se efter posterne Swarm, eksempelvis:

Swarm announcing /ip4/ip_eller_server/tcp/4001

3. Sammenstill et samlet adresseformat som «/ip4/ip_eller_server/tcp/4001/ipfs/$PeerID».

4. For at være på den sikre side prøver vi at tilføje denne adresse til peers via vores lokale webui.

5. Hvis alt er i orden, åbner vi den lokale konfiguration ~/.ipfs/config, finder «Bootstrap»: […
og tilføjer den modtagne adresse som den første i arrayet.

Genstart IPFS.

Nu tilføjer vi en fil på den eksterne server og prøver at anmode om den lokalt. Den burde komme hurtigt.

Men denne funktion er endnu ikke stabil. Som jeg forstår det, selv når vi angiver peer-adressen i Bootstrap, ændrer IPFS under arbejdet listen over aktive forbindelser til peers. Uanset hvad, er der diskussion om dette, og ønsker der er for muligheden for at angive permanente peers. her Og det ser ud til, at formodes der vil blive tilføjet en funktion i ipfs@5.0+

Den aktuelle liste over peers kan ses både i webui og i terminalen.

ipfs swarm peers

Både i webui og terminalen kan man manuelt tilføje sin peer.

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

Indtil dette funktionalitet forbedres, kan man skrive et værktøj, der kontrollerer forbindelsen til den ønskede peer, og hvis ikke, tilføjer forbindelsen.

Refleksioner

Bland dem, der allerede kender til IPFS, er der både argumenter for og imod IPFS. I princippet diskussionen mindede mig om at grave lidt dybere i IPFS. Og angående den nævnte diskussion: jeg kan ikke sige, at jeg er meget imod nogen af de argumenter, der er blevet fremført (jeg er kun uenig i det, at halvanden programør bruger IPFS). Generelt har både parter deres ret (især kommentaren om kvitteringer giver stof til eftertanke). Men hvis man ser bort fra moralsk og juridisk vurdering, hvilken teknisk vurdering giver man så denne teknologi? Jeg har personligt en indre fornemmelse af, at "det er absolut nødvendigt, det har bestemte perspektiver". Men hvorfor præcist, er der ingen klar formulering. Hvis man ser på de eksisterende centraliserede løsninger, så ligger de foran på mange parametre (stabilitet, hastighed, håndterbarhed osv.). Alligevel har jeg en tanke, som virker meningsfuld, og som næppe kan realiseres uden sådanne decentraliserede systemer. Selvfølgelig er jeg lidt ambitiøs, men jeg ville formulere det sådan: princippet for informationsspredning på internettet skal ændres.

Lad mig forklare. Når man tænker over det, så spreder information sig nu efter princippet "Jeg håber, at den, som jeg har givet det til, vil beskytte det, og det ikke vil gå tabt eller blive modtaget af dem, det ikke var tiltænkt". For eksempel er det let at se på forskellige e-mail tjenester, cloud storage osv. Hvad har vi så i sidste ende? På Habr er Informationssikkerhed det på førstepladsen, og næsten hver dag modtager vi nyheder om endnu et globalt databrud. I princippet er alt det mest interessante nævnt i <ironi>den fantastiske<\/ironi> artikel Sommeren er næsten slut. Næsten ingen lækkede data er tilbage. Så de store internet giganter bliver større og akkumulerer mere information, og sådanne brud er en slags informationsmæssige atomvåben. Det har aldrig været sådan før, og nu er det her igen. Selvom mange forstår, at der er risici, vil de fortsat stole på deres data hos tredjeparts virksomheder. For det første er der ikke mange alternativer, og for det andet lover de, at de har lappet alle huller, og at det aldrig vil ske igen.

Hvilket alternativ ser jeg for mig? Jeg mener, at data fra starten bør være tilgængelige åbent. Men åbenhed i dette tilfælde betyder ikke, at alt skal være let at læse. Jeg taler om åbenhed i opbevaring og distribution, men ikke total åbenhed i læsning. Jeg foreslår, at informationen skal distribueres med åbne nøgler. For princippet om åbne/lukkede nøgler er næsten lige så gammelt som internettet. Hvis informationen ikke er fortrolig og er beregnet til et bredt publikum, lægges den straks ud med en åben nøgle (men stadig i krypteret form, så enhver kan dekryptere den med den rådighed nøgle). Og hvis ikke, så lægges den ud uden en åben nøgle, og selve nøglen gives til den, der skal have adgang til denne information. Derudover skal den, der skal læse det, kun have nøglen; hvor man får informationen fra, bør ikke bekymre ham - han henter det blot fra nettet (det er den nye princip for distribution baseret på indhold snarere end adresse).

Dermed skal hackere for en masseangreb skaffe et enormt antal lukkede nøgler, og det vil næppe være muligt at gøre i ét sted. Denne opgave virker også mere kompleks end at hacke en bestemt service.

Og her lukkes endnu et problem: bekræftelse af forfatterskab. I dag kan man finde mange citater på internettet, skrevet af vores bekendte. Men hvor er garantien for, at det netop er dem, der skrev dem? Hvis hver sådan post blev ledsaget af en digital underskrift, ville det være meget nemmere. Og det er ligegyldigt, hvor denne information ligger; det vigtigste er underskriften, som er svært at forfalske.

Og det interessante her er: IPFS har allerede indbygget krypteringsmidler (for det er bygget på blockchain-teknologi). Den private nøgle er straks angivet 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.................

Jeg er ikke sikkerhedsspecialist og kan ikke med sikkerhed vide, hvordan dette skal bruges, men jeg tror, at disse nøgler anvendes på niveauet for kommunikationen mellem IPFS-noder. Og desuden js-ipfs og projekter som orbit-db, som kører på orbit.chat. Teoretisk set kan hver enhed (mobil og ikke-mobil) nemt udstyres med sine egne krypterings- og dekrypteringsmaskiner. I så fald skal alle sørge for at beskytte deres private nøgler, og hver enkelt vil være ansvarlig for sin egen sikkerhed, i stedet for at være en fange af en menneskelig faktor hos en eller anden superpopulær internetgigant.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.

Har du hørt om IPFS før?

• Har aldrig hørt om IPFS, men det lyder spændende

• Har ikke hørt om det og vil ikke høre om det

• Har hørt om det, men har ikke været interesseret

• Har hørt om det, men forstod det ikke, nu lyder det spændende

• Har aktivt brugt IPFS i lang tid nu

69 brugere har stemt. 13 brugere har valgt at undlade at stemme.

Kilde: habr.com