🥇IPFS uden smerte (men dette er ikke nøjagtigt)

På trods af at Habré allerede var det mere end én artikel om IPFS.

Jeg vil med det samme præcisere, at jeg ikke er ekspert på dette område, men jeg har vist interesse for denne teknologi mere end én gang, men at forsøge at lege med det gav ofte nogle smerter. I dag begyndte jeg at eksperimentere igen og fik nogle resultater, som jeg gerne vil dele. Kort fortalt vil IPFS installationsprocessen og nogle funktioner blive beskrevet (alt blev gjort på ubuntu, jeg har ikke prøvet det på andre platforme).

Hvis du gik glip af, hvad IPFS er, er det skrevet i nogle detaljer her: habr.com/en/post/314768

Installation

Af hensyn til eksperimentets renhed foreslår jeg straks at installere det på en ekstern server, da vi vil overveje nogle faldgruber ved at arbejde i lokal tilstand og fjernbetjening. Så bliver det om ønsket ikke revet ned i lang tid, der er ikke meget.

Installer go

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

Bemærk: det er bedre at installere IPFS på vegne af den bruger, der skal bruge det oftest. Faktum er, at vi nedenfor vil overveje muligheden for at montere via FUSE og der er 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

Så skal du opdatere miljøet (flere detaljer 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

Kontrollerer, at go er installeret

go version

Installer IPFS

Jeg kunne bedst lide installationsmetoden ipfs opdatering.

Installer det med kommandoen

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

Derefter kan du køre følgende kommandoer:

ipfs-opdateringsversioner - for at se alle tilgængelige versioner til download.
ipfs-opdateringsversion - for at se den aktuelt installerede version (indtil vi har installeret IPFS, vil den ikke være nogen).
ipfs-update installer den seneste - installer den seneste version af IPFS. I stedet for henholdsvis nyeste, kan du angive enhver ønsket version fra listen over tilgængelige.

Installation af ipfs

ipfs-update install latest

Kontrol

ipfs --version

Direkte med installationen i generelle vendinger alt.

Start IPFS

Initialisering

Først skal du udføre initialisering.

ipfs init

Som svar vil du modtage 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 køre den foreslåede kommando

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Outcome

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

Her begynder det interessante efter min mening. Fyrene på installationsstadiet er allerede begyndt at bruge deres egne teknologier. Den foreslåede hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv er ikke genereret specifikt til dig, men syet ind i udgivelsen. Det vil sige, før udgivelsen forberedte de en velkomsttekst, hældte den i IPFS og tilføjede adressen til installationsprogrammet. Jeg synes, det er meget fedt. Og denne fil (mere præcist, hele mappen) kan nu ses ikke kun lokalt, men også på den officielle gateway ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samtidig kan du være sikker på, at indholdet af mappen ikke har ændret sig på nogen måde, for hvis det havde ændret sig, så ville hashen også have ændret sig.

Forresten, i dette tilfælde har IPFS nogle ligheder med versionskontrolserveren. Hvis du foretager ændringer i mappens kildefiler og igen hælder mappen i IPFS, vil den modtage en ny adresse. Samtidig vil den gamle mappe ikke gå nogen steder bare sådan og vil være tilgængelig på dens tidligere adresse.

Direkte lancering

ipfs daemon

Du bør modtage 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

Åbner dørene til internettet

Vær opmærksom på disse to linjer:

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

Nu, hvis du installerede IPFS lokalt, så vil du få adgang til IPFS-grænseflader på lokale adresser, og alt vil være tilgængeligt for dig (f.eks. localhost:5001/webui/). Men når de er installeret på en ekstern server, er gateways som standard lukket til internettet. Gateways to:

webui admin (github) på port 5001.
Ekstern API på port 8080 (skrivebeskyttet).

Indtil videre kan begge porte (5001 og 8080) åbnes for eksperimenter, men på en kampserver skal port 5001 selvfølgelig lukkes med en firewall. Der er også port 4001, som er nødvendig for at andre jævnaldrende kan finde dig. Det bør stå åbent for udefrakommende anmodninger.

Åbn ~/.ipfs/config for redigering og find disse linjer 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"
}

Skift 127.0.0.1 til din servers ip og gem filen, og genstart derefter ipfs (stop den kørende kommando med Ctrl+C og start den igen).

