डिबग API

इस डिप्लॉयमेंट के एक CE से 2026-07-28 को कैप्चर किया गया। sitecli/capture-manifest.json यह दर्ज करता है कि कौन-सा नोड था, और scripts/capture-sitecli.sh --check कमांड सरफ़ेस को एक लाइव CE के विरुद्ध पुनः सत्यापित करता है।

vpm/debug API किसी रजिस्टर्ड नोड पर Site CLI कमांड चलाता है और उनका आउटपुट लौटाता है। नीचे दी गई हर बात एक लाइव नोड के विरुद्ध स्थापित की गई थी; इसमें से कुछ भी अपस्ट्रीम प्रकाशित नहीं है।

कमांड कैटलॉग स्वयं-वर्णनात्मक है

नोड से पूछें कि वह क्या समर्थन करता है — exec-user पर POST करके, जिसमें command कुंजी छोड़ दी गई हो:

curl -sS -X POST \
  -H "Authorization: APIToken $XCSH_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"system","site":"<site>","node":"<node>"}' \
  "$XCSH_API_URL/api/operate/namespaces/system/sites/<site>/vpm/debug/<node>/exec-user" \
  | jq -r .output | jq .

प्रतिक्रिया एक JSON ऑब्जेक्ट है जिसकी कुंजियाँ कमांड नाम हैं:

{
  "crictl-inspect": ["System Troubleshooting", "ExecUser", " container-id"],
  "diagnosis":      ["System Troubleshooting", "ExecUser", "no argument needed", "GLOBAL"],
  "ip-link-set":    ["Network Troubleshooting", "Exec", " (<device>||<group>) (up||down)"]
}

प्रत्येक प्रविष्टि [category, tier, exampleArgument?, scope?] है, और ये फ़ील्ड दस्तावेज़ीकरण नहीं हैं — ये तय करते हैं कि कमांड को कैसे कॉल किया जाना चाहिए।

कुंजी छोड़ दें; गलत मान न भेजें

डिस्कवरी command को छोड़ देने से काम करती है। इसके बजाय कोई अज्ञात मान भेजने पर कैटलॉग नहीं, बल्कि एक त्रुटि मिलती है:

{"code":3,"details":[],"message":"exec command failed: command not supported"}

यही संदेश तब भी मिलता है जब कोई वास्तविक कमांड गलत एंडपॉइंट पर भेजा जाए, इसलिए इसे “यह कमांड मौजूद नहीं है” समझ लेना आसान है।

तीन ट्रांसपोर्ट, कैटलॉग प्रविष्टि द्वारा चुने गए

शर्त	विधि और पथ	बॉडी	लौटाता है
scope का मान GLOBAL है	GET .../vpm/debug/global/<cmd>	कोई नहीं	JSON
tier का मान ExecUser है	POST .../vpm/debug/<node>/exec-user	command सरणी	टेक्स्ट
tier का मान Exec है	POST .../vpm/debug/<node>/exec	command सरणी	टेक्स्ट

ExecUser — केवल-पठन tier 31 commands

सामान्य स्थिति। कमांड और उसके तर्कों को एक सरणी के रूप में पास करें, पहले कमांड नाम:

curl -sS -X POST \
  -H "Authorization: APIToken $XCSH_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"namespace":"system","site":"<site>","node":"<node>","command":["crictl-ps"]}' \
  "$XCSH_API_URL/api/operate/namespaces/system/sites/<site>/vpm/debug/<node>/exec-user"

{ "return_code": 0, "output": "CONTAINER    IMAGE    CREATED    STATE ..." }

तर्क अलग-अलग सरणी तत्व होते हैं, एक अकेली स्ट्रिंग नहीं:

{ "command": ["journalctl", "-u", "vpm", "-n", "200"] }

GLOBAL — साइट-व्यापी, और पूरी तरह भिन्न ट्रांसपोर्ट 2 commands

health और diagnosis ही केवल दो हैं। ये global पथ पर GET अनुरोध हैं, कोई तर्क नहीं लेते, और टर्मिनल टेक्स्ट के बजाय संरचित JSON लौटाते हैं।

curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/operate/namespaces/system/sites/<site>/vpm/debug/global/health" | jq .

कोई GLOBAL कमांड exec-user के माध्यम से पहुँच में नहीं है

यह वह जाल है जो सबसे अधिक समय खर्च कराता है। health या diagnosis को exec-user पर भेजने से command not supported मिलता है, जो ऐसा पढ़ा जाता है मानो कमांड नोड पर मौजूद नहीं है — जबकि वास्तव में वह मौजूद है और आपने गलत ट्रांसपोर्ट का उपयोग किया।

# Wrong. Returns: exec command failed: command not supported
-d '{"namespace":"system","site":"…","node":"…","command":["health"]}'   # POST exec-user

# Right.
GET .../vpm/debug/global/health

Exec — विशेषाधिकार-प्राप्त tier 1 command on this build

एक अलग एंडपॉइंट, और tier सलाहकारी नहीं बल्कि लागू किया जाता है: exec एक ExecUser कमांड को उसी command not supported संदेश के साथ अस्वीकार करता है। इसका हर सदस्य या तो नोड को बदलता है या किसी स्टेट मार्कर को पढ़ता है।

