SMF - सोलारिस पर सेवा प्रबंधन

हाल ही में लेख "हम सोलारिस के लिए एक पैकेज का निर्माण कर रहे हैं" को पढ़ने के बाद , मैंने महसूस किया कि एसएमएफ की कार्यक्षमता हैबर के साथ बिल्कुल भी नहीं है।
आइए इस स्थिति को ठीक करें और देखें कि एसएमएफ क्या है और यह प्रशासकों को क्या लाभ देता है।

परिचय

सेवा प्रबंधन सुविधा (SMF) सोलारिस 10. में शुरू की गई एक सेवा प्रबंधन प्रणाली है। SMF आपको अधिक लचीले ढंग से प्रक्रियाओं को प्रबंधित करने, उन पर निर्भरता प्रदान करने और यदि आवश्यक हो तो उन्हें पुनः आरंभ करने की अनुमति देता है। इसके अतिरिक्त, SMF आपको गैर-रूट उपयोगकर्ताओं के लिए सेवा प्रबंधन अधिकार सौंपने की अनुमति देता है।
एसएमएफ को नियंत्रित करने के लिए, "केवल" तीन कमांड पर्याप्त हैं:

• svcs - सेवाओं की स्थिति की जाँच करता है,
• svcadm - सेवा राज्य प्रबंधन,
• svccfg - सेवा सेटिंग्स कॉन्फ़िगर करें।

आइए यह पता लगाने की कोशिश करें कि हमारी स्वयं की सेवा को जोड़ने के उदाहरण का उपयोग करके एसएमएफ का प्रबंधन कैसे करें।
हाल ही में, मुझे सोलारिस के लिए नग्नेक्स की आवश्यकता थी, मुझे एक पैकेज का निर्माण करना था और एक सामान्य सेवा प्रणाली में एकीकृत करना था - इसके उदाहरण का उपयोग करके, हम इस बात पर ध्यान देंगे कि एसएमएफ के माध्यम से प्रबंधन के लिए एक सेवा कैसे तैयार की जा सकती है।

सेवा जोड़ना

सेवा को एसएमएफ में एकीकृत करने के लिए, आपको इसके लिए एक घोषणापत्र लिखने की आवश्यकता है - निर्भरता, स्टार्टअप विधियों और अन्य मापदंडों के विवरण के साथ एक XML फ़ाइल। प्राथमिक सेवाओं के लिए, यह पर्याप्त है, अधिक जटिल सेवाओं के लिए आपको एक स्टार्टअप स्क्रिप्ट (/etc/init.d/service के अनुरूप) की आवश्यकता है।

एसएमएफ प्रकट सामग्री

 <? xml संस्करण = "1.0"?> <! DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> <service_bundle प्रकार = 'प्रकट' नाम = 'nginx'> <सेवा का नाम = 'नेटवर्क / nginx' प्रकार = 'सेवा' संस्करण = '1'> <create_default_instance सक्षम = 'गलत' /> <सिंगल_स्टेंस /> <निर्भरता का नाम = 'लूपबैक' समूहीकरण = 'आवश्यकता' फिर से शुरू करना '=' त्रुटि 'प्रकार =' सेवा '> <service_fmri मान =' svc: / network / loopback: default '/> </ निर्भरता> <निर्भरता का नाम =' भौतिक 'समूहीकरण =' वैकल्पिक_का 'पुनः आरंभ_का =' त्रुटि 'प्रकार => सेवा>> <service_fmri मान = 'svc: / network / physical: default' /> </ निर्भरता> <निर्भरता का नाम = 'बहुउद्देशीय-सर्वर' समूहीकरण = 'requ_all' पुनरारंभ_on = 'त्रुटि' प्रकार = 'सेवा'> <service_fmash मान = 'svc: / milestone' / बहु-उपयोगकर्ता-सर्वर: डिफ़ॉल्ट '/> </ निर्भरता> <exec_method प्रकार =' विधि 'नाम =' प्रारंभ 'निष्पादित =' / ऑप्ट / nginx / svc / nginx प्रारंभ 'timeout_seconds = "60'>> <exec_method प्रकार = 'विधि' नाम = 'रोक' निष्पादन = ': मार-जांच' टाइमआउट_सेकेंड = '60 '/> <निष्पादन_मिथोड प्रकार =' विधि 'नाम =' ताज़ा 'निष्पादन =' / ऑप्ट / nginx / svc / nginx  ताज़ा करें 'timeout_seconds =' 60 '/> <property_group नाम =' nginx 'प्रकार =' अनुप्रयोग '> <प्रोपॉल नाम =' config 'प्रकार =' astring 'मान =' / opt / nginx / / आदि / nginx.conf '/> <प्रचलित नाम = 'pid' प्रकार = 'astring' मान = '/ opt / nginx / var / run / nginx.pid' /> </ property_group> <property_group नाम = 'startd' = 'ढाँचा'> <! -! - उप-प्रक्रिया कोर डंप सत्र को पुनरारंभ नहीं करना चाहिए -> <प्रणाम नाम = 'ign_error' प्रकार = 'astring' मान = 'कोर, सिग्नल' /> </ property_group> <टेम्पलेट> <आम_नाम> <loctive xml: lang = 'C'> Nginx HTTP सर्वर </ loctext> </ common_name> <प्रलेखन> <manpage शीर्षक = 'nginx' अनुभाग = '1M' /> <doc_link नाम = 'nginx.org' uri = 'http: // www .nginx.org / '/> </ प्रलेखन> </ टेम्पलेट> </ सेवा> </ service_bundle> 

