Lorawan-stack: हमारी आरंभ करना मार्गदर्शिका में समस्या निवारण अनुभाग जोड़ें

नमस्ते, निश्चित रूप से इसके लिए एक अंगूठा। गाइड का पालन करते हुए मुझे कुछ समस्याओं और खुले प्रश्नों का सामना करना पड़ा। फिलहाल मैं इस त्रुटि से फंस गया हूं। हो सकता है कि आप इसे दस्तावेज़ीकरण में भी इंगित कर सकें?

@fox27374 क्या आप ब्राउज़र डेवलपर टूल खोल सकते हैं और window.PAGE_DATA मान पेस्ट कर सकते हैं? इस त्रुटि को देखते हुए आप इसे ब्राउज़र कंसोल में दर्ज कर सकते हैं।

साथ ही, क्या आपने प्रारंभ करने के सभी चरणों का पालन किया, अर्थात कंसोल OAuth क्लाइंट बनाने के लिए?

नमस्ते,
यहाँ विंडो है। PAGE_DATA और साथ ही वह कमांड जो मैं शपथ क्लाइंट बनाने के लिए उपयोग करता हूँ। उल्लेख करने के लिए एक महत्वपूर्ण बिंदु यह है कि मैं अपने स्वयं के प्रमाणपत्र (लैब सीए द्वारा हस्ताक्षरित) का उपयोग करता हूं।

आंकड़े
window.PAGE_DATA = { "error": { "code": 7, "message": "error:pkg/web/oauthclient:exchange (token exchange refused)", "details": [{ "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails", "namespace": "pkg/web/oauthclient", "name": "exchange", "message_format": "token exchange refused", "code": 7 }] } };

COMMAND
docker-compose run --rm stack is-db create-oauth-client --id console --name "Console" --owner admin --secret "SM2CE7335KDAIILCA76KETRHDQTTDAQTDJHBSL6RCOX3WFZFDZ4Q" --redirect-uri "https://lora01.ntslab.loc/console/oauth/callback" --redirect-uri "/console/oauth/callback"

बहुत - बहुत धन्यवाद!
चीयर्स,
डैनियल

@ Fox27374 अतिरिक्त जानकारी के लिए धन्यवाद।

कॉन्फ़िगर किया गया OAuth URL क्या है, अर्थात /token URL जिसे आपने कॉन्फ़िगर किया है? आप संवेदनशील सामग्री को संशोधित कर सकते हैं।

क्या आप पुष्टि कर सकते हैं कि lora01.ntslab.loc डॉकर कंटेनर में हल हो जाता है, यह मानते हुए कि आप डॉकर के माध्यम से थिंग्स स्टैक चलाते हैं?

नमस्ते,

उत्तर के लिए और यहां मेरी मदद करने के लिए धन्यवाद। सामग्री अभी तक समझदार नहीं है, यह भविष्य के उत्पादन वातावरण के परीक्षण के रूप में अभी के लिए एक प्रयोगशाला सेटअप है। मैं एक्टिविटी सर्वर से छुटकारा पाना चाहता हूं :)

हां, मैं लिनक्स सर्वर पर डॉकर के माध्यम से टीटीएन स्टैक चलाता हूं। lora01.ntslab.loc को होस्ट फ़ाइल में कॉन्फ़िगर किया गया है, इसलिए नाम समाधान काम करना चाहिए।

/टोकन यूआरएल है:
टोकन-यूआरएल: ' https://lora01.ntslab.loc/oauth/token '

यदि आपको अधिक जानकारी की आवश्यकता है, तो आप सीधे docker-compose.yml और ttn-lw-stack.yml फ़ाइलों को देख सकते हैं। मैं इनिशियलाइज़ेशन ( start.sh ) करने के लिए एक स्टार्ट स्क्रिप्ट का भी उपयोग करता हूँ।

पहले ही, आपका बहुत धन्यवाद,
डैनियल

हाय @ फॉक्स27374

