Lorawan-stack: विभिन्न स्थानों पर सर्वर स्थापित करने के लिए समर्थन

सुझाव के लिए धन्यवाद @zamashal

वास्तव में प्रारंभ करना वर्तमान में एकल प्रक्रिया दृष्टिकोण के लिए है, लेकिन जैसा कि आपने देखा होगा, आप घटकों को व्यक्तिगत रूप से प्रारंभ कर सकते हैं। देखो;

$ 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]

जब ये सेवाएं एक ही क्लस्टर और सबनेट का हिस्सा हों तो प्रति घटक सेवाओं को स्पॉन करना बहुत मुश्किल नहीं है।

मैं इस मुद्दे को अभी के लिए निर्देश दे रहा हूं कि कैसे करें;

• एक स्टैंड-अलोन पहचान सर्वर स्थापित करें
• एक स्टैंड-अलोन जॉइन सर्वर स्थापित करें
• गेटवे सर्वर, नेटवर्क सर्वर और एप्लिकेशन सर्वर के साथ रूटिंग क्लस्टर स्थापित करें जो स्टैंड-अलोन सेवाओं का उपयोग करता है

@johanstokking आपकी प्रतिक्रिया के लिए और इस मुद्दे को बैकलॉग में जोड़ने के लिए बहुत-बहुत धन्यवाद। इस बीच, मुझे आश्चर्य है कि क्या आप इसमें मेरी मदद कर सकते हैं। मैंने निम्नलिखित कमांड के साथ अकेले जॉइन सर्वर शुरू किया:
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

जो मैं नहीं समझ सकता वह यह है कि जॉइन सर्वर को किस पोर्ट पर Join_Req प्राप्त होता है और क्या यह स्वचालित रूप से निर्दिष्ट नेटवर्क सर्वर पर Join_Ans भेजने वाला है?

एक बार फिर धन्यवाद!

@zamashal वास्तव में JS सर्वर है और NS और AS क्लाइंट हैं। तो NS और AS में JS क्लस्टर एड्रेस को कॉन्फ़िगर करें। यह उन्हें एक ही क्लस्टर में काम करता है, हालांकि वे अलग-अलग घटक हैं। ध्यान दें कि यह क्लस्टर प्रमाणीकरण का उपयोग करता है, जो एक ही क्लस्टर में एक दूसरे पर भरोसा करने वाले घटकों के लिए डिज़ाइन किया गया है। यदि आप जीएस, एनएस और एएस को किनारे पर और जेएस को क्लाउड में तैनात कर रहे हैं, तो शायद ऐसा नहीं है।

उस स्थिति में, आपको लोरावन बैकएंड इंटरफेस के माध्यम से इंटरऑप का उपयोग करना होगा, जो भी समर्थित है। यह NS को TLS क्लाइंट प्रमाणीकरण के माध्यम से आपके JS से संपर्क करने की अनुमति देता है।

यह दो भागों में आता है: अपने JS का उपयोग करने के लिए NS को कॉन्फ़िगर करना और अपने JS को interop कॉन्फ़िगरेशन के साथ कॉन्फ़िगर करना (देखें --help )। यह दुर्भाग्य से अभी तक पूरी तरह से प्रलेखित नहीं है।

फिर से धन्यवाद @johanstokking ! जैसा कि आपने समझाया है, मैं इस सेटअप को काम करने की कोशिश कर रहा हूं। एक बात मुझे भ्रमित कर रही है। आपके द्वारा प्रदान किए गए लिंक पर, Semtech Join Server के साथ इंटरऑपरेबिलिटी कैसे सेट करें, इसका एक उदाहरण है। हालांकि, मैं टीटीएन स्टैक के जॉइन सर्वर का उपयोग करने की कोशिश कर रहा हूं, न कि कुछ बाहरी जैसे सेमटेक या अन्य। क्या मुझे अभी भी configure.yml और example/js.yml लिए कॉन्फ़िगरेशन डालने की आवश्यकता है? अगर ऐसा है तो वह कैसा दिखेगा?

