🥇IPFS uten smerte (men dette er ikke nøyaktig)

Til tross for at Habré allerede var det mer enn én artikkel om IPFS.

Jeg vil med en gang presisere at jeg ikke er en ekspert på dette området, men jeg har vist interesse for denne teknologien mer enn en gang, men å prøve å leke med den førte ofte til noe smerte. I dag begynte jeg å eksperimentere igjen og fikk noen resultater som jeg gjerne vil dele. Kort fortalt vil IPFS-installasjonsprosessen og noen funksjoner bli beskrevet (alt ble gjort på ubuntu, jeg har ikke prøvd det på andre plattformer).

Hvis du gikk glipp av hva IPFS er, er det skrevet i detalj her: habr.com/en/post/314768

Installasjon

For renheten til eksperimentet foreslår jeg at du umiddelbart installerer det på en ekstern server, siden vi vil vurdere noen fallgruver med å jobbe i lokal modus og ekstern. Da skal det om ønskelig ikke rives på lenge, det er ikke mye.

Installer go

Offisiell dokumentasjon
Se gjeldende versjon på golang.org/dl

Merk: det er bedre å installere IPFS på vegne av brukeren som skal bruke det oftest. Faktum er at vi nedenfor vil vurdere muligheten for montering via FUSE og det 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

Da må du oppdatere miljøet (mer 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

Sjekker at go er installert

go version

Installer IPFS

Jeg likte installasjonsmetoden best ipfs oppdatering.

Installer den med kommandoen

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

Etter det kan du kjøre følgende kommandoer:

ipfs-oppdateringsversjoner - for å se alle tilgjengelige versjoner for nedlasting.
ipfs-oppdateringsversjon - for å se den installerte versjonen (inntil vi har installert IPFS, vil den ikke være noen).
ipfs-update install siste - installer den nyeste versjonen av IPFS. I stedet for henholdsvis nyeste, kan du spesifisere hvilken som helst ønsket versjon fra listen over tilgjengelige.

Installerer ipfs

ipfs-update install latest

Sjekker

ipfs --version

Direkte med installasjonen generelt sett alt.

Start IPFS

Initialisering

Først må du utføre initialisering.

ipfs init

Som svar vil du motta noe slikt:

 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 kjøre den foreslåtte kommandoen

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

Her begynner etter min mening det interessante. Gutta på installasjonsstadiet begynner allerede å bruke sine egne teknologier. Den foreslåtte hashen QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv er ikke generert spesifikt for deg, men sydd inn i utgivelsen. Det vil si at før utgivelsen forberedte de en velkomsttekst, helte den inn i IPFS og la til adressen til installasjonsprogrammet. Jeg synes det er veldig kult. Og denne filen (mer presist, hele mappen) kan nå sees ikke bare lokalt, men også på den offisielle gatewayen ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samtidig kan du være sikker på at innholdet i mappen ikke har endret seg på noen måte, for hvis det hadde endret seg, så hadde også hashen endret seg.

Forresten, i dette tilfellet har IPFS noen likheter med versjonskontrollserveren. Hvis du gjør endringer i kildefilene til mappen og igjen fyller mappen i IPFS, vil den motta en ny adresse. Samtidig vil den gamle mappen ikke gå noen steder bare sånn og vil være tilgjengelig på den forrige adressen.

Direkte lansering

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

Åpne dørene til Internett

Vær oppmerksom på disse to linjene:

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

Nå, hvis du installerte IPFS lokalt, vil du få tilgang til IPFS-grensesnitt på lokale adresser og alt vil være tilgjengelig for deg (for eksempel, localhost:5001/webui/). Men når den er installert på en ekstern server, er gatewayene som standard stengt for Internett. Gateways to:

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

Foreløpig kan begge portene (5001 og 8080) åpnes for eksperimenter, men på en kampserver skal selvfølgelig port 5001 lukkes med en brannmur. Det er også port 4001, som er nødvendig for at andre jevnaldrende kan finne deg. Det bør stå åpent for forespørsler utenfra.

Åpne ~/.ipfs/config for redigering og finn disse linjene 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"
}

Endre 127.0.0.1 til ip-en til serveren din og lagre filen, og start deretter ipfs på nytt (stopp den kjørende kommandoen med Ctrl+C og start den på nytt).

Burde få

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

