🧣 🍓 🉑 पपेट के माध्यम से WMI अनुमतियों को प्रबंधित करें ♂️ 🤱🏼 👩🏿‍🌾

एक प्रस्तावना के रूप में

मेरे काम का मुख्य उद्देश्य लोहे और वीएम मेजबानों के बेड़े का समर्थन करना है - पहले से ही 200 से कम (और यह 100 से कम था, ओह, समय चल रहा था ...) मैं सभी हार्डवेयर, साथ ही साथ नेटवर्क का समर्थन करता हूं। मेरे पास सभी मॉनीटरिंग भी है (हम ऑप्सव्यू का उपयोग करते हैं - नगिओस कोर पर बनाया गया), लॉग्स का एकत्रीकरण (मैंने लॉगस्टैश को लागू किया, एक जगह soooooo महंगा स्पंक के लिए भयानक ओपनसोर्स समाधान), कॉन्फ़िगरेशन प्रबंधन (कठपुतली), बैकअप, डेटाबेस समर्थन और अन्य सिस्टम भी मुझ पर हैं (MongoDB, MySQL, Redis, ElasticSearch, आदि)। सामान्य तौर पर - सभी सबसे दिलचस्प)। यह ध्यान देने योग्य है कि हमारे पास समर्थन और विकास के बीच एक पतली रेखा है, और डेवलपर्स अक्सर कहते हैं कि वे क्या चाहते हैं, और मैं पहले से ही इसे लागू कर रहा हूं। मैं आपको उन सभी चीजों के बारे में बताना चाहता हूं जो दिलचस्प होती हैं और क्या प्रौद्योगिकियों का उपयोग किया जा सकता है। जो मूल लिया, और जो किसी कारण से नहीं।

समस्याओं को हल करने से अपने खाली समय में, मैं बुनियादी ढांचे को इन्फ्रास्ट्रक्चर-ए-कोड (IaaC) में स्थानांतरित करता हूं, हमने अपने बुनियादी ढांचे की विविधता के कारण इसके लिए कठपुतली को चुना। मेरे नेटवर्क पर, चिड़ियाघर विंडोज सर्वर 2008, विंडोज सर्वर 2012, सेंटोस 5.5, सेंटोस 6.4 से है। अरे हाँ, 2003 के लिए दादाजी के एक जोड़े - उन्हें जल्द ही रिटायर करने के लिए भेजने का समय है ...

मैंने पहले ही लिखा था कि मैं ऑप्सवे में निगरानी को स्वचालित रूप से कॉन्फ़िगर करने के लिए कठपुतली का उपयोग कैसे करता हूं, और आज मैं इस बारे में बात करना चाहता हूं कि मैंने अपने पर्यावरण की विषमता के साथ एक बार फिर "लड़ाई" कैसे की।

कार्य

विंडोज 2008/2012 सर्वरों पर WMI कॉन्फ़िगरेशन को स्वचालित करने की आवश्यकता थी। स्थानीय सर्वर समूहों के लिए एक सेवा उपयोगकर्ता को जोड़ने की आवश्यकता थी (इसे "डोमेन \ _ सेवा-उपयोगकर्ता" कहते हैं) जो WMI के दूरस्थ उपयोग की अनुमति देता है, साथ ही प्रदर्शनकर्ता, प्रदर्शन लॉग्स, प्रदर्शन लॉग्स तक पहुंच की अनुमति देता है। सामान्य तौर पर, सर्वर को दूरस्थ रूप से मॉनिटर करने के लिए आपको हर चीज की आवश्यकता होती है। स्वयं समूहों ने जल्दी से पर्याप्त निर्णय लिया, यह ऐसा करने के लिए एक सुविधाजनक और त्वरित तरीका खोजने के लिए बना रहा। रूट WMS नामस्थानों के लिए उपयोगकर्ता डोमेन \ सेवा-उपयोगकर्ता पहुँच प्रदान करना भी आवश्यक था। इसके अलावा, यह सब IaaC की सामान्य अवधारणा का हिस्सा होना चाहिए, जिसका अर्थ कम से कम वर्तमान स्थिति की जांच करना चाहिए, और निष्पादन को छोड़ देना चाहिए यदि उपयोगकर्ता को पहले ही जोड़ा गया है जहां समूहों में उपयोगकर्ता की उपस्थिति-अनुपस्थिति के किसी भी संस्करण में आवश्यक है। यानी समाधान यथासंभव स्वचालित होना चाहिए, या पूरी तरह से। थोड़ा गुगली करने के बाद, यह स्पष्ट हो गया कि मेरे मामले के लिए क्या आवश्यक है, लेकिन मुझे यह करना था:

