Cfengine3 - पॉलिसी हब के बारे में थोड़ा

पिछली पोस्ट में, मैंने संक्षेप में अद्भुत cfengine3 विन्यास प्रबंधन प्रणाली के बारे में बात की थी। आज हम इसे ग्राहक-सर्वर सेटिंग्स और अधिक ठीक-ट्यूनिंग क्लाइंट के बारे में थोड़ा और विस्तार से देखना चाहते हैं।



ग्राहक और पॉलिसी सर्वर (पॉलिसी हब) दोनों पर, पिछले नोट की तरह, cigerine3 पैकेज स्थापित करें। निम्नलिखित क्लाइंट-सर्वर cfengine3 कॉन्फ़िगरेशन पर विचार करें। पुट: नीतिभुब 198.51.100.10, srv01.local 203.0.113.101। हम खुद को एक पॉलिसी हब (198.51.100.10 हमारे अपने आईपी) के रूप में शुरू करते हैं। पॉलिसी हब ठीक वह जगह है जो हमारी नीतियों के केंद्रीकृत भंडार के रूप में कार्य करता है, जिसे बाद में ग्राहकों द्वारा डाउनलोड किया जाएगा। लगभग सभी कॉन्फ़िगरेशन प्रबंधन सिस्टम पुश के बजाय पुल का उपयोग करते हैं, ऐसे कई कारण हैं जिनके लिए विचार इस नोट की मात्रा से कम नहीं होगा।
रूट @ policyhub01: / tmp # / var / cfengine / bin / cf-agent --bootstrap --policy-server = 198.51.100.10

** CFEngine BOOTSTRAP probe initiated @@@ @@@ CFEngine @ @@@ @ CFEngine Core 3.4.1 @ @@@ @ @ @@@ @ @ @ @@@ @ @ @ @ @ @ Copyright (C) CFEngine AS 2008-2012 See Licensing at http://cfengine.com/3rdpartylicenses -> This host is: policyhub01.local -> Operating System Type is linux -> Operating System Release is 3.6.10-vs2.3.4.6 -> Architecture = x86_64 -> Internal soft-class is linux -> No policy failsafe discovered, assume temporary bootstrap vector -> No previous policy has been cached on this host -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles -> Attempting to initiate promised autonomous services... ** This host recognizes itself as a CFEngine Policy Hub, with policy distribution and knowledge base. -> The system is now converging. Full initialisation and self-analysis could take up to 30 minutes R: This host assumes the role of policy distribution host R: -> Updated local policy from policy server R: -> Started the server R: -> Started the scheduler -> Bootstrap to 198.51.100.10 completed successfully 

अब ग्राहक के पास जाएं:
रूट @ srv01: / tmp # / var / cfengine / bin / cf-agent --bootstrap --policy-server = 198.51.100.10

 -> No policy failsafe discovered, assume temporary bootstrap vector -> No previous policy has been cached on this host -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles -> Attempting to initiate promised autonomous services... Challenge response from server 198.51.100.10/198.51.100.10 was incorrect! !! Authentication dialogue with 198.51.100.10 failed R: This autonomous node assumes the role of voluntary client R: !! Failed to pull policy from policy server R: !! Did not start the scheduler !! Bootstrapping failed, no input file at /var/cfengine/inputs/promises.cf after bootstrap   . 

काम नहीं करता है! डिफ़ॉल्ट रूप से, cfengine3 केवल अपने / 16 से मेजबान पर भरोसा करता है, और हमारे पास विभिन्न नेटवर्क पर एक सर्वर और क्लाइंट है। इसके अलावा, यह बहुत विस्तृत है और इसे तुरंत /var/cfengine/inputs/def.cf और /var/cfengine/inputs/controls/cf_serverd.cf फ़ाइलों में सीमित होना चाहिए।
हम plicyhub01 पर फ़ाइल /var/cfengine/inputs/def.cf को ठीक करते हैं

  "acl" slist => { "$(sys.policy_hub)", "203.0.113.101/32", }, 