Nå skal de eksterne grensesnittene være tilgjengelige.

Sjekk ut

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

Readme-filen ovenfor skal åpnes.

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

Nettgrensesnittet skal åpnes.

Hvis webui fungerer for deg, kan IPFS-innstillingene endres direkte i den, inkludert visning av statistikk, men nedenfor vil jeg vurdere konfigurasjonsalternativer direkte gjennom konfigurasjonsfilen, som vanligvis ikke er kritisk. Det er bare bedre å huske nøyaktig hvor konfigurasjonen er og hva du skal gjøre med den, ellers hvis nettflaten ikke fungerer, blir det vanskeligere.

Sette opp et webgrensesnitt for å fungere med serveren din

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

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

Faktum er at webui, etter min mening, fungerer veldig tvetydig. Først prøver den å koble til APIen til serveren der grensesnittet er åpent (basert på adressen i nettleseren, selvfølgelig). og hvis det ikke fungerer der, prøver det å koble til den lokale gatewayen. Og hvis du har IPFS som kjører lokalt, vil webui fungere bra for deg, bare du vil jobbe med lokal IPFS, og ikke ekstern, selv om du åpnet webui på en ekstern server. Så laster du opp filene, men av en eller annen grunn ser du dem ikke bare sånn på en ekstern server...

Og hvis den ikke kjører lokalt, får vi en tilkoblingsfeil. I vårt tilfelle skyldes feilen mest sannsynlig CORS, som også indikeres av webui, noe som tyder på å legge til en konfigurasjon.

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 registrerte nettopp et jokertegn

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

De tillagte overskriftene kan finnes i samme ~/.ipfs/config. I mitt tilfelle er det det

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

Vi starter ipfs på nytt, og vi ser at webui har koblet til (i alle fall, hvis du åpnet portene for forespørsler utenfra, som beskrevet ovenfor).

Nå kan du laste opp mapper og filer direkte gjennom webgrensesnittet, samt lage dine egne mapper.

Montering av FUSE-filsystemet

Her er en ganske interessant funksjon.

Filer (så vel som mapper) kan vi legge til ikke bare gjennom 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 å bruke denne hashen kan vi åpne en mappe på hvilken som helst ipfs-node (som kan finne noden vår og hente innholdet), vi kan i webgrensesnittet på port 5001 eller 8080, eller vi kan lokalt via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Men du kan fortsatt åpne den som en vanlig mappe.

La oss lage to mapper ved roten og gi rettigheter til dem til brukeren vår.

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

og start ipfs på nytt med --mount flagg

ipfs daemon --mount

Du kan opprette mapper andre steder og spesifisere banen til dem gjennom ipfs daemon-parametere -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Nå er det noe uvanlig å lese fra denne mappen.

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

Det vil si at det ikke er direkte tilgang til roten til denne mappen. Men du kan få innholdet, vel vitende om hasjen.

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 autofullføring inne i mappen når banen er spesifisert.

Som jeg sa ovenfor, er det finesser med slik montering: som standard er monterte FUSE-mapper kun tilgjengelig for gjeldende bruker (selv root vil ikke kunne lese fra en slik mappe, for ikke å nevne andre brukere i systemet). Hvis du vil gjøre disse mappene tilgjengelige for andre brukere, må du i konfigurasjonen endre "FuseAllowOther": false til "FuseAllowOther": true. Men det er ikke alt. Hvis du kjører IPFS som root, er alt OK. Og hvis du er på vegne av en vanlig bruker (til og med sudo), vil du få en feilmelding

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

I dette tilfellet må du redigere /etc/fuse.conf ved å avkommentere #user_allow_other-linjen.

Etter det, start ipfs på nytt.

Kjente problemer med FUSE

Problemet har blitt lagt merke til mer enn én gang at etter omstart av ipfs med montering (og kanskje i andre tilfeller), blir /ipfs og /ipns monteringspunktene utilgjengelige. Det er ingen tilgang til dem, og ls -la /ipfs viser ???? i rettighetslisten.

Fant denne løsningen:

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

Start deretter ipfs på nytt.

Legger til en tjeneste

Å kjøre i terminalen er selvfølgelig kun egnet for innledende tester. I kampmodus skal demonen starte automatisk ved systemstart.

På vegne av sudo, opprett filen /etc/systemd/system/ipfs.service og skriv 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

