🥇IPFS sem dor (mas isso não é certo)

Apesar de já haver no Habr mais de um artigo sobre IPFS.

Deixe-me esclarecer que não sou um especialista nesta área, mas sempre tive interesse por essa tecnologia, embora minhas tentativas de brincar com ela costumem causar um certo desconforto. Hoje, novamente me lancei em experimentos e obtive alguns resultados que gostaria de compartilhar. Resumidamente, descreverei o processo de instalação do IPFS e algumas dicas (tudo foi feito no Ubuntu, em outras plataformas não testei).

Se você perdeu o que é IPFS, está descrito de forma bastante detalhada aqui: habr.com/ru/post/314768

Instalação

Para a clareza do experimento, sugiro instalar em algum servidor externo, pois vamos considerar algumas armadilhas operando no modo local e remoto. Depois, se você desejar, não será difícil desinstalar, pois não ocupa muito espaço.

Vamos instalar o Go

Documentação oficial
Veja a versão atual em golang.org/dl

Observação: é melhor instalar o IPFS com a conta de usuário que você planeja usar com mais frequência. O fato é que a seguir abordaremos a opção de montagem através de FUSE e lá existem algumas sutilezas.

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

Em seguida, é necessário atualizar o ambiente (mais detalhes aqui: 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

Não verificamos se o Go foi instalado

go version

Instalamos o IPFS

Gostei mais do método de instalação via ipfs-update.

Instalamos com o comando

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

Depois disso, você pode executar os seguintes comandos:

ipfs-update versions — para ver todas as versões disponíveis para download.
ipfs-update version — para ver a versão atual instalada (por enquanto, como não temos o IPFS instalado, aparecerá 'none').
ipfs-update install latest — para instalar a versão mais recente do IPFS. Em vez de 'latest', você pode especificar qualquer versão desejada da lista de disponíveis.

Instalamos o IPFS

ipfs-update install latest

Verificamos

ipfs --version

Em geral, é isso sobre a instalação.

Executando o IPFS

Inicialização

Primeiro, você precisa inicializar.

ipfs init

Em resposta, você receberá algo parecido com isto:

 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

Você pode executar o comando sugerido

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultado

Olá e bem-vindo ao IPFS!

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

Se você está vendo isso, você instalou com sucesso
o IPFS e agora está interagindo com o ipfs merkledag!

 -------------------------------------------------------
| Aviso:                                              |
|   Este é um software alfa. Utilize por sua conta e risco! |
|   Muitas coisas estão faltando ou precisam de polimento. Existem bugs.  |
|   Não é seguro ainda. Leia as notas de segurança para mais informações.   |
 -------------------------------------------------------

Confira alguns dos outros arquivos neste diretório:

  .\/about
  .\/help
  .\/quick-start     <-- exemplos de uso
  .\/readme          <-- este arquivo
  .\/security-notes

Aqui começa a parte interessante, na minha opinião. Os desenvolvedores já começam a usar suas próprias tecnologias durante a instalação. O hash proposto QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv não foi gerado especialmente para você, mas está embutido na release. Ou seja, antes do lançamento, eles prepararam o texto de boas-vindas, o colocaram no IPFS e adicionaram o endereço no instalador. Na minha opinião, isso é muito legal. E esse arquivo (ou melhor, toda a pasta) agora pode ser visualizado não apenas localmente, mas também no gateway oficial. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Isso significa que você pode ter certeza de que o conteúdo da pasta não mudou, porque se tivesse mudado, o hash também teria mudado.

Por sinal, neste caso, o IPFS tem certa semelhança com um servidor de controle de versão. Se você fizer alterações nos arquivos de origem da pasta e despejar a pasta novamente no IPFS, ela receberá um novo endereço. Nesse caso, a pasta antiga não desaparece e estará disponível em seu endereço anterior.

Início do processo

ipfs daemon

Você deve receber uma resposta como esta:

ipfs daemon
Inicializando daemon...
Versão do go-ipfs: 0.4.22-
Versão do repositório: 7
Sistema: amd64/linux
Versão do Golang: go1.12.7
Swarm escutando em /ip4/x.x.x.x/tcp/4001
Swarm escutando em /ip4/127.0.0.1/tcp/4001
Swarm escutando em /ip6/::1/tcp/4001
Swarm escutando em /p2p-circuit
Swarm anunciando /ip4/127.0.0.1/tcp/4001
Swarm anunciando /ip6/::1/tcp/4001
Servidor API escutando em /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Servidor do Gateway (somente leitura) escutando em /ip4/127.0.0.1/tcp/8080
Daemon está pronto

Abrindo as portas para a Internet

Preste atenção nessas duas linhas:

WebUI: http://127.0.0.1:5001/webui
Servidor do Gateway (somente leitura) escutando em /ip4/127.0.0.1/tcp/8080

Se você instalou o IPFS localmente, você acessará as interfaces do IPFS por endereços locais e tudo estará disponível para você (por exemplo, localhost:5001/webui/). Mas ao instalar em um servidor externo, por padrão, os gateways estão fechados para a internet. Existem dois gateways:

Administração do webui (github) na porta 5001.
API externa na porta 8080 (somente leitura).

Por enquanto, para experimentos, você pode abrir ambas as portas (5001 e 8080), mas em um servidor de produção, a porta 5001 deve ser fechada pelo firewall. Também há a porta 4001, que é necessária para que outros peers possam encontrá-lo. Esta deve ser mantida aberta para solicitações externas.

Abrimos para edição ~/ .ipfs/config e encontramos estas linhas:

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

Trocamos 127.0.0.1 pelo IP do seu servidor e salvamos o arquivo, depois reiniciamos o ipfs (interrompemos o comando em execução com Ctrl+C e iniciamos novamente).

Deve-se obter

...
WebUI: http://ip_seu_servidor:5001/webui
Servidor Gateway (somente leitura) ouvindo em /ip4/ip_seu_servidor/tcp/8080

Agora as interfaces externas devem estar acessíveis.

Verifique

http://dominio_ou_ip_do_servidor:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

O arquivo README acima deve abrir.

http://dominio_ou_ip_do_servidor:5001/webui/

A interface web deve abrir.

Se a webui estiver funcionando, você pode alterar as configurações do IPFS diretamente nela, além de visualizar estatísticas. Mas abaixo discutirei as opções de configuração diretamente através do arquivo de configuração, o que no geral não é crítico. Apenas é melhor lembrar onde exatamente está o config e o que fazer com ele, pois se a interface web não funcionar, ficará mais difícil.

Configurando a interface web para trabalhar com seu servidor

Aqui está a primeira armadilha, na qual foram desperdiçadas cerca de três horas.

Se você instalou o IPFS em um servidor externo, mas não instalou ou não iniciou o IPFS localmente, ao acessar /webui na interface web, você deve ver um erro de conexão:

O fato é que, na minha opinião, a webui funciona de maneira bastante ambígua. Primeiro, ela tenta se conectar à API do servidor onde a interface está aberta (certamente com base no endereço no navegador). E se não consegue lá, tenta se conectar ao gateway local. E se você tiver o IPFS rodando localmente, a webui funcionará normalmente, apenas você estará interagindo com o IPFS local, e não com o externo, embora tenha aberto a webui em um servidor externo. Depois você envia arquivos, mas por algum motivo não consegue vê-los simplesmente no servidor externo…

E se não estiver rodando localmente, obtemos um erro de conexão. No nosso caso, o erro provavelmente é devido ao CORS, que é mencionado pelo webui, sugerindo adicionar a configuração.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_seu_servidor:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Eu simplesmente configurei um wildcard.

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

Os cabeçalhos adicionados podem ser encontrados no mesmo ~/.ipfs/config. No meu caso, isso é

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

Reiniciamos o ipfs e vemos que o webui conectou-se com sucesso (pelo menos deve, se você abriu os gateways para solicitações externas, conforme descrito acima).

Agora você pode enviar pastas e arquivos diretamente pela interface da web, bem como criar suas pastas.

Montagem do sistema de arquivos FUSE

Isso é uma funcionalidade bastante interessante.

Podemos adicionar arquivos (assim como pastas) não apenas pela interface da web, mas também diretamente no terminal, por exemplo

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

O último hash é o hash da pasta raiz.

Com esse hash, podemos abrir a pasta em qualquer nó ipfs (que conseguir encontrar nosso nó e obter o conteúdo), seja na interface da web na porta 5001 ou 8080, ou localmente via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Mas ainda podemos abri-la como uma pasta comum.

Vamos criar duas pastas na raiz e conceder permissões a elas para nosso usuário.

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

e reiniciaremos o ipfs com a flag --mount

ipfs daemon --mount

É possível criar pastas em outros locais e especificar o caminho para elas através dos parâmetros ipfs daemon --mount --mount-ipfs /ipfs_path --mount-ipns /ipns_path

Agora, ler a partir desta pasta é um pouco incomum.

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

Ou seja, não há acesso direto à raiz desta pasta. Mas você pode obter o conteúdo, conhecendo o hash.

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

E dentro da pasta, até mesmo o autocompletar funciona ao indicar o caminho.

Como mencionei anteriormente, ao montar dessa maneira, há algumas peculiaridades: por padrão, as pastas FUSE montadas estão disponíveis apenas para o usuário atual (nem mesmo o root conseguirá ler essa pasta, sem mencionar outros usuários do sistema). Se você deseja tornar essas pastas acessíveis a outros usuários, será necessário alterar a configuração de "FuseAllowOther": false para "FuseAllowOther": true. Mas isso não é tudo. Se você iniciar o IPFS como root, tudo estará OK. E se for como um usuário comum (mesmo com sudo), você terá um erro.

erro do helper de montagem: fusermount: a opção allow_other só é permitida se 'user_allow_other' estiver configurado em /etc/fuse.conf

Nesse caso, é necessário ajustar /etc/fuse.conf, descomentando a linha #user_allow_other.

Após isso, reiniciamos o ipfs.

Problemas conhecidos com o FUSE

Já foi notado o problema de que, após reiniciar o ipfs com a montagem (ou pode ser em outros casos), os pontos de montagem /ipfs e /ipns tornam-se inacessíveis. Não há acesso a eles, e ls -la /ipfs mostra ???? na lista de permissões.

Encontrei a seguinte solução:

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

Depois disso, reiniciamos o ipfs.

Adicionando o serviço

Claro, a execução no terminal é adequada apenas para testes iniciais. Em produção, o daemon deve ser iniciado automaticamente durante a inicialização do sistema.

Usando sudo, criamos o arquivo /etc/systemd/system/ipfs.service e escrevemos nele:

[Unit]
Description=Daemon IPFS
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

Claro, USERNAME deve ser substituído pelo seu usuário (e possivelmente o caminho completo para o programa ipfs será diferente para você (deve-se indicar exatamente o caminho completo)).

Ativamos o serviço.

sudo systemctl enable ipfs.service

Iniciamos o serviço.

sudo service ipfs start

Verificamos o status do serviço.

sudo service ipfs status

Para manter a integridade do experimento, você pode reiniciar o servidor mais tarde para verificar se o ipfs inicia automaticamente.

Adicionamos os pares que conhecemos.

Vamos considerar a situação em que temos nós IPFS instalados tanto em um servidor externo quanto localmente. No servidor externo, adicionamos um arquivo e tentamos obtê-lo através do IPFS localmente por CID. O que vai acontecer? Claro, o servidor local, provavelmente, não sabe nada sobre nosso servidor externo e simplesmente tentará encontrar o arquivo pelo CID "perguntando" a todos os IPFS peers disponíveis a ele (com os quais já conseguiu "conhecer"). Esses, por sua vez, perguntarão a outros. E assim por diante, até que o arquivo seja encontrado. Na verdade, o mesmo acontece quando tentamos acessar o arquivo através do gateway oficial. ipfs.io. Se tivermos sorte, o arquivo será encontrado em poucos segundos. Caso contrário, não será encontrado nem mesmo em alguns minutos, o que afeta muito o conforto de uso. Mas sabemos onde esse arquivo aparecerá primeiro. Então, por que não dizemos imediatamente ao nosso servidor local "Procure lá primeiro"? Aparentemente, isso pode ser feito.

1. Acesse o servidor remoto e no arquivo de configuração ~/ .ipfs/config procure por

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

2. Execute sudo service ipfs status e procure por entradas de Swarm, por exemplo:

Swarm announcing /ip4/ip_seu_servidor/tcp/4001

3. Combine isso em um endereço geral do tipo "/ip4/ip_seu_servidor/tcp/4001/ipfs/$PeerID".

4. Para maior segurança, através da nossa interface web local, tentaremos adicionar esse endereço aos peers.

5. Se tudo estiver OK, abra o arquivo de configuração local ~/ .ipfs/config, encontre "Bootstrap": [...
e adicione primeiro o endereço obtido ao array.

Reinicie o IPFS.

Agora, vamos adicionar um arquivo no servidor externo e tentar solicitá-lo localmente. Deve ser rápido.

Mas essa funcionalidade ainda é instável. Pelo que entendi, mesmo que indiquemos o endereço do peer no Bootstrap, durante o funcionamento o ipfs muda a lista de conexões ativas com os peers. De qualquer forma, está havendo discussões sobre isso e pedidos para que a possibilidade de especificar peers permanentes seja implementada. aqui E parece que é previsto algum funcionalidade será adicionada no ipfs@5.0+.

A lista de peers atuais pode ser vista tanto na webui quanto no terminal.

ipfs swarm peers

Em ambos os casos, você pode adicionar manualmente seu peer.

ipfs swarm connect "/ip4/ip_seu_servidor/tcp/4001/ipfs/$PeerID"

Enquanto essa funcionalidade não for melhorada, você pode escrever uma ferramenta para verificar a existência de conexão com o peer necessário e, se não houver, adicionar a conexão.

Reflexões

Entre os que já estão familiarizados com IPFS, há argumentos a favor e contra. Basicamente, antes de ontem, desativaram isso me levou a investigar o IPFS mais uma vez. E sobre a discussão mencionada: não posso dizer que estou fortemente contra algum dos argumentos apresentados (só discordo da afirmação de que uma ou duas programadoras usam IPFS). No geral, ambos estão certos à sua maneira (especialmente o comentário sobre os cheques faz pensar). Mas se descartarmos a avaliação moral e jurídica, que tipo de avaliação técnica essa tecnologia receberia? Pessoalmente, tenho uma sensação interna de que "isso é definitivamente necessário, isso tem perspectivas específicas". Mas por que exatamente, não há uma formulação clara. Se olharmos para as soluções centralizadas já existentes, em muitos parâmetros, elas estão anos-luz à frente (estabilidade, velocidade de funcionamento, gerenciabilidade, etc.). No entanto, tenho uma ideia que parece fazer sentido e que dificilmente pode ser realizada sem esses sistemas descentralizados. Claro, estou me aventurando um pouco, mas eu a formularei assim: o princípio de disseminação da informação na Internet precisa mudar.

Vou explicar. Se pensarmos bem, atualmente a informação se dissemina com base no princípio "Espero que quem eu a passe, a proteja e que não se perca ou chegue a quem não deveria". É fácil considerar diferentes serviços de e-mail, armazenamento em nuvem, etc. E o que temos no final? No Habr, a Segurança da Informação está na primeira posição e praticamente todos os dias recebemos notícias sobre mais uma grande violação. Em essência, tudo que é interessante está listado na maravilhosa matéria. O verão quase acabou. Quase não restam dados vazados.Ou seja, os principais gigantes da Internet estão se tornando cada vez maiores, acumulando mais informações, e essas violações são como explosões atômicas de informação. Nunca aconteceu antes, e aqui estamos novamente. Ao mesmo tempo, embora muitos entendam que existem riscos, continuarão a confiar seus dados a empresas terceiras. Em primeiro lugar, não há muitas alternativas, e em segundo lugar, elas prometem que corrigiram todas as falhas e que isso nunca mais acontecerá.

Qual é a versão que imagino? Acredito que os dados devem ser distribuídos abertamente desde o início. Mas a abertura, neste caso, não significa que tudo deve ser facilmente legível. Falo sobre a abertura do armazenamento e distribuição, mas não sobre a total abertura na leitura. Suponho que a informação deve ser compartilhada com chaves públicas. Afinal, o princípio das chaves abertas/fechadas já é antigo, quase como a Internet. Se a informação não é confidencial e se destina a um amplo público, ela deve ser publicada imediatamente com uma chave pública (mas ainda assim em formato criptografado, apenas qualquer um pode descriptografá-la com a chave disponível). E se não, ela é publicada sem a chave pública, e a própria chave é transmitida para quem deve ter acesso a essa informação. Assim, quem deve lê-la deve ter apenas a chave, e não deve se preocupar muito com onde encontrar a informação — ele simplesmente a puxa da rede (este é o novo princípio de disseminação baseado no conteúdo, e não no endereço).

Assim, para um ataque em massa, os criminosos precisariam obter um enorme número de chaves privadas, e é pouco provável que consigam fazer isso em um só lugar. Essa tarefa, me parece, é mais complicada do que invadir um serviço específico.

E aqui se fecha mais um problema: a confirmação de autoria. Atualmente, é possível encontrar na internet muitas citações escritas por nossos conhecidos. Mas onde está a garantia de que foram realmente eles que as escreveram? Se cada registro desse fosse acompanhado de uma assinatura digital, seria muito mais simples. E não importa onde essa informação esteja, o que conta é a assinatura, que é, por definição, difícil de falsificar.

E aqui está o que é interessante: o IPFS já carrega recursos de criptografia (já que é construído sobre a tecnologia blockchain). No arquivo de configuração, a chave privada é especificada imediatamente.

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

Eu não sou especialista em segurança e não posso saber exatamente como isso é usado corretamente, mas parece que, no nível da troca entre os nós do IPFS, essas chaves são utilizadas. E ainda js-ipfs e projetos-exemplo como orbit-db, que é onde funciona orbit.chat. Ou seja, teoricamente, cada dispositivo (móvel e não só) pode ser facilmente equipado com suas próprias máquinas de criptografia e descriptografia. Nesse caso, cabe a cada um cuidar da preservação de suas chaves privadas, e cada um será responsável pela sua própria segurança, em vez de ser refém de mais um fator humano em algum gigante da internet super popular.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.

Você já ouviu falar do IPFS?

Nunca ouvi falar do IPFS, mas parece interessante
Não ouvi e não quero ouvir
Ouvi, mas não me interessei
Ouvi, mas não entendi, e agora parece interessante
Já uso o IPFS ativamente há muito tempo

69 usuários votaram. 13 usuários se abstiveram.

Fonte: habr.com