हम क्रम में विश्लेषण करेंगे:

• service_bundle - दिखाता है कि इस फ़ाइल को SMF द्वारा कैसे संसाधित किया जाना चाहिए। "अर्हाइव", "मैनिफ़ेस्ट", "प्रोफ़ाइल" प्रकार के लिए संभावित मान। हमारे मामले में, केवल "प्रकट" माना जाता है। नाम विशेषता सेवा का नाम रिकॉर्ड करती है;
• सेवा - में सेवा उदाहरणों का एक सेट होता है (प्रत्येक सेवा के विन्यास में कई उदाहरण हो सकते हैं), निर्भरता, प्रबंधन के तरीके और कॉन्फ़िगरेशन पैरामीटर। नाम, संस्करण और प्रकार की विशेषताओं में क्रमशः नाम, संस्करण और सेवा का प्रकार शामिल है। प्रकार "सेवा", "स्टार्टर", "मील का पत्थर" में से एक हो सकता है।
  एक सेवा (विशेषता नाम) के नामकरण के लिए कई सम्मेलन हैं। वे बाध्यकारी नहीं हैं, लेकिन समग्र धारणा को सुविधाजनक बनाते हैं। कई मानक श्रेणियां (सिस्टम, एप्लिकेशन, नेटवर्क, आदि) हैं जिन्हें स्लैश (नेटवर्क / नगनेक्स) के माध्यम से नाम से जोड़ा जाता है। कई श्रेणियां भी मान्य हैं, उदाहरण के लिए, प्रकार पृथक्करण (अनुप्रयोग / डेटाबेस / mysql) के लिए;
• create_default_instance और single_instance हमें बताते हैं कि सेवा का केवल एक उदाहरण है और इसे ऑफ स्टेट में बनाया जाना चाहिए (सक्षम = 'गलत');
• निर्भरता - सेवा की निर्भरता का वर्णन करता है। सभी निर्भरताएं प्रकार (विशेषता ग्रूपिंग) द्वारा समूहीकृत की जाती हैं। सेवा शुरू करने के लिए आवश्यक_ऑल ग्रुप से सेवाएँ ऑनलाइन होनी चाहिए। आवश्यकता_ किसी भी समूह को वर्णित सेवाओं में से किसी की भी आवश्यकता होती है, बहिष्कृत_all सभी निर्दिष्ट सेवाओं को छोड़ देता है, और आल्टरनेटिव_ऑल (जैसा कि मैं इसे समझता हूं) सभी वैकल्पिक_all निर्भरता के बाद सेवा शुरू करने की आवश्यकता होती है, क्योंकि यह अभी भी प्रतीक्षा करता है कि उन्हें लोड करने या त्रुटि के साथ निकलने के लिए, या बंद थे।
  निर्भरता के आधार पर सेवा पुनरारंभ का प्रकार पुनरारंभ_ऑन विशेषता द्वारा निर्धारित किया जाता है और इसमें निम्न मान शामिल हैं: "त्रुटि" - पुनरारंभ यदि निर्भरता एक हार्डवेयर त्रुटि के कारण रिबूट हो गई है, तो "पुनः आरंभ करें" - पुनरारंभ करें यदि निर्भरता किसी भी कारण से पुनः लोड की गई है (हार्डवेयर त्रुटि सहित), "ताज़ा" - निर्भरता रिबूट या अपडेट होने पर पुनः आरंभ करें। "कोई नहीं" का एक मूल्य निर्भरता की स्थिति के बावजूद सेवा का एक रिबूट प्रतिबंधित करता है;
