🥇IPFS без болка (но не е сигурно)

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

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

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

Инсталиране

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

Инсталираме go

Официална документация
Актуалната версия вижте на 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-update.

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

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

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

ipfs-update versions — за да видите всички налични версии за изтегляне.
ipfs-update version — за да видите текущо инсталираната версия (понеже към момента нямаме инсталиран IPFS, ще бъде none).
ipfs-update install latest — да инсталирате последната версия на IPFS. Вместо latest можете да посочите всяка желана версия от списъка с налични.

Инсталираме 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

Резултат

Здравейте и добре дошли в IPFS!

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

Ако виждате това, успешно сте инсталирали
IPFS и сега взаимодействате с ipfs merkledag!

 -------------------------------------------------------
| Предупреждение:                                      |
|   Това е софтуер в алфа версия. Използвайте на собствен риск! |
|   Липсват много функции или те не са полирани. Има бъгове.  |
|   Все още не е сигурен. Прочетете бележките за сигурността за повече информация. |
 -------------------------------------------------------

Разгледайте някои от другите файлове в тази директория:

  .\/about
  .\/help
  .\/quick-start     <-- примери за употреба
  .\/readme          <-- този файл
  .\/security-notes

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

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

Непосредствено стартиране

ipfs daemon

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

ipfs daemon
Инициализиране на демон...
go-ipfs версия: 0.4.22-
Версия на репото: 7
Системна версия: amd64/linux
Версия на Golang: go1.12.7
Swarm слуша на /ip4/x.x.x.x/tcp/4001
Swarm слуша на /ip4/127.0.0.1/tcp/4001
Swarm слуша на /ip6/::1/tcp/4001
Swarm слуша на /p2p-circuit
Swarm обявява /ip4/127.0.0.1/tcp/4001
Swarm обявява /ip6/::1/tcp/4001
API сървърът слуша на /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Сървър на шлюза (readonly) слуша на /ip4/127.0.0.1/tcp/8080
Демонът е готов

Отваряме вратите за Интернет

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

WebUI: http://127.0.0.1:5001/webui
Сървър на шлюза (readonly) слуша на /ip4/127.0.0.1/tcp/8080

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

Админ панел webui (github) на порт 5001.
Външно 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 (само за четене) сървър слушащ на /ip4/ip_вашия_сървър/tcp/8080

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

Проверете

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

Трябва да се отвори посоченият по-горе readme файл.

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

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

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

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

Ето тук е първата подводна скала, на която бяха похарчени около три часа.

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

Фактът е, че 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"]'

Аз просто написах wildcard при мен.

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 търсим

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

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

Swarm announcing /ip4/ip_вашия_сървър/tcp/4001

3. Съставяме от това общ адрес, вида „/ip4/ip_вашия_сървър/tcp/4001/ipfs/$PeerID“.

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

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

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

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

Но тази функционалност все още е нестабилна. Dokолкото разбирам, дори ако посочим адреса на пира в Bootstrap, по време на работа IPFS променя списъка на активните връзки с пировете. Във всеки случай това и желанията за възможността да се указват постоянни пирове се обсъждат тук. и изглежда, че се предполага ще бъде добавена някаква функционалност в ipfs@5.0+

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

ipfs swarm peers

И в двата случая може да добавите ръчно своя пир.

ipfs swarm connect "/ip4/ip_вашия_сървър/tcp/4001/ipfs/$PeerID"

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

Размишления

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

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

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

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

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

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

  "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 и примери за проекти като orbit-db, на базата на който работи orbit.chat. Тоест, теоретично, всяко устройство (мобилно и не само) може лесно да бъде оборудвано със собствените си шифровално-дешифровални машини. В такъв случай остава само всеки да се погрижи за запазването на своите лични ключове и всеки сам ще бъде отговорен за своята сигурност, а не да бъде заложник на човешкия фактор в някой супер популярен интернет гигант.

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