🥇IPFS brez bolečin (morda)

Kljub temu, da je na Habrju že več kot en članek o IPFS.

Takoj naj povem, da nisem strokovnjak na tem področju, ampak me je ta tehnologija večkrat pritegnila. Moji poskusi z njo so pogosto povzročali nekaj težav. Danes sem ponovno začel eksperimentirati in dosegel nekaj rezultatov, s katerimi bi rad delil. Na kratko, opisal bom postopek namestitve IPFS in nekatere funkcionalnosti (vse izvedeno na ubuntu, na drugih platformah nisem poskusil).

Če ste zamudili, kaj je IPFS, je to podrobno opisano tukaj: habr.com/ru/post/314768

Namestitev

Za čistočo eksperimenta priporočam, da takoj namestite na nekem zunanjem strežniku, saj bomo razpravljali o nekaterih skritih težavah pri delu v lokalnem načinu in na daljavo. Pozneje ga lahko enostavno odstranite, saj ni veliko dela.

Namestimo go

Uradna dokumentacija
Trenutno različico si oglejte na golang.org/dl

Opomba: bolje je namestiti IPFS s uporabniškim računom, s katerim boste najpogosteje delali. To zato, ker bomo spodaj obravnavali možnost montaže preko FUSE in tam so nekatere posebnosti.

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