हां, मैं लिनक्स सर्वर पर डॉकर के माध्यम से टीटीएन स्टैक चलाता हूं। lora01.ntslab.loc को होस्ट फ़ाइल में कॉन्फ़िगर किया गया है, इसलिए नाम समाधान काम करना चाहिए।

क्या आपका मतलब आपकी मशीन की /etc/hosts फ़ाइल से है? यह डॉकर कंटेनर को प्रभावित नहीं करता है जहां स्टैक चल रहा है, जो आपके द्वारा देखी जा रही समस्या का स्रोत हो सकता है।

आप इसे निम्न आदेश के साथ देख सकते हैं:

$ docker-compose stack exec nc -z lora01.ntslab.loc

आपको nc: bad address 'lora01.ntslab.loc' की तर्ज पर कुछ देखना चाहिए।

क्या आप अपने docker-compose.yaml में extra_hosts अनुभाग जोड़ने का प्रयास कर सकते हैं, जैसे:

# docker-compose.yaml
services:
  # ...
  stack:
    # ...
    extra_hosts:
      - "lora01.ntslab.loc:YOUR_IP_ADDRESS"
    # ...

और docker-compose up -d . के साथ पुनः आरंभ करें

होस्टनाम रिज़ॉल्यूशन तब काम करना चाहिए। (लेकिन, अगर YOUR_IP_ADDRESS कुछ इस तरह है 127.0.0.1 , तो फिर भी आपको कुछ त्रुटियां मिल सकती हैं)

नमस्ते @neoaggelos
जानकारी के लिए धन्यवाद। मैंने मेजबानों की प्रविष्टि को हटा दिया और आईपी/होस्टनाम को सीधे DNS सर्वर पर सेट कर दिया। इसके अतिरिक्त मैंने docker-compose.yml में "extra_hosts" प्रविष्टि जोड़ी।
मुझे डर है, त्रुटि अभी भी मौजूद है।

मैंने कंटेनर में ऐश शेल शुरू किया और डीएनएस रिज़ॉल्यूशन की जाँच की:

$ nslookup lora01.ntslab.loc
Name:      lora01.ntslab.loc
Address 1: 172.24.89.120 lora01.ntslab.loc

तो यह अच्छा लगता है। त्रुटि संदेश के बाद टोकन एक्सचेंज ने इनकार कर दिया , क्या कोई और डिबगिंग है जिसे हम ओथ टोकन एक्सचेंज के लिए सक्षम कर सकते हैं? आपको इसमें व्यस्त रखने के लिए खेद है....
धन्यवाद

वैसे लगता है किसी और को भी यही समस्या है

नमस्ते @neoaggelos
जानकारी के लिए धन्यवाद। मैंने मेजबानों की प्रविष्टि को हटा दिया और आईपी/होस्टनाम को सीधे DNS सर्वर पर सेट कर दिया। इसके अतिरिक्त मैंने docker-compose.yml में "extra_hosts" प्रविष्टि जोड़ी।

हम्म, उचित DNS कॉन्फ़िगरेशन के साथ, आपको extra_hosts सेट नहीं करना चाहिए।

मुझे डर है, त्रुटि अभी भी मौजूद है।

मैंने कंटेनर में ऐश शेल शुरू किया और डीएनएस रिज़ॉल्यूशन की जाँच की:

$ nslookup lora01.ntslab.loc
Name:      lora01.ntslab.loc
Address 1: 172.24.89.120 lora01.ntslab.loc

172.24.89.120 डॉकर द्वारा बनाए गए नेटवर्क में से एक है, जो विफलता का एक संभावित कारण भी हो सकता है।

तो यह अच्छा लगता है। त्रुटि संदेश के बाद टोकन एक्सचेंज ने इनकार कर दिया , क्या कोई और डिबगिंग है जिसे हम ओथ टोकन एक्सचेंज के लिए सक्षम कर सकते हैं? आपको इसमें व्यस्त रखने के लिए खेद है....
धन्यवाद