स्थानीय समूहों (कम से कम) के लिए डोमेन उपयोगकर्ता डोमेन \ सेवा-उपयोगकर्ता जोड़ें:
- सर्टिफिकेट सर्विस DCOM एक्सेस
- प्रदर्शन लॉग उपयोगकर्ता
- प्रदर्शन मॉनिटर उपयोगकर्ता
- वितरित COM उपयोगकर्ता।
निम्न WMI नामस्थानों के लिए डोमेन \ सेवा-उपयोगकर्ता के लिए कम से कम "रीड" एक्सेस अधिकारों को सेट करें:
- CIMV2
- MicrosoftIISv2।
एक बार सब कुछ स्थापित हो जाने के बाद, check_wmi_plus (मानक ऑप्सव्यू प्रो पैकेज में शामिल) IIS और अन्य दिलचस्प मापदंडों (जो हमें चाहिए) के बारे में आवश्यक डेटा प्राप्त करने में सक्षम होगा!

जटिलता

मुख्य कठिनाई जो उत्पन्न हुई - चलाने के लिए कोई तैयार समाधान नहीं है और सुनिश्चित करें कि "सर्वर निगरानी के लिए उपलब्ध होगा"। सामान्य तौर पर, मैं बहुत परेशान नहीं हूं, क्योंकि बहुत कम ही मेरे कार्यों के लिए तैयार समाधान होते हैं, और यदि वे होते हैं, तो वे अक्सर कुछ गलत या गलत करते हैं।

कठपुतली में एक अंतर्निहित संसाधन "उपयोगकर्ता" है, जो, सिद्धांत रूप में, सभी कार्यों में से आधे को पूरा करना चाहिए था, "डोमेन उपयोगकर्ता - स्थानीय समूह" कनेक्शन में काम नहीं किया। जैसा कि यह पता चला है, यह एक ज्ञात बग है और वे इसे ठीक करने जा रहे हैं ( यूपीडी: उन्होंने पहले ही इसे 3.4 रिलीज में तय कर दिया है ), लेकिन वे लगातार अगली रिलीज के लिए कठपुतली को हटा रहे हैं। कठपुतली डीएसएल में एक वर्कअराउंड चलाने का प्रयास एक अत्यधिक जटिल संरचना के कारण असफल रहा, जिसके लिए जटिल भागने के दृश्यों की आवश्यकता होती है जो हमेशा काम नहीं करते हैं।

एक और जटिलता - खिड़कियों में कोई भी अंतर्निहित सार्वभौमिक तरीका नहीं है जो कि wmi वर्गों तक पहुंच अधिकारों का प्रबंधन करता है, जो कठपुतली में "लिपटे" हो सकता है, यदि केवल रजिस्ट्री को उठाकर और पहिया को फिर से मजबूत करना।

कार्यान्वयन

नतीजतन, मैंने अपने प्रदाता को लिखने का फैसला किया और इसका उपयोग तब तक किया जब तक कि मूल प्रदाता को सर्वर पर एक स्थानीय समूह में एक डोमेन उपयोगकर्ता जोड़ने के लिए मरम्मत नहीं की गई। और मैंने इसे किया ... शक्तियाँ कोडिंग कोडिंग!

win_user.rb

Puppet::Type.type(:win_user).provide(:win_user) do @doc = %q{Manage windows users and groups} desc "Manage windows users and groups" confine :operatingsystem => :windows defaultfor :operatingsystem => :windows commands :powershell => if File.exists?("#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe") "#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe" elsif File.exists?("#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe") "#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe" else 'powershell.exe' end def add_user_to_group # end def exists? #add transform to array if just a string groups = resource[:groups] if groups.kind_of?(String) groups.to_a end found = false groups.to_a.each do |group| Puppet.debug("Checking the existence of value: #{self} in #{group}") result = powershell 'if (([ADSI]"WinNT://$env:computername/'+group+'").IsMember(([ADSI]"WinNT://$env:userdomain/'+ resource[:name]+'").ADsPath) -eq $False){echo 0} else {echo 1}' if result.chomp == "0" #if not found (ps returned false on search of user in group) Puppet.debug("User '#{resource[:name]}' is not found in group '#{group}'") found = false # break else Puppet.debug("User '#{resource[:name]}' is found in a group '#{group}'") found = true end end found end def create groups = resource[:groups] if groups.kind_of?(String) groups.to_a end groups.to_a.each do |group| Puppet.debug("Adding user to a group #{self}") powershell 'if (([ADSI]"WinNT://$env:computername/'+group+'").IsMember(([ADSI]"WinNT://$env:userdomain/'+ resource[:name]+'").ADsPath) -eq $False){$([ADSI]"WinNT://$env:computername/'+group+'").Add(([ADSI]"WinNT://$env:userdomain/'+resource[:name]+'").ADsPath)} else {echo "User is already in a group"}' end end def destroy end end

