ERPC CLI में लॉग इन करें और देखें कि आपकी keys कहाँ रखी जाती हैं
इस मशीन से लॉग इन करें, और ERPC CLI session को आपकी कीचेन या 1Password में रखता है। यह पेज यह भी दिखाता है कि नोड keys कहाँ रखी जाती हैं और erpc कौन-सी फ़ाइलें रखता है।
यह पेज ERPC CLI
v0.1.0-rc.4 के बारे में है, जो एक प्री-रिलीज़ है।लॉग इन करें
bash
erpc login, OAuth device authorization grant के ज़रिए session लेता है। बिना browser वाली मशीन पर erpc login --no-browser browser खोलने के बजाय URL और code छापता है, और erpc signup --no-browser sign-up URL छापता है। erpc whoami दिखाता है कि सहेजा गया session किसका है, और erpc logout लॉग आउट करता है और सहेजा गया session हटा देता है।चुनें कि session कहाँ रखा जाए
टर्मिनल में
erpc login पूछता है कि कौन-सा store इस्तेमाल करना है: ऑपरेटिंग सिस्टम की कीचेन, जो डिफ़ॉल्ट है, या 1Password, अगर वह जवाब देता है। --store और --vault बिना पूछे चुनाव कर देते हैं, और चुनाव config.toml में दर्ज होता है, जहाँ से बाकी कमांड उसे पढ़ती हैं।जब कोई चुनाव न दिया गया हो और न दर्ज हो, तो
OP_SERVICE_ACCOUNT_TOKEN सेट होने पर erpc 1Password service account इस्तेमाल करता है, नहीं तो ऑपरेटिंग सिस्टम की कीचेन, अगर वह मौजूद हो, और नहीं तो अपनी state directory में एक फ़ाइल। erpc doctor बताता है कि कौन-सा store इस्तेमाल हो रहा है और क्यों। service account के साथ, erpc OP_SERVICE_ACCOUNT_TOKEN केवल उन्हीं op processes को देता है जिन्हें वह खुद शुरू करता है, और उस token को कहीं नहीं लिखता।1Password item का शीर्षक मशीन के नाम पर होता है, ताकि दो मशीनें कभी एक session साझा न करें।
ERPC_HOST_LABEL इस नाम को बदल देता है।Linux पर
जहाँ कोई Secret Service जवाब देती है, वहाँ कीचेन वही Secret Service है। नहीं तो यह आपके user के लिए kernel का persistent keyring है, जो मेमोरी में रहता है और डिस्क पर कभी नहीं: session किसी रीबूट तक या कुछ दिन इस्तेमाल न होने तक चलता है, और फिर
erpc login दोबारा माँगा जाता है। जो shell अपने खुद के login के बिना शुरू हुआ हो (- के बिना su, sudo -E), वह उस keyring का उपयोग नहीं कर सकता, और erpc मना कर देता है और यह बता देता है।macOS पर
erpc,
/usr/bin/security के ज़रिए कीचेन तक पहुँचता है। आपके नाम से चल रहा कोई भी दूसरा program भी security चलाकर session पढ़ सकता है, हालाँकि कीचेन फिर भी session को at rest एन्क्रिप्टेड और दूसरे users से दूर रखती है।जब session डिस्क पर हो
erpc तीन स्थितियों में session को अपनी state directory में लिखता है:
file store के साथ, किसी parked session के लिए (एक rotated refresh token जो store तक नहीं पहुँच सका), और किसी अधूरे write के बाद। erpc doctor ऐसी हर फ़ाइल की रिपोर्ट तब तक करता है जब तक वह मौजूद है। Unix पर ये फ़ाइलें mode 0600 के साथ बनती हैं; Windows पर erpc अपनी ओर से कोई permissions सेट नहीं करता।नोड keys कहाँ रखी जाती हैं
नोड इन्वेंटरी, और हर चेन की गाइड जिन original-key बैकअप का नाम लेती है, वे 1Password में रखे जाते हैं। हर key 1Password में नहीं होती, और कोई नोड चलने के लिए ज़रूरी key अपने पास रख सकता है। होस्ट पर जो है, उसका बैकअप खुद लें: बिना बैकअप के उस होस्ट को दोबारा बनाने पर वह खो जाता है। सक्रिय Sui validator या चुना गया TRON witness भी नए होस्ट पर जाने से मना कर देता है।
बाकी RPC नोड किसी validator के लिए कोई signing key नहीं रखते, लेकिन उनके होस्ट वह रखते हैं जो client अपने लिए बनाता है, जैसे engine JWT, peer identity या RPC cookie।
केवल key बैकअप होने से validator recovery सुरक्षित नहीं हो जाती। सर्वर बदलने या उसका डेटा पुनर्स्थापित करने से पहले चेन की recovery प्रक्रिया का पालन करें; हर चेन की गाइड बताती है कि उसकी keys कैसे पुनर्स्थापित करें (नोड)।
केवल एक कमांड आपकी मशीन की डिस्क पर नोड keys लिखती है:
erpc validator vote-account, Solana CLI चलने के दौरान identity और vote keys को state directory के तहत mode 0600 वाली फ़ाइलों में लिखती है, और बाद में उन्हें मिटा देती है। अगर process बीच में बंद हो जाए, तो फ़ाइल तब तक रह सकती है जब तक कोई बाद का run उसे साफ़ न कर दे।erpc worker app की trading key और secrets इनसे अलग रखे जाते हैं: keys और secrets।