Potem je treba posodobiti okolje (več o tem tukaj: 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

Preverimo, ali je go nameščen

go version

Namestimo IPFS

Najbolj mi je všeč način namestitve preko ipfs-update.

Namestimo ga z ukazom

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

Po tem lahko izvajate naslednje ukaze:

ipfs-update versions — da si ogledate vse razpoložljive različice za prenos.
ipfs-update version — da vidite trenutno nameščeno različico (dokler IPFS ni nameščen, bo prikazano 'none').
ipfs-update install latest — namestiti najnovejšo različico IPFS. Namesto 'latest' lahko navedete katero koli želeno različico s seznama razpoložljivih.

Namestimo ipfs

ipfs-update install latest

Proveravamo.

ipfs --version

Na splošno, kar zadeva namestitev, to je to.

Zagon IPFS

Inicijalizacija

Najprej je treba izvesti inicializacijo.

ipfs init

V odgovoru boste prejeli nekaj takega:

 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

Lahko izvedete predlagani ukaz

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Результат.

Pozdravljeni in dobrodošli na IPFS!

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

Če to vidite, ste uspešno namestili
IPFS in sedaj komunicirate z ipfs merkledag!

 -------------------------------------------------------
| Opozorilo:                                           |
|   To je alfa programska oprema. Uporabite na lastno  |
|   odgovornost! Veliko stvari manjka ali nima         |
|   dodelave. Obstajajo napake. Ni še varno.          |
|   Preberite varnostne opombe za več informacij.     |
 -------------------------------------------------------

Oglejte si nekatere druge datoteke v tej mapi:

  .\/about
  .\/help
  .\/quick-start     <-- primeri uporabe
  .\/readme          <-- ta datoteka
  .\/security-notes

Tu se mi zdi, da se začne zanimivo. Fantje že med namestitvijo začnejo uporabljati svoje tehnologije. Ponuditi hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — ni bilo posebej generirano za vas, ampak je vključeno v izdajo. To pomeni, da so pred izdajo pripravili pozdravno besedilo, ga naložili v IPFS in dodali naslov v installer. Po mojem mnenju, to je zelo kul. In to datoteko (natančneje, vso mapo) je zdaj mogoče pregledati ne le lokalno, ampak tudi na uradnem prehodu. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Hkrati pa si lahko zagotovite, da se vsebina mape nikakor ni spremenila, saj bi se, če bi se, tudi hash spremenil.

Mimogrede, v tem primeru ima IPFS nekaj podobnosti z sistemom za nadzor različic. Če v izvorne datoteke mape vnesete spremembe in jo ponovno naložite v IPFS, bo dobila nov naslov. Stara mapa pa se ne bo kar nekam izgubila in bo dostopna po svojem prejšnjem naslovu.

Neposredno zaženite

ipfs daemon

V odgovor bi morali dobiti nekaj takega:

ipfs daemon
Inicializacija daemona...
go-ipfs različica: 0.4.22-
Repo različica: 7
Sistemska različica: amd64/linux
Golang različica: go1.12.7
Swarm posluša na /ip4/x.x.x.x/tcp/4001
Swarm posluša na /ip4/127.0.0.1/tcp/4001
Swarm posluša na /ip6/::1/tcp/4001
Swarm naznanjuje /p2p-circuit
Swarm oglašuje /ip4/127.0.0.1/tcp/4001
Swarm oglašuje /ip6/::1/tcp/4001
API strežnik posluša na /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Prehod (samo za branje) strežnik posluša na /ip4/127.0.0.1/tcp/8080
Daemon je pripravljen

Odpiramo vrata za internet

Pozorni bodite na ti dve vrstici:

WebUI: http://127.0.0.1:5001/webui
Prehod (samo za branje) strežnik posluša na /ip4/127.0.0.1/tcp/8080

Če ste IPFS namestili lokalno, se boste do IPFS vmesnikov povezovali po lokalnih naslovih in vam bo vse dostopno (na primer, localhost:5001/webui/). Vendar pa so privzeto, ko je nameščen na zunanjem strežniku, prehodi zaprti za internet. Prehodi so dva:

Admin panel webui (github) na portu 5001.
Zunanje API na portu 8080 (readonly).

Za eksperimente je možno odpreti oba porta (5001 in 8080), vendar pa je na produkcijskem strežniku port 5001 seveda treba zapreti s požarnim zidom. Obstaja tudi port 4001, ki je potreben, da vas lahko najdejo drugi pari. Ta je treba pustiti odprt za zunanje poizvedbe.

Odprimo za urejanje ~/ipfs/config in najdemo te vrstice:

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

Spremenimo 127.0.0.1 v IP vašega strežnika in shranimo datoteko, nato pa ponovno zaženemo ipfs (ustavimo z ukazom Ctrl+C in ponovno zaženemo).

Moral bi dobiti

...
WebUI: http://ip_vašega_strežnika:5001/webui
Gateway (readonly) strežnik posluša na /ip4/ip_vašega_strežnika/tcp/8080

Zdaj bi morali biti zunanji vmesniki dostopni.

Preverite

http://domena_ali_ip_strežnika:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Odprti bi morali biti zgoraj navedeni readme datoteki.

http://domena_ali_ip_strežnika:5001/webui/

Odprti bi se moral spletni vmesnik.

Če vam deluje webui, lahko nastavitve IPFS spreminjate kar tam, tudi si ogledate statistiko, a spodaj bom obravnaval možnosti konfiguracije neposredno preko datoteke konfiguracije, kar ni kritično. Preprosto je bolje zapomniti, kje je pravilno mesto za konfiguracijo in kaj z njo storiti, ker bo, če spletni vmesnik ne bo deloval, že težje.

Nastavitve spletnega vmesnika za delo s svojim strežnikom

Tukaj je prvi skriti problem, za katerega je bilo porabljenih približno tri ure.

Če ste IPFS namestili na zunanjem strežniku, vendar niste namestili ali zagnali IPFS lokalno, bi morali pri dostopu do /webui v spletni vmesnik videti napako pri povezovanju:

Gre za to, da webui, po mojem mnenju, deluje precej nedvoumno. Najprej poskuša povezati na API tistega strežnika, kjer je odprt vmesnik (seveda na podlagi naslova v brskalniku), in če tam ne uspe, poskuša povezati na lokalni prehod. In če imate IPFS zagnan lokalno, bo vaš webui deloval normalno, a delali boste z lokalnim IPFS, ne z zunanjim, čeprav ste odprli webui na zunanjem strežniku. Nato nalagate datoteke, a jih iz nekega razloga ne vidite kar tako na zunanjem strežniku...

A če lokalno ni zagnan, dobimo napako povezave. V našem primeru je težava najverjetneje povezana s CORS, kar potrjuje tudi webui, ki predlaga dodajanje konfiguracije.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_vašega strežnika:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Pri sebi sem preprosto nastavil wildcard.

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

Vse dodane glave lahko najdete v istem ~/.ipfs/config. V mojem primeru je to:

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

Ponovno zagnamo ipfs in vidimo, da se webui uspešno povezal (vsaj bi se moral, če ste odprli prehode za zunanje zahteve, kot je opisano zgoraj).

Sedaj lahko neposredno preko spletnega vmesnika nalagate mape in datoteke ter ustvarjate svoje mape.

Priključitev datotečnega sistema FUSE.

To je precej zanimiva funkcionalnost.

Datoteke (kot tudi mape) lahko dodajamo ne le preko spletnega vmesnika, temveč tudi neposredno v terminalu, na primer:

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

Zadnji hash je hash korenske mape.

Po tem hashu lahko odprete mapo na kateri koli ipfs vozli, ki bo mogel najti našo vozlišče in pridobiti vsebino; lahko to storite v spletni aplikaciji na portu 5001 ali 8080, ali lokalno preko ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Lahko pa jo tudi odprete kot navadno mapo.

Ustvarimo dve mapi v korenu in podelimo pravice našemu uporabniku.

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

in ponovno zagnamo ipfs s flagom --mount.

ipfs daemon --mount

Lahko ustvarimo mape tudi na drugih mestih in pot do njih določimo preko parametrov ipfs daemon --mount --mount-ipfs /ipfs_path --mount-ipns /ipns_path.

Sedaj je branje iz te mape nekoliko nenavadno.

ls -la /ipfs
ls: reading directory '/ipfs': Operacija ni dovoljena
total 0

To pomeni, da direktnega dostopa do korena te mape ni. A vseeno lahko pridobite vsebino, če poznate hash.

ls -la /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx
total 0
-r--r--r-- 1 root root 10 31 avg 07:03 test.txt

cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt 
test
test

Pri tem znotraj mape celo deluje samodejno dopolnjevanje ob navedbi poti.

Kot sem že omenil, pri takšni montaži so nekatere posebnosti: privzeto so montažne FUSE-mape dostopne samo trenutnemu uporabniku (tudi root jih ne more brati, kaj šele drugi uporabniki v sistemu). Če želite te mape narediti dostopne drugim uporabnikom, morate v konfiguraciji spremeniti "FuseAllowOther": false na "FuseAllowOther": true. Ampak to še ni vse. Če IPFS zaženete kot root, je vse v redu. Če pa kot običajni uporabnik (tudi s sudo), dobite napako.

napaka pomočnika za montažo: fusermount: možnost allow_other je dovoljena samo, če je 'user_allow_other' nastavljen v /etc/fuse.conf

V tem primeru je treba urediti /etc/fuse.conf in odkomentirati vrstico #user_allow_other.

Po tem znova zagnamo ipfs.

Znane težave s FUSE

Večkrat je bila opažena težava, da po ponovnem zagonu ipfs z montažo (ali morda v drugih primerih) točke montaže /ipfs in /ipns postanejo nedostopne. Dostopa do njih ni, ls -la /ipfs pa prikaže ???? v seznamu pravic.

Našel sem takšno rešitev:

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

Po tem znova zaženemo ipfs.

Dodajamo storitev

Seveda je zagon v terminalu primeren le za začetne teste. V produkcijskem načinu mora demon automatsko zagnati ob zagonu sistema.

Kot sudo ustvarimo datoteko /etc/systemd/system/ipfs.service in vanjo vpišemo:

[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 je seveda treba zamenjati s svojim uporabniškim imenom (in morda bo pot do programa ipfs drugačna (vpisati je treba natančno celotno pot)).

Aktiviramo storitev.

sudo systemctl enable ipfs.service

Začnemo storitev.

sudo service ipfs start

Preverimo stanje storitve.

sudo service ipfs status

Za čistočo eksperimenta bomo pozneje morda znova zagnali strežnik, da preverimo, ali se ipfs uspešno zažene samodejno.

Dodajamo nam znane peers

Представим ситуацию, когда у нас установлены ноды IPFS как на внешнем сервере, так и локально. На внешнем сервере мы добавляем какой-то файл и пытаемся его получить через IPFS локально по CID. Что происходит? Локальный сервер, скорее всего, ничего не знает о нашем внешнем сервере и будет просто пытаться найти файл по CID, «спрашивая» у всех доступных ему IPFS-пиров, с которыми он уже успел «познакомиться». Те, в свою очередь, будут спрашивать у других. И так продолжится, пока файл не будет найден. То же самое происходит и тогда, когда мы пытаемся получить файл через официальный шлюз ipfs.io. Если повезет, файл будет найден за несколько секунд. Если нет, может пройти несколько минут, прежде чем его удастся найти, что сильно снижает комфорт работы. Но мы знаем, где этот файл в первую очередь появится. Так почему бы не сказать нашему локальному серверу «Ищи сначала там»? Похоже, это возможно сделать.

1. Заходим на удаленный сервер и в конфиге ~/.ipfs/config ищем

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

2. Выполняем sudo service ipfs status и ищем в нем записи Swarm, например:

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

3. Формируем общий адрес вида «/ip4/ip_вашего_сервера/tcp/4001/ipfs/$PeerID».

4. Для надежности через наш локальный webui попробуем добавить этот адрес в пиры.

5. Если все в порядке, открываем локальный конфиг ~/.ipfs/config, находим в нем «Bootstrap»: […
и добавляем полученный адрес первым в массив.

Перезапускаем IPFS.

Теперь добавим файл на внешний сервер и попробуем его запросить локально. Должен загрузиться быстро.

Но этот функционал пока нестабилен. Насколько я понимаю, даже если мы указываем адрес пира в Bootstrap, ipfs меняет список активных соединений с пирами в процессе работы. Тем не менее, обсуждение этого и желания по поводу возможности указывать постоянные пиры ведется ovde и вроде как se predpostavlja добавить какой-то функционал в ipfs@5.0+

Список текущих пиров можно посмотреть как в webui, так и в терминале.

ipfs swarm peers

В обоих случаях можно добавить вручную свой пир.

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

Пока функционал не улучшен, можно написать инструмент, который будет проверять наличие соединения с нужным пиром и, если его нет, автоматически добавлять соединение.

Размышления

Med tistimi, ki so že seznanjeni z IPFS, so tako argumenti za IPFS kot tudi proti njemu. Na splošno razpravljanje in me je spodbudilo, da še enkrat poglobim v IPFS. Kar zadeva omenjeni razpravi: ne morem reči, da sem močno proti kateremu od navedenih argumentov (samo s tistim, da poltora programista uporablja IPFS, se ne strinjam). Na splošno so tako eni kot drugi nekako prav (še posebej komentar o čekih to daje za razmišljanje). Toda če odmislimo moralno in pravno oceno, kdo bi dal kakšno tehnično oceno tej tehnologiji? Osebno imam nekakšen notranji občutek, da 'to je nedvomno potrebno, to ima določene perspektive'. Ampak zakaj natančno, nimam jasne formulacije. Kot da bi pogledali že obstoječa centralizirana sredstva, na mnogih parametrih so precej bolj napredna (stabilnost dela, hitrost dela, obvladljivost itd.). Kljub temu imam eno misel, ki se zdi smiselna in ki verjetno ne more biti uresničena brez takšnih decentraliziranih sistemov. Seveda se zelo pretvarjam, ampak jo bom formuliral takole: princip širjenja informacij na internetu je potrebno spremeniti.

Pojasnil bom. Če tako pomislimo, torej imamo zdaj informacije, ki se širijo po principu 'Upam, da bo tisti, ki sem mu jo posredoval, zaščitil in da ne bo izgubljena ali prejela s strani nekoga, ki ji ni bil namenjen'. Enostavno je na primer razmisliti o različnih poštnih storitvah, oblačnih hrambah itd. In kaj imamo na koncu? Na Habrju hub Informacijska varnost stoji na prvem mestu in praktično vsak dan prejemamo novice o novi globalni uhajanju. Na splošno je vse najbolj zanimivo našteveno v čudovitem članku. Poletje se skoraj končuje. Skoraj ni preteklih podatkov.Torej glavni internetni giganti postajajo vedno večji, akumulirajo vse več informacij, in podobna uhajanja so neke vrste informacijski atomski eksploziji. Nikoli ni bilo tako, in zdaj spet. Ob tem, čeprav mnogi razumejo, da obstajajo tveganja, bodo še naprej zaupali svoje podatke zunanjim podjetjem. Prvič, alternativ ni prav zlasti, in drugič, ti obljubljajo, da so zamašili vse luknje in da se kaj takega nikoli ne bo ponovilo.

Kakšen variant se mi zdi? Mislim, da bi podatki morali biti prvotno dostopni. Ampak dostopnost v tem primeru ne pomeni, da bi moralo biti vse lahko razumljivo. Govorim o odprtosti shranjevanja in distribucije, ne pa o totalni odprtosti pri branju. Predvidevam, da bi se informacije morale širiti z odprtimi ključi. Nazadnje je načelo odprtih/zaprtih ključev staro, skoraj tako kot internet. Če informacija ni zaupna in je namenjena širokemu krogu, se takoj objavi z odprtim ključem (vendar še vedno v šifrirani obliki, le da jo lahko kdorkoli dešifrira s tem ključem). Če pa ni, se objavi brez odprtega ključa, ključ pa se posreduje tistemu, ki mora imeti dostop do te informacije. Pri tem bi moral tisti, ki naj bi to prebral, imeti le ključ, kje dobiti to informacijo, pa ga ne bi smelo posebej prizadeti — enostavno jo potegne iz mreže (to je nov načelo distribucije po vsebini, ne po naslovu).

Tako da bi morali zločinci za množični napad pridobiti ogromno število zaprtih ključev, in malo verjetno je, da bi to uspelo narediti na enem mestu. Ta naloga se mi zdi težja kot vdora v določen storitveni sistem.

In tukaj se zapira še en problem: potrditev avtorstva. Danes lahko na internetu najdemo številne citate, napisane od naših znancev. Ampak kje je garancija, da so jih prav oni pisali? Če bi vsaka takšna objava bila opremljena z digitalnim podpisom, bi bilo veliko lažje. In ni pomembno, kje se ta informacija nahaja, pomemben je podpis, ki ga je vnaprej težko ponarediti.

In kar je tukaj zanimivo: IPFS že vsebuje sredstva za šifriranje (saj je zgrajen na tehnologiji blokchain). V konfiguraciji je takoj naveden zasebni ključ.

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

Nisem strokovnjak za varnost in ne morem natančno vedeti, kako to pravilno uporabiti, vendar menim, da se ti ključki uporabljajo na ravni izmenjave med IPFS vozlišči. Poleg tega js-ipfs in takšni projekti, kot so orbit-db, na kateri deluje orbit.chat. To pomeni, da lahko teoretično vsaka naprava (mobilna in ne le) enostavno opremimo s svojimi kriptografsko-dekriptorskimi napravami. V tem primeru bo vsak moral skrbeti za varnost svojih zasebnih ključev, vsak pa bo odgovoren za svojo varnost, namesto da bi bil ujetnik spet človeškega faktorja pri neki super priljubljeni internetni velikanki.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite se, molim vas.