Hned upřesním, že nejsem odborníkem v této oblasti, ale o tuto technologii jsem projevil zájem více než jednou, ale pokoušet se s ní hrát často způsobovalo bolest. Dnes jsem začal znovu experimentovat a získal jsem 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 vám uniklo, co je IPFS, je to podrobně napsáno zde: habr.com/en/post/314768
Instalace
Pro čistotu experimentu jej doporučuji okamžitě nainstalovat na nějaký externí server, protože zvážíme některá úskalí s prací v místním režimu a vzdáleně. Pak se na přání dlouho bourat nebude, moc toho není.
Poznámka: IPFS je lepší instalovat jménem uživatele, který jej má používat nejčastěji. Faktem je, že níže zvážíme možnost montáže přes FUSE a jsou tam jemnosti.
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 verze - zobrazit všechny dostupné verze ke stažení. ipfs-update verze - zobrazit aktuálně nainstalovanou verzi (dokud nebudeme mít nainstalovaný IPFS, nebude žádná). ipfs-update nainstalovat nejnovější - nainstalujte nejnovější verzi IPFS. Místo nejnovější, resp., můžete zadat libovolnou požadovanou verzi ze seznamu dostupných.
Instalace ipfs
ipfs-update install latest
Zkontrolujte
ipfs --version
Přímo s instalací obecně vše.
Spusťte IPFS
Inicializace
Nejprve musíte provést inicializaci.
ipfs init
Jako odpověď obdržíte něco takové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
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
Zde podle mého názoru začíná to zajímavé. Kluci ve fázi instalace už začínají používat své vlastní technologie. Navrhovaný hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv není generován speciálně pro vás, ale je šitý do vydání. To znamená, že před vydáním připravili uvítací text, nalili jej do IPFS a přidali adresu do instalátoru. Myslím, že je to velmi cool. A tento soubor (přesněji celou složku) lze nyní prohlížet nejen lokálně, ale i na oficiální bráně ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Zároveň si můžete být jisti, že se obsah složky nijak nezměnil, protože pokud by se změnil, změnil by se i hash.
Mimochodem, v tomto případě má IPFS určité podobnosti se serverem pro správu verzí. Pokud provedete změny ve zdrojových souborech složky a znovu nalijete složku do IPFS, obdrží novou adresu. Stará složka přitom jen tak nikam neodejde a bude dostupná na své předchozí adrese.
Přímé spuštění
ipfs daemon
Měli byste obdržet odpověď takto:
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
Otevírání dveří k internetu
Věnujte pozornost těmto dvěma řádkům:
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Nyní, pokud jste nainstalovali IPFS lokálně, budete přistupovat k rozhraním IPFS na lokálních adresách a vše vám bude dostupné (např. localhost:5001/webui/). Ale při instalaci na externí server jsou brány ve výchozím nastavení pro internet uzavřeny. Brány dvě:
Zatím lze oba porty (5001 a 8080) otevřít pro experimenty, ale na bojovém serveru by měl být port 5001 samozřejmě uzavřen firewallem. K dispozici je také port 4001, který je potřebný k tomu, aby vás ostatní kolegové mohli najít. Mělo by být ponecháno otevřené žádostem zvenčí.
Otevřete ~/.ipfs/config pro úpravy a najděte v něm tyto řádky:
Pokud vám webi funguje, pak lze nastavení IPFS měnit přímo v něm, včetně prohlížení statistik, níže ale zvážím možnosti konfigurace přímo přes konfigurační soubor, což obecně není kritické. Jen je lepší si pamatovat, kde přesně je konfigurace a co s ní dělat, jinak pokud nefunguje web face, bude to složitější.
Nastavení webového rozhraní pro práci s vaším serverem
Zde je první úskalí, které trvalo asi tři hodiny.
Pokud jste nainstalovali IPFS na externí server, ale nenainstalovali nebo nespustili IPFS lokálně, pak když přejdete na /webui ve webovém rozhraní, měli byste vidět chybu připojení:
Faktem je, že webi podle mě funguje velmi nejednoznačně. Nejprve se pokusí připojit k API serveru, kde je rozhraní otevřené (samozřejmě na základě adresy v prohlížeči). a pokud to tam nefunguje, zkusí se připojit k místní bráně. A pokud máte IPFS spuštěný lokálně, pak vám webui bude fungovat dobře, pouze vy budete pracovat s lokálním IPFS a ne externím, ačkoli jste webi otevřeli na externím serveru. Poté nahrajete soubory, ale z nějakého důvodu je nevidíte jen tak na externím serveru…
A pokud neběží lokálně, dostaneme chybu připojení. V našem případě je chyba s největší pravděpodobností způsobena CORS, což je také indikováno webi, což naznačuje přidání konfigurace.
Restartujeme ipfs a vidíme, že webi se úspěšně připojilo (v každém případě by mělo, pokud jste otevřeli brány pro požadavky zvenčí, jak je popsáno výše).
Nyní můžete nahrávat složky a soubory přímo přes webové rozhraní a také vytvářet vlastní složky.
Připojení souborového systému FUSE
Zde je docela zajímavá funkce.
Soubory (ale i složky) můžeme přidávat nejen přes webové rozhraní, ale i přímo v terminálu, např.
ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test
Poslední hash je hash kořenové složky.
Pomocí tohoto hashe můžeme otevřít složku na libovolném uzlu ipfs (který dokáže najít náš uzel a získat obsah), můžeme ve webovém rozhraní na portu 5001 nebo 8080 nebo můžeme lokálně přes ipfs.
ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt
Stále ji však můžete otevřít jako běžnou složku.
Vytvořme dvě složky v kořenovém adresáři a udělme k nim práva našemu uživateli.
Složky můžete vytvořit na jiných místech a zadat cestu k nim pomocí parametrů démona ipfs -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path
Nyní je čtení z této složky poněkud neobvyklé.
ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
To znamená, že neexistuje přímý přístup do kořenového adresáře této složky. Ale můžete získat obsah, když 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
Ve složce přitom funguje i automatické dokončování, když je zadána cesta.
Jak jsem řekl výše, takové připojení má jemnosti: ve výchozím nastavení jsou připojené složky FUSE dostupné pouze aktuálnímu uživateli (dokonce ani root nebude moci číst z takové složky, nemluvě o ostatních uživatelích v systému). Pokud chcete tyto složky zpřístupnit ostatním uživatelům, musíte v konfiguraci změnit "FuseAllowOther": false na "FuseAllowOther": true. Ale to není všechno. Pokud spustíte IPFS jako root, pak je vše OK. A pokud jménem běžného uživatele (i sudo), dostanete chybu
mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
V tomto případě musíte upravit soubor /etc/fuse.conf zrušením komentáře na řádku #user_allow_other.
Poté restartujte ipfs.
Známé problémy s FUSE
Problém byl zaznamenán více než jednou, že po restartování ipfs s připojením (a možná i v jiných případech) se body připojení /ipfs a /ipns stanou nedostupnými. Není k nim přístup a ls -la /ipfs ukazuje ???? v seznamu práv.
Našel toto řešení:
fusermount -z -u /ipfs
fusermount -z -u /ipns
Poté restartujte ipfs.
Přidání služby
Spuštění v terminálu je samozřejmě vhodné pouze pro počáteční testy. V bojovém režimu by se měl démon spustit automaticky při startu systému.
Jménem sudo vytvořte soubor /etc/systemd/system/ipfs.service a zapište do něj:
USERNAME samozřejmě musí být nahrazeno vaším uživatelem (a možná bude pro vás úplná cesta k programu ipfs jiná (musíte zadat úplnou cestu)).
Službu aktivujeme.
sudo systemctl enable ipfs.service
Spouštíme službu.
sudo service ipfs start
Kontrola stavu služby.
sudo service ipfs status
Kvůli čistotě experimentu bude možné v budoucnu restartovat server, aby se zkontrolovalo, zda se ipfs automaticky spouští.
Přidání nám známých svátků
Zvažte situaci, kdy máme uzly IPFS nainstalované na externím serveru i lokálně. Na externí server přidáme nějaký soubor a pokusíme se ho získat přes IPFS lokálně podle CID. Co se bude dít? Samozřejmě, že lokální server s největší pravděpodobností neví nic o našem externím serveru a jednoduše se pokusí najít soubor podle CID tak, že se „zeptá“ všech IPFS protějšků, které má k dispozici (se kterými se již stihl „seznámit“). Ti se zase budou ptát ostatních. A tak dále, dokud není soubor nalezen. Ve skutečnosti se totéž stane, když se pokusíme dostat soubor přes oficiální bránu ipfs.io. Pokud budete mít štěstí, soubor bude nalezen během několika sekund. A pokud ne, nenajde se ani za pár minut, což velmi ovlivňuje komfort práce. Víme ale, kde se tento soubor poprvé objeví. Proč tedy okamžitě neřekneme našemu místnímu serveru „Nejdřív tam hledej“? Zdá se, že to lze udělat.
1. Přejdeme na vzdálený server a podíváme se do konfigurace ~/.ipfs/config
2. Spusťte sudo service ipfs status a vyhledejte v něm položky Swarm, například:
Swarm announcing /ip4/ip_вашего_сервера/tcp/4001
3. Z toho přidáme obecnou adresu formuláře "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID".
4. Z důvodu spolehlivosti se pokusíme přidat tuto adresu k kolegům prostřednictvím našeho místního webu.
5. Pokud je vše v pořádku, otevřete místní konfiguraci ~ / .ipfs / config, najděte v ní „Bootstrap“: [...
a nejprve přidejte přijatou adresu do pole.
Restartujte IPFS.
Nyní přidejte soubor na externí server a zkusme si jej vyžádat na místním. Měl by letět rychle.
Tato funkce ale zatím není stabilní. Pokud jsem pochopil, i když v Bootstrapu zadáme adresu peeru, ipfs během provozu změní seznam aktivních spojení s peery. V každém případě o tom a přáních ohledně možnosti upřesnění stálých svátků probíhá diskuse zde a zdá se měl přidat nějakou funkcionalitu [chráněno e-mailem]+
Seznam aktuálních peerů si můžete prohlédnout na webu i v terminálu.
Dokud nebude tato funkce vylepšena, můžete napsat nástroj pro kontrolu připojení k požadovanému peeru, a pokud ne, pro přidání připojení.
Uvažování
Mezi těmi, kteří již znají IPFS, existují argumenty pro i proti IPFS. V podstatě včera diskuse a vybídl mě, abych se znovu ponořil do IPFS. A co se týče výše zmíněné diskuse: Nemohu říci, že bych se důrazně bránil jakémukoli argumentu těch, kteří hovořili (nesouhlasím pouze s tím, že jeden a půl programátorů používá IPFS). Obecně platí, že oba mají svým způsobem pravdu (zejména komentovat kontroly nutí vás přemýšlet). Ale když odmyslíme morální a právní posouzení, kdo bude dávat technické posouzení této technologie? Osobně mám jakýsi vnitřní pocit, že „to se musí jednoznačně udělat, má to jisté vyhlídky“. Ale proč přesně, neexistuje jasná formulace. Jako, když se podíváte na stávající centralizované nástroje, pak jsou v mnoha ohledech daleko napřed (stabilita, rychlost, ovladatelnost atd.). Přesto mám jednu myšlenku, která se zdá být smysluplná a kterou lze jen stěží realizovat bez takto decentralizovaných systémů. Samozřejmě, že se moc oháním, ale formuloval bych to takto: musí se změnit princip šíření informací na internetu.
Nech mě to vysvětlit. Pokud se nad tím zamyslíte, nyní máme informace distribuované podle zásady „doufám, že ten, komu jsem je dal, je ochrání a neztratí je ani nepřijmou ti, kterým nebyly určeny“. Jako příklad je snadné vzít v úvahu různé poštovní služby, cloudová úložiště atd. A čím skončíme? Na hubu Habré Informační bezpečnost je na první linii a téměř každý den dostáváme zprávy o dalším globálním úniku. V zásadě jsou všechny nejzajímavější věci uvedeny v <ironie> úžasné článek Léto je téměř u konce. Nezůstala téměř žádná neuniklá data. To znamená, že hlavní internetoví giganti se zvětšují, hromadí stále více informací a takové úniky jsou jakýmsi informačním atomovým výbuchem. To se ještě nikdy nestalo a je to tady znovu. Zároveň, ačkoli mnozí chápou, že existují rizika, budou i nadále důvěřovat svým údajům společnostem třetích stran. Zaprvé není moc alternativ a zadruhé slibují, že všechny díry zalepili a už se to nikdy nestane.
Jakou možnost vidím? Zdá se mi, že data by měla být zpočátku distribuována otevřeně. Otevřenost ale v tomto případě neznamená, že by mělo být vše dobře čitelné. Mluvím o otevřenosti skladování a distribuce, ale ne o úplné otevřenosti ve čtení. Předpokládám, že informace by měly být distribuovány pomocí veřejných klíčů. Ostatně princip veřejných / soukromých klíčů je již starý, skoro jako internet. Pokud informace nejsou důvěrné a jsou určeny širokému okruhu, pak se okamžitě rozloží s veřejným klíčem (ale stále v zašifrované podobě, dešifrovat je může kdokoli pomocí dostupného klíče). A pokud ne, pak se položí bez veřejného klíče a samotný klíč se přenese na to, co by mělo mít k těmto informacím přístup. Přitom ten, kdo by to měl číst, by měl mít pouze klíč a kde tyto informace získat, by se opravdu neměl vznášet – jen je tahá ze sítě (to je nový princip distribuce podle obsahu, nikoli podle adresa).
Pro hromadný útok tedy útočníci budou muset získat obrovské množství soukromých klíčů, a to se pravděpodobně nepodaří na jednom místě. Tento úkol, jak to vidím já, je obtížnější než hackování konkrétní služby.
A tady je uzavřen další problém: potvrzení autorství. Nyní na internetu můžete najít mnoho citátů napsaných našimi přáteli. Kde je ale záruka, že je napsali právě oni? Nyní, kdyby každý takový záznam byl opatřen digitálním podpisem, bylo by to mnohem jednodušší. A nezáleží na tom, kde tyto informace leží, hlavní věcí je podpis, který je samozřejmě obtížné padělat.
A tady je to zajímavé: IPFS již nese šifrovací nástroje (ostatně je postaven na technologii blockchain). Soukromý klíč je okamžitě uveden v konfiguraci.
Nejsem bezpečnostní specialista a nemohu přesně vědět, jak to správně používat, ale zdá se mi, že tyto klíče se používají na úrovni výměny mezi uzly IPFS. A také js-ipfs a ukázkové projekty jako např orbit-dbna kterém to funguje orbit.chat. To znamená, že teoreticky každé zařízení (nejen mobilní) může být snadno vybaveno vlastními šifrovacími a dešifrovacími stroji. V tomto případě zůstává pouze na všech, aby se postarali o uložení svých soukromých klíčů a každý bude zodpovědný za svou vlastní bezpečnost a nebude rukojmím dalšího lidského faktoru na nějakém superpopulárním internetovém gigantu.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.
Slyšeli jste již o IPFS?
O IPFS jsem nikdy neslyšel, ale vypadá to zajímavě
Neslyšel a nechci slyšet
Slyšel, ale nezajímal
Slyšel jsem, ale nerozuměl, ale teď to vypadá zajímavě
IPFS aktivně používám již delší dobu.
Hlasovalo 69 uživatelů. 13 uživatelů se zdrželo hlasování.