WMI मापदंडों को कॉन्फ़िगर करने के लिए, मुझे तीसरे पक्ष के ओपनसोर्स wmisecurity.exe उपयोगिता का उपयोग करना पड़ा। इसे स्थापित करने के लिए, मैंने chocoaltey.org - wmisecurity पर एक पैकेज बनाया। पैकेज को स्थापित करने के लिए, मैंने चॉकलेट पपेट प्रदाता का उपयोग किया, जिसका मैं लगातार उपयोग करता हूं।

और यहाँ कठपुतली स्वयं प्रकट होती है, जो पहले लिखे गए मॉड्यूल का उपयोग करती है, और इसमें उपयोगकर्ता के लिए wmi कक्षाओं में एक्सेस अधिकार जोड़ने के लिए पॉवरशेल हुक भी होते हैं (हो सकता है कि मैं इसे बाद में एक अलग मॉड्यूल के रूप में फिर से लिखूँ):

wmi.pp

 class packages::wmi { $wmiuser = 'service-user' ###Doesn't work on windows right now #user { $wmiuser: # groups => ['Certificate Service DCOM Access','Performance Log Users','Performance Monitor Users', 'Distributed COM Users'], # } win_user { $wmiuser: groups => ['Certificate Service DCOM Access','Performance Log Users','Performance Monitor Users', 'Distributed COM Users'], ensure => present_local, } ###it is required to add user to those local groups in order monitoring to perform correctly. exec {"add-to-wmi-cimv2": command => "wmisecurity.exe /C=\$env:computername /A /N=Root/CIMV2 /M=\$env:userdomain\\$wmiuser:REMOTEACCESS /R", path => $::path, #if found user guid - skip onlyif => "if (WmiSecurity.exe /c=\$env:computername /N=Root/CIMV2 /R | Select-String $($(New-Object System.Security.Principal.NTAccount( \"\$env:userdomain\", '$wmiuser')).Translate([System.Security.Principal.SecurityIdentifier]).Value)){exit 1} else {exit 0}", provider => powershell, require => Package['wmisecurity'], } exec {"add-to-wmi-microsoftiisv2": command => "wmisecurity.exe /C=\$env:computername /A /N=Root/MicrosoftIISv2 /M=\$env:userdomain\\$wmiuser:REMOTEACCESS /R", path => $::path, #if found user guid - skip onlyif => "if (WmiSecurity.exe /c=\$env:computername /N=Root/MicrosoftIISv2 /R | Select-String $($(New-Object System.Security.Principal.NTAccount( \"\$env:userdomain\", '$wmiuser')).Translate([System.Security.Principal.SecurityIdentifier]).Value)){exit 1} else {exit 0}", provider => powershell, require => Package['wmisecurity'], } package {'wmisecurity': provider => 'chocolatey', install_options => '-pre', require => Class["packages::chocolatey"] } }

निष्कर्ष

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

wmi.pp

 class packages::wmi { $wmiuser = "${env:userdomain}\\service-user" user { $wmiuser: groups => ['Certificate Service DCOM Access','Performance Log Users','Performance Monitor Users', 'Distributed COM Users'], ensure => present, } wmi_security_user { $wmiuser: namespaces => ['Root/CIMV2','Root/MicrosoftIISv2'], ensure => present, } }

अब, एक नया सर्वर स्थापित करते समय, यह मेरे लिए पैकेज :: wmi वर्ग को इस सर्वर (मैन्युअल रूप से या शामिल) को असाइन करने के लिए बना रहता है और यही है, कठपुतली अपना काम करेगी। व्यक्तिगत रूप से, मैं अक्सर इस वर्ग का उपयोग ऑप्सव्यू क्लास के माध्यम से करता हूं, जो स्वचालित रूप से ऑप्सव में निगरानी के लिए एक मेजबान बनाता है और आवश्यक टेम्पलेट असाइन करता है, अर्थात। यदि यह है, तो, IIS, के साथ एक सर्वर, अंतिम कठपुतली वर्ग opsview को सभी आवश्यक जानकारी बताएगा कि यह IIS के साथ एक मेजबान है, इस तरह के और ऐसे होस्ट के साथ जिन्हें एक निश्चित तरीके से निगरानी करने की आवश्यकता है, साथ ही opsview के लिए एक मॉनिटरिंग टेम्पलेट असाइन करना होगा wmi के माध्यम से, जो कि ऊपर वर्णित वर्ग पर निर्भर करता है। इसलिए, जैसे मैंने कुछ भी याद नहीं किया।

परिणाम के स्क्रीनशॉट की एक जोड़ी:

पपेट के माध्यम से WMI अनुमतियों को प्रबंधित करें

एक प्रस्तावना के रूप में

कार्य

जटिलता

कार्यान्वयन

निष्कर्ष

More articles: