痛みのない IPFS (ただし、これは正確ではありません)

すでにハブレにあったにもかかわらず IPFS に関する複数の記事.

私はこの分野の専門家ではないことをすぐに明確にしておきますが、私はこのテクノロジーに何度も興味を示しましたが、それを試してみると、痛みを伴うことがよくありました。 今日、私は再び実験を開始し、いくつかの結果を得たので共有したいと思います。 つまり、IPFS のインストールプロセスといくつかのトリックについて説明します (すべては ubuntu で実行されました。他のプラットフォームでは試していません)。

IPFS とは何かを見逃した場合は、ここで詳しく説明されています。 habr.com/ru/post/314768

インストール

ローカル モードとリモート モードで作業する場合のいくつかの落とし穴を考慮するため、実験の純度を高めるために、すぐに外部サーバーにインストールすることをお勧めします。 そうすれば、望むなら取り壊すのにそれほど時間はかかりません。そこには何もありません。

goをインストールする

公式ドキュメント
現在のバージョンについては、次を参照してください。 golang.org/dl

注: IPFS を最も頻繁に使用すると予想されるユーザーの代わりに 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更新バージョン — ダウンロード可能なすべてのバージョンを表示します。
ipfs更新バージョン — 現在インストールされているバージョンを確認します (IPFS がインストールされるまではバージョンは表示されません)。
ipfs-update 最新のインストール — IPFS の最新バージョンをインストールします。 最新のバージョンの代わりに、利用可能なバージョンのリストから任意のバージョンを指定できます。

IPFのインストール

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

インターネットへの扉を開く

次の XNUMX 行に注目してください。

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

IPFS をローカルにインストールした場合は、ローカル アドレスを使用して IPFS インターフェイスにアクセスすると、すべてを利用できるようになります (たとえば、 ローカルホスト:5001/webui/)。 ただし、外部サーバーにインストールされている場合、デフォルトではゲートウェイはインターネットに対して閉じられます。 ゲートウェイは XNUMX つあります。

1. ウェブイ管理者 (githubの) ポート 5001。
2. ポート 8080 の外部 API (読み取り専用)。

