Cloud-init और machine images

manual install छोड़ने के दो तरीके: VPS बनाते समय एक cloud-init template paste करें, या एक machine image बनाएँ जिसमें सब कुछ पहले से installed हो।

Cloud-init (एक बार में एक सर्वर)

panel/deploy/cloud-init.yaml एक user-data template है। ऊपर की कुछ settings edit करें, सर्वर बनाते समय इसे अपने provider के "user data" box में paste करें, और सर्वर के boot होते ही पैनल चालू हो जाता है। प्रगति और कोई भी विफलता /var/log/nimbopanel-provision.log में दर्ज होती है।

user data को secret store की तरह न समझें

यही वह हिस्सा है जिसे दो बार पढ़ना चाहिए। हर बड़े provider पर, user data चल रहे instance के भीतर से HTTP पर 169.254.169.254 पर retrievable रहता है — और वह address machine पर मौजूद किसी भी process के लिए पहुँच में है, जिसमें एक होस्टिंग customer की PHP script भी शामिल है।

तो user data में paste की गई एक licence key आपके host किए हर customer के लिए पढ़ने योग्य है, जब तक कोई चीज़ उसे न रोके। template इसे दो steps में, इसी क्रम में रोकता है:

1. यह key के disk तक पहुँचने से पहले metadata service को root के अलावा सबके लिए बंद कर देता है;
2. installer द्वारा key को root-only configuration में store करने के बाद, यह user data की on-disk copy को shred कर देता है।

अगर आप key को वहाँ बिलकुल न रखना चाहें, तो उसे खाली छोड़ दें और बाद में पैनल से डालें। जब तक आप ऐसा नहीं करते सर्वर unlicensed चलता है, जो एक supported स्थिति है।

Machine images (एक build से कई सर्वर)

panel/deploy/packer/nimbopanel.pkr.hcl पूरा stack installed वाली एक image बनाता है। वहीं मिनट लगते हैं — packages, PHP, mail, DNS, database — और इसमें से कोई भी सर्वरों के बीच अलग नहीं होता।

वह ग़लती जो हर clone को एक ही सर्वर बना देती है

एक image में कोई पहचान नहीं होनी चाहिए। अगर होती है, तो उससे बना हर सर्वर वह पहचान साझा करता है:

ग़लती से bake हुआ	हर clone पर क्या होता है
SSH host keys	वे सब वही key पेश करते हैं। जो कोई customer और उनके सर्वर के बीच में हो वह उसकी नक़ल कर सकता है, सब पर, बिना कोई चेतावनी दिखाए
Nimbopanel instance-id	licence fingerprint इससे बनती है, और installer किसी पहले से मौजूद id को दोबारा seed नहीं करता — तो हज़ार सर्वर एक ही activation जैसे दिखते हैं
/etc/machine-id	systemd, DHCP leases और journald identity टकराते हैं
panel database और config	Admin password, licence key और हर account एक ऐसी file में जाते हैं जिसे अजनबी download करते हैं
DKIM keys, TLS certificates	build machine के लिए जारी; एक clone पर बेमानी, और image रखने वाले हर किसी को leak

इनमें से कोई भी ख़ुद घोषणा नहीं करता। ये बाद में, किसी और के द्वारा पाई जाती हैं।

panel/deploy/image-deidentify.sh यह सब हटा देता है, और Packer build इसे आख़िरी step के रूप में चलाता है और फिर --check के साथ दोबारा चलाता है, ताकि एक ऐसा snapshot पैदा करने के बजाय build विफल हो जो केवल साफ़ दिखता है। हटाया गया सब कुछ clone के पहले boot पर फिर से बन जाता है: sshd नई host keys बनाता है, systemd एक नया machine-id लिखता है, installer एक ताज़ा instance-id seed करता है।

/etc/machine-id को delete करने के बजाय खाली छोड़ा जाता है — systemd एक खाली file को "boot पर एक बनाओ" के रूप में पढ़ता है, जबकि एक ग़ायब file कुछ images को boot ही होने से रोक देती है।

publish करने से पहले verify करें

sudo ./image-deidentify.sh          # remove
sudo ./image-deidentify.sh --check  # confirm, exits non-zero if anything survives

केवल build समय पर नहीं, एक booted clone पर भी check चलाएँ। अगर यह कुछ भी रिपोर्ट करे, तो image publish न करें।

मार्केटप्लेस लिस्टिंग

Provider "1-click app" programmes (Vultr, DigitalOcean, Linode, Contabo) हर एक का अपना submission format और review है। ऊपर बताई image वही artefact है जो वे माँगते हैं; paperwork प्रति-provider है और यह ऐसी चीज़ नहीं जो यह tooling आपके लिए कर सके।