🥇IPFS bez bolesti (ale není to jisté)

I když na Habr již byla ne jedna článek o IPFS.

Hned upřesním, že nejsem odborník v této oblasti, ale několikrát jsem měl zájem o tuto technologii, i když pokusy o hraní si s ní často způsobovaly určitou bolest. Dnes jsem se znovu pustil do experimentů a získal nějaké výsledky, o které bych se rád podělil. Ve zkratce bude popsán proces instalace IPFS a některé funkce (vše bylo děláno na ubuntu, na jiných platformách jsem to nezkoušel).

Pokud jste prop missed, co je to IPFS, bylo o tom podrobně napsáno zde: habr.com/ru/post/314768

Instalace

Pro čistotu experimentu doporučuji okamžitě instalovat na nějakém externím serveru, protože se budeme zabývat některými podvodními kameny s prací v lokálním režimu a vzdáleném. Později, pokud budete chtít, to nebude trvat dlouho, abyste to smazali, není toho moc.

Instalujeme go

Oficiální dokumentace
Aktuální verzi naleznete na golang.org/dl

Poznámka: je lepší instalovat IPFS pod uživatelským jménem, které se hodlá nejčastěji používat. Věc je ta, že níže zohledníme variantu s montováním prostřednictvím FUSE a tam jsou nuance.

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

