इस deployment के एक CE से 2026-07-28 को कैप्चर किया गया। sitecli/capture-manifest.json
यह रिकॉर्ड करता है कि कौन सा नोड है, और scripts/capture-sitecli.sh --check किसी live CE के
विरुद्ध command surface को पुनः सत्यापित करता है।
SSH उपकरण के admin अकाउंट तक पहुँचता है, जिसका लॉगिन शेल Site CLI
(/opt/bin/vpmu) है। यह पूर्ण on-box command surface तक पहुँचने का एकमात्र मार्ग है —
debug API 34 commands को एक्सपोज़ करता है, और उपकरण स्वयं कई और commands
प्रदान करता है जो उस API पर बिल्कुल नहीं हैं।
उस command line का हर हिस्सा महत्वपूर्ण है, और अगले तीन अनुभाग बताते हैं
कि प्रत्येक किस विफलता को रोकता है।
लैंड करने के लिए कोई शेल प्रॉम्प्ट नहीं है: admin का लॉगिन शेल ही Site CLI है, इसलिए आप
उसके >>> प्रॉम्प्ट पर पहुँचते हैं। वहाँ on-box commands को execcli <name> के रूप में चलाएँ —
on-box commands देखें।
site object पर admin_user_credentials.ssh_key बिल्कुल उसी फ़ील्ड जैसा दिखता है। यह accept
होता है, read-back में बना रहता है, और कुछ configure नहीं करता। vpm नोड के local users का
मालिक है और इसे touch करने से मना करता है — नोड के अपने log से, एक single boot में तीन बार:
vpm users.go:165: Won't do any change for user admin (internal skip)
बाकी सब कुछ उसी एक लाइन से निकलता है। /var/home/admin/.ssh कभी मौजूद नहीं होता, site के
ONLINE होने से पहले या बाद में। admin shadow last-change date image build date पर बनी रहती
है जबकि vesbkp और vesopcon current date दिखाते हैं, क्योंकि vpm ने उन दोनों को set किया
और admin को skip किया। और vpm किसी भी बिंदु पर ssh_key या authorized_keys के बारे में
कुछ log नहीं करता।
इसलिए file को vpm के बाहर लिखा जाना चाहिए। admin uid 2202 है, node image में baked in है,
इसलिए यह cloud-init के चलने से पहले मौजूद होता है और owner: admin:admin write समय पर
resolve होता है — कोई runcmd नहीं, कोई ownership fix-up नहीं:
- path: /var/home/admin/.ssh/authorized_keys
permissions: "0600"
owner: admin:admin
content: |
${ssh_public_key}
sshd हमेशा से तैयार था। sshd -T रिपोर्ट करता है pubkeyauthentication yes, और admin
नोड पर ship होने वाली दोनों sshd_config files में AllowUsers में दिखता है। कभी कुछ enable
करने की ज़रूरत नहीं थी — केवल एक missing file थी।
sshd0.0.0.0:22 से bind करता है, लेकिन केवल internal (SLI) address ही host network
stack पर इस तरह है जिस पर sshd जवाब देगा। eth0 का नाम बदलकर a-i-eth0 किया गया है और
इस पर कोई host IP नहीं है — Argo data plane उस interface का मालिक है, और management/SLO
address जो उस पर होती, वह बजाय vhost0 पर दिखती है। बाकी दो NICs अपने नाम से host stack पर
बने रहते हैं।
VNet के अंदर एक VM से, एक CE के विरुद्ध probe किया गया:
management/SLO address timed out
external address timed out
internal/SLI address OPEN SSH-2.0-OpenSSH_8.7
an unused address timed out (control)
इसलिए उस address के विरुद्ध probe जिससे आप नोड को जानते हैं, बंद security group जैसा ही
return करता है। कुछ block नहीं कर रहा; उस address पर कोई listener नहीं है।
CE public addresses पर भी 22 पर कोई listener नहीं है, इसीलिए ऊपर दिया गया command -J से
जाता है: VNet के अंदर एक ऑपरेटर VM, SLI addresses के समान subnet में। यह deployment इस
उद्देश्य के लिए एक बनाता है —
terraform output -raw client_vm_name उसका नाम देता है।
Site CLI को एक terminal और एक carriage return चाहिए
admin login shell एक शेल नहीं है। यह एक go-prompt application है, जो terminal को raw mode
में डालता है और lines के बजाय keystrokes पढ़ता है। चार परिणाम, जिनमें से प्रत्येक इस तरह
विफल होता है जो एक अलग समस्या जैसा दिखता है:
Mechanic
इसके बिना क्या होता है
Terminal allocate करें (ssh -tt)
go-prompt.NewStandardInputParser से panic: no such device or address, जो एक crashed appliance जैसा दिखता है
Enter के लिए line feed नहीं, carriage return भेजें
Line कभी submit नहीं होती, और session end-of-input पर कुछ print किए बिना बंद हो जाता है
Standard input खुला रखें
Command render होने से पहले connection समाप्त हो जाता है, इसलिए एक काम करने वाला command silent दिखता है
Command text और Enter byte अलग-अलग लिखें
Newline buffer में literal character के रूप में आता है और CLI unknown command जवाब देता है, जो ऐसा पढ़ता है जैसे command मौजूद नहीं है
इसलिए ssh host 'some-command' काम नहीं करता: argument ignore होता है और interactive prompt
वैसे भी शुरू होता है। इसे एक terminal के रूप में चलाएँ या बिल्कुल नहीं।
scripts/sitecli_ssh_harvest.py reference implementation है।
कुछ type करने से पहले ही, login banner ने उन कई सवालों का जवाब दे दिया है जिन पर आप
अन्यथा commands पर समय बिताते। f5-xc-ce-vm-01 से, ASCII art और public IP हटाए गए:
Registration Status अभी आ रहे नोड (PROVISIONING) को पूरे हो चुके (PROVISIONED) से
अलग करता है। Software वह build string है जो तय करती है कि कौन से commands मौजूद हैं।
DNS और NTP वे दो dependencies cover करते हैं जो सबसे पहले registration तोड़ती हैं, इसलिए
एक नोड जो कभी online नहीं आया, उसने आमतौर पर यहाँ पहले ही बता दिया होता है क्यों —
chronyc-sources या
dig की आवश्यकता से पहले ही।
इनमें से प्रत्येक को तब test किया गया और खारिज किया गया जब route को असंभव माना जाता था।
प्रत्येक इतना प्रशंसनीय है कि एक दिन लग सकता है।
कारण नहीं
कैसे खारिज किया गया
Credential केवल create time पर लागू होता है
sshd पहले boot में लगभग 90 seconds में शुरू होता है, site object के exist करने से पहले। admin_user_credentials भी ReplaceSpecType में मौजूद है और in-place लागू होता है।
block_all_services
Management address पर port-22 closure वही है चाहे services blocked हों या नहीं।
Key पर trailing newline
दोनों तरह से test किया, कोई बदलाव नहीं। Cloud-init फिर भी इसे strip करता है, क्योंकि literal block अन्यथा एक दूसरी, खाली line render करती।
Pinned, पुराना CE software
तीन builds पर reproduce हुआ, जिसमें OpenSSH 9.9 चलाने वाला एक build शामिल है।
Missing admin_password
शुरू से CE पर ssh_key के साथ admin_password set करने से कुछ नहीं बदला।
Debug APIScripted, VNet के अंदर किसी access की आवश्यकता नहीं, और दोहराने योग्य evidence के लिए सही विकल्प। 34 commands cover करता है और site के ONLINE होने की आवश्यकता है।
Site ConsoleAzure Bastion tunnel पर F5 का node troubleshooting UI। कोई key नहीं, कोई jump host नहीं, और site के register होने से पहले जवाब देता है।
Serial consoleकिसी ऐसे नोड के लिए जो कभी register नहीं हुआ, या जिसका कोई काम करने वाला network path नहीं है। Terminal की आवश्यकता है, या websocket harness।