(और वैचारिक रूप से अधिक सही ढंग से?) कुंजी विनिमय को अलग कर सकता है
वैसे, क्या आईपी द्वारा 'ट्रस्ट' करना संभव है। Srv01 पर फिर से चलाएँ: रूट @ srv01: / tmp # / var / cfengine / bin / cf-agent --bootstrap --policy-server = 198.51.100.10

 ** CFEngine BOOTSTRAP probe initiated @@@ @@@ CFEngine @ @@@ @ CFEngine Core 3.4.1 @ @@@ @ @ @@@ @ @ @ @@@ @ @ @ @ @ @ Copyright (C) CFEngine AS 2008-2012 See Licensing at http://cfengine.com/3rdpartylicenses -> This host is: srv01.local -> Operating System Type is linux -> Operating System Release is 3.6.10-vs2.3.4.6 -> Architecture = x86_64 -> Internal soft-class is linux -> An existing policy was cached on this host in /var/cfengine/inputs -> Assuming the policy distribution point at: 198.51.100.10:/var/cfengine/masterfiles -> Attempting to initiate promised autonomous services... R: This autonomous node assumes the role of voluntary client -> Bootstrap to 198.51.100.10 completed successfully 

सफलता! अब पॉलिसीबब 01 की ओर कुछ नीतियों को लिखने और यह सुनिश्चित करने का समय है कि सब कुछ काम करता है।
Policyhub01 में / var / cfengine / Masterfiles पर हम फाइलें बनाते हैं
config_web_srv.cf:

 bundle agent config_web_srv { vars: "package_list" slist => { "nginx" }; packages: "${package_list}" package_policy => "add", package_method => generic; processes: "nginx" restart_class => "start_nginx"; commands: "/etc/init.d/nginx restart" ifvarclass => canonify("start_nginx"); } 

और install_base_pkg.cf:

 bundle agent install_base_pkg { vars: "package_list" slist => { "vim", "mc" }; packages: "${package_list}" package_policy => "add", package_method => generic; files: linux:: "/etc/motd" edit_line => insert_lines("This host is managed by cfengine3!"); } 