अपनी कुकीज़ साफ़ करने का प्रयास करें, और स्वच्छ ब्राउज़र सत्र से भी प्रयास करें। साथ ही, सुनिश्चित करें कि प्रमाणपत्रों को स्टैक cat /var/run/secrets/cert.pem से ठीक से पढ़ा गया है और कंटेनर के भीतर एक खोल से cat /var/run/secrets/key.pem उस एक को जांचने के लिए पर्याप्त होना चाहिए।

विषय से परे; क्या आपने लोकलहोस्ट पर स्टैक सेट करने का प्रयास किया है? क्या आप सफल हुए?

नमस्ते,

क्षमा करें, मैंने उल्लेख नहीं किया कि 172.24.89.120 प्रयोगशाला में ही सर्वर का आईपी पता है। डॉकर पते 172.9.0.X हैं

मैं निजी मोड में ब्राउज़र के साथ सभी परीक्षण करता हूं, इसलिए इसमें कोई कुकी शामिल नहीं है। कुंजी और प्रमाणपत्र "thethings" उपयोगकर्ता के साथ पठनीय है:

/ $ whoami
thethings

/ $ cat /var/run/secrets/key.pem 
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC7IjZoBd2Mu4Ev
AYDrEh6mBWYw5cRDA02F10OQpbQbm6RigFbODM2owGRyCkkZfAUL2VV9xl5TzdMl
I6IecaA7/F7TpciuiJHmnfRVAbDlPI6EJYybdrU7tmfdeWc/ThuVVNolJFUeap+T
OIzv9MkGbBAF19ju4PJel6z3ef+NUhc5LKfjVQZeieQULX2b9+Hpd4ySdR2Nfzdt
......

मैं सेटअप को लोकलहोस्ट में बदलने की कोशिश करूंगा और आपको पोस्ट करता रहूंगा।

क्षमा करें, मैंने उल्लेख नहीं किया कि 172.24.89.120 प्रयोगशाला में ही सर्वर का आईपी पता है। डॉकर पते 172.9.0.X हैं

लेकिन क्या आप कंटेनर के अंदर से curl https://lora01.ntslab.loc कर सकते हैं? यदि नहीं, तो रिपोर्ट की गई त्रुटि क्या है?

नमस्ते,

ऐसा लगता है कि हमें मिल गया। कर्ल संकेत एक अच्छा था। इससे पता चला, कि ca.pem विश्वसनीय प्रमाणपत्र स्टोर में नहीं था:

/ # curl https://lora01.ntslab.loc
curl: (60) SSL certificate problem: self signed certificate in certificate chain

इसलिए मैंने ca.pem प्रमाणपत्र को /usr/local/share/ca-certificates/ पर कॉपी किया

/ $ ls -la /usr/local/share/ca-certificates/ca.pem 
-rw-r--r--    1 thething thething      1310 Apr 14 11:36 /usr/local/share/ca-certificates/ca.pem

इसे docker-compose.yml फ़ाइल के वॉल्यूम सेक्शन में जोड़कर:

volumes:
      - "./data/blob:/srv/ttn-lorawan/public/blob"
      - "./config/stack:/config:ro"
      - "./config/stack/cert/ca.pem:/usr/local/share/ca-certificates/ca.pem"

अब मैं कंसोल में लॉगिन करने में सक्षम हूं और सभी प्रमाणपत्र विश्वसनीय हैं। बहुत बढ़िया!

क्या यह TTN कंटेनर में एक विश्वसनीय रूट प्रमाणपत्र जोड़ने का सबसे अच्छा/इच्छित तरीका है?

बहुत जल्दी उत्साहित होने के लिए क्षमा करें। ऐसा लगता है कि ऑथ टोकन अभी भी डीबी में था, इसलिए सबकुछ काम करता था। कंटेनर शुरू होने के बाद, मुझे ca.pem प्रमाणपत्र को विश्वसनीय स्टोर में जोड़ने के लिए इस कमांड को चलाने की आवश्यकता है:

docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates

फिर शपथ ग्राहक टोकन प्राप्त करने और उसे डीबी में स्टोर करने में सक्षम होता है। मैं अभी के लिए काम कर सकता हूं, लेकिन मुझे लगता है कि यह अंतिम समाधान नहीं होना चाहिए। कोई विचार?
बहुत - बहुत धन्यवाद!