burde få

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

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

Kontrollere

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

Ovenstående readme-fil skulle åbne.

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

Webgrænsefladen skal åbne.

Hvis webui virker for dig, så kan IPFS-indstillingerne ændres direkte i den, inklusive visning af statistik, men nedenfor vil jeg overveje konfigurationsmuligheder direkte gennem konfigurationsfilen, hvilket generelt ikke er kritisk. Det er bare bedre at huske præcis, hvor konfigurationen er, og hvad man skal gøre med den, ellers vil det være vanskeligere, hvis web-ansigtet ikke virker.

Opsætning af en webgrænseflade til at arbejde med din server

Her er den første faldgrube, som tog omkring tre timer.

Hvis du installerede IPFS på en ekstern server, men ikke installerede eller kørte IPFS lokalt, så når du går til /webui i webgrænsefladen, skulle du se en forbindelsesfejl:

Faktum er, at webui efter min mening fungerer meget tvetydigt. Først forsøger den at oprette forbindelse til serverens API, hvor grænsefladen er åben (baseret på adressen i browseren, selvfølgelig). og hvis det ikke virker der, forsøger det at oprette forbindelse til den lokale gateway. Og hvis du har IPFS, der kører lokalt, så vil webui fungere fint for dig, kun du vil arbejde med lokal IPFS, og ikke ekstern, selvom du åbnede webui på en ekstern server. Så uploader du filerne, men af en eller anden grund ser du dem ikke bare sådan på en ekstern server...

Og hvis det ikke kører lokalt, så får vi en forbindelsesfejl. I vores tilfælde skyldes fejlen højst sandsynligt CORS, hvilket også er angivet af webui, hvilket tyder på at tilføje 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"]'

Jeg har lige registreret et jokertegn

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

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

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

Vi genstarter ipfs, og vi ser, at webui har oprettet forbindelse (under alle omstændigheder, hvis du åbnede gateways for anmodninger udefra, som beskrevet ovenfor).

Nu kan du uploade mapper og filer direkte via webgrænsefladen, samt oprette dine egne mapper.

Montering af FUSE-filsystemet

Her er en ret interessant funktion.

Filer (såvel som mapper) kan vi tilføje ikke kun via webgrænsefladen, men også direkte i terminalen, f.eks.

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

Den sidste hash er hashen i rodmappen.

Ved hjælp af denne hash kan vi åbne en mappe på enhver ipfs-node (som kan finde vores node og hente indholdet), vi kan i webgrænsefladen på port 5001 eller 8080, eller vi kan lokalt via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men du kan stadig åbne den som en almindelig mappe.

Lad os oprette to mapper ved roden og give rettigheder til dem til vores bruger.

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

og genstart ipfs med --mount flag

ipfs daemon --mount

Du kan oprette mapper andre steder og angive stien til dem gennem ipfs daemon-parametrene -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Nu er det noget usædvanligt at læse fra denne mappe.

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 du kan få indholdet ved at kende 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 selv autofuldførelse inde i mappen, når stien er angivet.

