Lorawan-stack: さまざまな場所へのサーバーのインストールのサポート

提案をありがとう@zamashal

実際、Getting Startedは現在、単一プロセスアプローチを対象としていますが、ご覧のとおり、コンポーネントを個別に開始できます。 見る;

$ ttn-lw-stack start --help
Start The Things Stack

Usage:
  ttn-lw-stack start [is|gs|ns|as|js|console|gcs|dtc|qrg|all]... [flags]

これらのサービスが同じクラスターとサブネットの一部である場合、コンポーネントごとにサービスを生成することはそれほど難しくありません。

私は今のところこの問題をその方法の説明にスコープしています。

• スタンドアロンのIdentityServerをインストールします
• スタンドアロンのJoinServerをインストールします
• スタンドアロンサービスを使用するゲートウェイサーバー、ネットワークサーバー、およびアプリケーションサーバーを使用してルーティングクラスターをインストールします

@johanstokkingご
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

私が理解できないのは、Join ServerがJoin_Reqを受信するポートであり、Join_Ansを指定されたネットワークサーバーに自動的に送信するのでしょうか。

再度、感謝します！

@zamashalは実際、JSがサーバーであり、NSとASがクライアントです。 したがって、NSおよびASでJSクラスターアドレスを構成します。 これにより、個々のコンポーネントですが、同じクラスター内で機能します。 これは、同じクラスター内で相互に信頼するコンポーネント用に設計されたクラスター認証を使用することに注意してください。 GS、NS、ASをエッジにデプロイし、JSをクラウドにデプロイしている場合、これはおそらく当てはまりません。

その場合、LoRaWANバックエンドインターフェイスを介して相互運用機能を使用する必要があります。これもサポートされています。 これにより、NSはTLSクライアント認証を介してJSに接続できます。

これには2つの部分があります。JSを使用するようにNSを構成することと、 interop構成でJSを構成することです（ --help ）。 残念ながら、これはまだ完全には文書化されていません。

もう一度ありがとう@johanstokking ！ あなたが説明したように、私はこのセットアップを機能させようとしています。 私を混乱させることが1つあります。 提供したリンクには、 Semtech JoinServerとの相互運用性を設定する方法の例がありconfigure.ymlとexample/js.ymlの構成を追加する必要がありますか？ もしそうなら、それはどのように見えるでしょうか？

NSを外部JS（別名TTNスタックのJS）と連携するように構成しましたが、参加サーバーのポート8886 （Interop / tls）を使用してJoin_Reqを送信すると、接続が拒否されますが、 JSはそのポートでリッスンしているようです。

ありがとう！

@zamashalこれが大まかに行う必要のあることです。

サーバー相互運用構成に参加する

フラグを参照してください：

      --interop.listen-tls string                                      Address for the interop server to listen on (default ":8886")
      --interop.sender-client-ca.blob.bucket string                    Bucket to use
      --interop.sender-client-ca.blob.path string                      Path to use
      --interop.sender-client-ca.directory string                      OS filesystem directory, which contains sender client CA configuration
      --interop.sender-client-ca.source string                         Source of the sender client CA configuration (static, directory, url, blob)
      --interop.sender-client-ca.url string                            URL, which contains sender client CA configuration

相互運用機能には、TLSクライアント認証を使用する専用のリスナーがあります。 gRPCと同じパブリックIPアドレスを使用し、専用の相互運用ポート（デフォルトは8886）を使用できます。

クライアント証明書を発行するプライベートCAが必要です。 これらはNSによってエッジで使用されます。 信頼できるクライアントCAをJoinServerで構成できます。これは、NetIDごとです。 プライベートネットワークではいつでもNetID 000000と000001を使用できます。または、LoRaAllianceに参加して自分で取得することもできます。

interop.sender-client-ca.sourceをdirectoryに設定し、そこにconfig.ymlを入力します。例：

# Experimentation
000000: ca-000000.pem

# The Things Network Foundation
#000013: ca-000013.pem

プライベートCAはca-000000.pemます。 例のように、TTN NetIDにTTNのCAを追加して、これがどのように機能するかを示すことができます。

ネットワークサーバーの相互運用構成

これは文書化されている

fqdn: 'thethings.example'
port: 8886
protocol: 'BI1.0'
tls:
  root-ca: 'path/to/clientca.pem'
  certificate: 'path/to/clientcert.pem'
  key: 'path/to/clientkey.pem'

ここで、 thethings.exampleはJoin ServerのFQDNであり、8886はJS相互運用機能で構成したlisten-tlsのポートです。