BRUKERNAVN må selvfølgelig erstattes med brukeren din (og kanskje den fullstendige banen til ipfs-programmet vil være annerledes for deg (du må spesifisere den fullstendige banen)).

Vi aktiverer tjenesten.

sudo systemctl enable ipfs.service

Vi starter tjenesten.

sudo service ipfs start

Sjekker statusen til tjenesten.

sudo service ipfs status

For renheten til eksperimentet vil det være mulig å starte serveren på nytt i fremtiden for å sjekke at ipfs starter automatisk.

Legge til kjente for oss høytider

Tenk på en situasjon der vi har IPFS-noder installert både på en ekstern server og lokalt. På en ekstern server legger vi til en fil og prøver å få den via IPFS lokalt av CID. Hva vil skje? Selvfølgelig vet den lokale serveren mest sannsynlig ikke noe om vår eksterne server og vil ganske enkelt prøve å finne filen med CID ved å "spørre" alle IPFS-kolleger som er tilgjengelige for den (som den allerede har klart å "bli kjent med"). De vil på sin side spørre andre. Og så videre, til filen er funnet. Det samme skjer faktisk når vi prøver å få filen gjennom den offisielle gatewayen ipfs.io. Hvis du er heldig, vil filen bli funnet i løpet av få sekunder. Og hvis ikke, vil den ikke bli funnet selv om noen få minutter, noe som i stor grad påvirker arbeidskomforten. Men vi vet hvor denne filen først vises. Så hvorfor sier vi ikke umiddelbart til vår lokale server "Søk der først"? Tilsynelatende kan dette gjøres.

1. Vi går til den eksterne serveren og ser i ~/.ipfs/config-konfigurasjonen

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

2. Kjør sudo service ipfs status og se etter Swarm-oppføringer i den, for eksempel:

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

3. Vi legger fra denne den generelle adressen til skjemaet "/ip4/ip_din_server/tcp/4001/ipfs/$PeerID".

4. For pålitelighet vil vi prøve å legge til denne adressen til jevnaldrende via vår lokale webui.

