Od razu wyjaśniam, że nie jestem ekspertem w tej dziedzinie, ale już nie raz wyrażałem zainteresowanie tą technologią, jednak próby zabawy nią często powodowały pewien ból. Dzisiaj ponownie zacząłem eksperymentować i uzyskałem pewne wyniki, którymi chciałbym się podzielić. W skrócie zostanie opisany proces instalacji IPFS i kilka trików (wszystko zostało zrobione na Ubuntu, nie próbowałem tego na innych platformach). Jeśli przegapiłeś, czym jest IPFS, tutaj jest napisane szczegółowo: habr.com/en/post/314768
Instalacja
Dla czystości eksperymentu sugeruję od razu zainstalować go na jakimś zewnętrznym serwerze, ponieważ rozważymy pewne pułapki związane z pracą w trybie lokalnym i zdalnym. A jeśli chcesz, zburzenie go nie zajmie dużo czasu; nie ma tam zbyt wiele.
Uwaga: Lepiej jest zainstalować IPFS w imieniu użytkownika, który będzie z niego najczęściej korzystał. Faktem jest, że poniżej rozważymy opcję montażu przez FUSE i są tam subtelności.
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
wersje aktualizacji ipfs — aby zobaczyć wszystkie dostępne wersje do pobrania. wersja aktualizacji ipfs — aby zobaczyć aktualnie zainstalowaną wersję (dopóki nie zainstalujemy IPFS, nie będzie żadnej). ipfs-update zainstaluj najnowszą wersję — zainstaluj najnowszą wersję IPFS. Zamiast najnowszej możesz odpowiednio określić dowolną żądaną wersję z listy dostępnych.
Instalowanie ipfs
ipfs-update install latest
Kontrola
ipfs --version
Wszystko bezpośrednio z instalacją w ujęciu ogólnym.
Uruchamiam IPFS
Inicjalizacja
Najpierw musisz wykonać inicjalizację.
ipfs init
W odpowiedzi otrzymasz coś takiego:
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
Tutaj moim zdaniem robi się ciekawie. Nawet na etapie instalacji chłopaki zaczynają już korzystać z własnych technologii. Proponowany skrót QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv nie jest generowany specjalnie dla Ciebie, ale osadzony w wydaniu. Oznacza to, że przed wydaniem przygotowali tekst powitalny, wlali go do IPFS i dodali adres do instalatora. Myślę, że to bardzo fajne. I ten plik (a dokładniej cały folder) można teraz przeglądać nie tylko lokalnie, ale także na oficjalnej bramce ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. W takim przypadku możesz być pewien, że zawartość folderu nie uległa żadnej zmianie, ponieważ gdyby uległa zmianie, zmieniłby się również hash.
Nawiasem mówiąc, w tym przypadku IPFS ma pewne podobieństwa z serwerem kontroli wersji. Jeśli dokonasz zmian w plikach źródłowych folderu i ponownie prześlesz folder do IPFS, otrzyma on nowy adres. Jednocześnie stary folder nie pójdzie tak po prostu i będzie dostępny pod poprzednim adresem.
Bezpośrednie uruchomienie
ipfs daemon
Powinieneś otrzymać taką odpowiedź:
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
Otwarcie drzwi do Internetu
Zwróć uwagę na te dwie linie:
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Teraz, jeśli zainstalowałeś IPFS lokalnie, będziesz mieć dostęp do interfejsów IPFS przy użyciu adresów lokalnych i wszystko będzie dla ciebie dostępne (na przykład localhost:5001/webui/). Jednak po zainstalowaniu na serwerze zewnętrznym bramy są domyślnie zamknięte dla Internetu. Istnieją dwie bramy:
Zewnętrzny interfejs API na porcie 8080 (tylko do odczytu).
Na razie oba porty (5001 i 8080) można otworzyć do eksperymentów, ale na serwerze produkcyjnym oczywiście port 5001 musiałby zostać zamknięty zaporą ogniową. Istnieje również port 4001, jest on potrzebny, aby inni rówieśnicy mogli Cię znaleźć. Należy pozostawić ją otwartą na prośby z zewnątrz.
Otwórz plik ~/.ipfs/config do edycji i znajdź w nim następujące linie:
Zmieniamy 127.0.0.1 na ip Twojego serwera i zapisujemy plik, po czym restartujemy ipfs (zatrzymujemy uruchomioną komendę Ctrl+C i uruchamiamy ją ponownie).
Musieć dostać
...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080
Jeśli masz uruchomione webui, możesz bezpośrednio w nim zmienić ustawienia IPFS, w tym statystyki przeglądania, ale poniżej rozważę opcje konfiguracji bezpośrednio przez plik konfiguracyjny, co generalnie nie jest krytyczne. Po prostu lepiej zapamiętać, gdzie dokładnie znajduje się konfiguracja i co z nią zrobić, w przeciwnym razie, jeśli interfejs sieciowy nie będzie działał, będzie to trudniejsze.
Konfigurowanie interfejsu sieciowego do współpracy z serwerem
Oto pierwsza pułapka, nad którą spędziliśmy trzy godziny.
Jeśli zainstalowałeś IPFS na serwerze zewnętrznym, ale nie zainstalowałeś ani nie uruchomiłeś IPFS lokalnie, to kiedy przejdziesz do /webui w interfejsie internetowym, powinieneś zobaczyć błąd połączenia:
Faktem jest, że moim zdaniem webui działa zupełnie inaczej. Najpierw próbuje połączyć się z API serwera, na którym interfejs jest otwarty (oczywiście na podstawie adresu w przeglądarce). a jeśli tam nie działa, próbuje połączyć się z bramą lokalną. A jeśli masz IPFS działający lokalnie, webui będzie działać dobrze, tylko ty będziesz pracować z lokalnym IPFS, a nie zewnętrznym, nawet jeśli otworzyłeś webui na serwerze zewnętrznym. Następnie przesyłasz pliki, ale z jakiegoś powodu nie widzisz ich tylko na serwerze zewnętrznym...
A jeśli nie zostanie uruchomiony lokalnie, pojawi się błąd połączenia. W naszym przypadku za błąd najprawdopodobniej odpowiada CORS, na co wskazuje także webui, które sugeruje dodanie konfiguracji.
Ponownie uruchamiamy ipfs i widzimy, że webui pomyślnie nawiązało połączenie (przynajmniej powinno, jeśli otworzyłeś bramy dla żądań z zewnątrz, jak opisano powyżej).
Teraz możesz przesyłać foldery i pliki bezpośrednio przez interfejs internetowy, a także tworzyć własne foldery.
Montowanie systemu plików FUSE
To dość interesująca funkcja.
Pliki (takie jak foldery) możemy dodawać nie tylko poprzez interfejs WWW, ale także np. bezpośrednio w terminalu
ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test
Ostatni skrót jest skrótem folderu głównego.
Za pomocą tego skrótu możemy otworzyć folder na dowolnym węźle ipfs (który może znaleźć nasz węzeł i odebrać zawartość), możemy to zrobić w interfejsie WWW na porcie 5001 lub 8080, lub możemy to zrobić lokalnie poprzez ipfs.
ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt
Ale możesz także otworzyć go jak zwykły folder.
Stwórzmy dwa foldery w katalogu głównym i nadajmy do nich uprawnienia naszemu użytkownikowi.
Możesz tworzyć foldery w innych miejscach i określać ścieżkę do nich za pomocą parametrów demona ipfs -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path
Teraz czytanie z tego folderu jest nieco niezwykłe.
ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
Oznacza to, że nie ma bezpośredniego dostępu do katalogu głównego tego folderu. Ale możesz uzyskać zawartość, jeśli znasz skrót.
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
Co więcej, wewnątrz folderu działa nawet autouzupełnianie podczas określania ścieżki.
Jak powiedziałem powyżej, tego rodzaju montowanie ma pewne subtelności: domyślnie zamontowane foldery FUSE są dostępne tylko dla bieżącego użytkownika (nawet root nie będzie mógł odczytać takiego folderu, nie mówiąc już o innych użytkownikach w systemie) . Jeśli chcesz udostępnić te foldery innym użytkownikom, musisz w konfiguracji zmienić „FuseAllowOther”: false na „FuseAllowOther”: true. Ale to nie wszystko. Jeśli uruchomisz IPFS jako root, wszystko jest w porządku. A jeśli w imieniu zwykłego użytkownika (nawet Sudo), pojawi się błąd
mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
W takim przypadku musisz edytować plik /etc/fuse.conf, usuwając komentarz z linii #user_allow_other.
Następnie ponownie uruchamiamy ipfs.
Znane problemy z plikiem FUSE
Niejednokrotnie zauważono problem polegający na tym, że po ponownym uruchomieniu ipfs z montowaniem (i być może w innych przypadkach) punkty montowania /ipfs i /ipns stają się niedostępne. Nie ma do nich dostępu, ale wyświetla się ls -la /ipfs ???? na liście praw.
Znalazłem to rozwiązanie:
fusermount -z -u /ipfs
fusermount -z -u /ipns
Następnie ponownie uruchamiamy ipfs.
Dodanie usługi
Oczywiście uruchomienie w terminalu nadaje się tylko do wstępnych testów. W trybie walki demon powinien uruchomić się automatycznie wraz ze startem systemu.
Utwórz w imieniu sudo plik /etc/systemd/system/ipfs.service i wpisz w nim:
USERNAME oczywiście należy zastąpić swoim użytkownikiem (a być może pełna ścieżka do programu ipfs będzie dla Ciebie inna (musisz podać pełną ścieżkę)).
Aktywujmy usługę.
sudo systemctl enable ipfs.service
Uruchommy usługę.
sudo service ipfs start
Sprawdzanie statusu usługi.
sudo service ipfs status
Dla zachowania czystości eksperymentu możliwe będzie w przyszłości ponowne uruchomienie serwera w celu sprawdzenia, czy ipfs uruchomi się automatycznie.
Dodawanie znanych nam rówieśników
Rozważmy sytuację, w której mamy zainstalowane węzły IPFS zarówno na serwerze zewnętrznym, jak i lokalnie. Na serwerze zewnętrznym dodajemy jakiś plik i próbujemy pobrać go lokalnie poprzez IPFS poprzez CID. Co się stanie? Oczywiście lokalny serwer najprawdopodobniej nic nie wie o naszym serwerze zewnętrznym i po prostu spróbuje znaleźć plik po CID, „pytając” wszystkich dostępnych dla niego peerów IPFS (z którymi udało mu się już „zaznajomić”). Oni z kolei będą pytać innych. I tak dalej, aż plik zostanie znaleziony. Właściwie to samo dzieje się, gdy próbujemy otrzymać plik przez oficjalną bramę ipfs.io. Jeśli masz szczęście, plik zostanie znaleziony w ciągu kilku sekund. A jeśli nie, to nie zostanie odnaleziony nawet w kilka minut, co znacząco wpływa na komfort pracy. Wiemy jednak, gdzie ten plik pojawi się jako pierwszy. Dlaczego więc od razu nie powiemy naszemu lokalnemu serwerowi: „Najpierw spójrz tam”? Najwyraźniej da się to zrobić.
1. Przejdź do zdalnego serwera i poszukaj ~/.ipfs/config w pliku config
2. Uruchom usługę sudo ipfs status i poszukaj w niej wpisów Swarm, na przykład:
Swarm announcing /ip4/ip_вашего_сервера/tcp/4001
3. Z tego dodajemy ogólny adres w postaci „/ip4/ip_of_your_server/tcp/4001/ipfs/$PeerID”.
4. Dla pewności spróbujmy dodać ten adres do peerów poprzez nasz lokalny webui.
5. Jeśli wszystko jest w porządku, otwórz lokalną konfigurację ~/.ipfs/config, znajdź w niej „Bootstrap”: [...
i najpierw dodaj otrzymany adres do tablicy.
Uruchom ponownie IPFS.
Dodajmy teraz plik do serwera zewnętrznego i spróbujmy zażądać go na serwerze lokalnym. Powinien szybko przylecieć.
Ale ta funkcjonalność nie jest jeszcze stabilna. O ile rozumiem, nawet jeśli w Bootstrapie podamy adres peera, podczas operacji ipfs zmienia listę aktywnych połączeń na peery. W każdym razie toczy się dyskusja na ten temat i życzenia dotyczące możliwości określenia stałych rówieśników tutaj i wygląda na to, że powinien dodać trochę funkcjonalności do [email chroniony]+
Listę aktualnych peerów można przeglądać zarówno w webui, jak i w terminalu.
ipfs swarm peers
W obu miejscach możesz ręcznie dodać własną ucztę.
Dopóki ta funkcjonalność nie zostanie poprawiona, możesz napisać narzędzie sprawdzające połączenie z żądanym peerem i, jeśli nie, dodać połączenie.
Rozumowanie
Wśród osób już zaznajomionych z IPFS istnieją zarówno argumenty za, jak i przeciw IPFS. W zasadzie przedwczoraj dyskusja i skłoniło mnie do ponownego zagłębienia się w IPFS. A nawiązując do powyższej dyskusji: nie mogę powiedzieć, że jestem zdecydowanie przeciwny któremukolwiek z podanych argumentów wypowiadających się (nie zgadzam się jedynie z tym, że półtora programisty korzysta z IPFS). Ogólnie rzecz biorąc, obaj mają rację na swój sposób (zwłaszcza komentarz na temat kontroli sprawia że myślisz). Ale jeśli odłożymy na bok ocenę moralną i prawną, kto wystawi jaką ocenę techniczną tej technologii? Osobiście mam jakieś wewnętrzne przeczucie, że „to jest na pewno potrzebne, to ma pewne perspektywy”. Ale dlaczego dokładnie, nie ma jasnego sformułowania. Na przykład, jeśli spojrzysz na istniejące scentralizowane narzędzia, to pod wieloma względami są one daleko do przodu (stabilność działania, szybkość działania, sterowalność itp.). Niemniej jednak mam jeden pomysł, który wydaje się mieć sens i który trudno będzie wdrożyć bez takich zdecentralizowanych systemów. Oczywiście nalegam, ale ująłbym to w ten sposób: należy zmienić zasadę rozpowszechniania informacji w Internecie.
Pozwól mi wyjaśnić. Jeśli tak o tym pomyśleć, to teraz rozpowszechniamy informacje w myśl zasady „Mam nadzieję, że ten, któremu je dałem, będzie je chronił i nie zostanie utracone ani nie otrzymane przez osobę, dla której nie było przeznaczone”. Jako przykład można łatwo rozważyć różne usługi e-mail, przechowywanie w chmurze itp. I co w końcu mamy? Centrum na Habré Bezpieczeństwo informacji jest na pierwszej linii i niemal codziennie docierają do nas informacje o kolejnym globalnym wycieku. W zasadzie wszystkie najciekawsze rzeczy są wymienione w <ironicznie>cudownym artykuł Lato już prawie się skończyło. Prawie nie ma już danych, które nie wyciekłyby. Oznacza to, że główni giganci Internetu stają się coraz więksi, gromadzą coraz więcej informacji, a takie wycieki są rodzajem informacyjnych eksplozji atomowych. Coś takiego nigdy wcześniej się nie zdarzyło, a teraz ma to miejsce ponownie. Jednocześnie, chociaż wiele osób rozumie, że istnieje ryzyko, nadal będzie powierzać swoje dane firmom zewnętrznym. Po pierwsze alternatywy nie ma zbyt wiele, a po drugie obiecują, że załatali wszystkie dziury i to się nigdy więcej nie powtórzy.
Jaką opcję widzę? Wydaje mi się, że początkowo dane powinny być rozpowszechniane w sposób otwarty. Ale otwartość w tym przypadku nie oznacza, że wszystko powinno być łatwe do odczytania. Mówię o otwartości przechowywania i dystrybucji, ale nie o całkowitej otwartości w czytaniu. Wychodzę z założenia, że informacje powinny być rozpowszechniane za pomocą kluczy publicznych. W końcu zasada kluczy publicznych/prywatnych jest już tak stara jak Internet. Jeśli informacja nie jest poufna i przeznaczona jest dla szerokiego kręgu odbiorców, wówczas jest ona natychmiast publikowana z kluczem publicznym (ale nadal w formie zaszyfrowanej, każdy może ją odszyfrować za pomocą istniejącego klucza). A jeśli nie, to zostaje on opublikowany bez klucza publicznego, a sam klucz przekazywany jest temu, kto powinien mieć dostęp do tych informacji. Jednocześnie ten, kto musi to przeczytać, powinien mieć jedynie klucz, a to, skąd wziąć tę informację, nie powinno być dla niego tak naprawdę istotne – po prostu wyciąga ją z sieci (to nowa zasada dystrybucji według treści, a nie według adresu).
Zatem w przypadku masowego ataku napastnicy będą musieli zdobyć ogromną liczbę kluczy prywatnych, a jest mało prawdopodobne, aby udało się tego dokonać w jednym miejscu. To zadanie, moim zdaniem, jest trudniejsze niż zhakowanie konkretnej usługi.
I tu pojawia się kolejny problem: potwierdzenie autorstwa. Teraz w Internecie można znaleźć wiele cytatów napisanych przez naszych przyjaciół. Ale gdzie jest gwarancja, że to oni je napisali? Teraz, gdyby każdy taki zapis był opatrzony podpisem cyfrowym, byłoby to znacznie prostsze. I nie ma znaczenia, gdzie znajdują się te informacje, najważniejszy jest podpis, który oczywiście jest trudny do sfałszowania.
A oto co tu jest ciekawe: IPFS zawiera już narzędzia szyfrujące (w końcu jest zbudowany na technologii blockchain). Klucz prywatny jest natychmiast wskazany w konfiguracji.
Nie jestem specjalistą ds. bezpieczeństwa i nie wiem dokładnie, jak poprawnie tego używać, ale wydaje mi się, że klucze te są używane na poziomie wymiany między węzłami IPFS. I również js-ipfs oraz takie przykładowe projekty jak orbita-db, na którym to działa orbita.chat. Oznacza to, że teoretycznie każde urządzenie (mobilne i nie tylko) można łatwo wyposażyć we własne maszyny szyfrujące i deszyfrujące. W tym przypadku pozostaje tylko, aby każdy zadbał o zachowanie swoich kluczy prywatnych i każdy będzie odpowiedzialny za własne bezpieczeństwo, a nie będzie zakładnikiem kolejnego czynnika ludzkiego w jakimś superpopularnym internetowym gigantze.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.
Czy słyszałeś już o IPFS?
Nigdy nie słyszałem o IPFS, ale wydaje się interesujące
Nie słyszałem i nie chcę słyszeć
Słyszałem o tym, ale nie byłem zainteresowany
Słyszałem, ale nie rozumiałem, ale teraz wydaje mi się to interesujące
Od dłuższego czasu aktywnie korzystam z IPFS.
Głosowało 69 użytkowników. 13 użytkowników wstrzymało się od głosu.