@ Fox27374 बढ़िया है कि आपको इसका कारण मिल गया। स्वच्छ समाधान के साथ आने के लिए यह हमेशा एक अच्छी शुरुआत है।

स्टैक आपके सीए के साथ TTN_LW_TLS_ROOT_CA (या tls.root-ca ), एक फ़ाइल नाम का सम्मान करता है। देखें https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : मैंने docker-compose.yml में फोलोइंग जोड़ा है

......
    secrets:
      - cert.pem
      - key.pem
      - ca.pem

secrets:
  cert.pem:
    file: config/stack/cert/cert.pem
  key.pem:
    file: config/stack/cert/key.pem
  ca.pem:
    file: config/stack/cert/ca.pem

इस तरह, प्रमाणपत्र फ़ाइलें कंटेनर में /run/secrets और /var/run/secrets में उपलब्ध हैं। मैंने कंटेनर में इस प्रत्यक्षता की जाँच की।

मैंने जोड़ा
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
docker-compose.yml फ़ाइल में। त्रुटि अभी भी है। मैंने इसे ttn-lw-stack.yml में जोड़ने का भी प्रयास किया:

tls:
  source: "file"
  root-ca: "/var/run/secrets/ca.pem"
  certificate: "/var/run/secrets/cert.pem"
  key: "/var/run/secrets/key.pem"

इधर भी ऐसा ही है। मुझे अभी भी त्रुटि मिलती है। क्या ऐसा हो सकता है कि कुछ एप्लिकेशन, विशेष रूप से ओथ क्लाइंट ओएस आंतरिक विश्वसनीय रूट प्रमाणपत्र का उपयोग करते हैं? क्योंकि जैसे ही मैं ca.pem को विश्वसनीय रूट प्रमाणपत्र में जोड़ता हूं, सब कुछ काम करता है।
धन्यवाद, डेनियल

सीसी @adriansmares

नमस्ते, यहाँ कोई खबर है? मैंने स्ट्रेस के साथ विश्वसनीय रूट प्रमाणपत्रों तक पहुंच को डीबग करने का प्रयास किया लेकिन सफल नहीं हुआ।

@ Fox27374 क्या आप सत्यापित कर सकते हैं कि यह काम करता है?

$ curl -cacert /var/run/secrets/ca.pem https://lora01.ntslab.loc

@adriansmares ऐसा लगता है कि हमें दो चीजों की जरूरत है;

1. अंतर्निहित त्रुटि कारण की रिपोर्ट करें, संभावित रूप से कारण विशेषता के रूप में, क्योंकि यह net त्रुटि या कुछ और है stdlib
2. सत्यापित करें कि हम OAuth क्लाइंट में tls.root-ca का सम्मान कर रहे हैं

हाय दोस्तों,

मुझे वही 403 त्रुटि मिल रही है, एक वैग्रांट बॉक्स (वर्चुअल बॉक्स के साथ) के भीतर डॉकटर के साथ टीटीएन स्टैक v3 चला रहा है। - साल्टस्टैक रेसिपी बनाने के लिए मेरे लिए सिर्फ एक सैंडबॉक्स।

मैंने डीएनएस का ख्याल रखने पर विचार करते हुए कई तरीकों की कोशिश की।

• स्व-हस्ताक्षरित प्रमाणपत्रों का उपयोग करें
• TTN स्टैक द्वारा VPS पर letsencrypt के साथ बनाए गए कुछ मौजूदा प्रमाणपत्रों का पुन: उपयोग करें।
• एक-एक करके सभी insecure कॉन्फिगर करने की कोशिश की

मेरे लिए यह root-ca की समस्या नहीं है, मुझे नहीं पता कि यह क्या है। क्या हमें इसके लिए एक और मुद्दा खोलना चाहिए?