また、 root-caは（例の説明とは異なり）_servercertificate_のルートCAです。 これは同じCAである可能性があります。 NSによってすでに信頼されている商用（またはLet's Encrypt）サーバー証明書を使用している場合は、省略できます。

どちらかの側でデバッグログを有効にすると（ log.level=debug ）、動作していることを確認するか、動作しない理由を追跡する必要があります。 幸運を！

また、これを機能させる場合は、これを文書化するためのプルリクエストを提出してください。 おそらくガイドが必要ですが、リファレンスページにもいくつかの愛が必要です。

@johanstokking 、私はこれに取り組んでいます、そしてうまくいけば、私がそれを理解したらすぐに私はガイドを更新するためにプルリクエストをすることを確実にします。 すべてのあなたの助けに十分に感謝することはできません！

ねえ@ johanstokking-私はすべてがあなたとうまくいっていることを願っています。 進捗状況をお知らせします。 残念ながら、私はこれを機能させるために多くのエラーに取り組んできました。ここで私が直面している最新のエラーを共有します。 相互運用機能を設定し、デフォルトのポート8886で参加サーバーに参加要求を送信するようにネットワークサーバーを構成した後、ネットワークサーバーログに次のエラーが表示され続けます。
error="join-request to join-server error: http post error: Post http://js-server_ip:8886: dial tcp js-server_ip:8886: connect: connection refused"

gRPCサーバーのポート1884に参加要求を送信するようにネットワークサーバーを構成すると、代わりにネットワークサーバーログに次のエラーが表示されます。
level=error msg="uplink: processing uplink frame error" ctx_id=f046310d-e528-4dd2-9dcb-6d5c8232a799 error="join-request to join-server error: http post error: Post http://js-server_ip:1884: net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\\x00\\x00\\f\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\\x00\\x03\\x00\\x00\\xff\\xff\""
ttnスタックログからの次のエラーと組み合わされます。
stack_1 | WARN grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: http2Server.HandleStreams received bogus greeting from client: \"POST / HTTP/1.1\\r\\nHost: 1\"" namespace=grpc

あなたや他の誰かが私がこれらのエラーを解決する方法を理解し、そのようなエラーを引き起こす可能性があるものを知るのを手伝ってくれることを願っています。

今後ともよろしくお願い申し上げます。

参加サーバーはhttps経由でのみ利用できます。

NSはDNS経由でjs-server_ipを解決できないようです。

ありがとう@johanstokking！ そうです、docker-compose.ymlのホストにポート8886をマップしなかったことがわかりました。 今私が直面している問題はTLSハンドシェイクエラーです：

tls: failed to verify client's certificate: x509: certificate signed by unknown authority

一つには、フラグ--tls.insecure-skip-verifyを使用しましたが、それでも証明書の検証を要求し、同じエラーが発生しました。 問題は、Dockerコンテナの認証局を信頼する必要があることだと思います。 スタックにシェルを開いたところ、マシンで証明書を信頼するために証明書を/usr/local/share/ca-certificates/にコピーしようとすると、 Permission deniedエラーが発生しました。

--tls.insecure-skip-verifyフラグで許可されているはずですが、実装が異なる可能性があります。 私の問題は、Dockerコンテナが自己署名証明書を信頼するオプションを提供しないことです。 そこに欠けているものはありますか？

クライアントCA構成で定義されているSenderIDのCAの1つによって署名されていますか？

これは、JoinServerがクライアント証明書を検証するために使用するものです。 システムの信頼などではありません。

私はそれに従うことを試みましたが、それはウェブサイトの指示と完全に一致していません。
私が持っているのは私のconfig.ymlにあるものです：

000000: ca-000000.pem
join-servers:
  - file: './example/js.yml'
    join-euis:
    - 'abcd000000000000/16'

次に、これをjs.ymlに入れます。

fqdn: 'thethings.example'
port: 8886
protocol: 'BI1.0'
tls:
  root-ca: 'path/to/clientca.pem'
  certificate: 'path/to/clientcert.pem'
  key: 'path/to/clientkey.pem'