• exec_method - एक सेवा के प्रबंधन के लिए विभिन्न तरीके। सेवा को सक्षम (सक्षम), अक्षम (अक्षम), और सेवा के पुनरारंभ (पुनरारंभ) होने पर स्टार्ट / स्टॉप के तरीकों को कहा जाता है। जब सेवा को अपडेट किया जाता है तो ताज़ा विधि को कहा जाता है (ताज़ा);
• property_group - सेवा के लिए कॉन्फ़िगरेशन मापदंडों का एक सेट परिभाषित करता है। प्रकार "फ्रेमवर्क" एसएमएफ मापदंडों के विन्यास के लिए जिम्मेदार है, और सेवा के मापदंडों के लिए "आवेदन"। हमारे मामले में, startd / ign_error पैरामीटर पारित किया जाता है, जो टॉयलेटरी (टॉयलेटरी का अंग्रेजी संस्करण) को समझाता है कि सेवा को केवल तभी पुनरारंभ करने की आवश्यकता है, जब इसकी सभी प्रक्रियाएं बाहर जाती हैं और "छाल" और "घातक संकेतों" को अनदेखा करती हैं। "एप्लिकेशन" समूह में पैरामीटर का उपयोग उदाहरण को कॉन्फ़िगर करने के लिए किया जाता है;
• टेम्पलेट - एक वैकल्पिक टैग जिसमें सेवा के बारे में मेटा-जानकारी होती है।

जैसा कि आप देख सकते हैं, प्रकट रूप से सेवा का वर्णन कुछ विस्तार से किया गया है और यह भी एक बाहरी स्क्रिप्ट / ऑप्ट / nginx / svc / nginx को संदर्भित करता है जो जिम्मेदार है, वास्तव में, सेवा शुरू करने के लिए। आइए अब इसका विश्लेषण करें:

 #! / sbin / श
 #

 ।  /lib/svc/share/smf_include.sh

 # SMF_FMRI लक्ष्य सेवा का नाम है।  यह कई उदाहरणों की अनुमति देता है
 # एक ही स्क्रिप्ट का उपयोग करने के लिए।

 अगर [-Z $ SMF_FMRI];  तो
 इको "SMF फ्रेमवर्क वैरिएबल को आरंभिक नहीं किया गया है।"
 $ SMF_EXIT_ERR से बाहर निकलें
 फाई

 getproparg () {
 वैल = `svcprop -p $ 1 $ SMF_FMRI`
 [-n "$ val"] && इको $ वैल
 }

 NGINX_HOME = / ऑप्ट / nginx
 HTTPD = "$ {NGINX_HOME} / sbin / nginx"
 CONF_FILE = `getproparg nginx / config`
 PIDFILE = `getproparg nginx / pid`

 अगर [-z $ CONF_FILE];  तो
 गूंज "nginx / config संपत्ति सेट नहीं है"
 $ SMF_EXIT_ERR_CONFIG से बाहर निकलें
 फाई

 अगर [-z $ PIDFILE];  तो
 गूंज "nginx / pid संपत्ति सेट नहीं है"
 $ SMF_EXIT_ERR_CONFIG से बाहर निकलें
 फाई

 अगर [!  -f $ {CONF_FILE}];  तो
 इको "nginx / config: कॉन्फ़िगर फ़ाइल नहीं मिल सका"
 $ SMF_EXIT_ERR_CONFIG से बाहर निकलें
 फाई

 मामले में "$ 1"
 शुरुआत)
         $ HTTPD -t -c $ {CONF_FILE} 2> & 1
         अगर [$?  —ने ०];  तो
                 $ SMF_EXIT_ERR_CONFIG से बाहर निकलें
         फाई
         $ HTTPD -c $ {CONF_FILE} 2> & 1
         ;;
 ताज़ा)
         अगर [-f "$ पिडोमेर"];  तो
                 / usr / bin / kill -HUP `/ usr / bin / cat $ PIDFILE`
         फाई
         ;;
 बंद)
         अगर [-f "$ पिडोमेर"];  तो
                 / usr / bin / kill -KILL `/ usr / बिन / बिल्ली $ PIDFILE`
         फाई
         ;;
 *)
         इको "यूज़: $ 0 {स्टार्ट | स्टॉप | रिफ्रेश}"
         बाहर निकलें 1
         ;;
 esac

 $ SMF_EXIT_OK से बाहर निकलें

यह कुछ सहायक कार्यों के साथ एक सामान्य init.d स्क्रिप्ट है। बहुत शुरुआत में, सिस्टम चर के साथ एक फ़ाइल शामिल है जो भविष्य में हमारी मदद करेगी। उनमें से एक SMF_FRMI है - इसमें सेवा का पूरा नाम शामिल है। SMF_FRMI का उपयोग मैनिफ़ेस्ट (getproparg सहायक फ़ंक्शन) से कॉन्फ़िगरेशन पैरामीटर प्राप्त करने के लिए किया जाता है। इस दृष्टिकोण का लाभ बाद में स्पष्ट होगा, जब हम एक ही सेवा के विभिन्न उदाहरणों पर विचार करेंगे।

अब हमारे पास फ़ाइलों का एक पूरा सेट है, हम उन्हें सिस्टम को दिखाई देंगे:

 # svccfg -v इंपोर्ट nginx.xml
 svccfg: svc के लिए "प्रारंभिक" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: svc के लिए "अंतिम-आयात" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: Refreshed svc: / network / nginx: default।
 svccfg: सफल आयात।

अब हमारे पास एक डिफ़ॉल्ट उदाहरण के साथ नेटवर्क / nginx सेवा है, क्योंकि प्रकट रूप से कहा गया है "डिफ़ॉल्ट आवृत्ति बनाएं"। इसके अलावा, इस उदाहरण को ऑफ स्टेट में बनाया जाना चाहिए, जाँच करें:

 # svcs nginx
 स्टेट टाइम एफएमआरआई
 अक्षम 19:11:07 svc: / network / nginx: डिफ़ॉल्ट

प्रबंधन टीमों के लिए पूर्ण FRMI (Eng। Fault Managed Resource Identifier) ​​सेवा को प्रसारित करना आवश्यक नहीं है, बस एक नाम (उदाहरण के लिए nginx) पर्याप्त है, लेकिन यदि एक ही नाम के साथ कई सेवाएँ हैं, लेकिन विभिन्न श्रेणियों में, तो आपको पूरा नाम निर्दिष्ट करने की आवश्यकता नहीं है। आपको एक उदाहरण निर्दिष्ट करना होगा (nginx: default) यदि सेवा में एक से अधिक उदाहरण हैं (svcs कमांड उन सभी सेवाओं की स्थिति दिखाएगी जिनकी तुलना FRMI के अपूर्ण होने पर की जाती है)।

OS बूट होने पर अक्षम अवस्था में सेवा नहीं उठेगी। इसलिए, आपको इसे सक्षम करने की आवश्यकता है:

 # svcadm -v nginx सक्षम करें
 svc: / network / nginx: डिफ़ॉल्ट सक्षम।

जांचें कि सेवा चल रही है:

 # svcs nginx
 स्टेट टाइम एफएमआरआई
 रखरखाव 19:26:28 svc: / नेटवर्क / nginx: डिफ़ॉल्ट

निराशा हमें इंतजार कर रही है - ऑनलाइन स्थिति के बजाय हमारे पास रखरखाव है। रखरखाव की स्थिति सेवा में एक निश्चित त्रुटि से मेल खाती है। SMF इस स्थिति में सेवा देता है यदि प्रारंभ विधि OK के अलावा कोई मान लौटाती है या सेवा को रोकने का प्रयास लगातार तीन बार विफल हुआ है। आइए देखें कि हमारे मामले में क्या कारण बने। ऐसा करने के लिए, सेवा की विस्तारित स्थिति देखें:

 # svcs -x nginx
 svc: / network / nginx: default (Nginx HTTP सर्वर)
  राज्य: थू Mar 24 19:26:28 2011 के बाद से रखरखाव
 कारण: $ SMF_EXIT_ERR_CONFIG के साथ प्रारंभ विधि।
    देखें: http://sun.com/msg/SMF-8000-KS
    देखें: nginx (1M)
    देखें: /var/svc/log/network-nginx:default.log
 प्रभाव: यह सेवा नहीं चल रही है।

जैसा कि आप देख सकते हैं, विस्तारित स्थिति में टेम्पलेट मेनिफ़ेस्ट का विवरण भी शामिल है। हमें दिखाया गया है कि प्रारंभिक विधि विफल हो गई और लॉग को इंगित करें जहां आप अधिक विस्तार से देख सकते हैं। लॉग निम्न दिखाता है:

 [मर 24:26:28 सक्षम।  ]
 [मार्च 24 19:26:28 निष्पादन शुरू करने की विधि ("/ opt / nginx / svc / nginx start")]
 nginx / config: config फ़ाइल नहीं मिल सकी
 [Mar 24 19:26:28 विधि "शुरू" स्थिति 96 के साथ बाहर निकल गया]

हमारी स्टार्ट-अप स्क्रिप्ट कहती है कि यह कॉन्फ़िगरेशन फ़ाइल नहीं ढूँढ सकती। हां, मैं इसे बनाना भूल गया। फ़ाइल बनाने के बाद सेवा को पुनः आरंभ करने का प्रयास करते हैं। यह ध्यान दिया जाना चाहिए कि रखरखाव राज्य किसी भी तरह से सक्षम / अक्षम सेवा को प्रभावित नहीं करता है - यह एक अस्थायी रोक है। इसलिए, हमें बस सेवा को "साफ" करने की आवश्यकता है, उस प्रणाली को बताएं जो हमने इसे तय किया था:

 # svcadm स्पष्ट nginx
 # svcs -x nginx
 svc: / network / nginx: default (Nginx HTTP सर्वर)
  राज्य: ऑनलाइन थु Mar 24 19:40:03 2011 के बाद से
    देखें: nginx (1M)
    देखें: /var/svc/log/network-nginx:default.log
 प्रभाव: कोई नहीं।

 # पीएस-एफए |  ग्रीप नगीनक्स
     जड़ 5864 1 0 19:40:04?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx.ff
   कोई नहीं 5865 5864 0 19:40:04?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx.ff

सेवा शुरू हुई और सफलतापूर्वक अपने कार्यों को करती है। इस स्थिति में, निम्नलिखित लॉग किया जाएगा:

 [Mar 24 19:40:03 रखरखाव को छोड़ना क्योंकि स्पष्ट अनुरोध।  ]
 [Mar 24 19:40:03 सक्षम किया गया।  ]
 [मार्च 24 19:40:03 आरंभ करने की विधि ("/ opt / nginx / svc / nginx start")]
 कॉन्फ़िगरेशन फ़ाइल /opt /nginx/etc/nginx.conf सिंटैक्स ठीक है
 कॉन्फ़िगरेशन फ़ाइल /opt/nginx/etc/nginx.conf परीक्षण सफल है
 [Mar 24 19:40:03 विधि "शुरू" स्थिति 0 के साथ बाहर निकल गया]

अब, यदि सेवा की अप्रत्याशित रूप से मृत्यु हो जाती है, तो एसएमएफ स्वचालित रूप से इसे फिर से शुरू करेगा (प्रारंभ / ign_error मापदंडों के अनुसार)। किल -9 के साथ इस स्थिति को बनाएं और लॉग देखें:

 [Mar 24 19:42:25 रोकना क्योंकि सेवा में सभी प्रक्रियाएँ समाप्त हो गईं।  ]
 [Mar 24 19:42:25 निष्पादन रोकने की विधि (: मार)]
 [Mar 24 19:42:25 निष्पादन शुरू करने की विधि ("/ ऑप्ट / nginx / svc / nginx start")]
 कॉन्फ़िगरेशन फ़ाइल /opt /nginx/etc/nginx.conf सिंटैक्स ठीक है
 कॉन्फ़िगरेशन फ़ाइल /opt/nginx/etc/nginx.conf परीक्षण सफल है
 [Mar 24 19:42:25 विधि "शुरू" स्थिति 0 के साथ बाहर निकल गया]

अतिरिक्त विशेषताएं

तो, हमारे पास एक सेवा है जिसका प्रदर्शन ओएस स्तर पर नियंत्रित है। लेकिन अगर हमें दो या तीन समान सेवाओं की आवश्यकता है (उदाहरण के लिए, कई पोस्टग्रैक्स्ल सर्वर या अलग-अलग कार्यों के साथ नैग्नेक्स) तो क्या, मैनिफ़ेस्ट्स का एक गुच्छा लिखें? फिर क्या फायदा?
यहां हम एक सेवा के कई उदाहरण बनाने के लिए बचाव अवसर पर आएंगे। ऐसा करने के लिए, हमें घोषणापत्र में create_default_instance और single_service टैग को हटाने की जरूरत है, स्पष्ट रूप से अपना स्वयं का उदाहरण बनाएं और वहां अद्वितीय पैरामीटर स्थानांतरित करें:

 <उदाहरण का नाम = 'डिफ़ॉल्ट' सक्षम = 'गलत'>
   <property_group नाम = 'nginx' प्रकार = 'अनुप्रयोग'> 
      <प्रॉवल नाम = 'कॉन्फ़िगरेशन' प्रकार = 'एस्ट्रिंग' 
               मान = '/ ऑप्ट / nginx / etc / nginx.conf' /> 
      <प्रॉवल नाम = 'पीआईडी' टाइप = 'एस्ट्रिंग' 
               मान = '/ ऑप्ट / nginx / var / run / nginx.pid' /> 
   </ Property_group> 

   <संपत्ति_ समूह का नाम = 'प्रारंभ' प्रकार = 'ढांचा'> 
      <! - उप-प्रक्रिया कोर डंप पुनः आरंभ नहीं होना चाहिए 
           सत्र -> 
      <प्रॉवल नाम = 'ign_error' प्रकार = 'एस्ट्रिंग' 
               मूल्य = 'कोर, सिग्नल' /> 
   </ Property_group> 
 </ उदाहरण>

आयात के माध्यम से प्रकट को फिर से लोड करना आवश्यक है। SMF निर्धारित करेगा कि क्या बदल गया है:

 # svccfg -v इंपोर्ट nginx.xml 
 svccfg: svc के लिए "पिछले" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: svc के उन्नयन गुण: / नेटवर्क / nginx उदाहरण के अनुसार "डिफ़ॉल्ट"।
 svccfg: svc: / network / nginx: संपत्ति समूह को हटाना "nginx"।
 svccfg: svc: / network / nginx: संपत्ति समूह "सामान्य" हटाना।
 svccfg: svc: / network / nginx: संपत्ति समूह को हटाना "startd"।
 svccfg: svc के लिए "अंतिम-आयात" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: Refreshed svc: / network / nginx: default।
 svccfg: सफल आयात।

नतीजतन, हमें सेवा का एक ही विवरण मिला, केवल अब कई उदाहरणों को कॉन्फ़िगर करने की क्षमता के साथ। आप सीधे प्रकट में एक अतिरिक्त उदाहरण निर्दिष्ट कर सकते हैं:

 <उदाहरण का नाम = 'निगरानी' सक्षम = 'गलत'>
   <property_group नाम = 'nginx' प्रकार = 'अनुप्रयोग'> 
      <प्रॉवल नाम = 'कॉन्फ़िगरेशन' प्रकार = 'एस्ट्रिंग' 
               value = '/ opt / nginx / etc / nginx-munin.conf' /> 
      <प्रॉवल नाम = 'पीआईडी' टाइप = 'एस्ट्रिंग' 
               value = '/ opt / nginx / var / run / nginx-munin.pid' /> 
   </ Property_group> 

   <संपत्ति_ समूह का नाम = 'प्रारंभ' प्रकार = 'ढांचा'> 
      <! - उप-प्रक्रिया कोर डंप पुनः आरंभ नहीं होना चाहिए 
           सत्र -> 
      <प्रॉवल नाम = 'ign_error' प्रकार = 'एस्ट्रिंग' 
               मूल्य = 'कोर, सिग्नल' /> 
   </ Property_group> 
 </ उदाहरण>

और आयात करें:

 # svccfg -v इंपोर्ट nginx.xml 
 svccfg: svc के लिए "पिछले" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: नई सेवा के लिए "पिछले" स्नैपशॉट लेना svc: / network / nginx: निगरानी।
 svccfg: svc के उन्नयन गुण: / नेटवर्क / nginx उदाहरण के अनुसार "डिफ़ॉल्ट"।
 svccfg: svc के लिए "प्रारंभिक" स्नैपशॉट लेना: / नेटवर्क / nginx: निगरानी।
 svccfg: svc के लिए "अंतिम-आयात" स्नैपशॉट लेना: / नेटवर्क / nginx: निगरानी।
 svccfg: svc के लिए "अंतिम-आयात" स्नैपशॉट लेना: / नेटवर्क / nginx: डिफ़ॉल्ट।
 svccfg: Refreshed svc: / network / nginx: निगरानी।
 svccfg: Refreshed svc: / network / nginx: default।
 svccfg: सफल आयात।

अब हमारे पास दो सेवा उदाहरण हैं (ध्यान दें कि डिफ़ॉल्ट उदाहरण सक्षम बना हुआ है):

 # svcs nginx
 स्टेट टाइम एफएमआरआई
 अक्षम 20:16:31 svc: / network / nginx: निगरानी
 ऑनलाइन 20:16:31 svc: / network / nginx: डिफ़ॉल्ट

अब, सेवा शुरू करने के लिए, आपको स्पष्ट रूप से उदाहरण निर्दिष्ट करना होगा, अन्यथा सिस्टम हमें चेतावनी देगा:

 # svcadm nginx सक्षम करें
 svcadm: पैटर्न 'nginx' कई उदाहरणों से मेल खाता है:
	 svc: / network / nginx: निगरानी
	 svc: / network / nginx: default

 # svcadm -v सक्षम nginx: निगरानी
 svc: / network / nginx: निगरानी सक्षम।

आप अभिव्यक्ति को संपादित किए बिना भी एक उदाहरण जोड़ सकते हैं (लेकिन पहले से ही कई उदाहरणों के लिए इसे कॉन्फ़िगर किया जाना चाहिए और svccfg कमांड का उपयोग करते हुए डिफ़ॉल्ट होना चाहिए), जो सेवा सेटिंग्स को बदलने का काम करता है। मोटे तौर पर, प्रकट आयात करने के बाद, स्रोत फ़ाइल अब कोई भूमिका नहीं निभाती है, क्योंकि यह एसएमएफ डेटाबेस में आयात किया जाता है। वर्तमान सेवा सेटिंग्स के साथ एक अभिव्यक्ति प्राप्त करने के लिए, आप svccfg निर्यात कमांड का उपयोग कर सकते हैं। मक्खी पर उदाहरण जोड़ने से आप प्रक्रिया को स्वचालित कर सकते हैं:

 # svccfg -s nginx में phpfpm मिलाएं
 # svccfg -s nginx: phpfpm addpg nginx एप्लीकेशन
 # svccfg -s nginx: phpfpm setprop nginx / config = astring: /opt/nginx/etc/fpm.conf
 # svccfg -s nginx: phpfpm setprop nginx / pid = astring: /opt/nginx/run/fpm.pid
 # svcadm अक्षम nginx: phpfpm # यह स्वचालित रूप से सिस्टम गुण जोड़ देगा
 # svcs nginx
 स्टेट टाइम एफएमआरआई
 अक्षम 20:37:30 svc: / network / nginx: phpfpm
 ऑनलाइन 20:16:31 svc: / network / nginx: डिफ़ॉल्ट
 ऑनलाइन 20:21:09 svc: / network / nginx: निगरानी

यदि आपको रूट उपयोगकर्ता से नहीं सेवा शुरू करने की आवश्यकता है, तो यहां सब कुछ संभव है। बस जोड़ते हैं

  <method_context> <method_credential उपयोगकर्ता = 'munin' समूह = 'munin' /> </ method_context> 

उदाहरण या एक अलग विधि के विवरण में (यदि आपको किसी अन्य उपयोगकर्ता से केवल विधि चलाने की आवश्यकता है):

 # पीएस-एफए |  ग्रीप नगीनक्स
   मुनिन 6254 1 0 21:10:52?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx-munin.conf
   मुनिन 6255 6254 0 21:10:52?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx-munin.conf 
   जड़ 5884 1 0 19:42:25?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx.ff
   कोई नहीं 6015 5884 0 21:05:04?  0:00 / ऑप्ट / nginx / sbin / nginx -c /opt /nginx/etc/nginx.ff

इसी तरह के माध्यम से, आप व्यक्तिगत परियोजनाओं (परियोजनाओं - संसाधन सीमा) में सेवाएं चला सकते हैं। और अगर आप भी केवल सेवाओं को प्रबंधित करने में सक्षम होना चाहते हैं, तो एसएमएफ सोलारिस आरबीएसी के साथ एकीकृत करता है!
उपयोगकर्ता को "एप्लिकेशन" / "फ्रेमवर्क" समूहों में किसी भी तरीके, निर्भरता, मापदंडों को बदलने और विशिष्ट समूहों की अनुमति के लिए दोनों वैश्विक भूमिकाओं को सौंपा जा सकता है। प्रत्येक समूह के लिए, आप विशेष गुण (संपत्ति मान) संशोधित कर सकते हैं_ऑपरेशन, value_authorization, action_authorization, जिसमें ऑपरेशन के लिए आवश्यक "प्राधिकरण" लिखना है।

• action_authorization - मैं उदाहरण के "सामान्य" समूह में केवल उपयोग से मिला हूं। सक्षम विशेषता समूह में संग्रहीत है और यह "प्राधिकरण" आपको प्रकट होने के लिए कोई भी डेटा लिखे बिना सेवा के साथ कार्य करने की अनुमति देता है। उदा। ताज़ा, पुनः आरंभ, सेट / स्पष्ट रखरखाव
• value_authorization - आपको समूह में विशेषता मान बदलने की अनुमति देता है, लेकिन विशेषताओं को जोड़ / हटा नहीं सकता है। यदि आप इस प्राधिकरण को सामान्य समूह में जोड़ते हैं, तो यह उपयोगकर्ता को सक्षम विशेषता को बदलने की अनुमति देगा, इसलिए वह सक्षम / अक्षम सेवा करने में सक्षम होगा। यदि आप इस प्राधिकरण को समूह में जोड़ते हैं, कहते हैं, nginx, तो यह उपयोगकर्ता को कॉन्फ़िगरेशन फ़ाइल का पथ बदलने की अनुमति देगा
• संशोधित_अधिकरण - आपको एक समूह में विशेषताओं को संशोधित करने, जोड़ने और हटाने की अनुमति देता है।
  एक उदाहरण के लिए मैं सेवा प्रबंधन के लिए प्राधिकरण के एक्शन / मूल्य का उपयोग दिखाऊंगा

पहले हम उपयोगकर्ता को किसी प्रकार का "प्राधिकरण" जोड़ते हैं, मैं एक छोटी लाइन ले लूंगा, लेकिन एक समझौता है जिसके द्वारा प्राधिकरण को सार्थक रूप से कहा जाना चाहिए (उदाहरण के लिए, Solaris.smf.manage.nginx / निगरानी)। (/ / / सुरक्षा / सुरक्षा_ऑटर में पूर्वनिर्धारित प्राधिकरणों की संख्या भी है, लेकिन RBAC एक अलग बड़े लेख का विषय है):

 # इको ​​"सोलारिस.मुनिन ::: मुनिन ओन्ट्रीजेशन ::" >> / आदि / सुरक्षा / ओडिट_आट्र
 # usermod -एक Solaris.munin मुनिन

अब तक, हमने किसी भी तरह से सेवा को कॉन्फ़िगर नहीं किया है और उपयोगकर्ता कुछ भी नहीं कर सकता है:

 munin @ sol2 $ / usr / sbin / svcadm पुनरारंभ nginx: निगरानी
 svcadm: svc: / network / nginx: निगरानी: अनुमति से इनकार किया।
 munin @ sol2 $ / usr / sbin / svcadm को nginx अक्षम करना: निगरानी करना
 svcadm: svc: / network / nginx: निगरानी: अनुमति से इनकार किया।

"प्राधिकरण" Solaris.munin के लिए सेवा को पुनरारंभ करने की क्षमता जोड़ें:

 # svccfg -s nginx: मॉनिटरिंग सेटप्रॉप सामान्य / क्रिया_अधिकरण = कसैला: Solaris.munin
 # svcadm रिफ्रेश नग्नेक्स: मॉनिटरिंग

(प्रकट में किसी भी परिवर्तन के बाद, आपको एक ताज़ा सेवा करनी चाहिए ताकि SMF वर्तमान सेवा के लिए कॉन्फ़िगरेशन को फिर से पढ़ें)

हम जाँच करते हैं:

 munin @ sol2 $ / usr / sbin / svcadm -v पुनरारंभ nginx: निगरानी
 Svc: / network / nginx: मॉनिटरिंग के लिए सेट किया गया एक्शन रीस्टार्ट।
 munin @ sol2 $ / usr / sbin / svcadm -v अक्षम nginx: निगरानी
 svcadm: svc: / network / nginx: निगरानी: "सामान्य" संपत्ति समूह (अनुमति अस्वीकृत) को संशोधित नहीं कर सका।

यह स्पष्ट है कि उपयोगकर्ता सेवा को फिर से शुरू कर सकता है, लेकिन वह एसएमएफ डेटाबेस में संपत्ति को बदल नहीं सकता है। यह दृष्टिकोण उपयोगकर्ता को कॉन्फ़िगरेशन फ़ाइल बदलते समय "अपनी" सेवाओं को फिर से लोड करने की अनुमति देता है। यदि उपयोगकर्ता को सेवा को स्थायी रूप से बंद करने का अवसर दिया जाना है, तो हम उसे "सामान्य" संपत्ति समूह को संशोधित करने का अवसर देंगे:

 # svccfg -s nginx: मॉनिटरिंग सेटप्रॉप जनरल / वैल्यू_ऑथराइजेशन = एस्ट्रिंग: सोलारिस.मूनिन
 # svcadm रिफ्रेश नग्नेक्स: मॉनिटरिंग

हम जाँच करते हैं:

 munin @ sol2 $ / usr / sbin / svcadm -v अक्षम nginx: निगरानी
 svc: / network / nginx: निगरानी अक्षम।
 munin @ sol2 $ / usr / sbin / svcadm -v सक्षम nginx: निगरानी
 svc: / network / nginx: निगरानी सक्षम।

उपरोक्त तकनीकों का उपयोग करके, आप उपयोगकर्ताओं के लिए सुविधाजनक प्रणाली बना सकते हैं, जबकि लचीले ढंग से उनके अधिकारों का परिसीमन कर सकते हैं।

मुझे उम्मीद है कि यह लेख किसी को एसएमएफ, आरबीएसी और सोलारिस की गहरी समझ को प्रोत्साहित करने में मदद करेगा।