Mindjárt leszögezem, hogy nem vagyok szakértő ezen a területen, de nem egyszer érdeklődtem ez iránt a technológia iránt, de sokszor okozott némi fájdalmat a vele való játszadozás. Ma újra elkezdtem kísérletezni, és olyan eredményeket kaptam, amelyeket szeretnék megosztani. Röviden leírom az IPFS telepítési folyamatát és néhány szolgáltatást (ubuntu-n minden megtörtént, más platformon nem próbáltam). Ha kihagytad, mi az az IPFS, itt le van írva részletesen: habr.com/en/post/314768
Telepítés
A kísérlet tisztasága érdekében azt javaslom, hogy azonnal telepítse valamilyen külső szerverre, mivel figyelembe vesszük néhány buktatót a helyi módban és távolról történő munkavégzés során. Aztán, ha kívánják, sokáig nem bontják, nincs sok.
Megjegyzés: jobb, ha az IPFS-t annak a felhasználónak a nevében telepíti, aki azt leggyakrabban használja. Az a tény, hogy az alábbiakban megvizsgáljuk a szerelési lehetőséget FUSE és vannak finomságok.
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 verziók - az összes letölthető verzió megtekintéséhez. ipfs-update verzió — az aktuális telepített verzió megtekintéséhez (amíg nem telepítjük az IPFS-t, addig nem lesz). Az ipfs-update legújabb telepítése - telepítse az IPFS legújabb verzióját. A legfrissebb helyett bármelyik kívánt verziót megadhatja az elérhetők listájából.
ipfs telepítése
ipfs-update install latest
Ellenőrzés
ipfs --version
Közvetlenül a telepítéssel általában mindent.
Indítsa el az IPFS-t
Inicializálás
Először inicializálást kell végrehajtania.
ipfs init
Válaszul valami ilyesmit fog kapni:
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
Véleményem szerint itt kezdődik az érdekes. A telepítési szakaszban lévő srácok már elkezdik használni a saját technológiáikat. A javasolt QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv hash nem kifejezetten az Ön számára készült, hanem bele van varrva a kiadásba. Vagyis a megjelenés előtt elkészítettek egy üdvözlő szöveget, beöntötték az IPFS-be, és hozzáadták a címet a telepítőhöz. Szerintem nagyon klassz. Ez a fájl (pontosabban a teljes mappa) pedig már nem csak helyben, hanem a hivatalos átjárón is megtekinthető ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Ugyanakkor biztos lehet benne, hogy a mappa tartalma semmiben sem változott, mert ha változott volna, akkor a hash is megváltozott volna.
Mellesleg, ebben az esetben az IPFS-nek van némi hasonlósága a verzióvezérlő szerverrel. Ha módosítja a mappa forrásfájljait, és újra feltölti az IPFS-be, akkor az új címet kap. Ugyanakkor a régi mappa nem megy sehova csak úgy, és a korábbi címén lesz elérhető.
Közvetlen indítás
ipfs daemon
Ilyen választ kellene kapnod:
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
Az internet kapujának megnyitása
Ügyeljen erre a két sorra:
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Most, ha az IPFS-t helyileg telepítette, akkor helyi címekkel fog hozzáférni az IPFS-interfészekhez, és minden elérhető lesz az Ön számára (például localhost:5001/webui/). De ha külső szerverre telepíti, az átjárók alapértelmezés szerint zárva vannak az internet felé. Két átjáró:
Egyelőre mindkét port (5001-es és 8080-as) nyitható kísérletekhez, de éles szerveren természetesen az 5001-es portot kellene tűzfallal lezárni. Van a 4001-es port is, arra van szükség, hogy a többi társ megtalálhassa. Nyitva kell hagyni a külső kérések előtt.
Nyissa meg a ~/.ipfs/config fájlt szerkesztéshez, és keresse meg benne a következő sorokat:
Módosítsa a 127.0.0.1-et a szerver IP-jére, mentse a fájlt, majd indítsa újra az ipfs-t (a Ctrl+C billentyűkombinációval állítsa le a futó parancsot, és indítsa újra).
Meg kellene szerezni
...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080
Most már elérhetővé kell tenni a külső interfészeket.
Ha a webui működik az Ön számára, akkor az IPFS beállításai közvetlenül módosíthatók benne, beleértve a statisztikák megtekintését is, de az alábbiakban a konfigurációs lehetőségeket közvetlenül a konfigurációs fájlon keresztül vizsgálom, ami általában nem kritikus. Csak jobb, ha pontosan megjegyzi, hol van a konfig és mit kell vele csinálni, különben ha a weblap nem működik, akkor nehezebb lesz.
Webes felület beállítása a szerverrel való együttműködéshez
Íme az első buktató, amelyen három órát töltöttek.
Ha az IPFS-t külső kiszolgálóra telepítette, de nem telepítette vagy futtatta helyileg az IPFS-t, akkor a webes felületen a /webui megnyitásakor kapcsolódási hibaüzenetet kell látnia:
Az a helyzet, hogy a webui véleményem szerint nagyon másképp működik. Először annak a szervernek az API-jához próbál csatlakozni, ahol az interfész nyitva van (természetesen a böngészőben lévő cím alapján). és ha ott nem működik, akkor megpróbál csatlakozni a helyi átjáróhoz. És ha az IPFS helyileg fut, akkor a webui jól fog működni, csak te fogsz helyi IPFS-sel dolgozni, és nem külső, bár a webui-t külső szerveren nyitottad meg. Ezután feltölti a fájlokat, de valamiért nem csak a külső szerveren látja őket...
És ha nem indul el helyben, akkor kapunk egy kapcsolati hibát. Esetünkben a hiba nagy valószínűséggel a CORS miatt van, amit a webui is jelez, ami konfig hozzáadását javasolja.
Újraindítjuk az ipfs-t, és azt látjuk, hogy a webui sikeresen csatlakozott (mindenesetre meg kell tennie, ha megnyitotta az átjárókat a kívülről érkező kérések számára, a fent leírtak szerint).
Mostantól közvetlenül a webes felületen keresztül tölthet fel mappákat és fájlokat, valamint létrehozhat saját mappákat.
A FUSE fájlrendszer csatlakoztatása
Itt van egy nagyon érdekes funkció.
Fájlokat (és mappákat) nem csak a webes felületen, hanem közvetlenül a terminálon is hozzáadhatunk, pl.
ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test
Az utolsó kivonat a gyökérmappa hash-je.
Ezt a hash-t használva bármelyik ipfs csomóponton megnyithatjuk a mappát (ami meg tudja találni a csomópontunkat és fogadja a tartalmat), megtehetjük ezt a webes felületen az 5001-es vagy 8080-as porton, vagy megtehetjük lokálisan ipfs-en keresztül.
ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt
De megnyithatja úgy is, mint egy normál mappát.
Hozzunk létre két mappát a gyökérben, és biztosítsunk hozzájuk jogokat a felhasználónknak.
Más helyeken is létrehozhat mappákat, és megadhatja azok elérési útját az ipfs démon paraméterekkel -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path
Most ebből a mappából olvasni kissé szokatlan.
ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
Vagyis ennek a mappának nincs közvetlen hozzáférése a gyökérkönyvtárhoz. De a tartalmat a hash ismeretében megkaphatja.
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
Ugyanakkor még az automatikus kiegészítés is működik a mappán belül, ha az elérési út meg van adva.
Ahogy fentebb is mondtam, az ilyen rögzítésnek vannak finomságai: alapértelmezés szerint a csatlakoztatott FUSE mappák csak az aktuális felhasználó számára érhetők el (még a root sem tud olvasni egy ilyen mappából, nem beszélve a rendszer többi felhasználójáról) . Ha ezeket a mappákat más felhasználók számára is elérhetővé szeretné tenni, akkor a konfigurációban módosítania kell a „FuseAllowOther”: false értéket „FuseAllowOther”: true értékre. De ez még nem minden. Ha az IPFS-t rootként futtatod, akkor minden rendben van. És ha egy normál felhasználó nevében (akár sudo), akkor hibaüzenetet kap
mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
Ebben az esetben szerkesztenie kell az /etc/fuse.conf fájlt a #user_allow_other sor megjegyzésének törlésével.
Ezután indítsa újra az ipfs-t.
Ismert problémák a FUSE-val
Nemegyszer észlelték már azt a problémát, hogy az ipfs újraindítása után (és talán más esetekben) az /ipfs és /ipns csatolási pontok elérhetetlenné válnak. Nincs hozzáférésük hozzájuk, és az ls -la /ipfs megjeleníti a ???? a jogok listájában.
Ezt a megoldást találtam:
fusermount -z -u /ipfs
fusermount -z -u /ipns
Ezután indítsa újra az ipfs-t.
Szolgáltatás hozzáadása
Természetesen a terminálban való futás csak a kezdeti tesztekre alkalmas. Harci módban a démonnak automatikusan el kell indulnia a rendszer indításakor.
A sudo nevében hozza létre az /etc/systemd/system/ipfs.service fájlt, és írja be:
A FELHASZNÁLÓNÉV-t természetesen le kell cserélni a felhasználóval (és lehet, hogy az ipfs program teljes elérési útja más lesz (meg kell adnia a teljes elérési utat)).
Aktiváljuk a szolgáltatást.
sudo systemctl enable ipfs.service
Elkezdjük a szolgáltatást.
sudo service ipfs start
A szolgáltatás állapotának ellenőrzése.
sudo service ipfs status
A kísérlet tisztasága érdekében a jövőben lehetőség lesz a szerver újraindítására annak ellenőrzésére, hogy az ipfs automatikusan elindul-e.
Ismert ünnepek hozzáadása
Vegyünk egy olyan helyzetet, amikor az IPFS-csomópontok külső kiszolgálón és helyileg is telepítve vannak. Egy külső szerveren hozzáadunk néhány fájlt, és megpróbáljuk IPFS-en keresztül helyileg, CID-n keresztül lekérni. Mi fog történni? Természetesen a helyi szerver nagy valószínűséggel nem tud semmit a külső szerverünkről, és egyszerűen megpróbálja megtalálni a fájlt CID alapján úgy, hogy „megkéri” az összes rendelkezésére álló IPFS-társat (amivel már sikerült „megismerkednie”). Azok viszont megkérdeznek másokat. És így tovább, amíg meg nem találja a fájlt. Valójában ugyanez történik, amikor a fájlt a hivatalos átjárón keresztül próbáljuk elérni ipfs.io. Ha szerencséd van, a fájlt néhány másodpercen belül megtalálod. És ha nem, akkor még néhány perc alatt sem találja meg, ami nagyban befolyásolja a munka kényelmét. De tudjuk, hol jelenik meg először ez a fájl. Akkor miért nem mondjuk azonnal a helyi szerverünknek, hogy „Keressen ott először”? Úgy tűnik, ezt meg lehet tenni.
1. A távoli szerverre lépünk, és megnézzük a ~/.ipfs/config config fájlt
2. Futtassa a sudo szolgáltatás ipfs állapotát, és keresse meg a Swarm bejegyzéseket, például:
Swarm announcing /ip4/ip_вашего_сервера/tcp/4001
3. Ebből adjuk hozzá az "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID" űrlap általános címét.
4. A megbízhatóság érdekében megpróbáljuk hozzáadni ezt a címet a partnerekhez a helyi webujon keresztül.
5. Ha minden rendben van, nyissa meg a helyi config ~ / .ipfs / config fájlt, keresse meg benne a „Bootstrap” elemet: [...
és először adja hozzá a kapott címet a tömbhöz.
Indítsa újra az IPFS-t.
Most adjuk hozzá a fájlt a külső szerverhez, és próbáljuk lekérni a helyi szerveren. Gyorsan kell repülnie.
De ez a funkció még nem stabil. Ha jól értem, hiába adjuk meg a peer címet a Bootstrapban, az ipfs működés közben peerekre változtatja az aktív kapcsolatok listáját. Mindenesetre ennek és az állandó társak meghatározásának lehetőségével kapcsolatos kívánságok megvitatása folyamatban van itt és úgy tűnik feltételezett adjunk hozzá néhány funkciót [e-mail védett]+
Az aktuális társak listája a webuiban és a terminálban is megtekinthető.
Amíg ezt a funkciót nem javítják, írhat egy eszközt, amely ellenőrzi, hogy van-e kapcsolat a kívánt partnerrel, és ha nem, akkor a kapcsolat felvételéhez.
Érvelés
Azok között, akik már ismerik az IPFS-t, vannak érvek az IPFS mellett és ellen is. Lényegében tegnap vita és arra késztetett, hogy újra beleássak az IPFS-be. És ami a fent említett vitát illeti: nem mondhatom, hogy határozottan ellenzem a felszólalók bármely érvelését (csak azzal nem értek egyet, hogy másfél programozó használ IPFS-t). Általában mindkettőnek igaza van a maga módján (főleg megjegyzés a csekkekkel kapcsolatban elgondolkodtat). De ha félretesszük az erkölcsi és jogi értékelést, ki milyen technikai értékelést ad ennek a technológiának? Személy szerint van egyfajta belső érzésem, hogy „erre mindenképpen szükség van, ennek vannak bizonyos kilátásai”. De miért pontosan, nincs egyértelmű megfogalmazás. Például ha a meglévő központosított eszközöket nézzük, akkor sok tekintetben messze előrébb járnak (működés stabilitása, működési sebessége, irányíthatósága stb.). Ennek ellenére van egy ötletem, amely logikusnak tűnik, és amelyet ilyen decentralizált rendszerek nélkül aligha lehet megvalósítani. Természetesen túlságosan drukkolok, de én így fogalmaznám meg: az internetes információterjesztés elvét meg kell változtatni.
Hadd magyarázzam. Ha így gondolja, akkor most a „Remélem, hogy akinek átadtam, az megvédi, és nem veszi el, nem kapja meg olyan, akinek nem szánták.” Példaként könnyű megfontolni a különféle e-mail szolgáltatásokat, a felhőalapú tárolást stb. És mi van a végén? Hub a Habré-n Információ biztonság az első vonalban van, és szinte minden nap kapunk híreket egy újabb globális kiszivárogtatásról. Elvileg minden legérdekesebb dolog fel van sorolva az <irónia> csodálatos cikk Mindjárt vége a nyárnak. Szinte nem maradtak kiszivárgott adatok. Vagyis a fő internetes óriások egyre nagyobbak, egyre több információt halmoznak fel, az ilyen kiszivárogtatások pedig egyfajta információs atomrobbanások. Ilyen még nem fordult elő, és újra itt van. Ugyanakkor, bár sokan megértik, hogy vannak kockázatok, adataikat továbbra is külső cégekre bízzák. Egyrészt nincs sok alternatíva, másodszor pedig azt ígérik, hogy minden lyukat befoltoztak, és ez soha többé nem fordul elő.
Milyen lehetőséget látok? Számomra úgy tűnik, hogy az adatokat kezdetben nyíltan kell terjeszteni. De a nyitottság ebben az esetben nem jelenti azt, hogy mindennek könnyen olvashatónak kell lennie. A tárolás és terjesztés nyitottságáról beszélek, de nem az olvasás teljes nyitottságáról. Feltételezem, hogy az információkat nyilvános kulcsokkal kell terjeszteni. Végül is a nyilvános / privát kulcsok elve már régi, majdnem olyan, mint az internet. Ha az információ nem bizalmas és széles körnek szól, akkor azonnal közzétesszük nyilvános kulccsal (de továbbra is titkosított formában, a meglévő kulccsal bárki visszafejtheti). És ha nem, akkor a nyilvános kulcs nélkül kerül közzétételre, és magát a kulcsot átadják annak, akinek hozzá kell férnie ehhez az információhoz. Ugyanakkor annak, akinek el kell olvasnia, csak kulcsa kell, hogy legyen, és az, hogy ezt az információt honnan szerezze meg, nem igazán számíthat neki - egyszerűen kihúzza a hálózatból (ez az új tartalom szerinti terjesztés elve, és nem cím szerint).
Így egy tömeges támadáshoz a támadóknak hatalmas számú privát kulcsot kell beszerezniük, és ez nem valószínű, hogy egy helyen fog megtörténni. Ez a feladat, ahogy látom, nehezebb, mint egy adott szolgáltatás feltörése.
És itt jön egy másik probléma: a szerzőség megerősítése. Most az interneten számos, barátaink által írt idézetet találhat. De hol a garancia, hogy ők írták őket? Most, ha minden ilyen rekordhoz digitális aláírás járna, sokkal egyszerűbb lenne. És nem számít, hol találhatók ezek az információk, a lényeg az aláírás, amelyet nyilvánvalóan nehéz hamisítani.
És itt van, ami itt érdekes: az IPFS már tartalmaz titkosítási eszközöket (elvégre blockchain technológiára épül). A privát kulcs azonnal megadásra kerül a konfigurációban.
Nem vagyok biztonsági szakember, és nem tudom pontosan, hogyan kell helyesen használni, de számomra úgy tűnik, hogy ezeket a kulcsokat az IPFS csomópontok közötti csere szintjén használják. És még js-ipfs és példaprojektek, mint pl pálya-dbamelyen működik kering.csevegés. Azaz elméletileg minden eszköz (mobil és nem csak) könnyen felszerelhető saját titkosító-visszafejtő gépekkel. Ebben az esetben mindenkinek csak a magánkulcsai mentéséről kell gondoskodnia, és mindenki a saját biztonságáért lesz felelős, nem pedig egy újabb emberi tényező túsza valamelyik szupernépszerű internetes óriáscégen.
A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.
Hallottál már az IPFS-ről?
Még soha nem hallottam az IPFS-ről, de érdekesnek tűnik
Nem hallottam és nem is akarom hallani
Hallottam, de nem érdekelt
Hallottam, de nem értettem, de most érdekesnek tűnik