इन फाइलों को इनपुट में भी कॉपी करना महत्वपूर्ण है: root @ policyhub01: / var / cfengine / masterfiles # cp config_web_srv.cf install_base_pkg.cf ../inputs/ । अब यह कहने का समय है कि मेजबानों में से किसको इन नीतियों को लागू करना चाहिए। फ़ाइल /var/cfengine/masterfiles/promises.cf में हम बॉडी कंट्रोल इनपुट्स पाते हैं और वहां अपनी फाइल्स जोड़ते हैं:

 inputs => { # Global common bundles "def.cf", # Control body for all agents "controls/cf_agent.cf", "controls/cf_execd.cf", "controls/cf_monitord.cf", "controls/cf_report.cf", "controls/cf_runagent.cf", "controls/cf_serverd.cf", # COPBL/Custom libraries "libraries/cfengine_stdlib.cf", # Design Center # MARKER FOR CF-SKETCH INPUT INSERTION "cf-sketch-runfile.cf", # User services from here "services/init_msg.cf", # our policies "config_web_srv.cf", "install_base_pkg.cf", }; 

अगला, उसी फ़ाइल में, हमारी बंडल बनाएं:

 bundle agent config { classes: "web_srv" or => { classmatch("web.*"), "srv01_local", "web3_example_com" }; methods: web_srv:: "config_web_srv" usebundle => "config_web_srv"; any:: "install_everywhere" usebundle => "install_base_pkg"; reports: cfengine_3:: "bundle agent config DONE"; } 

और इसे bundlesequence में जोड़ें:

  bundlesequence => { # Common bundles first for best practice "def", # Design Center "cfsketch_run", # Agent buddles from here "main", # Our ccustomisation "config", }; 

हम बचाते हैं और लगभग 5 मिनट प्रतीक्षा करते हैं। हम जाँचते हैं और सुनिश्चित करते हैं कि install_base_pkg और config_web_srv से संकुल संस्थापित हैं। आइए जानें कि क्या हुआ। ग्राहक, जैसा कि अपेक्षित था, हमारी हब नीति के मास्टरफाइल्स से इनपुट्स में डाउनलोड की गई फाइलें। अगले, cf-agen srv01 पक्ष पर उन्हें संसाधित करना शुरू कर देता है, कठिन कक्षाएं लगाने के बाद:

 Hard classes = { 203_0_113_101 2_cpus 64_bit Afternoon Day6 GMT_Hr17 Hr17 Hr17_Q2 January Lcycle_0 Min20_25 Min21 PK_MD5_877dfa1640c3c49a2065ce220a3b821f Q2 Sunday Yr2013 agent any cfengine cfengine_3 cfengine_3_4 cfengine_3_4_1 cfengine_in_high community_edition compiled_on_linux_gnu cpu0_normal cpu1_normal cpu_normal debian debian_7 debian_7_0 diskfree_high_normal entropy_misc_in_low entropy_misc_out_low entropy_postgresql_in_low entropy_postgresql_out_low have_aptitude ipv4_203 ipv4_203_0 ipv4_203_0_113 ipv4_203_0_113_101 linux linux_3_6_10_vs2_3_4_6 linux_x86_64 linux_x86_64_3_6_10_vs2_3_4_6 linux_x86_64_3_6_10_vs2_3_4_6__1_SMP_Mon_Dec_17_03_23_11_UTC_2012 local mac_00_25_64_3b_97_cb messages_high_ldt messages_high_normal net_iface_br0 opt_dry_run otherprocs_low rootprocs_high rootprocs_high_ldt srv01 srv01_local syslog_high_ldt syslog_high_normal users_low verbose_mode www_in_low x86_64 } 

इस होस्ट पर हार्ड कक्षाओं की सूची cf-Agent -v चलाकर प्राप्त की जा सकती है। ऊपर, हमने अपने बंडल 'कॉन्फिग' को शामिल करने के लिए बंडललेक्वेंस को बताया। सबसे पहले, हम उपलब्ध हार्ड कक्षाओं के आधार पर सॉफ्ट कक्षाएं स्थापित करते हैं। हमारे srv01 के मामले में, सॉफ्ट क्लास web_srv स्थापित किया जाएगा, क्योंकि डोमेन नाम के वर्ग के लिए एक मैच होगा। तदनुसार, जब विधि अनुभाग पूरा हो जाता है, तो कक्षाओं की तुलना हो जाएगी और वांछित बंडल को बुलाया जाएगा। Install_base_pkg बंडल सभी होस्ट के लिए काम करेगा, क्योंकि हार्ड क्लास कोई भी हमेशा सेट होता है। वेब सर्वरों के लिए, install_base_pkg और config_web_srv दोनों काम करेंगे, जो नेगनेक्स पैकेज को स्थापित करेगा और समय-समय पर यह सुनिश्चित करेगा कि यह चल रहा है। यह ठीक उसी प्रकार है जो प्रकार का न्युनक्स वर्ग करता है, जो सॉफ्ट क्लास "start_nginx" सेट करता है, अगर ऐसी कोई प्रक्रिया नहीं है, जो कि तदनुसार, कमांड / /etc/init.d/nxx रिस्टार्ट के निष्पादन को बढ़ावा देगा। आप जानबूझकर या दुर्घटनावश नग्नेक्स को रोक सकते हैं, लेकिन थोड़ी देर बाद भी cigerine इसे लॉन्च करेगा!

यह सब, मुझे उम्मीद है कि इस नोट ने "एकल" और "क्लाइंट-सर्वर" कॉन्फ़िगरेशन के मुद्दे पर कुछ हद तक स्पष्ट किया है। हमेशा की तरह, आधिकारिक साइट, और विशेष रूप से, टर्नकी समाधान हमेशा बचाव में आएंगे!