送信側クライアントのCAはまだ文書化されていません。この問題を解決または置き換える一環として、文書化を行います。 （ここ）[ https://github.com/TheThingsNetwork/lorawan-stack/issues/1818#issuecomment-575534345 ]を参照してください。 これは特別なファイルであり、ファイルを参照するための独自の設定があります。

      --interop.sender-client-ca.blob.bucket string                    Bucket to use
      --interop.sender-client-ca.blob.path string                      Path to use
      --interop.sender-client-ca.directory string                      OS filesystem directory, which contains sender client CA configuration
      --interop.sender-client-ca.source string                         Source of the sender client CA configuration (static, directory, url, blob)
      --interop.sender-client-ca.url string                            URL, which contains sender client CA configuration

したがって、 sourceをdirectory設定する必要があり、そのフォルダーに前述の形式の構成をconfig.ymlに配置します。 これは、相互運用設定とは異なるディレクトリです。

ありがとう@johanstokking！ 私はそれが別のディレクトリにあるべきだとは気づいていませんでした、私はついに証明書の問題を乗り越え、ttn-stackデバッグログからこのエラーを処理しました（私は意図的にキーを隠しましたが、それらは正しかったです）：

stack_1      |   INFO Join not accepted                        dev_eui=0000000000000000 error=error:pkg/redis:not_found (entity not found) join_eui=0000000000000000 method=POST namespace=joinserver/interop remote_addr=gateway_ip:49426 request_id=01E1D3PZ63CQ7VNCE5JE8SDC3J url=/
stack_1      |   INFO Request handled                          duration=2.948762ms error=error:pkg/interop:join_req (join-request failed) error_cause=error:pkg/redis:not_found (entity not found) method=POST namespace=interop remote_addr=gateway_ip:49426 request_id=01E1D3PZ63CQ7VNCE5JE8SDC3J status=400 url=/

Gateway_ipは、NSとASが存在する場所でもあることに注意してください。

これは、NSデバッグログに表示されるものでもあります。

time="2020-02-18T16:36:52-05:00" level=error msg="uplink: processing uplink frame error" ctx_id=ef20804f-13a8-4f7f-b90e-ce279c1e11ea error="join-request to join-server error: response error, code: JoinReqFailed, description: error:pkg/redis:not_found (entity not found)"

私が読むことができることから、エラーは、docker-composeのredisコンポーネントの設定ミスについて不平を言っているようです。 構成チュートリアルに戻って、すべてが一致していることを確認しました。 私が自分の構成に持っていたのはこれでした：

volumes:
      - ${DEV_DATA_DIR:-.env/data}/redis:/data

だから私は先に進んでそれをこれに変更しました：

volumes:
    - './data/redis:/data'

次に、スタックを実行することさえできない次のエラーが表示され始めました。

stack_1      | error:cmd/internal/shared:initialize_identity_server (could not initialize Identity Server)
stack_1      | --- error:pkg/identityserver:db_needs_migration (the database needs to be migrated)
stack_1      | --- pq: database "ttn_lorawan" does not exist

この変更が必要かどうかはわかりません./data/redis/下にファイル `` appendonly.aof```が1つしか表示されないため、何かが不足しているようです。

この変更が必要かどうかはわかりません./data/redis/下にファイル `` appendonly.aof```が1つしか表示されないため、何かが不足しているようです。

いいえ、実際にはRedisにとっては問題ありません。

デバイスがJoinServerに登録されていないようです。

ああ、それがおそらく理由です。 さて、私がしたのはフラグ--js.join-eui-prefixを使用することだけ1942年の問題

redisデータベースに手動で行を追加してデバイスを登録できますか？ もしそうなら、フォーマットは何ですか？ それは私がその間他の問題を無視し続けるのを助けるかもしれません。

他の問題でダッシュボードにアクセスし、ダッシュボードにデバイスを登録することができました。 ゲートウェイが認識されないことについて不平を言っていると思われるsender unknownというエラーが表示されています。 コンソールからゲートウェイを追加しようとしましたが、それでもDisconnectedます。 Gateway_ipとserver_ipのアドレスを入力しようとしましたが、どちらもまだ違いがないようです。

送信者不明は、エンドデバイスのNetIDがネットワークサーバーのNetIDに設定されていないことを意味している可能性があります。 両方とも000000設定する必要があります。

ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000使用してCLI経由でエンドデバイスのNetIDを設定できます

ttn-lw-cli動作がおかしいので、ログインコマンドはデフォルトのオプションでしか実行できません。構成ファイルまたは認証局を指定すると、 permission deniedます。 chmodとchownを変更して、パーミッションを回避するいくつかの方法を試しましたが、引き続きpermission deniedを取得します。 ttn-lw-cli loginと入力するだけでデフォルト構成を実行すると、次のようになります。

Post https://localhost:8885/oauth/token: x509: certificate signed by unknown authority

docker-compose upは正常に実行されていますが、証明書の問題やその他のエラーは発生していません。 パーミッションが拒否される原因となる可能性のある、私が見逃している可能性のあるアイデアはありますか？
ありがとう！

サーバーとCLIの構成、および正確に何をしようとしているのかを投稿できますか？

最初にコマンドsudo ttn-lw-cli loginでログインしようとしていましたが、これが私の設定です。

# sudo ttn-lw-cli config
                         --allow-unknown-hosts="false"
                  --application-server-enabled="true"
             --application-server-grpc-address="localhost:8884"
                                          --ca=""
                                      --config="/etc/ttn-cli/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.config/.ttn-lw-cli.yml"
                              --credentials-id=""
         --device-claiming-server-grpc-address="localhost:8884"
      --device-template-converter-grpc-address="localhost:8884"
                      --gateway-server-enabled="true"
                 --gateway-server-grpc-address="localhost:8884"
                --identity-server-grpc-address="localhost:8884"
                                --input-format="json"
                                    --insecure="false"
                         --join-server-enabled="true"
                    --join-server-grpc-address="localhost:8884"
                                   --log.level="info"
                      --network-server-enabled="true"
                 --network-server-grpc-address="localhost:8884"
                        --oauth-server-address="https://localhost:8885/oauth"
                               --output-format="json"
              --qr-code-generator-grpc-address="localhost:8884"

したがって、デフォルトを実行すると、以前に共有したcertificate signed by unknown authorityエラーが発生します。 しかし、証明書の問題のため、次のオプションを追加しようとしました： sudo ttn-lw-cli login --ca "path/to/ca.pem"しかし、それは私に許可拒否エラーを与えました。

次のオプションを追加しようとしました： sudo ttn-lw-cli login --ca "path/to/ca.pem"

これはいい。 これを構成ファイルまたは環境に配置することもできます。

しかし、それは私に許可拒否エラーを与えました。

CLIまたはサーバー上で？ ログはありますか？

サーバーエラーだと思いますか？ これが私が見ることができるすべてです：

root<strong i="6">@myserver</strong>:/etc/ttn-cli# sudo ttn-lw-cli login --ca="/etc/ttn-cli/ca.pem" --log.level="debug"
open /etc/ttn-cli/ca.pem: permission denied

また、 chmod 777権限を付与しようとしましたが、それでも同じエラーが発生します。

設定ファイルを/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml追加することで、ようやくこの問題を回避することができました。

certificate signed by unknown authorityエラーが発生しました。 ttn-lw-cliツールはどのように証明書を信頼しますか？ 完全なログは次のとおりです。

root<strong i="8">@localhost</strong>:/etc/ttn-stack# sudo ttn-lw-cli login --callback=false --config="/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml" --log.level="debug" --insecure="true" --allow-unknown-hosts="true" --ca="/root/snap/ttn-lw-stack/149/ca.pem"
  WARN Access token expired at 5:17PM
 ERROR Please login with the login command
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:1884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00087caa0, {CONNECTING <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00087caa0, {READY <nil>}
 DEBUG Finished unary call                      duration=2.376756ms grpc_method=AuthInfo grpc_service=ttn.lorawan.v3.EntityAccess namespace=grpc
  INFO Opening your browser on https://localhost/oauth/authorize?client_id=cli&redirect_uri=code&response_type=code
  WARN Could not open your browser, you'll have to go there yourself error=fork/exec /usr/bin/xdg-open: permission denied
  INFO After logging in and authorizing the CLI, we'll get an access token for future commands.
  INFO Please paste the authorization code and press enter
> MF2XI.JX2QFUHNVVWMEYTTRQ3S4DTGPI5VXBYJWVJQ2ZI.OG5C4HQXGMRQ4LVW7ES4IZRNH2L5OJOING2SWOW74LFLQAYDH64Q
 ERROR Could not exchange OAuth access token    error=Post https://localhost/oauth/token: x509: certificate signed by unknown authority
Post https://localhost/oauth/token: x509: certificate signed by unknown authority

docker-composeで実行するttn-stackによって信頼されているのと同じca.pemを使用しています。

ttn-lw-cli http URIとhttpポートを使用して、ログイン/証明書の問題を再び回避しました。 sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug"を実行すると、次のように表示されます。

root<strong i="8">@localhost</strong>:/etc/ttn-stack$ sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug"
 DEBUG Using access token (valid until 6:42PM)
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:1884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {CONNECTING <nil>}
  WARN grpc: addrConn.createTransport failed to connect to {localhost:1884  <nil> 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: context deadline exceeded". Reconnecting...
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {TRANSIENT_FAILURE connection error: desc = "transport: authentication handshake failed: context deadline exceeded"}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {CONNECTING <nil>}
  WARN grpc: addrConn.createTransport failed to connect to {localhost:1884  <nil> 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

これが私のttn-lw-cli設定です：

                         --allow-unknown-hosts="true"
                  --application-server-enabled="true"
             --application-server-grpc-address="localhost:1884"
                                          --ca="/root/snap/ttn-lw-stack/149/ca.pem"
                                      --config="/etc/ttn-stack/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.config/.ttn-lw-cli.yml"
                              --credentials-id=""
         --device-claiming-server-grpc-address="localhost:1884"
      --device-template-converter-grpc-address="localhost:1884"
                      --gateway-server-enabled="true"
                 --gateway-server-grpc-address="localhost:1884"
                --identity-server-grpc-address="localhost:1884"
                                --input-format="json"
                                    --insecure="true"
                         --join-server-enabled="true"
                    --join-server-grpc-address="localhost:1884"
                                   --log.level="info"
                      --network-server-enabled="true"
                 --network-server-grpc-address="localhost:1884"
                        --oauth-server-address="http://localhost/oauth"
                               --output-format="json"
              --qr-code-generator-grpc-address="localhost:1884"

ログイン後にINFO Got OAuth access tokenメッセージが表示されましたが、これは認証が成功したことを示しているようですが、これは私のhttpセットアップに関連している可能性があると思います。

また、 docker-composeログから次のエラーが表示されるようになりました。

stack_1      |  DEBUG Rejected authentication                  client_id=mqtt_5bc528ca.ae4ea8 error=error:pkg/ttnpb:identifiers (invalid identifiers) error_cause=error:pkg/errors:validation (invalid `application_id`: value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$") field=application_id name=ApplicationIdentifiersValidationError namespace=applicationserver/io/mqtt reason=value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$" username=
stack_1      |   WARN Failed to setup connection               error=error:pkg/ttnpb:identifiers (invalid identifiers) error_cause=error:pkg/errors:validation (invalid `application_id`: value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$") field=application_id name=ApplicationIdentifiersValidationError namespace=applicationserver/io/mqtt reason=value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$" remote_addr=172.18.0.1:57472

それが何を指しているのか理解できませんでしたが、私が追加したのと同じデバイスとアプリケーションについて不平を言っているのではないかと思いましたが、まだセンサーが結合されていません。

certificate signed by unknown authorityエラーが発生しました。 ttn-lw-cliツールはどのように証明書を信頼しますか？

ca渡したCAファイルを使用します。 そのファイルは、サーバー証明書（自己署名の場合）またはサーバー証明書に署名したCAのいずれかを指している必要があります。

これが私のttn-lw-cli設定です：

この構成は、TLSを使用したくない場合に適しています。 しかし、サーバーは非TLS構成で、これらのアドレスをリッスンしていますか？

また、 docker-composeログから次のエラーが表示されるようになりました。

これは、有効なアプリケーションIDではないユーザー名で接続しているMQTTクライアントです。

ヒントをありがとう！ 指すcert.pemの代わりにca.pem解かcertificate signed by unknown authority問題を。 ただし、他の接続エラーが発生します。 私は間違いなくポート1884聞いています：

user<strong i="10">@localhost</strong>:/etc/ttn-stack$ sudo netstat -tulpn | grep LISTEN
tcp6       0      0 :::1884                 :::*                    LISTEN      18793/docker-proxy

ポート1884にTelnetで接続してttn-lw-cliツールを実行すると、データパケットが通過することもわかります。 したがって、パケットの交換が確実に行われていますが、デバッグログには次のエラーが表示されます： "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

end-device setコマンドに--insecureフラグを追加することで、この問題をようやく解決しました。 TLSに問題があるようですが、とにかく今は心配していません
再度、感謝します！

私は、設定後ことを通知するために興奮しています--root-keys.app-key.keyに加えて、 --net-idのためのプロセスに参加し、 end-device正常に完了し、私は独立した上で、エンドデバイスからデータを取得し始めましたアプリケーション・サーバー！ 私が直面したすべての問題を通してあなたの大きな助けにもう一度感謝します！

それは素晴らしいことです！ ここにシナリオを文書化できれば素晴らしいと思いますので、それを組み込むことができます。

モチベーションと最初のパンケーキであることにも感謝します。