इस टेनेंट पर चल रहे बिल्ड में, इस tier में केवल ip-link-set है। नए बिल्ड systemctl-restart-NetworkManager, systemctl-restart-crio, systemctl-restart-kubelet, systemctl-start-crio-prune और तीन marker-exists-* कमांड जोड़ते हैं।

यहाँ कुछ भी Exec कमांड नहीं चलाता

कैप्चर हार्नेस इस tier को अस्वीकार करता है, और tier को किसी हार्डकोडेड सूची के बजाय लाइव कैटलॉग से पढ़ता है — इसलिए भविष्य का कोई बिल्ड जो किसी कमांड को Exec में प्रोन्नत करता है, उसका सम्मान बिना किसी के कोड संपादित करने के होता है। इसे केवल जानबूझकर चलाएँ, उस नोड पर जिसे बाधित करने के लिए आप तैयार हैं।

साइट और नोड नाम खोजना

नोड नाम Azure VM नाम होता है, और list-service इसकी पुष्टि करने का एक सस्ता तरीका है, साथ ही उस पर चल रही सेवाओं के साथ:

curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/operate/namespaces/system/sites/<site>/vpm/debug/global/list-service" \
  | jq -r '[.service[].node] | unique'

["", "f5-xc-ce-vm-01"]

कुछ सेवाएँ खाली नोड नाम रिपोर्ट करती हैं, इसलिए उस सूची में एक खाली स्ट्रिंग दूसरे नोड के बजाय प्रतिक्रिया की एक कलाकृति है। list-service 34-कमांड कैटलॉग में भी नहीं है: यह एक global एंडपॉइंट है जिसका कैटलॉग प्रचार नहीं करता, और इसीलिए इसे यहाँ दस्तावेज़ित किया गया है, कमांड संदर्भ में नहीं।

इस रिपॉज़िटरी के कैप्चर पुनः उत्पन्न करना

प्रत्येक कमांड पृष्ठ scripts/capture-sitecli.sh द्वारा कैप्चर किया गया आउटपुट एम्बेड करता है, जो ऊपर के तीनों नियमों को लागू करता है।

1. इसे किसी टेनेंट पर लक्षित करें। यह XCSH_API_URL और XCSH_API_TOKEN पढ़ता है, या सक्रिय xcsh संदर्भ पर वापस लौट जाता है।

2. कैटलॉग रीफ़्रेश करें और पुष्टि करें कि दस्तावेज़ीकरण के नीचे नोड बदला नहीं है:

   bash scripts/capture-sitecli.sh --check

   यह केवल कमिट किए गए कैटलॉग और सॉफ़्टवेयर बिल्ड की तुलना करता है। यह बिल्ड परिवर्तन को जोड़े या हटाए गए कमांड से अलग रिपोर्ट करता है।

3. जब आप ताज़ा साक्ष्य चाहें, तो पुनः कैप्चर करें:

   bash scripts/capture-sitecli.sh

कैप्चर साक्ष्य हैं, पुनरुत्पादनीय कलाकृतियाँ नहीं

काउंटर, अपटाइम और कंटेनर की आयु रन के बीच बदलती रहती है, इसलिए पुनः कैप्चर करने पर हमेशा एक diff बनता है। कैटलॉग स्थिर अनुबंध है और जब नोड नहीं बदला हो तो रनों के बीच बाइट-समान रहता है; --check इसी की तुलना करता है। लंबा आउटपुट काट दिया जाता है और एक स्पष्ट मार्कर के साथ समाप्त होता है, इसलिए काटी गई तालिका को कभी ऐसा नहीं दिखाया जाता जैसे वह पूर्ण हो।

किसी ग्राहक नोड से कैप्चर करना: रिडैक्शन प्रोफ़ाइल जाँचें

कमांड आउटपुट अवसंरचना की पहचान वहन करता है — आंतरिक एड्रेसिंग, MAC पते, AS संख्याएँ, होस्टनाम — और किसी ग्राहक के लिए वह संगठन के बारे में पहचान योग्य जानकारी है।

इसलिए स्क्रब फ़िल्टर डिफ़ॉल्ट रूप से एक strict प्रोफ़ाइल पर होता है जो यह सब हटा देता है। यह रिपॉज़िटरी sitecli/capture-manifest.json में lab घोषित करती है, जो उस विवरण को बनाए रखती है, और यह केवल यहाँ सही है क्योंकि ये कैप्चर F5 के स्वामित्व वाली डेमो अवसंरचना से आते हैं।

उस सेटिंग को किसी ग्राहक कैप्चर पर न ले जाएँ। टोकन, निजी कुंजियाँ, टेनेंट पहचानकर्ता, ऑब्जेक्ट UUID, ईमेल पते और होम डायरेक्टरी पथ दोनों प्रोफ़ाइलों में हटा दिए जाते हैं।

एक सीमा जानने योग्य है: एक BGP नेबर तालिका AS को एक नंगे कॉलम के रूप में छापती है, जिसमें कोई लेबल नहीं होता जिस पर पैटर्न को टिकाया जा सके, इसलिए ASN को निजी श्रेणियों के विरुद्ध मान द्वारा मिलाया जाता है। वहाँ एक सार्वजनिक ASN strict में भी बच जाता है, और प्रकाशित करने से पहले show-ip-bgp* आउटपुट की मैन्युअल समीक्षा की आवश्यकता होती है।