मैंने अपने एनएस को बाहरी जेएस (उर्फ, टीटीएन स्टैक के जेएस) के साथ काम करने के लिए पहले ही कॉन्फ़िगर कर दिया है, लेकिन Join_Req भेजने के लिए जॉइन सर्वर के पोर्ट 8886 (इंटरऑप/टीएलएस) का उपयोग करके, कनेक्शन अस्वीकार कर दिया जा रहा है, हालांकि ऐसा लगता है कि जेएस उस बंदरगाह पर सुन रहा है।

धन्यवाद!

@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

इंटरऑप का अपना समर्पित श्रोता है जो टीएलएस क्लाइंट प्रमाणीकरण का उपयोग करता है। आप जीआरपीसी के समान सार्वजनिक आईपी पते का उपयोग कर सकते हैं और एक समर्पित इंटरऑप पोर्ट (डिफ़ॉल्ट 8886) का उपयोग कर सकते हैं।

आपको एक निजी CA की आवश्यकता है जो क्लाइंट प्रमाणपत्र जारी करे। इनका उपयोग NS द्वारा किनारे पर किया जाता है। आप जॉइन सर्वर में विश्वसनीय क्लाइंट CA को कॉन्फ़िगर कर सकते हैं, और यह प्रति NetID है। आप अपने निजी नेटवर्क में हमेशा NetIDs 000000 और 000001 का उपयोग कर सकते हैं, या लोरा एलायंस में शामिल हो सकते हैं और आप स्वयं एक प्राप्त कर सकते हैं।

interop.sender-client-ca.source से directory और उदाहरण के लिए वहां config.yml डालें:

# Experimentation
000000: ca-000000.pem

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

आपका निजी सीए ca-000000.pem । उदाहरण के तौर पर आप टीटीएन नेटआईडी के लिए टीटीएन का सीए जोड़ सकते हैं, बस आपको यह दिखाने के लिए कि यह कैसे काम करता है।

नेटवर्क सर्वर इंटरऑप कॉन्फ़िगरेशन

यह दस्तावेज जैसा है , लेकिन वास्तव में आपको जो चाहिए वह स्थानीय जेएस कॉन्फ़िगरेशन है। यह इस प्रकार होगा:

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 आपके ज्वाइन सर्वर का FQDN है और 8886 उस listen-tls का पोर्ट है जिसे आपने JS इंटरऑप में कॉन्फ़िगर किया था।

साथ ही, root-ca (उदाहरण के विपरीत) _server certificate_ का रूट CA है। यह वही सीए हो सकता है। आप इसे छोड़ भी सकते हैं यदि आप एक वाणिज्यिक (या लेट्स एनक्रिप्ट) सर्वर प्रमाणपत्र का उपयोग करते हैं जिस पर पहले से ही एनएस द्वारा भरोसा किया जाता है।