5. Hvis alt er OK, åpne den lokale konfigurasjonen ~ / .ipfs / config, finn "Bootstrap" i den: [...
og legg først den mottatte adressen til matrisen.

Start IPFS på nytt.

La oss nå legge til filen på den eksterne serveren og prøve å be om den på den lokale. Bør fly fort.

Men denne funksjonaliteten er ennå ikke stabil. Så vidt jeg forstår, selv om vi spesifiserer adressen til en peer i Bootstrap, endrer ipfs listen over aktive forbindelser med peers under drift. Uansett er diskusjonen om dette og ønsker om muligheten for å spesifisere faste høytider i gang her og det virker som antatt legge til litt funksjonalitet [e-postbeskyttet]+

Listen over nåværende jevnaldrende kan sees både på webuiet og i terminalen.

ipfs swarm peers

Og her og der kan du legge til festen manuelt.

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

Inntil denne funksjonaliteten er forbedret, kan du skrive et verktøy for å se etter en tilkobling til ønsket peer og, hvis ikke, legge til en tilkobling.

Argumentasjon

Blant de som allerede er kjent med IPFS er det både argumenter for og imot IPFS. I utgangspunktet i går diskusjon og fikk meg til å grave inn i IPFS igjen. Og med hensyn til diskusjonen nevnt ovenfor: Jeg kan ikke si at jeg er sterkt imot ethvert argument fra de som snakket (jeg er bare uenig i det faktum at halvannen programmerere bruker IPFS). Generelt har begge rett på hver sin måte (spesielt kommentar om sjekker får deg til å tenke). Men hvis vi forkaster den moralske og juridiske vurderingen, hvem vil gi en teknisk vurdering av denne teknologien? Personlig har jeg en slags indre følelse av at «dette må gjøres entydig, det har visse utsikter». Men hvorfor akkurat, det er ingen klar formulering. Som, hvis du ser på de eksisterende sentraliserte verktøyene, så er de i mange henseender langt foran (stabilitet, hastighet, håndterbarhet, etc.). Likevel har jeg en tanke som virker fornuftig og som vanskelig lar seg gjennomføre uten slike desentraliserte systemer. Jeg svinger selvfølgelig for hardt, men jeg ville formulert det slik: Prinsippet om å spre informasjon på Internett må endres.

La meg forklare. Hvis du tenker på det, har vi nå informasjon distribuert i henhold til prinsippet "Jeg håper at den jeg ga den til vil beskytte den og den vil ikke gå tapt eller mottas av de som den ikke var ment for." Som et eksempel er det lett å vurdere ulike e-posttjenester, skylagringer osv. Og hva ender vi opp med? På Habré hub Informasjonssikkerhet er på første linje og nesten hver dag mottar vi nyheter om en ny global lekkasje. I prinsippet er alle de mest interessante tingene oppført i <ironi> vidunderlig artikkel Sommeren er nesten over. Det er nesten ingen ulekkede data igjen. Det vil si at de viktigste Internett-gigantene blir større, de akkumulerer mer og mer informasjon, og slike lekkasjer er en slags informasjon atomeksplosjoner. Dette har aldri skjedd før, og her er det igjen. Samtidig, selv om mange forstår at det er risikoer, vil de fortsette å stole på dataene sine til tredjepartsselskaper. For det første er det ikke så mye alternativ, og for det andre lover de at de har lappet alle hullene og at dette aldri skal skje igjen.

Hvilket alternativ ser jeg? Det virker for meg som om data i utgangspunktet bør distribueres åpent. Men åpenhet i dette tilfellet betyr ikke at alt skal være lett å lese. Jeg snakker om åpenheten i lagring og distribusjon, men ikke total åpenhet i lesing. Jeg antar at informasjon skal distribueres med offentlige nøkler. Tross alt er prinsippet om offentlige / private nøkler allerede gammelt, nesten som Internett. Hvis informasjonen ikke er konfidensiell og er ment for en bred krets, legges den ut umiddelbart med en offentlig nøkkel (men fortsatt i kryptert form, bare hvem som helst kan dekryptere den med den tilgjengelige nøkkelen). Og hvis ikke, så legges den ut uten offentlig nøkkel, og selve nøkkelen overføres til det som skal ha tilgang til denne informasjonen. Samtidig skal den som skal lese den bare ha en nøkkel, og hvor han kan få tak i denne informasjonen, han skal egentlig ikke sveve - han trekker den bare fra nettverket (dette er det nye prinsippet om distribusjon etter innhold, ikke etter innhold). adresse).

Derfor, for et masseangrep, vil angripere trenge å skaffe et stort antall private nøkler, og dette vil neppe bli gjort på ett sted. Denne oppgaven, slik jeg ser det, er vanskeligere enn å hacke en bestemt tjeneste.

Og her er et annet problem lukket: bekreftelse av forfatterskap. Nå på Internett kan du finne mange sitater skrevet av våre venner. Men hvor er garantien for at det var de som skrev dem? Nå, hvis hver slik post ble ledsaget av en digital signatur, ville det være mye enklere. Og det spiller ingen rolle hvor denne informasjonen ligger, det viktigste er signaturen, som selvfølgelig er vanskelig å forfalske.

Og her er det som er interessant her: IPFS har allerede krypteringsverktøy (det er tross alt bygget på blockchain-teknologi). Den private nøkkelen spesifiseres umiddelbart i konfigurasjonen.

  "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 en sikkerhetsspesialist og kan ikke vite nøyaktig hvordan jeg skal bruke den riktig, men det ser ut til at disse nøklene brukes på nivået for utveksling mellom IPFS-noder. Og også js-ipfs og eksempelprosjekter som f.eks bane-dbsom det fungerer på orbit.chat. Det vil si at teoretisk sett kan hver enhet (mobil og ikke bare) enkelt utstyres med sine egne krypterings-dekrypteringsmaskiner. I dette tilfellet gjenstår det bare for alle å ta seg av å lagre sine private nøkler, og alle vil være ansvarlige for sin egen sikkerhet, og ikke være gisler for en annen menneskelig faktor på en superpopulær Internett-gigant.

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

Har du hørt om IPFS før?

Jeg har aldri hørt om IPFS, men det virker interessant
Har ikke hørt og vil ikke høre
Hørt men ikke interessert
Hørt, men forsto ikke, men nå virker det interessant
Jeg har brukt IPFS aktivt i lang tid.

69 brukere stemte. 13 brukere avsto.

Kilde: www.habr.com

IPFS uten smerte (men dette er ikke nøyaktig)