IPFS без болка (но това не е точно)

IPFS без болка (но това не е точно)

Въпреки факта, че Хабре вече беше повече от една статия за IPFS.

Веднага ще поясня, че не съм експерт в тази област, но съм проявявал интерес към тази технология повече от веднъж, но опитите да си играя с нея често причиняваха известна болка. Днес започнах да експериментирам отново и получих някои резултати, които бих искал да споделя. Накратко, процесът на инсталиране на IPFS и някои функции ще бъдат описани (всичко беше направено на ubuntu, не съм го пробвал на други платформи).

Ако сте пропуснали какво е IPFS, тук е написано доста подробно: habr.com/en/post/314768

Инсталация

За чистотата на експеримента предлагам незабавно да го инсталирате на някакъв външен сървър, тъй като ще разгледаме някои клопки при работа в локален режим и отдалечено. След това, ако желаете, няма да бъде съборен дълго време, няма много.

Инсталирайте отидете

Официална документация
Вижте текущата версия на golang.org/dl

Забележка: по-добре е да инсталирате IPFS от името на потребителя, който трябва да го използва най-често. Факт е, че по-долу ще разгледаме опцията за монтиране чрез FUSE и има тънкости.

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

След това трябва да актуализирате средата (повече подробности тук: 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

Проверете дали go е инсталиран

go version

Инсталирайте IPFS

Най-много ми хареса начина на инсталиране ipfs актуализация.

Инсталирайте го с командата

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

След това можете да изпълните следните команди:

ipfs-update версии - за да видите всички налични версии за изтегляне.
ipfs-актуализирана версия - за да видите текущо инсталираната версия (докато не инсталираме IPFS, няма да е).
ipfs-update инсталира най-новата - инсталирайте най-новата версия на IPFS. Вместо последната, съответно, можете да посочите всяка желана версия от списъка с налични.

Инсталиране на ipfs

ipfs-update install latest

проверите

ipfs --version

Директно с инсталацията в общи линии всичко.

Стартирайте IPFS

Инициализация

Първо трябва да извършите инициализация.

ipfs init

В отговор ще получите нещо подобно:

 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

Можете да изпълните предложената команда

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

Тук според мен започва интересното. Момчетата на етапа на инсталиране вече започват да използват свои собствени технологии. Предложеният хеш QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv не се генерира специално за вас, а е зашит в изданието. Тоест преди пускането те подготвиха текст за добре дошли, изляха го в IPFS и добавиха адреса към инсталатора. Мисля, че е много готино. И този файл (по-точно цялата папка) вече може да се разглежда не само локално, но и на официалния портал ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. В същото време можете да сте сигурни, че съдържанието на папката не се е променило по никакъв начин, защото ако се беше променило, хешът също щеше да се промени.

Между другото, в този случай IPFS има някои прилики със сървъра за контрол на версиите. Ако направите промени в изходните файлове на папката и отново излеете папката в IPFS, тогава тя ще получи нов адрес. В същото време старата папка няма да отиде никъде просто така и ще бъде достъпна на предишния си адрес.

Директно стартиране

ipfs daemon

Трябва да получите отговор като този:

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

Отваряне на вратите към Интернет

Обърнете внимание на тези два реда:

WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080

Сега, ако сте инсталирали IPFS локално, тогава ще имате достъп до IPFS интерфейси, използвайки локални адреси и всичко ще ви бъде достъпно (Например, Localhost:5001/webui/). Но когато се инсталира на външен сървър, по подразбиране шлюзовете са затворени за интернет. Портали две:

  1. webui администратор (GitHub) на порт 5001.
  2. Външен API на порт 8080 (само за четене).

Засега и двата порта (5001 и 8080) могат да бъдат отворени за експерименти, но на боен сървър, разбира се, порт 5001 трябва да бъде затворен със защитна стена. Има и порт 4001, който е необходим, за да могат други партньори да ви намерят. Трябва да бъде оставен отворен за външни искания.

Отворете ~/.ipfs/config за редактиране и намерете тези редове в него:

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

Променете 127.0.0.1 на ip на вашия сървър и запазете файла, след което рестартирайте ipfs (спрете изпълняваната команда с Ctrl+C и я стартирайте отново).

Трябва да взема

...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080

Сега външните интерфейси трябва да са налични.

Вижте

http://домен_или_ip_сервера:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Горният readme файл трябва да се отвори.

http://домен_или_ip_сервера:5001/webui/

Уеб интерфейсът трябва да се отвори.

Ако webui работи за вас, тогава настройките на IPFS могат да се променят директно в него, включително преглед на статистика, но по-долу ще разгледам опциите за конфигуриране директно чрез конфигурационния файл, което обикновено не е критично. Просто е по-добре да запомните точно къде е конфигурацията и какво да правите с нея, в противен случай, ако уеб лицето не работи, ще бъде по-трудно.

Настройка на уеб интерфейс за работа с вашия сървър

Ето го и първият капан, който отне около три часа.

Ако сте инсталирали IPFS на външен сървър, но не сте инсталирали или стартирали IPFS локално, когато отидете на /webui в уеб интерфейса, трябва да видите грешка при свързване:

IPFS без болка (но това не е точно)

Факт е, че webui, по мое мнение, работи много двусмислено. Първо, той се опитва да се свърже с API на сървъра, където интерфейсът е отворен (въз основа на адреса в браузъра, разбира се). и ако не работи там, се опитва да се свърже с локалния шлюз. И ако имате IPFS, работещ локално, тогава webui ще работи добре за вас, само вие ще работите с локален IPFS, а не външен, въпреки че сте отворили webui на външен сървър. След това качвате файловете, но по някаква причина не ги виждате просто така на външен сървър...

И ако не работи локално, тогава получаваме грешка при свързване. В нашия случай грешката най-вероятно се дължи на CORS, което също е посочено от webui, предлагайки добавяне на конфигурация.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_вашего сервера:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Току-що регистрирах заместващ знак

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

Добавените заглавки могат да бъдат намерени в същия ~/.ipfs/config. В моя случай е така

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

Рестартираме ipfs и виждаме, че webui се е свързал успешно (във всеки случай би трябвало, ако сте отворили шлюзовете за заявки отвън, както е описано по-горе).

Вече можете да качвате папки и файлове директно през уеб интерфейса, както и да създавате свои собствени папки.

Монтиране на файловата система FUSE

Ето една доста интересна функция.

Файлове (както и папки) можем да добавяме не само през уеб интерфейса, но и директно в терминала, напр.

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

Последният хеш е хешът на основната папка.

Използвайки този хеш, можем да отворим папка на всеки ipfs възел (който може да намери нашия възел и да получи съдържанието), можем в уеб интерфейса на порт 5001 или 8080 или можем локално чрез ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Но все още можете да го отворите като обикновена папка.

Нека създадем две папки в основата и да предоставим права върху тях на нашия потребител.

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

и рестартирайте ipfs с --mount флаг

ipfs daemon --mount

Можете да създавате папки на други места и да посочите пътя до тях чрез параметрите на ipfs daemon -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Сега четенето от тази папка е малко необичайно.

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

Тоест няма директен достъп до корена на тази папка. Но можете да получите съдържанието, като знаете хеша.

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

В същото време дори автоматичното довършване работи вътре в папката, когато пътят е посочен.

Както казах по-горе, има тънкости при такова монтиране: по подразбиране монтираните папки FUSE са достъпни само за текущия потребител (дори root няма да може да чете от такава папка, да не говорим за други потребители в системата). Ако искате да направите тези папки достъпни за други потребители, тогава в конфигурацията трябва да промените "FuseAllowOther": false на "FuseAllowOther": true. Но това не е всичко. Ако стартирате IPFS като root, тогава всичко е наред. И ако от името на обикновен потребител (дори sudo), тогава ще получите грешка

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

В този случай трябва да редактирате /etc/fuse.conf, като разкоментирате реда #user_allow_other.

След това рестартирайте ipfs.

Известни проблеми с FUSE

Проблемът е забелязан повече от веднъж, че след рестартиране на ipfs с монтиране (и може би в други случаи), /ipfs и /ipns точките за монтиране стават недостъпни. Няма достъп до тях и ls -la /ipfs показва ???? в списъка с права.

Намерих това решение:

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

След това рестартирайте ipfs.

Добавяне на услуга

Разбира се, работата в терминала е подходяща само за първоначални тестове. В боен режим демонът трябва да стартира автоматично при стартиране на системата.

От името на sudo създайте файла /etc/systemd/system/ipfs.service и напишете в него:

[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, разбира се, трябва да бъде заменено с вашия потребител (и може би пълният път до програмата ipfs ще бъде различен за вас (трябва да посочите пълния път)).

Активираме услугата.

sudo systemctl enable ipfs.service

Стартираме услугата.

sudo service ipfs start

Проверка на състоянието на услугата.

sudo service ipfs status

За чистотата на експеримента ще бъде възможно да рестартирате сървъра в бъдеще, за да проверите дали ipfs стартира успешно автоматично.

Добавяне на познати ни празници

Помислете за ситуация, при която имаме IPFS възли, инсталирани както на външен сървър, така и локално. На външен сървър добавяме някакъв файл и се опитваме да го получим чрез IPFS локално по CID. Какво ще се случи? Разбира се, локалният сървър най-вероятно не знае нищо за нашия външен сървър и просто ще се опита да намери файла по CID, като „попита“ всички достъпни за него IPFS партньори (с които вече е успял да се „запознае“). Тези на свой ред ще питат други. И така нататък, докато файлът бъде намерен. Всъщност същото се случва, когато се опитаме да получим файла през официалния портал ipfs.io. Ако имате късмет, файлът ще бъде намерен след няколко секунди. И ако не, няма да бъде намерен дори след няколко минути, което значително влияе върху комфорта на работа. Но знаем къде този файл ще се появи първо. Така че защо не кажем веднага на нашия локален сървър „Търси първо там“? Очевидно това може да се направи.

1. Отиваме на отдалечения сървър и гледаме в ~/.ipfs/config config

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

2. Стартирайте sudo service ipfs status и потърсете записи на Swarm в него, например:

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

3. Добавяме от това общия адрес на формата "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID".

4. За надеждност ще се опитаме да добавим този адрес към партньори чрез нашия локален webui.

IPFS без болка (но това не е точно)

5. Ако всичко е наред, отворете локалната конфигурация ~ / .ipfs / config, намерете „Bootstrap“ в нея: [...
и първо добавете получения адрес към масива.

Рестартирайте IPFS.

Сега нека добавим файла към външния сървър и да се опитаме да го поискаме на локалния. Трябва да лети бързо.

Но тази функционалност все още не е стабилна. Доколкото разбирам, дори ако посочим адреса на партньор в Bootstrap, ipfs променя списъка с активни връзки с партньори по време на работа. Във всеки случай, обсъждането на това и желанията относно възможността за определяне на постоянни празници са в ход тук и изглежда като предполага се добавете някаква функционалност към [имейл защитен]+

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

ipfs swarm peers

И тук-там можете да добавите празника си ръчно.

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

Докато тази функционалност не бъде подобрена, можете да напишете инструмент за проверка за връзка с желания партньор и, ако не, за добавяне на връзка.

Обосновавам се

Сред тези, които вече са запознати с IPFS, има аргументи за и против IPFS. По принцип, вчера дискусия и ме подтикна отново да се заровя в IPFS. И по отношение на дискусията, спомената по-горе: не мога да кажа, че категорично се противопоставям на който и да е аргумент на тези, които говориха (не съм съгласен само с факта, че един и половина програмисти използват IPFS). Като цяло и двамата са прави по свой начин (особено коментар за проверките кара те да мислиш). Но ако отхвърлим моралната и правната оценка, кой ще даде техническа оценка на тази технология? Лично аз имам някакво вътрешно усещане, че „това трябва да се направи недвусмислено, има определени перспективи“. Но защо точно, няма ясна формулировка. Например, ако погледнете съществуващите централизирани инструменти, тогава в много отношения те са далеч напред (стабилност, скорост, управляемост и т.н.). Въпреки това имам една мисъл, която изглежда има смисъл и която трудно може да бъде реализирана без такива децентрализирани системи. Разбира се, замахвам много, но бих го формулирал така: трябва да се промени принципът на разпространение на информация в интернет.

Нека обясня. Ако се замислите, сега имаме информация, разпределена на принципа „Надявам се, че този, на когото съм я дал, ще я защити и няма да бъде изгубена или получена от тези, за които не е предназначена.“ Като пример е лесно да разгледаме различни пощенски услуги, облачни хранилища и др. И какво завършваме? В центъра на Хабре Информационна сигурност е на първа линия и почти всеки ден получаваме новини за поредното глобално изтичане на информация. По принцип всички най-интересни неща са изброени в <irony> чудесно статия Лятото почти свърши. Почти не са останали неизтекли данни. Тоест, основните интернет гиганти стават все по-големи, те натрупват все повече и повече информация и подобни течове са вид информационни атомни експлозии. Това никога не се е случвало и ето го отново. В същото време, въпреки че мнозина разбират, че има рискове, те ще продължат да се доверяват на своите данни на трети страни. Първо няма много алтернатива и второ обещават, че са закърпили всички дупки и това никога повече няма да се повтори.

Какъв вариант виждам? Струва ми се, че първоначално данните трябва да се разпространяват открито. Но откритостта в случая не означава, че всичко трябва да се чете лесно. Говоря за отвореността на съхранението и разпространението, но не и за пълната отвореност при четенето. Предполагам, че информацията трябва да се разпространява с публични ключове. В крайна сметка принципът на публичните / частните ключове вече е стар, почти като интернет. Ако информацията не е поверителна и е предназначена за широк кръг, тогава тя се излага незабавно с публичен ключ (но все още в криптирана форма, просто всеки може да я дешифрира с наличния ключ). И ако не, тогава той се излага без публичен ключ, а самият ключ се прехвърля към това, което трябва да има достъп до тази информация. В същото време този, който трябва да го прочете, трябва да има само ключ и откъде да вземе тази информация, той не трябва да се издига много - той просто я изтегля от мрежата (това е новият принцип на разпространение по съдържание, а не по адрес).

По този начин, за масова атака, нападателите ще трябва да получат огромен брой частни ключове, а това едва ли ще бъде направено на едно място. Тази задача, според мен, е по-трудна от хакването на определена услуга.

И тук е приключен друг проблем: потвърждаване на авторството. Сега в интернет можете да намерите много цитати, написани от наши приятели. Но къде е гаранцията, че те са ги написали? Сега, ако всеки такъв запис беше придружен с цифров подпис, щеше да е много по-лесно. И няма значение къде се намира тази информация, основното е подписът, който, разбира се, е трудно да се фалшифицира.

И ето какво е интересно тук: IPFS вече носи инструменти за криптиране (в края на краищата той е изграден върху технологията blockchain). Частният ключ веднага се посочва в конфигурацията.

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

Аз не съм специалист по сигурността и не мога да знам точно как да го използвам правилно, но ми се струва, че тези ключове се използват на ниво обмен между IPFS възли. И също js-ipfs и примерни проекти като орбита-dbвърху който работи orbit.chat. Тоест, теоретично всяко устройство (мобилно и не само) може лесно да бъде оборудвано със собствени машини за криптиране и декриптиране. В този случай остава само всеки да се погрижи за запазването на личните си ключове и всеки ще отговаря за собствената си сигурност, а не да бъде заложник на друг човешки фактор в някой супер популярен интернет гигант.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Чували ли сте за IPFS преди?

  • Никога не съм чувал за IPFS, но изглежда интересно

  • Не съм чувал и не искам да чувам

  • Чух, но не се интересувам

  • Чух, но не разбрах, но сега изглежда интересно

  • От доста време активно използвам IPFS.

69 потребители гласуваха. 13 потребители се въздържаха.

Източник: www.habr.com

Добавяне на нов коментар