दोनों तरफ डीबग लॉग सक्षम करें ( 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"

अगर मैं अपने नेटवर्क सर्वर को जीआरपीसी सर्वर के पोर्ट 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: failed to verify client's certificate: x509: certificate signed by unknown authority

एक बात के लिए, मैंने झंडे का इस्तेमाल किया --tls.insecure-skip-verify लेकिन इसने अभी भी प्रमाण पत्र को सत्यापित करने पर जोर दिया और मुझे वही त्रुटि दी। मुझे लगता है कि मुद्दा यह है कि मुझे अपने डॉकटर कंटेनर में प्रमाणपत्र प्राधिकरण पर भरोसा करने की आवश्यकता है। मैंने स्टैक में एक खोल खोला और जब भी मैं मशीन द्वारा उन पर भरोसा करने के लिए प्रमाणपत्रों को /usr/local/share/ca-certificates/ में कॉपी करने का प्रयास करता हूं तो मुझे Permission denied त्रुटि मिलती है।

मुझे लगता है कि --tls.insecure-skip-verify ध्वज को इसकी अनुमति देनी चाहिए थी, लेकिन हो सकता है कि आपका कार्यान्वयन अलग हो। मेरी समस्या अब यह है कि डोकर कंटेनर मुझे मेरे स्व-हस्ताक्षरित प्रमाणपत्र पर भरोसा करने का विकल्प नहीं देता है। क्या मुझे वहां कुछ याद आ रहा है?

क्या क्लाइंट CA कॉन्फ़िगरेशन में परिभाषित SenderID लिए किसी CA द्वारा क्लाइंट प्रमाणपत्र पर हस्ताक्षर किए गए हैं?

क्लाइंट प्रमाणपत्र को सत्यापित करने के लिए जॉइन सर्वर का उपयोग करता है; सिस्टम ट्रस्ट या कुछ भी नहीं।

मैंने उसका पालन करने का प्रयास किया, लेकिन यह पूरी तरह से वेबसाइट पर दिए गए निर्देशों के अनुरूप नहीं है।
मेरे पास मेरे 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! मुझे नहीं पता था कि एक अलग निर्देशिका में होना चाहिए, मैं अंत में प्रमाण पत्र के मुद्दे से आगे निकल गया और अब टीटीएन-स्टैक डीबग लॉग से इस त्रुटि से निपट रहा हूं (मैंने जानबूझकर चाबियों को कवर किया था, लेकिन वे सही थे):

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=/

ध्यान दें, गेटवे_आईपी वह जगह भी है जहां एनएस और एएस रहते हैं।

एनएस डीबग लॉग पर मैं यही देख रहा हूं:

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

मैं जो पढ़ सकता हूं, वह त्रुटि डॉकर-कंपोज़ के मेरे रेडिस घटक के गलत कॉन्फ़िगरेशन के बारे में शिकायत कर रही है। मैंने यह सुनिश्चित करने के लिए कॉन्फ़िगरेशन ट्यूटोरियल पर दोबारा गौर किया कि सब कुछ मेल खा रहा है। मेरे कॉन्फ़िगरेशन पर मेरे पास यह था:

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`` दिखाई देती है, इसलिए ऐसा लगता है कि मुझे कुछ याद आ रहा है।

मुझे यकीन नहीं था कि यह परिवर्तन बिल्कुल भी आवश्यक था, ./data/redis/ तहत मुझे केवल एक फ़ाइल ``appendonly.aof`` दिखाई देती है, इसलिए ऐसा लगता है कि मुझे कुछ याद आ रहा है।

नहीं, वास्तव में रेडिस के लिए यह ठीक है।

ऐसा लगता है कि आपका डिवाइस ज्वाइन सर्वर में पंजीकृत नहीं है?

अरे शायद इसीलिए। खैर मैंने जो कुछ किया वह ध्वज --js.join-eui-prefix का उपयोग कर रहा था लेकिन ऐसा लगता है कि यह पर्याप्त नहीं है। मैं एक और मुद्दे पर फंस गया हूं जिसे मैं नजरअंदाज करने की कोशिश कर रहा हूं: अंक 1942

क्या मैं रेडिस डेटाबेस में मैन्युअल रूप से पंक्तियों को जोड़कर डिवाइस को पंजीकृत कर सकता हूं? यदि हां, तो प्रारूप क्या है ? इससे मुझे इस बीच अन्य मुद्दे को अनदेखा करने में मदद मिल सकती है ..

मैं दूसरे मुद्दे पर डैशबोर्ड तक पहुंचने और डिवाइस को डैशबोर्ड पर पंजीकृत करने में सक्षम था। मुझे अब एक त्रुटि दिखाई दे रही है जो कह रही है sender unknown जो मुझे विश्वास है कि गेटवे की पहचान नहीं होने के बारे में शिकायत कर रहा है। मैंने कंसोल से गेटवे जोड़ने का प्रयास किया लेकिन यह अभी भी Disconnected कहता है। मैंने गेटवे_आईपी और सर्वर_आईपी का पता दर्ज करने का प्रयास किया लेकिन दोनों को अभी तक कोई फर्क नहीं पड़ा।

प्रेषक अज्ञात संभावना का अर्थ है कि अंतिम डिवाइस का नेटआईडी आपके नेटवर्क सर्वर के नेटआईडी पर सेट नहीं है। दोनों को 000000 सेट किया जाना चाहिए।

आप ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000 साथ सीएलआई के माध्यम से अंतिम डिवाइस का नेटआईडी सेट कर सकते हैं

मेरा ttn-lw-cli अजीब काम कर रहा है, मैं केवल डिफ़ॉल्ट विकल्पों के साथ लॉगिन कमांड चला सकता हूं, और अगर मैं कुछ भी कॉन्फ़िगरेशन फ़ाइल या प्रमाणपत्र प्राधिकरण निर्दिष्ट करता हूं तो मुझे permission denied । मैंने chmod को बदलकर अनुमतियों के आसपास कई तरीकों की कोशिश की और मुझे permission denied प्राप्त करना जारी रखा। अगर मैं केवल ttn-lw-cli login टाइप करके डिफ़ॉल्ट कॉन्फ़िगरेशन चलाता हूं तो मुझे मिलता है:

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

हालांकि डॉकर-कंपोज़ अप प्रमाणपत्र समस्याओं या किसी अन्य त्रुटि के बिना ठीक चल रहा है। किसी भी विचार से मुझे क्या याद आ रहा है जो संभवतः अनुमतियों से इनकार कर रहा है?
धन्यवाद!

क्या आप अपना सर्वर और सीएलआई कॉन्फ़िगरेशन पोस्ट कर सकते हैं और आप वास्तव में क्या करने का प्रयास कर रहे हैं?

मैं केवल 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"

यह अच्छा है। आप इसे किसी कॉन्फ़िग फ़ाइल या परिवेश में भी रख सकते हैं।

लेकिन इसने मुझे एक अनुमति अस्वीकृत त्रुटि दी।

सीएलआई या सर्वर पर? क्या आपके पास लॉग हैं?

सर्वर त्रुटि मुझे लगता है? यह सब मैं देख सकता हूँ:

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

मैं उसी ca.pem का उपयोग कर रहा हूं जिस पर ttn-stack द्वारा भरोसा किया जाता है जिसे मैं docker-compose के साथ चलाता हूं।

मैंने 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"

मुझे लगता है कि यह मेरे http सेटअप से संबंधित हो सकता है, हालांकि मेरे पास लॉगिन के बाद INFO Got OAuth access token संदेश था जो सफल प्रमाणीकरण को इंगित करता है।

मुझे अपने 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 का उपयोग नहीं करना चाहते हैं तो यह कॉन्फ़िगरेशन अच्छा दिखता है। लेकिन, क्या सर्वर इन पतों पर अपने गैर-टीएलएस कॉन्फिगरेशन में सुन रहा है?

मुझे अपने docker-compose लॉग से निम्न त्रुटि भी दिखाई देने लगी:

यह एक 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 पोर्ट पर टेलनेट करता हूं और ttn-lw-cli टूल चलाता हूं तो मैं डेटा पैकेट भी देख सकता हूं। तो निश्चित रूप से पैकेट का आदान-प्रदान हो रहा है, लेकिन डीबग लॉग अभी भी मुझे निम्न त्रुटि देता है: "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

मैंने अंततः --insecure ध्वज को end-device set कमांड में जोड़कर इस मुद्दे को हल किया !! ऐसा लगता है कि मुझे टीएलएस के साथ समस्या हो रही है, लेकिन मैं इसके बारे में अब वैसे भी चिंतित नहीं हूं
एक बार फिर धन्यवाद!

मैं आपको सूचित करना है कि सेट करने के बाद रोमांचित हूँ --root-keys.app-key.key के अलावा --net-id , के लिए प्रक्रिया में शामिल होने के end-device सफलतापूर्वक पूरा कर लिया है और मैं स्वतंत्र पर अंत डिवाइस से डेटा आने शुरू हो गए अनुप्रयोग सर्वर! मैंने जिन सभी मुद्दों का सामना किया है, उनके लिए आपकी महान मदद के लिए फिर से धन्यवाद!

एक दम बढ़िया! यह बहुत अच्छा होगा यदि आप यहां अपने परिदृश्य का दस्तावेजीकरण कर सकें, ताकि हम इसे शामिल कर सकें।

प्रेरणा और पहला पैनकेक होने के लिए भी धन्यवाद।