Täpsustan kohe, et ma ei ole selles vallas asjatundja, kuid olen selle tehnoloogia vastu huvi tundnud rohkem kui korra, kuid sellega mängimine tekitas sageli valu. Täna hakkasin uuesti katsetama ja sain mõned tulemused, mida tahaksin jagada. Lühidalt kirjeldatakse IPFS-i installiprotsessi ja mõningaid funktsioone (kõik sai tehtud ubuntu peal, teistel platvormidel pole proovinud). Kui jäite tähelepanuta, mis on IPFS, on see siin üksikasjalikult kirjas: habr.com/en/post/314768
Paigaldamine
Katse puhtuse huvides soovitan see kohe installida mõnda välisserverisse, kuna arvestame kohalikus režiimis ja kaugjuhtimisega töötamise mõningaid lõkse. Siis soovi korral kaua ei lammuta, vähe on.
Märkus: IPFS on parem installida selle kasutaja nimel, kes peaks seda kõige sagedamini kasutama. Fakt on see, et allpool käsitleme läbi paigaldamise võimalust FUSE ja seal on nüansse.
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
ipfs-update versioonid - et näha kõiki allalaadimiseks saadaolevaid versioone. ipfs-uuenduse versioon - praegu installitud versiooni vaatamiseks (kuni IPFS-i pole installitud, pole seda installitud). ipfs-update install uusim - installige IPFS-i uusim versioon. Vastavalt uusima versiooni asemel saate saadaolevate versioonide loendist määrata mis tahes soovitud versiooni.
IPfs-i installimine
ipfs-update install latest
Kontrollige
ipfs --version
Otse paigaldusega üldiselt kõike.
Käivitage IPFS
Initsialiseerimine
Kõigepealt peate läbi viima lähtestamise.
ipfs init
Vastuseks saate midagi sellist:
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
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
Siit algab minu arvates huvitav. Paigaldamise etapis olevad poisid hakkavad juba oma tehnoloogiaid kasutama. Pakutud räsi QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv ei ole spetsiaalselt teie jaoks loodud, vaid väljalasesse õmmeldud. See tähendab, et enne väljalaskmist koostasid nad tervitusteksti, valasid selle IPFS-i ja lisasid installijale aadressi. Minu meelest on see väga lahe. Ja seda faili (täpsemalt kogu kausta) saab nüüd vaadata mitte ainult kohapeal, vaid ka ametlikus lüüsis ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samas võid kindel olla, et kausta sisu pole kuidagi muutunud, sest kui see oleks muutunud, siis oleks muutunud ka räsi.
Muide, antud juhul on IPFS-il mõningaid sarnasusi versioonihaldusserveriga. Kui muudate kausta lähtefaile ja valate kausta uuesti IPFS-i, saab see uue aadressi. Samas ei kao vana kaust niisama kuhugi ja on saadaval oma eelmisel aadressil.
Otsene käivitamine
ipfs daemon
Peaksite saama sellise vastuse:
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
Uste avamine Internetile
Pöörake tähelepanu nendele kahele reale:
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Nüüd, kui olete IPFS-i kohapeal installinud, pääsete IPFS-i liidestele juurde kohalike aadresside abil ja kõik on teile kättesaadav (näiteks localhost:5001/webui/). Kuid välisserverisse installimisel on lüüsid Internetti vaikimisi suletud. Kaks lüüsi:
Seni saab katseteks avada mõlemad pordid (5001 ja 8080), kuid lahinguserveris tuleks muidugi port 5001 tulemüüriga kinni panna. Samuti on olemas port 4001, mis on vajalik selleks, et teised kaaslased teid üles leiaksid. See tuleks jätta avatuks välistele taotlustele.
Avage redigeerimiseks ~/.ipfs/config ja leidke sellest järgmised read:
Muutke 127.0.0.1 oma serveri IP-ks ja salvestage fail, seejärel taaskäivitage ipfs (peatage töötav käsk klahvikombinatsiooniga Ctrl+C ja käivitage see uuesti).
Peaks saama
...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080
Kui webui teie jaoks töötab, saab IPFS-i sätteid selles otse muuta, sealhulgas statistikat vaadata, kuid allpool käsitlen konfiguratsioonivõimalusi otse konfiguratsioonifaili kaudu, mis üldiselt pole kriitiline. Parem on lihtsalt meeles pidada, kus konfiguratsioon täpselt asub ja mida sellega teha, muidu kui veebinägu ei tööta, on see keerulisem.
Siin on esimene lõks, mis võttis aega umbes kolm tundi.
Kui installisite IPFS-i välisserverisse, kuid ei installinud ega käivitanud IPFS-i lokaalselt, peaksite veebiliideses /webui minnes nägema ühenduse viga:
Fakt on see, et webui töötab minu arvates väga mitmetähenduslikult. Esiteks proovib see luua ühenduse selle serveri API-ga, kus liides on avatud (muidugi brauseris oleva aadressi alusel). ja kui see seal ei tööta, siis proovib luua ühenduse kohaliku lüüsiga. Ja kui teie IPFS töötab kohapeal, töötab webui teie jaoks hästi, ainult teie töötate kohaliku IPFS-iga, mitte välise, kuigi avasite webui välises serveris. Seejärel laadite failid üles, kuid mingil põhjusel ei näe te neid välises serveris niisama…
Ja kui see ei tööta lokaalselt, saame ühenduse vea. Meie puhul on vea põhjuseks suure tõenäosusega CORS, millele viitab ka webui, soovitades konfiguratsiooni lisada.
Taaskäivitame ipfsi ja näeme, et webui on edukalt ühendatud (igal juhul peaks see olema, kui avasite lüüsid väljastpoolt tulevate päringute jaoks, nagu eespool kirjeldatud).
Nüüd saate kaustu ja faile otse veebiliidese kaudu üles laadida, samuti luua oma kaustu.
FUSE failisüsteemi paigaldamine
Siin on päris huvitav funktsioon.
Faile (nagu ka kaustu) saame lisada mitte ainult veebiliidese kaudu, vaid ka näiteks otse terminalis
ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test
Viimane räsi on juurkausta räsi.
Seda räsi kasutades saame avada kausta mis tahes ipfs-i sõlmes (mis võib leida meie sõlme ja saada sisu), saame seda teha veebiliideses pordil 5001 või 8080 või lokaalselt ipfs-i kaudu.
ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt
Kuid saate selle ikkagi avada nagu tavalist kausta.
Loome juurusse kaks kausta ja anname oma kasutajale nende õigused.
Saate luua kaustu mujal ja määrata nende tee ipfs deemoni parameetrite kaudu -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path
Nüüd on sellest kaustast lugemine mõnevõrra ebatavaline.
ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
See tähendab, et selle kausta juurtele pole otsest juurdepääsu. Aga sisu saab kätte, teades räsi.
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
Samal ajal töötab kausta sees isegi automaatne lõpetamine, kui tee on määratud.
Nagu ma eespool ütlesin, on sellisel paigaldamisel nüansse: vaikimisi on ühendatud FUSE-kaustad saadaval ainult praegusele kasutajale (isegi root ei saa sellisest kaustast lugeda, rääkimata teistest süsteemi kasutajatest). Kui soovite need kaustad teistele kasutajatele kättesaadavaks teha, peate konfiguratsioonis muutma "FuseAllowOther": false väärtuseks "FuseAllowOther": true. Kuid see pole veel kõik. Kui käivitate IPFS-i root kasutajana, on kõik korras. Ja kui tavakasutaja nimel (isegi sudo), siis saad veateate
mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
Sel juhul peate faili /etc/fuse.conf redigeerima, eemaldades rea #user_allow_other kommentaarid.
Pärast seda taaskäivitage ipfs.
Teadaolevad probleemid FUSE-ga
Rohkem kui üks kord on märgatud probleemi, et pärast ipfsi taaskäivitamist koos paigaldamisega (ja võib-olla ka muudel juhtudel) muutuvad /ipfs ja /ipns ühenduspunktid kättesaamatuks. Neile pole juurdepääsu ja ls -la /ipfs näitab ???? õiguste nimekirjas.
Leidsin sellise lahenduse:
fusermount -z -u /ipfs
fusermount -z -u /ipns
Seejärel taaskäivitage ipfs.
Teenuse lisamine
Mõistagi sobib terminalis jooksmine vaid esmaseks testimiseks. Võitlusrežiimis peaks deemon süsteemi käivitamisel automaatselt käivituma.
Looge sudo nimel fail /etc/systemd/system/ipfs.service ja kirjutage sellele:
USERNAME tuleb loomulikult asendada teie kasutajaga (ja võib-olla on ipfs-programmi täielik tee teie jaoks erinev (peate määrama täieliku tee)).
Aktiveerime teenuse.
sudo systemctl enable ipfs.service
Alustame teenust.
sudo service ipfs start
Teenuse oleku kontrollimine.
sudo service ipfs status
Katse puhtuse huvides on tulevikus võimalik serverit taaskäivitada, et kontrollida, kas ipfs käivitub automaatselt.
Meile tuntud pühade lisamine
Mõelge olukorrale, kus meil on IPFS-sõlmed installitud nii välisesse serverisse kui ka lokaalselt. Välises serveris lisame mõne faili ja proovime selle IPFS-i kaudu CID-i abil kohapeal hankida. Mis juhtub? Loomulikult ei tea kohalik server suure tõenäosusega meie välisserverist midagi ja püüab faili lihtsalt CID järgi leida, “küsib” kõigilt talle saadaolevatelt IPFS-i kaaslastelt (millega tal on juba õnnestunud “tutvuda”). Need omakorda küsivad teistelt. Ja nii edasi, kuni fail leitakse. Tegelikult juhtub sama asi, kui proovime faili ametliku lüüsi kaudu hankida ipfs.io. Kui veab, leitakse fail mõne sekundiga üles. Ja kui ei, siis ei leita seda isegi mõne minutiga, mis mõjutab oluliselt töö mugavust. Kuid me teame, kus see fail esmakordselt ilmub. Miks me siis ei ütle kohe oma kohalikule serverile "Otsi kõigepealt sealt"? Ilmselt saab seda teha.
1. Läheme kaugserverisse ja vaatame faili ~/.ipfs/config config
2. Käivitage sudo teenuse ipfs status ja otsige sellest Swarmi kirjeid, näiteks:
Swarm announcing /ip4/ip_вашего_сервера/tcp/4001
3. Lisame sellest vormi "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID" üldaadressi.
4. Usaldusväärsuse huvides proovime selle aadressi oma kohaliku webui kaudu kaaslastele lisada.
5. Kui kõik on korras, avage kohalik config ~ / .ipfs / config, leidke sealt "Bootstrap": [...
ja lisage saadud aadress kõigepealt massiivi.
Taaskäivitage IPFS.
Nüüd lisame faili välisserverisse ja proovime seda kohalikus serveris taotleda. Peaks kiiresti lendama.
Kuid see funktsioon ei ole veel stabiilne. Niipalju kui ma aru saan, siis isegi kui me Bootstrapis määrame kaaslase aadressi, muudab ipfs töö ajal aktiivsete ühenduste loendit partneritega. Igatahes selle ja soovide arutelu püsipidustuste täpsustamise võimaluse osas käib siin ja tundub, et peaks lisage sellele mõni funktsionaalsus [meiliga kaitstud]+
Praeguste kaaslaste nimekirja saab vaadata nii webuis kui ka terminalis.
Kuni seda funktsionaalsust pole täiustatud, saate kirjutada tööriista, et kontrollida ühenduse olemasolu soovitud partneriga ja kui mitte, siis ühenduse lisamiseks.
Põhjendamine
IPFS-iga juba tuttavate seas on nii IPFS-i poolt- kui ka vastuargumente. Põhimõtteliselt eile arutelu ja ajendas mind uuesti IPFS-i uurima. Ja mis puudutab ülalmainitud arutelu: ma ei saa öelda, et oleksin kindlalt vastu ühelegi sõnavõtjate argumendile (ei nõustu ainult sellega, et poolteist programmeerijat kasutab IPFS-i). Üldiselt on mõlemal omal moel õigus (eriti kommentaar tšekkide kohta paneb mõtlema). Aga kui me loobume moraalsest ja juriidilisest hinnangust, siis kes annab sellele tehnoloogiale tehnilise hinnangu? Minul isiklikult on mingisugune sisetunne, et "seda tuleb teha ühemõtteliselt, sellel on teatud väljavaated". Aga miks täpselt, selget sõnastust pole. Nagu, kui vaadata olemasolevaid tsentraliseeritud tööriistu, siis on need paljuski ees (stabiilsus, kiirus, juhitavus jne). Sellegipoolest on mul üks mõte, mis tundub olevat mõttekas ja mida ilma selliste detsentraliseeritud süsteemideta on vaevalt võimalik rakendada. Muidugi kiikun liiga kõvasti, aga sõnastaksin selle nii: internetis info levitamise põhimõtet tuleb muuta.
Las ma seletan. Kui järele mõelda, siis nüüd on meil infot jaotatud põhimõttel "Loodan, et see, kellele ma selle andsin, kaitseb seda ja see ei lähe kaduma ega lähe kätte nende poolt, kellele see pole mõeldud." Näitena on lihtne kaaluda erinevaid postiteenuseid, pilvesalvestusi jne. Ja millega me lõpuks jõuame? Habré keskuses Infoturbe on esimesel real ja peaaegu iga päev saame uudiseid järjekordse globaalse lekke kohta. Põhimõtteliselt on kõik huvitavamad asjad kirjas <iroonia> imeline artiklit Suvi on peaaegu läbi. Lekkimata andmeid pole peaaegu üldse alles. See tähendab, et peamised Interneti-hiiglased muutuvad suuremaks, nad koguvad üha rohkem teavet ja sellised lekked on omamoodi teabe aatomiplahvatused. Seda pole kunagi varem juhtunud ja siin see on jälle. Samal ajal, kuigi paljud mõistavad riskide olemasolu, usaldavad nad jätkuvalt oma andmeid kolmandate osapoolte ettevõtete kätte. Esiteks pole palju alternatiivi ja teiseks lubavad nad, et on kõik augud lappinud ja seda enam kunagi ei juhtu.
Millist varianti ma näen? Mulle tundub, et andmeid tuleks esialgu levitada avalikult. Kuid avatus ei tähenda antud juhul, et kõik peaks olema lihtsalt loetav. Ma räägin talletamise ja levitamise avatusest, kuid mitte lugemise täielikust avatusest. Eeldan, et infot tuleks levitada avalike võtmetega. Lõppude lõpuks on avalike / privaatvõtmete põhimõte juba vana, peaaegu nagu Internet. Kui teave ei ole konfidentsiaalne ja on mõeldud laiale ringile, siis paigutatakse see kohe avaliku võtmega (kuid siiski krüpteeritud kujul, lihtsalt igaüks saab selle olemasoleva võtmega dekrüpteerida). Ja kui ei, siis pannakse see ilma avaliku võtmeta ja võti ise kantakse üle sellele, millel peaks sellele teabele juurdepääs olema. Samal ajal peaks sellel, kes seda lugema peaks, olema ainult võti ja kust seda teavet saada, ei tohiks ta tegelikult tõusta - ta tõmbab selle lihtsalt võrgust välja (see on uus sisu ja mitte levitamise põhimõte aadress).
Seega peavad ründajad massirünnaku jaoks hankima tohutul hulgal privaatvõtmeid ja tõenäoliselt ei tehta seda ühes kohas. Minu arvates on see ülesanne keerulisem kui konkreetse teenuse häkkimine.
Ja siin on suletud veel üks probleem: autorsuse kinnitamine. Nüüd leiate Internetist palju meie sõprade kirjutatud tsitaate. Aga kus on garantii, et just nemad need kirjutasid? Nüüd, kui iga sellise kirjega kaasneks digiallkiri, oleks see palju lihtsam. Ja pole vahet, kus see teave asub, peamine on allkiri, mida on muidugi raske võltsida.
Ja siin on huvitav: IPFS kannab juba krüpteerimistööriistu (see on ju ehitatud plokiahela tehnoloogiale). Privaatvõti määratakse kohe konfiguratsioonis.
Ma ei ole turbespetsialist ega tea täpselt, kuidas seda õigesti kasutada, kuid mulle tundub, et neid võtmeid kasutatakse IPFS-i sõlmede vahelise vahetuse tasemel. Ja ka js-ipfs ja näidisprojektid nagu orbiit-dbmillel see töötab orbiit.vestlus. See tähendab, et teoreetiliselt saab iga seade (mobiilne ja mitte ainult) hõlpsasti varustada oma krüpteerimis-dekrüpteerimismasinatega. Sel juhul jääb igaühe enda kanda oma privaatvõtmete salvestamine ja igaüks vastutab oma turvalisuse eest ise, mitte ei saa olla mõne ülipopulaarse Interneti-hiiglase järjekordse inimfaktori pantvangis.
Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.
Kas olete IPFS-ist varem kuulnud?
Ma pole kunagi IPFS-ist kuulnud, kuid see tundub huvitav
Ei ole kuulnud ja ei taha kuulda
Kuulnud, aga pole huvitatud
Kuulnud, aga aru ei saanud, aga nüüd tundub huvitav
Olen IPFS-i aktiivselt kasutanud pikka aega.
69 kasutajat hääletas. 13 kasutajat jäi erapooletuks.