Poté je třeba aktualizovat prostředí (podrobnosti zde: 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

Kontrolujeme, že go je nainstalováno

go version

Instalujeme IPFS

Nejvíce se mi líbil způsob instalace přes ipfs-update.

Instalujeme jej příkazem

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

Po tomto můžeme vykonávat takové příkazy:

ipfs-update versions — abychom viděli všechny dostupné verze ke stažení.
ipfs-update version — abychom viděli aktuálně nainstalovanou verzi (zatím nemáme nainstalováno IPFS, bude none).
ipfs-update install latest — nainstalovat nejnovější verzi IPFS. Místo latest lze samozřejmě uvést jakoukoli požadovanou verzi ze seznamu dostupných.

Instalujeme ipfs

ipfs-update install latest

Kontrolujeme

ipfs --version

Přímo s instalací je všeobecně hotovo.

Spuštění IPFS

Inicializace

Nejprve je třeba provést inicializaci.

ipfs init

Jako odpověď obdržíte něco podobného:

 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

Můžete vykonat navrhovaný příkaz

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Výsledek

Ahoj a vítejte na IPFS!

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

Pokud to vidíte, úspěšně jste nainstalovali
IPFS a nyní komunikujete s ipfs merkledag!

 -------------------------------------------------------
| Varování:                                           |
|   Toto je alfa software. Používejte na vlastní riziko! |
|   Mnoho věcí chybí nebo není dokončeno. Obsahuje chyby.  |
|   Ještě není zabezpečeno. Přečtěte si poznámky k zabezpečení pro více informací.  |
 -------------------------------------------------------

Podívejte se na některé z dalších souborů v tomto adresáři:

  .\/about
  .\/help
  .\/quick-start     <-- příklady použití
  .\/readme          <-- tento soubor
  .\/security-notes

Tady už, podle mého názoru, začíná ta zajímavá část. Kluci už při instalaci začínají používat své vlastní technologie. Navržený hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — není speciálně pro vás vygenerovaný, ale je zabudovaný v releasu. To znamená, že před releasem připravili uvítací text, vložili ho do IPFS a adresu přidali do instalátoru. Podle mne je to opravdu skvělé. A tento soubor (přesněji celou složku) lze nyní prohlížet nejen lokálně, ale i na oficiálním bráně. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Přitom si lze být jistý, že obsah složky se nijak nezměnil, neboť kdyby se změnil, také by se změnil hash.

Mimochodem, v tomto případě má IPFS jistou podobnost s verzovacím serverem. Pokud do zdrojových souborů složky uděláte změny a opět vložíte složku do IPFS, dostane nový adresu. Strará složka však nikam nezmizí a bude dostupná pod svou bývalou adresou.

Spuštění je:

ipfs daemon

Měli byste obdržet odpověď podobnou této:

ipfs daemon
Inicializace démonu...
go-ipfs verze: 0.4.22-
Repo verze: 7
Systémová verze: amd64/linux
Golang verze: go1.12.7
Swarm naslouchá na /ip4/x.x.x.x/tcp/4001
Swarm naslouchá na /ip4/127.0.0.1/tcp/4001
Swarm naslouchá na /ip6/::1/tcp/4001
Swarm naslouchá na /p2p-circuit
Swarm oznamuje /ip4/127.0.0.1/tcp/4001
Swarm oznamuje /ip6/::1/tcp/4001
API server naslouchá na /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Brána (pouze pro čtení) server naslouchá na /ip4/127.0.0.1/tcp/8080
Démon je připraven

Otevíráme dveře pro internet

Všimněte si těchto dvou řádků:

WebUI: http://127.0.0.1:5001/webui
Brána (pouze pro čtení) server naslouchá na /ip4/127.0.0.1/tcp/8080

Pokud jste nainstalovali IPFS lokálně, budete přistupovat k IPFS rozhraním pomocí lokálních adres a vše vám bude dostupné (například, localhost:5001/webui/). Ale při instalaci na externím serveru jsou z bezpečnostních důvodů brány ve výchozím nastavení uzavřeny pro internet. Existují dvě brány:

Admin rozhraní webui (github) na portu 5001.
Externí API na portu 8080 (pouze pro čtení).

Pro experimenty můžete otevřít oba porty (5001 a 8080), ale na produkčním serveru byste měli port 5001 samozřejmě uzavřít pomocí firewallu. Existuje také port 4001, který je potřebný, aby vás mohly najít jiné peer. Ten by měl zůstat otevřený pro externí požadavky.

Otevřete k editaci ~/.ipfs/config a najděte v něm tyto řádky:

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

Změňte 127.0.0.1 na IP vaší serveru a uložte soubor, poté restartujte ipfs (běžící příkaz zastavte Ctrl+C a znovu spusťte).

Měli byste dostat

...
WebUI: http://ip_vašeho_serveru:5001/webui
Server brány (pouze pro čtení) naslouchá na /ip4/ip_vašeho_serveru/tcp/8080

Teď by měly být externí rozhraní dostupná.

Zkontrolujte

http://domena_nebo_ip_serveru:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Měl by se otevřít výše uvedený readme soubor.

http://domena_nebo_ip_serveru:5001/webui/

Měl by se otevřít webové rozhraní.

Pokud vám funguje webui, můžete nastavení IPFS měnit přímo v něm, včetně prohlížení statistik, ale níže se budu zabývat možnostmi konfigurace přímo přes konfigurační soubor, což není zásadní. Jen je dobré si zapamatovat, kde se konfigurační soubor nachází a co s ním dělat, protože pokud webová aplikace nebude fungovat, bude to obtížnější.

Nastavení webového rozhraní pro práci se svým serverem

Tady je první úskalí, na které jsem strávil asi tři hodiny.

Pokud jste IPFS nainstalovali na externím serveru, ale IPFS neinstallovali nebo nespustili lokálně, při přístupu na /webui v webovém rozhraní byste měli vidět chybu připojení:

Skutečnost je taková, že webui, podle mého názoru, funguje docela nejednoznačně. Nejdřív se pokouší připojit k API serveru, kde je otevřeno rozhraní (samozřejmě na základě adresy v prohlížeči). A pokud se mu to nepodaří, pokouší se připojit na lokální bránu. Pokud máte lokálně spuštěný IPFS, pak vám webui bude fungovat normálně, ale připojíte se k lokálnímu IPFS, nikoli k externímu, přestože jste otevřeli webui na externím serveru. Potom nahráváte soubory, ale z nějakého důvodu je prostě nevidíte na externím serveru...

Pokud není spuštěn ani lokálně, obdržíme chybu připojení. V našem případě je chyba pravděpodobně způsobena CORS, což naznačuje také webui, když nabízí přidat konfiguraci.

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

Já jsem si na svém zařízení jednoduše nastavil wildcard.

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

Přidané hlavičky lze všechny najít ve stejném ~/.ipfs/config. V mém případě je to

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

Restartujeme ipfs a vidíme, že se webui úspěšně připojil (v každém případě by měl, pokud jste otevřeli brány pro externí požadavky, jak bylo popsáno výše).

Nyní můžeme přímo přes webové rozhraní nahrávat složky a soubory, stejně jako vytvářet své vlastní složky.

Montování souborového systému FUSE

To je docela zajímavá funkce.

Soubory (stejně jako složky) můžeme přidávat nejen přes webové rozhraní, ale také přímo v terminálu, například

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

Poslední hash je hashem kořenové složky.

Podle tohoto hash můžeme otevřít složku na libovolném ipfs nodu (který dokáže najít naši nodu a získat obsah), můžeme to udělat ve webovém rozhraní na portu 5001 nebo 8080, a nebo lokálně přes ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Ale můžeme ji také otevřít jako běžnou složku.

Vytvoříme v kořenovém adresáři dvě složky a práva na ně poskytujeme našemu uživateli.

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

a restartujeme ipfs s příznakem —mount

ipfs daemon --mount

Můžete vytvořit složky i na jiných místech a určit jejich cestu pomocí parametrů ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Nyní je čtení z této složky poněkud zvláštní.

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

To znamená, že neexistuje přímý přístup k jádru této složky. Ale můžete získat obsah, pokud znáte hash.

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

Přitom uvnitř složky dokonce funguje automatické doplňování při zadávání cesty.

Jak jsem již zmínil, při takovém mountování existují určité nuance: ve výchozím nastavení jsou namontované FUSE složky dostupné pouze aktuálnímu uživateli (ani uživatel root nebude moci číst z takové složky, nemluvě o dalších uživatelích v systému). Pokud chcete, aby byly tyto složky dostupné i jiným uživatelům, je třeba v konfiguraci změnit „FuseAllowOther“: false na „FuseAllowOther“: true. Ale to ještě není vše. Pokud spouštíte IPFS pod uživatelským účtem root, je vše v pořádku. Pokud ale pod normálním uživatelským účtem (i s sudo), dostanete chybu.

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

V takovém případě je třeba upravit /etc/fuse.conf, a odkomentovat řádek #user_allow_other.

Poté restartujeme ipfs.

Známe problémy s FUSE

Několikrát se objevila potíž, že po restartu ipfs s mountováním (nebo možná v jiných případech) se mount pointy /ipfs a /ipns stávají nedostupnými. Není k nim žádný přístup a ls -la /ipfs ukazuje ???? v seznamu práv.

Našel jsem takové řešení:

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

Po čemž restartujeme ipfs.

Přidáváme službu

Samozřejmě, že spouštění v terminálu je vhodné pouze pro primární testy. V reálném režimu by měl daemon být spuštěn automaticky při startu systému.

Pod uživatelským účtem sudo vytvoříme soubor /etc/systemd/system/ipfs.service a zapíšeme do něj:

[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 samozřejmě nahraďte svým uživatelským jménem (a možná bude vaše úplná cesta k programu ipfs jiná (musíte uvést přesnou cestu)).

Aktivujeme službu.

sudo systemctl enable ipfs.service

Spouštíme službu.

sudo service ipfs start

Kontrolujeme stav služby.

sudo service ipfs status

Pro čistotu experimentu bude možné později restartovat server, abychom ověřili, že ipfs se úspěšně spouští automaticky.

Přidáváme nám známé peer.

Zvažme situaci, kdy máme nody IPFS nainstalované jak na externím serveru, tak lokálně. Na externím serveru přidáme nějaký soubor a pokusíme se ho získat přes IPFS lokálně podle CID. Co se stane? Samozřejmě, lokální server pravděpodobně nic neví o našem externím serveru a bude se snažit najít soubor podle CID tím, že se "zeptá" všech dostupných IPFS peerů, se kterými se již "seznámil". Ti se na druhé straně budou ptát dalších. A tak dále, dokud nebude soubor nalezen. V podstatě se to samé děje, když se snažíme soubor získat přes oficiální bránu. ipfs.io. Pokud budeme mít štěstí, soubor bude nalezen za několik sekund. A pokud ne, nebude nalezen ani za několik minut, což velmi negativně ovlivňuje komfort práce. Ale my víme, kde se tento soubor objeví jako první. Tak proč neříct našem lokálním serveru "Hledej nejprve tam"? Zjevně to lze udělat.

1. Přihlaste se na vzdálený server a v konfiguračním souboru ~\/ipfs\/config hledejte

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

2. Proveďte příkaz sudo service ipfs status a hledejte v něm záznamy Swarm, například:

Swarm announcing \/ip4\/ip_vašeho_serveru\/tcp\/4001

3. Sestavte z toho celkovou adresu ve tvaru „\/ip4\/ip_vašeho_serveru\/tcp\/4001\/ipfs\/$PeerID“.

4. Pro spolehlivost zkusíme přidat tuto adresu do peerů přes naše lokální webové rozhraní.

5. Pokud je vše v pořádku, otevřeme lokální konfiguraci ~\/ipfs\/config, najdeme v ní „Bootstrap“: […
a doplníme jako první do pole získanou adresu.

Restartujeme IPFS.

Nyní přidáme soubor na externí server a pokusíme se ho požádat na lokálním. Měl by se rychle dostat.

Ale tato funkčnost je zatím nestabilní. Podle mého chápání, i když uvádíme adresu peeru v Bootstrap, během práce ipfs mění seznam aktivních spojení s peerama. V každém případě se o tom diskutuje a jsou návrhy na možnost uvádět trvalé peery. zde A zdá se, že předpokládá se se má přidat nějaká funkčnost do ipfs@5.0+

Seznam aktuálních peerů lze zkontrolovat jak ve webovém rozhraní, tak v terminálu.

ipfs swarm peers

Jak tam, tak tam je možné ručně přidat svůj peer.

ipfs swarm connect "\/ip4\/ip_vašeho_serveru\/tcp\/4001\/ipfs\/$PeerID"

Dokud tuto funkčnost nezlepšíme, můžeme napsat nástroj, který by kontroloval připojení k potřebnému peeru a pokud neexistuje, aby přidal spojení.

Úvahy

Mezi těmi, kteří již znají IPFS, jsou jak argumenty pro IPFS, tak proti. V zásadě, to, co se stalo před dvěma dny, diskuze mě opět povzbudilo k prozkoumání IPFS. A co se týče zmíněné diskuse: nemohu říci, že jsem silně proti nějakému uvedenému argumentu vyjádřenému (nesouhlasím pouze s tím, že jeden a půl programátora používá IPFS). Celkově mají pravdu obě strany (zejména komentář o kontrolách což nutí k zamyšlení). Ale pokud odložíme morální a právní hodnocení, jaké technické hodnocení této technologie kdo dá? Osobně mám nějaký vnitřní pocit, že "to je rozhodně potřeba, má to určité perspektivy". Ale proč přesně, není jasné formulování. Pokud se podíváme na stávající centralized prostředky, pak podle mnoha parametrů jsou daleko před námi (stabilita práce, rychlost práce, spravovatelnost atd.). Přesto mám jednu myšlenku, která se zdá mít smysl a která se pravděpodobně nedá realizovat bez takových decentralizovaných systémů. Samozřejmě, že si to dost vymýšlím, ale formuloval bych to takto: princip šíření informací na internetu by měl být změněn.

Vysvětlím. Pokud na to pomyslíme, tak nyní informace se šíří na principu "Doufám, že ten, komu jsem je předal, je ochrání a nebudou ztraceny nebo získány někým, kdo k nim nemá přístup". Pro příklad se dají snadno zvážit různé poštovní služby, cloudové úložiště, atd. A co máme na konci? Na Habru je Informační bezpečnost první na seznamu a téměř každý den dostáváme zprávy o další globální úniku. V zásadě je vše nejzajímavější uvedeno v úžasném článku Léto skoro skončilo. Téměř už nezůstaly žádné uniklé údaje.. To znamená, že hlavní internetoví giganti se stále zvětšují, akumulují stále více informací a podobné úniky jsou jakési informační atomové exploze. Něco takového tu nikdy nebylo, a teď je to zase. Přitom, i když si mnozí uvědomují, že rizika existují, budou i nadále důvěřovat svým datům třetím stranám. Zaprvé, není tu moc alternativ, a zadruhé, slibují, že všechny díry zalátali a že se to už nikdy neopakuje.

Jaká varianta se mi jeví? Domnívám se, že data by měla být původně šířena otevřeně. Ale otevřenost v tomto případě neznamená, že vše musí být snadno čitelné. Mluvím o otevřenosti uchovávání a šíření, ale ne o totální otevřenosti v čtení. Předpokládám, že informace by měly být šířeny s veřejnými klíči. Vždyť princip veřejných/zavřených klíčů je už starý, téměř jako Internet. Pokud informace není důvěrná a je určena širokému okruhu, zveřejňuje se hned s veřejným klíčem (ale pořád v zašifrované podobě, prostě ji může jakýkoli uživatel dešifrovat pomocí dostupného klíče). A pokud tomu tak není, zveřejňuje se bez veřejného klíče a klíč se předává tomu, kdo by měl mít přístup k těmto informacím. Přitom ten, kdo by je měl číst, by měl mít pouze klíč a kde získat tyto informace, by ho nemělo příliš trápit — prostě si je stáhne ze sítě (toto je nový princip šíření podle obsahu, nikoli podle adresy).

Takže pro útočníky bude pro hromadný útok nutné získat obrovské množství zavřených klíčů, a pravděpodobně to nebude možné udělat z jednoho místa. Tato úloha se mi jeví jako složitější než prolomit nějakou konkrétní službu.

A zde se uzavírá další problém: potvrzení autorství. Dnes lze na internetu najít spoustu citátů napsaných našimi známými. Ale jaká je záruka, že je skutečně psali? Kdyby každá taková zpráva byla doprovázena digitálním podpisem, bylo by to mnohem jednodušší. A není důležité, kde tyto informace leží, hlavní je podpis, který je obecně těžké padělat.

A co je zde zajímavé: IPFS již obsahuje prostředky pro šifrování (byť je postaven na technologii blockchain). V konfiguraci je ihned uveden privátní klíč.

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

Nejsem bezpečnostní specialista a nemohu přesně vědět, jak to správně používat, ale mám pocit, že na úrovni výměny mezi uzly IPFS se tyto klíče používají. A také js-ipfs a projekty, jako jsou příklady orbit-db, na které běží orbit.chat. To znamená, že teoreticky může každé zařízení (mobilní i jiná) snadno mít svoje šifrovací a dešifrovací stroje. V takovém případě se každý musí postarat o uchování svých soukromých klíčů a každý bude sám zodpovědný za svou bezpečnost, nikoli být obětí dalšího lidského faktoru u nějakého super-populárního internetového giganta.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.