主持人 > 博客 > 管理 > 沒有痛苦的 IPFS（但這並不准確）

沒有痛苦的 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-更新版本 - 查看所有可供下載的版本。
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 接口，並且所有內容都可供您使用（例如， 本地:5001/網頁界面/)。 但是當安裝在外部服務器上時，默認情況下，網關對 Internet 是關閉的。 網關二：

  1. webui管理員（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

上面的自述文件應該打開。

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

Web 界面應打開。

如果 webui 適合你，那麼可以直接在其中更改 IPFS 設置，包括查看統計信息，但下面我將直接通過配置文件考慮配置選項，這通常並不重要。 只是最好記住config在哪裡，用它做什麼，不然萬一web face不行，就更難了。

設置 Web 界面以與您的服務器一起使用

這是第一個陷阱，大約花了三個小時。

如果你在外部服務器上安裝了 IPFS，但沒有在本地安裝或運行 IPFS，那麼當你在 Web 界面中轉到 /webui 時，你應該會看到一個連接錯誤：

沒有痛苦的 IPFS（但這並不准確）

事實上，在我看來，webui 的工作方式非常模糊。 首先，它會嘗試連接到打開接口的服務器的 API（當然，基於瀏覽器中的地址）。 如果它在那裡不起作用，它會嘗試連接到本地網關。 如果你有本地運行的 IPFS，那麼 webui 對你來說會很好，只有你會使用本地 IPFS，而不是外部 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 已成功連接（無論如何，如果您為來自外部的請求打開網關，則應該如此，如上所述）。

現在您可以直接通過 Web 界面上傳文件夾和文件，也可以創建自己的文件夾。

掛載 FUSE 文件系統

這是一個非常有趣的功能。

文件（以及文件夾），我們不僅可以通過網頁界面添加，也可以直接在終端中添加，例如

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

最後一個哈希是根文件夾的哈希。

使用這個哈希，我們可以在任何 ipfs 節點上打開一個文件夾（它可以找到我們的節點並獲取內容），我們可以在端口 5001 或 8080 上的 Web 界面中打開，或者我們可以在本地通過 ipfs。

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

但您仍然可以像打開普通文件夾一樣打開它。

讓我們在根目錄下創建兩個文件夾並將它們的權限授予我們的用戶。

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。 但這還不是全部。 如果您以 root 身份運行 IPFS，則一切正常。 如果代表普通用戶（甚至是 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_your_server/tcp/4001/ipfs/$PeerID”形式的通用地址。

4.為了可靠性，我們會嘗試通過我們本地的webui將這個地址添加到peer。

沒有痛苦的 IPFS（但這並不准確）

5.如果一切OK，打開本地config~/.ipfs/config，在裡面找到“Bootstrap”：[...
並將接收到的地址首先添加到數組中。

重啟 IPFS。

現在讓我們將文件添加到外部服務器並嘗試在本地服務器上請求它。 應該飛得快

但是這個功能還不穩定。 據我了解，即使我們在 Bootstrap 中指定了對等點的地址，ipfs 在運行期間也會更改與對等點的活動連接列表。 無論如何，關於指定永久盛宴的可能性的討論和願望正在進行中 這裡 好像 應該 添加一些功能 [電子郵件保護]+

當前節點列表可以在 webui 和終端中查看。 

ipfs swarm peers

你可以在這里和那里手動添加你的盛宴。 

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

在改進此功能之前，您可以編寫一個工具來檢查與所需對等點的連接，如果沒有，則添加一個連接。

推理

在已經熟悉 IPFS 的人中，既有支持 IPFS 的，也有反對 IPFS 的。 基本上，昨天 討論 並促使我再次深入研究 IPFS。 而關於上面提到的討論：我不能說我強烈反對發言者的任何論點（我不同意一個半程序員使用IPFS的事實）。 一般來說，兩者都以自己的方式是正確的（特別是 關於支票的評論 讓你思考）。 但如果我們拋棄道德和法律的評估，誰來對這項技術進行技術評估呢？ 我個人有一種內心的感覺，“這個一定要搞清楚，有一定的前景”。 但具體為什麼，沒有明確的提法。 比如，如果你看看現有的集中式工具，那麼它們在許多方面都遙遙領先（穩定性、速度、可管理性等）。 儘管如此，我有一個想法似乎是有道理的，但如果沒有這樣的去中心化系統，這個想法就很難實現。 當然，我搖得太厲害了，但我會這樣表述：必須改變互聯網上傳播信息的原則。

讓我解釋。 如果你想一想，現在我們根據“我希望我給它的人保護它並且它不會丟失或被不想要的人收到”的原則分發信息。 例如，很容易考慮各種郵件服務、雲存儲等。 我們最終會得到什麼？ 在哈布雷輪轂上 信息安全 處於第一線，幾乎每天我們都會收到有關另一起全球洩密事件的消息。 原則上，所有最有趣的東西都列在<irony> wonderful 文章 夏天快結束了。 幾乎沒有未洩露的數據. 也就是主要的互聯網巨頭越來越大，他們積累的信息越來越多，這種洩露就是一種信息原子爆炸。 這在以前從未發生過，現在又發生了。 同時，雖然很多人明白存在風險，但他們會繼續將自己的數據託付給第三方公司。 首先，沒有太多的選擇，其次，他們承諾他們已經修補了所有的漏洞，這樣的事情再也不會發生了。

我看到什麼選項？ 在我看來，數據最初應該公開分發。 但這種情況下的開放並不意味著一切都應該易於閱讀。 我說的是存儲和分發的開放，而不是閱讀的完全開放。 我假設信息應該用公鑰分發。 畢竟公鑰/私鑰的原理已經很老了，跟互聯網差不多。 如果信息不是機密的並且是為廣泛的圈子準備的，那麼它會立即使用公鑰進行佈局（但仍然以加密形式，任何人都可以使用可用密鑰對其進行解密）。 如果沒有，那麼它就沒有公鑰，密鑰本身被轉移到應該訪問這些信息的地方。 同時，應該閱讀它的人應該只有一把鑰匙，從哪裡獲得這些信息，他不應該真正飆升——他只是從網絡上拉下來（這是按內容分發的新原則，而不是按內容分發）地址）。

因此，對於大規模攻擊，攻擊者將需要獲得大量的私鑰，而這不太可能在一個地方完成。 在我看來，這項任務比破解特定服務更困難。

另一個問題在這裡解決了：作者身份的確認。 現在在互聯網上，您可以找到我們朋友寫的許多引述。 但是，哪裡能保證是他們寫的呢？ 現在，如果每個這樣的記錄都附有數字簽名，那就容易多了。 而且這些信息位於何處並不重要，主要是簽名，當然，簽名很難偽造。

有趣的是：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 和示例項目，例如 軌道數據庫它在其上工作 軌道.chat. 也就是說，理論上，每個設備（不僅是移動設備）都可以輕鬆配備自己的加密解密機。 在這種情況下，就剩下大家自己保管好自己的私鑰了，大家自己負責自己的安全，不要成為某個超人氣互聯網巨頭的人為因素的人質。

只有註冊用戶才能參與調查。 登入， 請。

你以前聽說過 IPFS 嗎？

  • 沒聽說過IPFS，不過好像很有意思

  • 沒聽過也不想听

  • 聽過但不感興趣

  • 聽說過，沒聽懂，現在看來很有趣

  • 很長一段時間以來，我一直在積極使用 IPFS。

69 位用戶投票。 13 名用戶棄權。

來源： www.habr.com

添加評論