現時点では、両方のポート (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/

Web インターフェースが開くはずです。

webui を実行している場合は、統計の表示を含めて、webui 内で IPFS 設定を直接変更できます。ただし、以下では、構成ファイルを介して直接構成オプションを検討します。これは一般に重要ではありません。 構成がどこにあるのか、そしてそれをどうするのかを正確に覚えておいたほうがよいでしょう。そうしないと、Web インターフェイスが機能しない場合に、作業がさらに難しくなります。

サーバーと連携するための Web インターフェイスのセットアップ

ここが最初の落とし穴で、これに XNUMX 時間を費やしました。

IPFS を外部サーバーにインストールしたが、IPFS をローカルにインストールまたは実行しなかった場合、Web インターフェイスで /webui に移動すると、接続エラーが表示されます。

実際のところ、私の意見では、webui の動作は大きく異なります。 まず、インターフェースが開いているサーバーの API への接続を試みます (もちろん、ブラウザーのアドレスに基づいて)。 そこで機能しない場合は、ローカル ゲートウェイへの接続を試みます。 また、IPFS をローカルで実行している場合は、外部サーバーで webui を開いたとしても、webui は正常に動作します。外部ではなく、ローカル IPFS のみを操作します。 次にファイルをアップロードしますが、何らかの理由でファイルが外部サーバー上に表示されないだけです...

また、ローカルで起動されていない場合は、接続エラーが発生します。 私たちの場合、エラーは 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 が正常に接続されたことがわかります (少なくとも、上記のように、外部からのリクエストに対してゲートウェイを開いている場合は接続できるはずです)。

Web インターフェイスからフォルダーやファイルを直接アップロードしたり、独自のフォルダーを作成したりできるようになりました。

FUSE ファイル システムのマウント

これは非常に興味深い機能です。

ファイル (フォルダーなど) は、Web インターフェイス経由だけでなく、ターミナルに直接追加することもできます。

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

最後のハッシュはルート フォルダーのハッシュです。

このハッシュを使用すると、任意の ipfs ノード上のフォルダーを開くことができます (ノードを見つけてコンテンツを受信できます)。ポート 5001 または 8080 の Web インターフェイスで実行することも、ipfs 経由でローカルに実行することもできます。

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

ただし、通常のフォルダーと同じように開くこともできます。

ルートに XNUMX つのフォルダーを作成し、ユーザーにそれらのフォルダーに対する権限を付与しましょう。

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

--mount フラグを指定して ipfs を再起動します

ipfs daemon --mount

他の場所にフォルダーを作成し、ipfs デーモンのパラメーター -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

この場合、#user_allow_other 行のコメントを解除して /etc/fuse.conf を編集する必要があります。

この後、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 ノードが外部サーバーとローカルの両方にインストールされている状況を考えてみましょう。 外部サーバー上でファイルを追加し、CID を使用して IPFS 経由でローカルにファイルを取得しようとします。 何が起こるか？ もちろん、ローカル サーバーは外部サーバーについて何も知らない可能性が高く、利用可能なすべての IPFS ピア (既に「知り合い」になっている) に「問い合わせ」て CID でファイルを見つけようとします。 彼らは今度は他の人に尋ねます。 ファイルが見つかるまで続きます。 実際、公式ゲートウェイ経由でファイルを受信しようとすると、同じことが起こります。 ipfs.io。 運が良ければ、ファイルは数秒以内に見つかります。 そうしないと、数分経っても見つからず、作業の快適さに大きく影響します。 ただし、このファイルが最初にどこに表示されるかはわかっています。 それでは、なぜすぐにローカルサーバーに「まずそこを見てください」と指示しないのでしょうか? どうやら、これはできるようです。

1. リモートサーバーに移動し、設定ファイル内で ~/.ipfs/config を探します。

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

2. sudo service ipfs status を実行し、その中で Swarm エントリを探します。次に例を示します。

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

3. ここから、「/ip4/ip_of_your_server/tcp/4001/ipfs/$PeerID」という形式の一般アドレスを追加します。

4. 信頼性を高めるために、ローカル Webui を通じてこのアドレスをピアに追加してみます。

5. すべて問題なければ、ローカル設定 ~/.ipfs/config を開き、その中で「Bootstrap」を見つけます。
そして受け取ったアドレスを最初に配列に追加します。

IPFSを再起動します。

次に、ファイルを外部サーバーに追加し、ローカルサーバーでそれをリクエストしてみます。 すぐに飛んでくるはずだ。

ただし、この機能はまだ安定していません。 私の理解する限り、ブートストラップでピアアドレスを指定したとしても、ipfsは動作中にピアへのアクティブな接続のリストを変更します。 いずれにせよ、これと永続的なピアを指定する可能性に関する要望についての議論が進行中です。 ここで そしてそれはのようです と思われる いくつかの機能を追加する [メール保護]+

現在のピアのリストは、WebUI とターミナルの両方で表示できます。

ipfs swarm peers

どちらの場所でも、独自のごちそうを手動で追加できます。

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

この機能が改善されるまでは、目的のピアとの接続を確認し、接続されていない場合は接続を追加するツールを作成できます。

推論

すでに IPFS に精通している人たちの間では、IPFS について賛成派と反対派の両方の意見があります。 要するに一昨日 話し合い そして、IPFS をもう一度詳しく調べるようになりました。 そして、前述の議論に関して言えば、私は発言者の主張のいずれにも強く反対しているとは言えません (同意できないのは、XNUMX 人のプログラマが IPFS を使用しているという事実だけです)。 一般に、どちらもそれぞれの意味で正しいです（特に 小切手についてのコメント 考えさせられます）。 しかし、道徳的および法的評価を脇に置いた場合、誰がこのテクノロジーにどのような技術的評価を与えるのでしょうか? 私個人としては、「これは絶対に必要だ、将来性がある」という思いが内にあります。 しかし、正確にはなぜなのか、明確な定式化はありません。 同様に、既存の集中型ツールを見ると、多くの点ではるかに優れています (動作の安定性、動作速度、制御性など)。 それにもかかわらず、私には理にかなっていると思われるアイデアが XNUMX つありますが、これはそのような分散システムなしではほとんど実装できません。 もちろん、私は無理をしすぎていますが、私は次のように表現します。インターネット上で情報を広める原則を変える必要があるのです。

説明しましょう。 こう考えてみると、今私たちは「渡した相手が守ってくれるように、紛失したり、意図しない人に渡されたりしないように」という原則に基づいて情報を配布しています。 例としては、さまざまなメール サービスやクラウド ストレージなどが考えられます。 そして最終的には何が得られるのでしょうか？ ハブ オン ハブレ 情報セキュリティ は最初の行にあり、ほぼ毎日、別の世界的リークに関するニュースが届きます。 原則として、最も興味深いものはすべて、<皮肉にも>素晴らしいリストにリストされています。 記事 夏ももう終わりに近づいています。 漏洩したデータはほとんど残っていない。 つまり、主要なインターネット巨人はますます大きくなり、ますます多くの情報を蓄積しており、そのような漏洩は一種の情報の原子爆発である。 このようなことはこれまで一度も起こったことはありませんでしたが、ここで再び起こりました。 同時に、多くの人がリスクがあることを理解しながらも、自分のデータをサードパーティ企業に信頼し続けるでしょう。 第一に、代替手段があまりないこと、第二に、彼らはすべての穴をふさぎ、このようなことは二度と起こらないと約束します。

どのようなオプションが表示されますか? データは最初はオープンに配布されるべきだと私には思われます。 ただし、この場合のオープン性は、すべてが読みやすくなければならないという意味ではありません。 私はストレージと配布のオープン性について話していますが、読み取りにおける完全なオープン性については話していません。 情報は公開鍵で配布されるべきだと思います。 結局のところ、公開鍵/秘密鍵の原則はインターネットと同じくらい古いものです。 情報が機密ではなく、広範囲に向けられたものである場合、その情報は公開キーとともに直ちに投稿されます (ただし、依然として暗号化された形式なので、既存のキーを使用して誰でも復号化できます)。 そうでない場合は、公開キーなしで投稿され、キー自体がこの情報にアクセスする必要がある人に転送されます。 同時に、それを読まなければならない人はキーだけを持っている必要があり、この情報をどこで入手するかは彼にとって実際には重要ではありません - 彼は単にネットワークからそれを引き出すだけです（これはコンテンツによる配布の新しい原則であり、そうではありません）住所で）。

したがって、大規模な攻撃の場合、攻撃者は膨大な数の秘密鍵を取得する必要がありますが、これを XNUMX か所で行うことは不可能です。 私の見方では、このタスクは特定のサービスをハッキングするよりも難しいです。

そしてここで、著者の確認という別の問題が生じます。 今ではインターネット上で、私たちの友人が書いた多くの引用を見つけることができます。 しかし、それらを書いたのが彼らであるという保証はどこにあるのでしょうか？ このような各記録にデジタル署名が付随していれば、作業ははるかに簡単になります。 そして、この情報がどこにあるかは関係ありません。重要なのは署名であり、署名は明らかに偽造が困難です。

ここで興味深いのは、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 などのサンプルプロジェクト 軌道データベース、それが動作します オービットチャット。 つまり、理論的には、各デバイス (モバイルに限らず) に独自の暗号化および復号化マシンを簡単に装備することができます。 この場合、残っているのは、全員が自分の秘密鍵の保存に注意することだけであり、誰もが自分のセキュリティに責任を負い、超人気のインターネット巨人のさらなる人的要因の人質にならないようにするだけです。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

IPFS について聞いたことがありますか?

• IPFS について聞いたことはありませんが、面白そうです

• 聞いてないし聞きたくない

• 聞いたことはあるけど興味がなかった

• 聞いたけど分からなかったけど、今見ると面白そう

• 私は長い間 IPFS を積極的に使用してきました。

69 人のユーザーが投票しました。 13名のユーザーが棄権した。

出所： habr.com