एक प्रश्न हालांकि: आपके ज्ञान से, क्या इसे टीएलएस के बिना कॉन्फ़िगर करना संभव है, केवल एक वैग्रांट बॉक्स के भीतर देव उद्देश्यों के लिए? यदि ऐसा है तो क्या आप कृपया मुझे कुछ संकेत देंगे?

मैं पुष्टि कर सकता हूं कि मेरे वीपीएस पर यह letsencrypt के साथ ठीक काम करता है, जो निश्चित रूप से हमारे पास उत्पादन में होगा।

धन्यवाद।

c/shared जोड़ना क्योंकि यह एक कॉन्फिग चीज नहीं हो सकता है

हाय, देर से उत्तर के लिए खेद है। मैं सत्यापित कर सकता हूं कि कर्ल केवल --cacert पैरामीटर के साथ काम करता है क्योंकि ca.pem प्रमाणपत्र टस्टेड रूट प्रमाणपत्रों में स्थापित नहीं है:

/ $ whoami
thethings
/ $ curl https://lora01.ntslab.loc
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
/ $ curl --cacert /var/run/secrets/ca.pem https://lora01.ntslab.loc
/ $ 

कृपया जांचें कि क्या OAuth क्लाइंट TLS कॉन्फ़िगरेशन का सम्मान करता है

यदि आप स्टैक के सामने nginx का उपयोग करते हैं तो nginx को सभी ssl/tls को संभालना होगा।

यह nginx के लिए विन्यास हैं:

nginx.conf

