Cfengine3 - a little about policy hub

In the last article, I briefly talked about the excellent configuration management system cfengine3. Today we will look at it in more detail regarding client-server configuration and more fine-tuning of clients depending on the intended functionality.



Install the cfengine3 package, as in the last note, both on the client and on the policy server (policy hub). Consider the following client-server cfengine3 configuration. Put: policyhub01 198.51.100.10, srv01.local 203.0.113.101. We initialize ourselves as a policy hub (198.51.100.10 our own IP). The policy hub is precisely that place which serves as a centralized repository of our policies, which will later be downloaded from it by clients. Almost all configuration management systems use pull rather than push; there are many reasons for this, consideration of which will take no less than the volume of this note.
root @ 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 

Now go to the client:
root @ 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   . 

Does not work! By default, cfengine3 only trusts hosts from its / 16, and we have a server and a client on different networks. In addition, this is too wide a range and should be immediately limited in the files /var/cfengine/inputs/def.cf and /var/cfengine/inputs/controls/cf_serverd.cf .
Fixing /var/cfengine/inputs/def.cf file on plicyhub01

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

It would be possible (and ideologically more correct?) To make the key exchange different
way, do not you do a 'trust' over IP. Perform on srv01 again: root @ 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 

Success! Now it's time to write a few policies on the side of policyhub01 and make sure that everything works.
On policyhub01 in / var / cfengine / masterfiles we create files
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"); } 

and 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!"); } 

It is important to copy these files also into the inputs: root @ policyhub01: / var / cfengine / masterfiles # cp config_web_srv.cf install_base_pkg.cf ../inputs/ . Now it is time to say which of the hosts must comply with these policies. In the /var/cfengine/masterfiles/promises.cf file , we find the body control inputs and add our files there:

 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", }; 

Further, in the same file we create our bundle:

 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"; } 

And add it to the bundlesequence:

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

Save and wait about 5 minutes. We check and make sure that the packages from install_base_pkg and config_web_srv are installed. Let's look at what happened. The client, as it should be, downloaded the files from the masterfiles of our hub policy into inputs. Further, cf-agen on the side of srv01 starts to process them, having pre-established hard classes:

 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 } 

The list of hard classes on this host can be obtained by running cf-agent -v . Above, we told the bundlesequence to enable our bundle 'config'. First of all, we install soft classes depending on the hard classes available. In the case of our srv01, the soft class web_srv will be set, because there will be a coincidence in the class of the domain name. Accordingly, when the methods section is processed, the classes will be compared and the required bundle will be called. The install_base_pkg bundle will work for all hosts, since the hard class any is always installed. For web servers, both install_base_pkg and config_web_srv will work, which will install the nginx package and periodically make sure that it is running. This is exactly what the class nginx of the proccess type is doing, which will install the soft class "start_nginx" if there is no such process, which, accordingly, will lead to the execution of the "/etc/init.d/nginx restart" command. You may intentionally or accidentally stop nginx, but cfengine will still launch it after a while!

That's all, I hope this article clarified to some extent the question of "solo" and "client-server" configuration. As always, the official site, and in particular, ready-made solutions will always come to the rescue!