> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/hi/self-hosted/enterprise/secure-gateway-podman.md). # Podman के साथ RHEL पर Secure Gateway Kubernetes के बिना Red Hat Enterprise Linux hosts पर Secure Gateway डिप्लॉय करें, जहाँ gateway और इसका encrypted cache Roboflow Deployment Manager द्वारा प्रबंधित Podman containers के रूप में चलते हैं। [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) यह उन Red Hat Enterprise Linux होस्ट्स पर भी चलता है जिन पर न Docker है न Kubernetes। एक समर्पित इंस्टॉलर गेटवे और उसके एन्क्रिप्टेड कैश को Podman कंटेनरों के रूप में तैनात करता है, जिनकी निगरानी Roboflow Deployment Manager (`rfdm`), द्वारा की जाती है, जो Podman को उसकी Docker-संगत API के माध्यम से संचालित करता है। आपको Docker परिनियोजन जैसा ही गेटवे मिलता है (एक नियंत्रित निकास बिंदु जो Roboflow API को प्रॉक्सी करता है और आपके फ़्लीट के लिए मॉडल वज़न तथा कंटेनर इमेज को कैश करता है), उसी air-gapped बंडल मॉडल के साथ, उस कंटेनर रनटाइम पर जो RHEL के साथ आता है। {% hint style="info" %} तीन परिनियोजन मॉडल उपलब्ध हैं। [Docker परिनियोजन](/deployment/hi/self-hosted/enterprise/secure-gateway.md) का उपयोग उन होस्ट्स पर करें जिन पर पहले से Docker चल रहा है, Docker या Kubernetes के बिना RHEL होस्ट्स पर यह पृष्ठ, और [MicroShift पर सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) उन Red Hat Device Edge होस्ट्स पर जो Kubernetes फ़्लीट के रूप में प्रबंधित हैं। गेटवे के कॉन्फ़िगरेशन संदर्भ (कैशिंग, TLS वेरिएबल, लॉग निर्यात) तीनों में समान हैं: देखें [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) और [सुरक्षित गेटवे मैनुअल](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## आर्किटेक्चर * Roboflow Deployment Manager होस्ट पर एक systemd सेवा के रूप में चलता है और Podman की Docker-संगत API (`podman.socket`) के माध्यम से कंटेनरों का प्रबंधन करता है। यह गेटवे को कॉन्फ़िगर, अपडेट और चालू रखता है। * गेटवे और उसका कैश बैकएंड (SeaweedFS, एक S3-संगत स्टोर जिसमें at rest एन्क्रिप्शन है) सिस्टम (root) Podman इंस्टेंस के तहत कंटेनरों के रूप में चलते हैं। * गेटवे पोर्ट प्रकाशित करता है `80` और `443` सीधे होस्ट पर: HTTPS `443`पर, और HTTP `80` को HTTPS पर रीडायरेक्ट करता है। * कैश `/data/seaweedfs` में होस्ट फ़ाइल सिस्टम पर संग्रहीत होता है, जिसे कैश कंटेनर में bind-mount किया जाता है। किसी LVM वॉल्यूम समूह या storage provisioner की आवश्यकता नहीं है। * SELinux enforcing ही रहता है। प्रबंधित कंटेनर कॉन्फ़िगरेशन में वॉल्यूम माउंट्स के साथ SELinux लेबल (`:Z`/`z`) होते हैं, इसलिए न मैनुअल relabeling की ज़रूरत है और न permissive mode की। यह एकल-होस्ट परिनियोजन है। High availability और बहु-होस्ट क्लस्टर समर्थित नहीं हैं। {% hint style="warning" %} गेटवे के लिए एक समर्पित होस्ट का उपयोग करें। Podman और CRI-O (जिस रनटाइम का MicroShift उपयोग करता है) होस्ट के container storage को साझा करते हैं, इसलिए एक में image cleanup (उदा.: `podman image prune`) दूसरे रनटाइम द्वारा कैश की गई images को पुनः प्राप्त कर सकता है। यदि होस्ट MicroShift चलाता है, तो इसके बजाय [MicroShift परिनियोजन](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) का उपयोग करें। {% endhint %} ## पूर्वापेक्षाएँ * x86\_64 पर Red Hat Enterprise Linux 9.x होस्ट, Podman 4.x या उससे नए संस्करण के साथ। इंस्टॉलर बंडल बनाया गया है केवल `linux-amd64` के लिए। Podman RHEL रिपॉज़िटरीज़ से बिना किसी अतिरिक्त subscription के आता है, लेकिन न्यूनतम installation में यह मौजूद न भी हो सकता है: पहले `sudo dnf install podman` चलाएँ यदि `podman --version` विफल हो। देखें [support matrix](#support-matrix). * Root access: गेटवे सिस्टम (root) Podman इंस्टेंस के तहत स्थापित होता है * डिस्क: लगभग 3 GB `/` कंटेनर images के लिए, साथ ही `/data`में कैश के लिए जगह, जो 50 GB तक बढ़ती है * पोर्ट्स `80` और `443` होस्ट पर गेटवे के लिए उपलब्ध * कनेक्टेड installs के लिए, outbound HTTPS `api.roboflow.com` और `repo.roboflow.com` {% hint style="info" %} MicroShift परिनियोजन के विपरीत, यहाँ स्थापित करने के लिए कोई Kubernetes distribution नहीं है: न OpenShift pull secret और न LVM volume group। आपके Red Hat subscription को केवल RHEL को ही कवर करना होगा। {% endhint %} ## कनेक्टेड होस्ट पर स्थापित करें Podman इंस्टॉलर बंडल डाउनलोड करें और उसकी अखंडता सत्यापित करें: ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-podman-installer-linux-amd64.tar.gz.sha256) secure-gateway-podman-installer-linux-amd64.tar.gz" \ | sha256sum -c - ``` इसे निकालें और इंस्टॉलर को root के रूप में चलाएँ: ```bash tar xzf secure-gateway-podman-installer-linux-amd64.tar.gz cd secure-gateway-podman-installer sudo ./install-podman.sh \ --api-key \ --device-id \ --workspace ``` इंस्टॉलर: 1. Podman API सॉकेट सक्षम करता है (`podman.socket`), Docker-संगत API जिसे Deployment Manager कंटेनरों को प्रबंधित करने के लिए उपयोग करता है। 2. बंडल की गई Secure Gateway और SeaweedFS images को होस्ट के root Podman storage में लोड करता है। किसी registry से कुछ भी pull नहीं किया जाता। 3. यदि होस्ट पर पुराने CNI leftovers अन्यथा कंटेनरों के बीच DNS को तोड़ सकते हों, तो Podman के network backend को netavark पर स्विच करता है। 4. गेटवे का TLS certificate और private key जनरेट करता है। 5. Roboflow Deployment Manager को Podman mode में systemd सेवा के रूप में स्थापित करता है और उसका device configuration लिखता है। 6. सक्षम करता है `podman-restart.service` ताकि होस्ट reboot के बाद कंटेनर वापस आ जाएँ। 7. Deployment Manager शुरू करता है, जो गेटवे और कैश कंटेनर बनाता और शुरू करता है। परिनियोजन सत्यापित करें: ```bash sudo systemctl is-active rfdm sudo podman ps curl -fk https:///health ``` गेटवे और कैश कंटेनर दोनों `Up`होने चाहिए, और health check को HTTP 200 लौटाना चाहिए। `-k` फ़्लैग तब तक ज़रूरी है जब तक आप गेटवे के certificate पर भरोसा न कर लें; देखें [TLS और trust](#tls-and-trust). ## Air-gapped स्थापना वही बंडल उन होस्ट्स पर भी स्थापित होता है जिनकी इंटरनेट पहुँच नहीं है। कंटेनर images इसके भीतर OCI archives के रूप में आती हैं और सीधे होस्ट के Podman storage में लोड की जाती हैं। कंटेनर सटीक version tags का संदर्भ लेते हैं, इसलिए स्थापना के समय या बाद में registry से कुछ भी कभी pull नहीं किया जाता। बंडल को connected मशीन पर डाउनलोड और सत्यापित करें, उसे removable media या अपनी आंतरिक file transfer प्रक्रिया से होस्ट तक पहुँचाएँ, फिर निकालकर चलाएँ `install-podman.sh` ठीक ऊपर जैसा। सत्यापन समान है। ## TLS और trust इंस्टॉलर गेटवे के लिए self-signed certificate जनरेट करता है, जो इसके साथ पोर्ट `443` पर HTTPS सेवा देता है और पोर्ट `80` पर HTTP को HTTPS पर रीडायरेक्ट करता है। जनरेट किया गया certificate common name `repo.roboflow.com`, को भी कवर करता है `*.roboflow.com`, `localhost`, और `127.0.0.1`, तथा 10 वर्षों के लिए वैध है। इंस्टॉलर को दोबारा चलाने पर वह जनरेट किया गया जोड़ा तब तक बना रहता है जब तक उस पर एक वर्ष से अधिक समय बचा है, इसलिए आपने पहले clients को जो trust वितरित किया था, वह काम करता रहता है। यह केवल जनरेट किए गए सामग्री पर लागू होता है: इंस्टॉलर इसे अलग से ट्रैक करता है, इसलिए बिना `--cert` और `--key` के दोबारा चलाने पर आपके द्वारा दिए गए certificate को self-signed certificate से ओवरराइट कर देता है। गेटवे अपना certificate और key होस्ट पर `/etc/secure-gateway/tls/tls.crt` और `/etc/secure-gateway/tls/tls.key` से पढ़ता है। पास करें `--cert` और `--key` को `install-podman.sh` ताकि शुरुआत से ही अपना material स्थापित कर सकें, या उन दो फ़ाइलों को बदलकर गेटवे कंटेनर को पुनः शुरू करें। आपके certificate को `repo.roboflow.com`को कवर करना होगा: client install script `repo.roboflow.com` को गेटवे पर `/etc/hosts`में पुनर्निर्देशित करता है, और कंटेनर रनटाइम इमेज खींचने से पहले TLS hostname की जाँच करते हैं। `*.roboflow.com`को न जोड़ें: client install script इस certificate को प्रत्येक client के system-wide trust store में स्थापित करता है, इसलिए wildcard किसी भी ऐसे व्यक्ति को अनुमति देगा जो बाद में private key प्राप्त कर लेता है कि वह `api.roboflow.com` या किसी अन्य roboflow\.com होस्ट का रूप धारण कर सके। गेटवे प्रक्रिया अपने कंटेनर के अंदर UID 1000 और group 0 के साथ चलती है, इसलिए यह फ़ाइलों को उनके owner permissions के माध्यम से पढ़ती है। इंस्टॉलर दोनों फ़ाइलों को owner `1000:0`पर सेट करता है, mode `0640` key पर और `0644` certificate पर, तथा directory को owner `root:0` और mode `0750`पर। फ़ाइलों को root के रूप में बदलकर उन्हें root-owned छोड़ देना सबसे सामान्य कारण है कि गेटवे अब अपनी key नहीं पढ़ पाता (देखें [समस्या निवारण](#troubleshooting)). ## Inference Servers को कनेक्ट करना Roboflow Inference Server चलाने वाली प्रत्येक मशीन पर, गेटवे का client install script चलाएँ। यह गेटवे के certificate को मशीन के trust store में जोड़ता है और उसके Roboflow ट्रैफ़िक (API calls, model weights, और container image pulls) को गेटवे के माध्यम से रूट करता है। पहले गेटवे का certificate client तक उस चैनल से कॉपी करें जिस पर आपको पहले से भरोसा है (उदा.: `scp` गेटवे होस्ट से, आपकी संस्था की file transfer प्रक्रिया, removable media)। certificate verification बंद करके इसे गेटवे से ही न प्राप्त करें: ```bash sudo cat /etc/secure-gateway/tls/tls.crt > gateway-ca.crt && scp gateway-ca.crt :/tmp/gateway-ca.crt ``` client पर, उस certificate के विरुद्ध सत्यापित TLS connection के माध्यम से install script डाउनलोड करें, फिर उसे चलाएँ। `--resolve` उस `repo.roboflow.com` नाम को, जिसे certificate गेटवे के IP पर कवर करता है, निर्दिष्ट करता है, इसलिए सत्यापन उसे अक्षम किए बिना सफल होता है। script को `?server=` के साथ अनुरोध करें ताकि गेटवे script को जहाँ-जहाँ template करता है, वहाँ सही address भर दे, बजाय request के `repo.roboflow.com` hostname के: ```bash curl -fsSL --cacert /tmp/gateway-ca.crt --resolve repo.roboflow.com:443: \ "https://repo.roboflow.com/install-client.sh?server=" -o install-client.sh sudo bash install-client.sh --server ``` script को अलग से डाउनलोड करना और उसे चलाना आपको उसे root के रूप में चलाने से पहले पढ़ने की भी सुविधा देता है। इसे केवल उस नेटवर्क पथ पर चलाएँ जिसे आप नियंत्रित करते हैं: `install-client.sh` प्राप्त करता है `/ca.crt` और `/trust-bundle.crt` गेटवे से ही, connection को सत्यापित किए बिना, इसलिए उस पथ पर कोई interceptor फिर भी उस चरण में trusted CA दे सकता है, भले ही ऊपर का डाउनलोड सत्यापित किया गया हो। वैकल्पिक रूप से, किसी individual Inference Server को `SECURE_GATEWAY` environment variable के साथ गेटवे की ओर इंगित करें; देखें [Inference Servers को कनेक्ट करना](/deployment/hi/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers). `SECURE_GATEWAY=https://repo.roboflow.com`का उपयोग करें। संस्करणों के बीच स्पष्ट HTTPS scheme का उपयोग करें; लंबित runtime-hardening build bare addresses और plaintext gateways के हैंडलिंग को बदलता है, जैसा कि [Security Configuration Migration](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md#gateway-transport)में वर्णित है। hostname भी महत्वपूर्ण है: जनरेट किया गया certificate `repo.roboflow.com` को कवर करता है `और होस्ट के IP address को नहीं, इसलिए` https\://\ `repo.roboflow.com` को गेटवे पर `/etc/hosts` certificate के machine द्वारा trust किए जाने के बाद भी certificate validation विफल होता है। पहले client install script चलाएँ, जो `--cert` और `--key`को इंगित करता है और certificate स्थापित करता है। IP address का उपयोग करने के लिए, उसे कवर करने वाला अपना certificate जारी करें और उसे `api.roboflow.com` और `repo.roboflow.com`. ## समस्या निवारण
लक्षणक्या करें
कंटेनर नाम से एक-दूसरे को resolve नहीं कर पा रहे हैं, और गेटवे अपने कैश तक पहुँचते समय name-resolution त्रुटियाँ लॉग करता हैPodman पुराने CNI network backend का उपयोग कर रहा है, जिसमें container DNS नहीं है, आमतौर पर किसी पहले के container runtime के CNI leftovers के कारण। जाँच करें sudo podman info --format '{{.Host.NetworkBackend}}'; इसे netavarkरिपोर्ट करना चाहिए। इंस्टॉलर /etc/containers/containers.conf.d/ के अंतर्गत एक drop-in लिखता है ताकि आवश्यकता होने पर netavark चुना जा सके। सुधार के बाद existing containers पुराने backend पर ही रहते हैं, इसलिए उन्हें हटाएँ sudo podman rm -f secure-gateway seaweedfs और Deployment Manager को पुनः शुरू करें (sudo systemctl restart rfdm) ताकि वे पुनः बन जाएँ।
गेटवे विफल होता है with Permission denied अपनी TLS key पढ़ते समयcertificate और key फ़ाइलों का स्वामी 1000:0 (mode 0640 key पर, 0644 certificate पर), एक directory के भीतर होना चाहिए जिसका स्वामी root:0 mode के साथ 0750हो। इंस्टॉलर यह सेट करता है; सामान्य कारण root के रूप में मैन्युअल रूप से बदला गया certificate है। इन्हें हाथ से सेट करें, फिर गेटवे कंटेनर को पुनः शुरू करें: sudo chown 1000:0 /etc/secure-gateway/tls/tls.crt /etc/secure-gateway/tls/tls.key, sudo chmod 0640 /etc/secure-gateway/tls/tls.key, sudo chmod 0644 /etc/secure-gateway/tls/tls.crt. Re-running install-podman.sh भी इसे ठीक कर देता है, लेकिन यदि आपने अपना certificate लाया है तो --cert और --key फिर से पास करें, अन्यथा दोबारा चलाने पर यह self-signed certificate से बदल जाएगा।
Permission denied माउंट की गई directory में लिखनावॉल्यूम माउंट में SELinux लेबल नहीं है। प्रबंधित कॉन्फ़िगरेशन में हर वॉल्यूम के साथ एक :Z (या साझा :z) विकल्प होता है; यदि आपने माउंट हाथ से जोड़ा है, तो SELinux को permissive mode में डालने के बजाय लेबल जोड़ें।
Gateway crash-loop करता है with PermissionError पढ़ते समय /etc/ssl/certs/ca-certificates.crtSELinux कंटेनर को उस host CA bundle तक पहुँचने से रोक रहा है जिसे Deployment Manager माउंट करता है। Denial दबा दिया जाता है, इसलिए audit searches में कुछ नहीं मिलता। चलाएँ sudo setsebool -P container_read_certs on. इंस्टॉलर यह boolean सेट करता है, इसलिए इसे दोबारा चलाने से host भी ठीक हो जाता है।
गेटवे लॉग करता है Init handshake failed ... starting in local-cache-only modeगेटवे startup पर Roboflow API तक नहीं पहुँच सका (गलत API key, outbound connectivity नहीं, या cache अभी भी शुरू हो रहा था)। यह traffic सेवा देता रहता है और local रूप से cache भी करता रहता है, लेकिन अपने S3-backed cache के बिना चलता है और अगली restart तक backend को telemetry या events रिपोर्ट नहीं कर सकता। कारण ठीक करें, फिर गेटवे कंटेनर पुनः शुरू करें: sudo podman restart <gateway-container>, container name के साथ sudo podman ps.
लॉग कहाँ हैंDeployment Manager: sudo journalctl -u rfdm. Gateway और cache: sudo podman logs <container>, container names के साथ sudo podman ps.
## support matrix
RHELPodmanनोट्स
9.x4.xPodman 4, RHEL 9 के साथ आता है
9.x5.xRHEL 9.6 पर Podman 5.4.0 के साथ सत्यापित
Podman 4.x न्यूनतम समर्थित संस्करण है। वर्तमान RHEL 9.x रिलीज़ के साथ आने वाला Podman बिना किसी अतिरिक्त repository या package के समर्थित है।