stream {
    include stream_conf.d/*.conf;
}

stream_conf.d/mqtt.conf

log_format mqtt '$remote_addr [$time_local] $protocol $status $bytes_received '
                '$bytes_sent $upstream_addr';

upstream ttn1 {
    server stack-ip:1881;
    zone tcp_mem 64k;
}
upstream ttn2 {
    server stack-ip:1882;
    zone tcp_mem 64k;
}
upstream ttn3 {
    server stack-ip:1883;
    zone tcp_mem 64k;
}

server {
    listen 8881 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn1;
    proxy_connect_timeout 1s;
}

server {
    listen 8882 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn2;
    proxy_connect_timeout 1s;


server {
    listen 8883 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn3;
    proxy_connect_timeout 1s;
}

server {
    listen 1881; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn1;
    proxy_connect_timeout 1s;
}

server {
    listen 1882; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn2;
    proxy_connect_timeout 1s;
}

server {
    listen 1883; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn3;
    proxy_connect_timeout 1s;
}

आपको सभी बंदरगाहों के लिए अपनी साइट कॉन्फ़िगरेशन में इसकी आवश्यकता है (पोर्ट = 1884, 1885, 1887):

server {
        server_name FQDN;

        location / {
                proxy_pass      http://stack-ip:PORT;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_buffering off;
        }

       listen [::]:PORT ipv6only=on; # managed by Certbot
       listen PORT; # managed by Certbot
}

और यह बंदरगाहों के लिए (पोर्ट/पोर्ट्सएसएल = 1885/443, 1884/8884, 1887/8887):

server {

        server_name FQDN;

        location / {
                proxy_pass      http://stack-ip:PORT;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_buffering off;
        }

        listen [::]:PORTSSL ssl ipv6only=on; # managed by Certbot
        listen PORTSSL ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

जैसा कि आप देख सकते हैं कि मैं लेट्स एनक्रिप्ट का उपयोग कर रहा हूं।

बहुत बहुत धन्यवाद @wasn-eu!

यह #1760 के लिए भी उपयोगी है।

नमस्ते,

उबंटू पर टीटीएन 3.7 स्थापित करते समय मेरे पास एक समान समस्या है।

मैंने फॉक्स27374 की मार्गदर्शिका का पालन किया (https://github.com/fox27374/lora-stack) लेकिन अभी भी समस्या है।
मेरी स्थापना VM और Ubuntu पर है। मैं स्थानीय विकास के लिए स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करता हूं।

मैं अभी भी इस त्रुटि के साथ फंस गया हूँ। "टोकन अस्वीकृत एक्सचेंज"
पहले ही, आपका बहुत धन्यवाद,

हाय @ramampiandra ,

जैसा कि मैंने स्लैक चैट में लिखा था, पूरी चीज़ के काम करने के लिए, आपको निम्नलिखित की आवश्यकता है:

• TLS ट्रैफ़िक के लिए एक प्रमाणपत्र: cert.pem
• संबंधित निजी कुंजी: key.pem
• CA प्रमाणपत्र जिसने cert.pem जारी किया: ca.pem

कृपया सुनिश्चित करें कि प्रमाणपत्र सही हैं:

सर्ट.पेम

openssl x509 -in cert.pem -text -noout | grep -A 1 Identifier
            X509v3 Subject Key Identifier:
                26:78:63:90:E7:1C:09:B7:DA:B3:7D:81:F0:DE:47:6B:AE:16:58:79
            X509v3 Authority Key Identifier:
                keyid:86:32:F5:56:44:21:EC:E3:2A:D9:5F:6E:87:82:7A:67:C2:F1:77:E8

सीए.पीईएम

openssl x509 -in ca.pem -text -noout | grep -A 1 Identifier
            X509v3 Subject Key Identifier:
                86:32:F5:56:44:21:EC:E3:2A:D9:5F:6E:87:82:7A:67:C2:F1:77:E8

सुनिश्चित करें कि cert.pem में प्राधिकरण कुंजी पहचानकर्ता ca.pem में विषय कुंजी पहचानकर्ता के समान है।

स्टैक शुरू होने के बाद और सभी डॉकटर कंटेनर ऊपर हैं, निम्न कमांड चलाएँ (अपने TTN कंटेनर के नाम पर "ttn-server_stack_1" को अनुकूलित करें):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
यह कंटेनर के भीतर ca.pem प्रमाणपत्र स्थापित करेगा और इसे विश्वसनीय प्रमाणपत्रों में जोड़ देगा।

उसके बाद, सीधे अपने कंटेनर में लॉगिन करें और परीक्षण करें कि प्रमाणपत्र काम करता है या नहीं:

docker-compose exec stack "/bin/ash"
curl https://YOURSERVER.YOUR.DOMAIN

आपको कोई परिणाम या त्रुटि नहीं दिखनी चाहिए - इसका मतलब है कि आपका प्रमाणपत्र विश्वसनीय है।

आशा है यह मदद करेगा,
चियर्स

इसलिए इसे विस्तार से देखने के बाद, मैं पुन: पेश करने में सक्षम था और पुष्टि कर सकता हूं कि वास्तव में हमारे ओएथ प्रवाह द्वारा टीएलएस कॉन्फ़िगरेशन (और विशेष रूप से रूट प्रमाणपत्र) का सम्मान नहीं किया जा रहा है, जिससे टोकन एक्सचेंज विफल हो गया है।

मैं वर्तमान में इसे ठीक करने के लिए एक पीआर पर काम कर रहा हूं जो आज बाद में आना चाहिए।

@kschiffer बहुत बढ़िया, इसे देखने के लिए धन्यवाद। बस मुझे पोस्ट करते रहें ताकि मैं परीक्षण में आपकी मदद कर सकूं।

नमस्ते! इसे अस्थायी रूप से ठीक करने के लिए एक और समाधान है?

@dgraposo इसे 3.8.1 . में तय किया जाना चाहिए

मैं इस मुद्दे को अभी के लिए बंद कर दूंगा, क्योंकि "टोकन एक्सचेंज ने इनकार कर दिया" मुद्दे पर ध्यान केंद्रित किया, जिसे # 2511 के माध्यम से संबोधित किया गया है और जिसे आगे # 2521 के माध्यम से पालन किया जा सकता है। मुझे संदेह है कि समस्या निवारण अनुभाग जोड़ने का यह सबसे बड़ा कारण था।

यह मुद्दा अब अपने प्रारंभिक उद्देश्य पर चर्चा करने के लिए बहुत उपयोगी नहीं है। मेरा सुझाव है कि यदि हम समस्या निवारण अनुभाग को अभी भी आवश्यक मानते हैं तो उचित दायरे के साथ फिर से खोलना।