Som jeg sagde ovenfor, er der finesser med sådan montering: som standard er monterede FUSE-mapper kun tilgængelige for den aktuelle bruger (selv root vil ikke være i stand til at 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 i konfigurationen ændre "FuseAllowOther": false til "FuseAllowOther": true. Men det er ikke alt. Hvis du kører IPFS som root, så er alt OK. Og hvis du er på vegne af en almindelig bruger (selv 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 dette tilfælde skal du redigere /etc/fuse.conf ved at fjerne kommentering af #user_allow_other-linjen.

Genstart derefter ipfs.

Kendte problemer med FUSE

Problemet er blevet bemærket mere end én gang, at efter genstart af ipfs med montering (og måske i andre tilfælde), bliver /ipfs og /ipns monteringspunkterne utilgængelige. Der er ingen adgang til dem, og ls -la /ipfs viser ???? på listen over rettigheder.

Fandt denne løsning:

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

Genstart derefter ipfs.

Tilføjelse af en tjeneste

Kørsel i terminalen er naturligvis kun egnet til indledende tests. I kamptilstand bør dæmonen starte automatisk ved systemstart.

På vegne af sudo skal du oprette filen /etc/systemd/system/ipfs.service og skrive til 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

BRUGERNAVN skal selvfølgelig erstattes med din bruger (og måske vil den fulde sti til ipfs-programmet være anderledes for dig (du skal angive den fulde sti)).

Vi aktiverer tjenesten.

sudo systemctl enable ipfs.service

Vi starter tjenesten.

sudo service ipfs start

Kontrol af tjenestens status.

sudo service ipfs status

Af hensyn til eksperimentets renhed vil det være muligt at genstarte serveren i fremtiden for at kontrollere, at ipfs starter automatisk.

Tilføjelse kendt for os fester

Overvej en situation, hvor vi har IPFS-noder installeret både på en ekstern server og lokalt. På en ekstern server tilføjer vi en fil og forsøger at få den via IPFS lokalt af CID. Hvad vil der ske? Selvfølgelig ved den lokale server højst sandsynligt ikke noget om vores eksterne server og vil blot forsøge at finde filen ved CID ved at "spørge" alle IPFS-peers, der er tilgængelige for den (som den allerede har formået at "blive bekendt med"). De vil til gengæld spørge andre. Og så videre, indtil filen er fundet. Faktisk sker det samme, når vi forsøger at få filen gennem den officielle gateway ipfs.io. Hvis du er heldig, vil filen blive fundet i løbet af få sekunder. Og hvis ikke, vil det ikke blive fundet selv om et par minutter, hvilket i høj grad påvirker arbejdskomforten. Men vi ved, hvor denne fil først vises. Så hvorfor fortæller vi ikke straks vores lokale server "Søg der først"? Det kan tilsyneladende lade sig gøre.

1. Vi går til fjernserveren og ser i ~/.ipfs/config config

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

2. Kør sudo service ipfs status og se efter Swarm-indgange i den, for eksempel:

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

3. Vi tilføjer herfra den generelle adresse på formen "/ip4/ip_din_server/tcp/4001/ipfs/$PeerID".

4. For pålidelighedens skyld vil vi forsøge at tilføje denne adresse til peers via vores lokale webui.

5. Hvis alt er OK, skal du åbne den lokale config ~ / .ipfs / config, finde "Bootstrap" i den: [...
og tilføje den modtagne adresse først til arrayet.

Genstart IPFS.

Lad os nu tilføje filen til den eksterne server og prøve at anmode om den på den lokale. Skal flyve hurtigt.

Men denne funktionalitet er endnu ikke stabil. Så vidt jeg forstår, selv hvis vi angiver adressen på en peer i Bootstrap, ændrer ipfs listen over aktive forbindelser med peers under drift. Under alle omstændigheder er diskussionen herom og ønsker vedrørende muligheden for at specificere faste gilder i gang her og det virker som antages tilføje noget funktionalitet [e-mail beskyttet]+

Listen over aktuelle peers kan ses både i webuiet og i terminalen.

ipfs swarm peers

Og her og der kan du tilføje din fest manuelt.

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

Indtil denne funktionalitet er blevet forbedret, kan du skrive et værktøj til at tjekke for en forbindelse til den ønskede peer og, hvis ikke, tilføje en forbindelse.

Ræsonnement

Blandt dem, der allerede er fortrolige med IPFS, er der både argumenter for og imod IPFS. I bund og grund i går diskussion og fik mig til at grave i IPFS igen. Og med hensyn til diskussionen nævnt ovenfor: Jeg kan ikke sige, at jeg er stærkt imod ethvert argument fra dem, der talte (jeg er kun uenig i, at halvanden programmør bruger IPFS). Generelt har begge ret på hver deres måde (især kommentar om checks får dig til at tænke). Men hvis vi kasserer den moralske og juridiske vurdering, hvem vil så give en teknisk vurdering af denne teknologi? Personligt har jeg en form for indre følelse af, at "det her skal gøres utvetydigt, det har visse perspektiver." Men hvorfor præcist, er der ingen klar formulering. Ligesom hvis man ser på de eksisterende centraliserede værktøjer, så er de i mange henseender langt foran (stabilitet, hastighed, håndterbarhed osv.). Ikke desto mindre har jeg en tanke, som synes at give mening, og som næppe kan implementeres uden sådanne decentrale systemer. Jeg svinger selvfølgelig for hårdt, men jeg vil formulere det sådan: Princippet om at formidle information på internettet skal ændres.

Lad mig forklare. Hvis du tænker over det, så har vi nu information distribueret i henhold til princippet "Jeg håber, at den, jeg gav den til, vil beskytte den, og den vil ikke gå tabt eller modtages af dem, som den ikke var beregnet til." Som et eksempel er det nemt at overveje forskellige mailtjenester, cloud storage mv. Og hvad ender vi med? På Habré hub Informationssikkerhed er på første linje og næsten hver dag modtager vi nyheder om endnu et globalt læk. I princippet er alle de mest interessante ting listet i <ironi> vidunderlig artikel Sommeren er næsten forbi. Der er næsten ingen ulækket data tilbage. Det vil sige, at de vigtigste internetgiganter bliver større, de akkumulerer mere og mere information, og sådanne lækager er en slags informations-atomeksplosioner. Dette er aldrig sket før, og her er det igen. På samme tid, selvom mange forstår, at der er risici, vil de fortsat stole på deres data til tredjepartsvirksomheder. For det første er der ikke meget alternativ, og for det andet lover de, at de har lappet alle hullerne, og det vil aldrig ske igen.

Hvilken mulighed ser jeg? Det forekommer mig, at data i første omgang skal distribueres åbent. Men åbenhed i dette tilfælde betyder ikke, at alt skal være let at læse. Jeg taler om åbenheden i opbevaring og distribution, men ikke total åbenhed i læsning. Jeg går ud fra, at information skal distribueres med offentlige nøgler. Når alt kommer til alt, er princippet om offentlige / private nøgler allerede gammelt, næsten som internettet. Hvis oplysningerne ikke er fortrolige og er beregnet til en bred kreds, så udlægges de straks med en offentlig nøgle (men stadig i krypteret form, bare enhver kan dekryptere dem med den tilgængelige nøgle). Og hvis ikke, så er den udlagt uden en offentlig nøgle, og selve nøglen overføres til det, der skal have adgang til disse oplysninger. Samtidig skal den, der skal læse den kun have en nøgle, og hvor man kan få denne information, han skal ikke rigtig svæve - han trækker den bare fra netværket (dette er det nye princip om distribution efter indhold, ikke ved adresse).

For et masseangreb skal angriberne således anskaffe et stort antal private nøgler, og det er usandsynligt, at det bliver gjort ét sted. Denne opgave, som jeg ser det, er sværere end at hacke en bestemt tjeneste.

Og her er endnu et problem lukket: bekræftelse af forfatterskab. Nu på internettet kan du finde mange citater skrevet af vores venner. Men hvor er garantien for, at det var dem, der skrev dem? Nu, hvis hver sådan post blev ledsaget af en digital signatur, ville det være meget nemmere. Og det er lige meget, hvor denne information ligger, det vigtigste er signaturen, som selvfølgelig er svær at forfalske.

Og her er det interessante her: IPFS har allerede krypteringsværktøjer (det er trods alt bygget på blockchain-teknologi). Den private nøgle angives straks 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 vide præcis, hvordan jeg bruger det korrekt, men det forekommer mig, at disse nøgler bruges på niveauet for udveksling mellem IPFS-noder. Og også js-ipfs og eksempelprojekter som f.eks orbit-dbsom det virker på orbit.chat. Det vil sige, at teoretisk set kan hver enhed (mobil og ikke kun) nemt udstyres med sine egne krypterings-dekrypteringsmaskiner. I dette tilfælde er det kun for alle at sørge for at gemme deres private nøgler, og alle vil være ansvarlige for deres egen sikkerhed og ikke være gidsler for en anden menneskelig faktor på en superpopulær internetgigant.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Har du hørt om IPFS før?

Jeg har aldrig hørt om IPFS, men det virker interessant
Har ikke hørt og ønsker ikke at høre
Hørt men ikke interesseret
Hørte, men forstod ikke, men nu virker det interessant
Jeg har brugt IPFS aktivt i lang tid.

69 brugere stemte. 13 brugere undlod at stemme.

Kilde: www.habr.com

IPFS uden smerte (men dette er ikke nøjagtigt)