CFENGINE 3 BEGINNERS GUIDE PDF
CFENGINE 3 BEGINNERS GUIDE PDF - PDF DESIGN. Part of Packt's Beginner's Guide series, this book guides you through setting up. ZKYZDMFFDU6L «PDF «Cfengine 3 Beginners Guide. Cfengine 3 Beginners Guide. Filesize: MB. Reviews. It is really an incredible publication that we. This guide provides the first steps in understanding and writing your own. CFEngine policy files ing of CFEngine concepts before proceeding (see CFEngine 3 Concept Guide: . clear syntax you can also get a fair understanding by starting directly with these examples. The .. cittadelmonte.info • CFEngine 3 Beginning Examples.
|Language:||English, Spanish, Japanese|
|ePub File Size:||16.74 MB|
|PDF File Size:||14.38 MB|
|Distribution:||Free* [*Regsitration Required]|
CFEngine 3 Beginner's GuideA step-by-step guide to setting up CFEngine and fully automating the configuration and man. Cfengine 3 Beginners Guide is the first and only book dedicated to Cfengine. It dives deep into using the Read PDF ·». Early National City CA Images of. Ebook Pdf Cfengine 3 Beginners Guide Rajneesh contains important information and a detailed explanation about Ebook Pdf Cfengine 3 Beginners Guide.
No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published:
Let's see what we defined for the common control body: In the common control body we define a bundlesequence which defines the order in which the promise bundles would be executed.
If you want more files to be included you may specify with the "inputs" constraint. Here we specify four files, update. These included files that have additional promises which define the default actions for CFEngine. In the previous section we define three more control body promises, which are the agent control, monitor control, and the executor control bodies: Here, in the agent control body we defined the ifelapsed constraint.
By default, the value for this constraint is five minutes but there may be tasks which may run for more than five minutes and hence we set this value to 15 minutes. A monitor control body provides the details for the promises made, as you'll find in the file named cf-monitord.
Here, in the monitor control body there are two constraints defined: The forgetrate constraint defines how quickly CFEngine forgets its previous history and this is expressed as fraction weighting of new values over old values in two days, average computation.
The histogram constraint is used to enable or disable the creation of histograms by CFEngine. An executor control body describes the settings which define the behavior of cf-execd. Here, in the executor control body we define four constraints splaytime, mailto, smtpserver, and mailmaxlines: Here we specify the following reports: Finally, we also define the type of output for the reports as HTML.
In the runagent control body we provide the name or IP address of the hosts to which CFEngine attempts to connect. In the server control body we define the hosts which may connect to the CFEngine server port with the help of the allowconnects constraint.
In addition to this we also define a list of hosts which may have more than one connection to the CFEngine server port with the help of allowallconnects. Finally, we specify the hosts from which CFEngine may accept public keys on the basis of trust. Other than the promises. These files are: This file is used to add site-specific configuration.
We may define site specific bundles. Global variables may be defined under common bundles. This file should never change. The file defines the environment for CFEngine when it is updated.
We need to ensure that the update. In this file we may define various editbundles. It ensures that the CFEngine system has upgraded gracefully even when there are errors. The CFEngine system, if unable to read or parse the contents in any of the above files, will failover to this failsafe configuration. This is a standard library of definitions which can be used in building solutions with CFEngine. The library has standard tasks predefined, [ 16 ] Chapter 1 contributed by the CFEngine community, which may be used while automating tasks with CFEngine.
The library can be included as: Copy and paste the following text in the promises file, which may be named as portcheck. For this we use the new CFEngine program, cf-promises. Let's assume you copied the text in the file portcheck. Now let's run the above command to give us a verbose output.
System error for fopen: This has not been done because currently whatever we executing is being executed on the local machine and the keys are required for remote authentication. We'll need the keys when want to execute this same example on multiple servers. The last line is of interest as it says, all looks good. Now we have verified the file, let's execute this and see what the output we get is.
You may want to change the user with which you want to run this example. Active Internet connections only servers Q: The report is generated in a text or HTML format. What just happened? We defined a promise control type. Under this control promise we defined a bundlesequence, portcheck. Multiple bundles may be added in the order we want them to be executed, as comma-separated entries.
Next we defined the attributes for this bundle agent portcheck, which has a command promise defined that gets the list of open ports and the services associated with them. Under the same portcheck bundle agent promise we defined two classes, followup and alert. The class alert fires alerts on the number of promises repaired and how many failed to repair. The followup class is defined to just get the listing of files under the directory from which the command was executed.
Once we execute the promises file with cf-agent we may see that in the output we get the TCP ports open on the system, the status of the port, the service associated with the open port, and the corresponding PID of the service associated with the port. The above promises may be used to audit the services and the associated ports on a host.
One may use it to create a map of services running on a host or may also be used as an 'auto discovery' promise. Time for action — creating a file under your home directory 1. Paste the following text in a file named file-perms-test.
We'll use the most basic promises, to keep it simple: Let's verify the file: Now let's execute the previous example: We defined a bundlesequence under the common control body having a single bundle named checkperms. In the third step we defined the file which needs to be created and permissions which need to be set under the file's promise type. We defined that if the file does not exist then CFEngine needs to create it by setting the value of the create constraint to true, in case the file does not exist.
As the final step we defined the file permissions which we want the file to exit with. Pop quiz 1. Name the core theory on which CFEngine is based. Which file is read by cf-agent, by default, when run without an argument? Name three promise types we came across in this chapter. Which directory serves as the workspace for CFEngine, by default?
Paste the following lines in the promises file of your choice. Execute the previous code with cf-agent: Let's check whether the files were removed: We defined a common control promise. Summary Let's summarize what all we learnt in this chapter: We also saw how cfengine may be tested without being a super user. This may be used to run tests on your CFEngine installation before you go live. Significance of cf-promises, cf-agent, cf-report, cf-execd, cf-runagent, cf-key, cf-monitord, cf-know, and cf-serverd.
We also looked at how these commands may be used for verification, reporting, remote promise execution, and performing various CFEngine tasks. Available promise types like files, vars, commands, and others. Defining various promise types and their usage. How to write promise files. Verifying the promises using "cf-promises" and running our tasks with "cf-agent". Now that we have learned how to install CFEngine, write basic promises, verify them, and execute them on a standalone system, we are ready to move to the next chapter where we will configure systems using CFEngine.
In the previous chapter we saw how to write CFEngine promises; in this chapter we will see how to distribute those promises on multiple systems so that the remote systems may change their state as per the promises.
In this chapter we shall learn about: The promises need to be distributed to multiple systems so that the systems may change their state accordingly. Unlike conventional tools, CFEngine works on the principle of "voluntary cooperation". Rather than "pushing" the promises on remote systems CFEngine expects the remote systems to "pull" the changes from the CFEngine file server and execute the promises at their will. CFEngine, by design, cannot force its will onto other systems.
At best, it can trigger a signal to remote systems and ask them to collect the changed file, at their will. There are three basic components involved in CFEngine communication.
Cf-serverd is a daemon that acts as file server and also receives requests for execution of policy files on individual hosts. The execution of policy files is dependent on the access control restrictions described in the server control body and the server bundles.
This is a daemon which needs to run on the policy server and acts as a distribution point for the necessary configuration files required by the clients. The policy files should be maintained on a version control system accessible by all the hosts. The configuration engine's only contact with the network is through remote copy requests.
It does not and cannot grant any access to a system from the network. It is only able to request access to files from the server component. The mechanism works in such a way that the updated policy files from the policy distribution server are first transferred to the individual hosts as per the promises in failsafe.
The next diagram explains this "two stage" process. Cf-execd is a daemon which runs cf-agent at regular or user defined intervals. Use of cf-execd is the recommended way of running cf-agent instead of using cron to run cf-agent. The cf-execd daemon is affected by changes in common and executor control bodies. This is a simple initiation program that can be used to run cf-agent on a number of remote hosts.
It cannot be run to tell cf-agent what to do; it can only ask cf-serverd on the remote host to run cf-agent with its existing configuration. Privileges can be granted to users to provide a kind of Role Based Access Control to certain parts of existing policy.
CFENGINE 3 BEGINNERS GUIDE PDF
These three components are everything we need for effective distribution of resources for systems. Let's see how the three components work together in tandem to make CFEngine one of the best system automation tools available.
The following diagram shows policy decision flow: Now, to maintain consistency, the policies should first be committed to a version control system and the policy distribution servers should pull files from the version control system to distribute them to the remote hosts.
The preceding diagram shows a similar process. This will also help track changes to policy files. The number of Policy Distribution Servers may depend on the size of the infrastructure. If the remote servers are distributed geographically, it makes sense to have a "Policy Distribution Server" at each location, which serves the systems at that location.
All the remote systems connect to the Policy Distribution Servers and download the updates. In case they are not, it does not permit copying of a file to the remote server unless the denybadclocks is set to false in the server control body. Apart from verifying system clocks, CFEngine takes a step ahead and does not copy the updated file to its destination directly.
The new files are copied to the remote hosts in the following manner: CFEngine copies the new updated file from the remote Policy Distribution Server as a new file on the same file system as the destination file. The new file being copied has the suffix. This transfer of policy files from the Policy Distribution Server is done on the basis of promises in failsafe. When cf-agent is run it first executes failsafe. Once the file has been successfully copied to the destination file system cfagent makes a copy of the old file and renames the new file.
This is done on the basis of promises in promises. In the preceding description we again come across the the "two stage" process of copying files from the policy distribution server and executing the same.
CFEngine being a flexible framework, it allows merging the two stages so that both the stages may be handled by a single policy file promises. By default, this is a two stage process and each process is handled by a different policy file and this is how it should be set up.
This is strongly recommended so that a failure at stage 1 does not impact stage 2. As an additional precaution one should ensure that promises. This can be done with the help of the following entry in the cf-execd command statement or providing a file with this entry to the cf-execd command as an argument: The above two stages are executed so as to take care of interruptions in network connections and to avoid race conditions.
CFEngine also sets a timeout of a few seconds for network connections to prevent processes from hanging. One of the various advantages of using CFEngine is that no "root" or "administrator" privileges are needed for CFEngine on the local host.
We just need to start the daemon as "root". This helps CFEngine to scale as the changes need to be pushed only to the centralized policy server and the rest of the infrastructure is updated from there. Let's try to configure a policy server. Switch to root user on the policy server: Create a source repository for the policy files: For demonstration, we will copy a few sample policy files already available with the CFEngine installation: Now let's generate the public-private keys for the policy distribution server: Let's check that the keys were created using the following command: The CFEngine key exchange mechanism works similarly to how the key exchange mechanism of OpenSSH works, which means that it is a peer-to-peer key exchange mechanism rather than a central certificate authority model.
The public keys of the policy distribution server are cached by the clients so, if the keys of the policy distribution server are lost, you will have to generate the key again with cf-key and also purge the old cached key from the clients manually.
Therefore, the key for the policy distribution server should always be backed up. Now let's start CFEngine. To start CFEngine we need to run a cf-serverd daemon. The cf-serverd daemon reads the promises. Let's see a promises. Shown next is an access control bundle defined in site. Let's start the CFEngine server daemon with the command cf-serverd and see what happens. DHCP whose bindings could vary over time: Let's see what happened when we started the cf-serverd daemon.
Once that it is done it sets the default port to Next, it verifies the syntax of the base [ 34 ] Chapter 2 configuration files. It sets the IP addresses or host names of the hosts that are allowed to connect to the server, which are allowed to make multiple connections to the server and keys from which hosts should be trusted. It also sets the name of the users that are allowed to connect. The CFEngine policy distribution server is now ready to serve configuration files to the clients.
We now have a CFEngine server that can be used to distribute policy files to other hosts. Let's assume we have m number of systems with host name my n. I have deliberately kept the host name for the the central policy repository server as my1. One can check the server and key mappings as follows: This is done by granting access to the client in the server control body and with access rules.
Here is a sample configuration from promises. The host names and IP addresses for the hosts that you trust may be specified as follows: The username with which the clients connect to the CFEngine server port should be mentioned inside the server bundle as follows: This is defined in the server bundle within the configuration file site.
Here is a configuration snippet from site. We will also see in this example which configuration files play a part when the communication starts and completes. Time for action — taking file backups 1. Let's first check the output of cf-serverd on the policy distribution server.
You may also start the cf-serverd daemon with an alternate configuration file cf-serverd. Shown next is the configuration that you could use for the same: Let's see the server control body from promises.
Now let's execute the cf-agent on the client: Final verification of transmission For this you would add the below lines to your access-rules server bundle in the configuration file site. Now if we observe the execution of failsafe.
After the host has the updated configuration files, on running cf-agent on It was created upon execution of the configuration files, and all the files and directories from the remote hosts were copied into it.
Now that we are more familiar with how CFEngine network services, key exchange, and file copy works, let's go ahead and use this knowledge to automate a few important tasks. In this next step, let's see how CFEngine can help us in configuring new systems. Once you have a system with a fresh OS and CFEngine installed, using Kickstart, there are a number of tasks that should be completed for the system to be ready to host applications and run in a production environment.
A few of the common tasks are: Configuring users and groups Once a fresh system is delivered, we will need to configure a number of users for the development team, DBA team or other teams who may need to work on it. We can have different groups for each team and add a user under this group for each member of the team or add users as per the organization's policy.
It is always good to have a centralized user, group, and access database such as an LDAP server or Active Directory; but there may be scenarios where user authentication happens on the individual hosts. The next example explains how you can add a user on the individual hosts. Time for action — user and group configuration 1. Let's write a configuration file for adding a user and group on a client. We'll also change a few default values for this user such as his password, age, and so on. The user to be added is, say, Clark with complete name as Clark Kent, password as superman.
This password expires after 60 days and the user starts getting a warning that the password is about to expire five days prior to the date of expiry. The following lines should be copied to a configuration file named addusergroup. We can test this promise as follows: Now we need to copy this file from the centralized policy server to all the other hosts. Let's run cf-agent which first copies the changes from the policy server to itself and then executes the promises as per the conditions set in its own configuration.
The outputs are as follows: We can see from the output that cf-agent when run with the configuration file failsafe. Now, as the files have been copied, let's check whether the user exists: Now let's execute the configuration file and verify that the user has been created: Creating mailbox file: Not copying any file from skel directory into it. Let's see the details of the user here: Minimum number of days between password change: Now let's execute the configuration file addusergroup.
We defined common control body. Under the common control body we defined a bundle sequence for the bundle agent addusergroup. We also set a classes promise defining how that class change is satisfied. Only if this class is set will the promises be executed. When we executed the configuration file for the first time and the user did not exist on the system, the class changes was set and the next set of command promises for setting the password expiry and days of warning before the password expiry was set to the specified number of days.
But when we executed the configuration files again, after the user was created, the commands promise for creating the user failed and hence the class changes was not set so further command promises were skipped. CFEngine does not provide any inbuilt if-else condition promises so all such conditional or event driven actions need to be executed using proper classes. We'll use Apache here. The next code snippet may be copied to a file called webserver-config. Various methods are available for installation of packages, such as yum, apt, zipper, and so on.
For example: Let's first execute cf-agent with the configuration file failsafe. This output shows that the new configuration file webserver-config was copied correctly from the policy distribution host with IP address These promises may again be verified by running cf-promises.
Once the configuration file has been copied and the promises verified, let's execute the promises file to set up the HTTP web service. As there is no output, the configuration file was executed correctly and the web service was set up. We had to set up a web service and for this we choose the Apache web server. Next we defined a package addition policy and the method for adding packages. To verify, we list the installed packages, see if the required packages are there, and, if not, install the apache package and modules using yum.
For this class we defined a commands promise to start the web service with the command service httpd start. Time for action — setting up a database service 1. For setting up a database server we'll need a database server software package. We'll use MySQL as the database server. The next code snippet should be copied to a CFEngine promises file named mysql-install. Let's run cf-agent with the configuration file failsafe. Let's verify the promise using cf-promises: The file may be distributed to the servers that will act as database servers.
Now we may go ahead and execute the promises with cf-agent. Under this bundle agent we defined two classes redhat and debian. Under these two classes we defined the packages to be installed for each of the operating systems.
Next, we defined promises for package installations. Finally, we defined commands to start the MySQL server after installation. The following lines should be copied to a file named nfs-exports. You should copy the file from the policy distribution server to the client host by executing the cf-agent command with the configuration file failsafe. In case the new configuration file has been copied from the centralized policy distribution server with the IP address You could also run the command in verbose mode to see how CFEngine validates the promises.
CFEngine writes the validations in the file. This is because we did not use any of the predefined bundles or body. Now this promises file may be put on the server which is sharing its NFS volume.
This can be done by could also triggering the transfer using: For this we need to create additional access rules. Once we have the file system exported we need to mount the file system on the client host. For this we write another configuration file nfs-mount. The following lines should be copied to a file nfs-mount. Please note: The policies should only be executed on servers which are sharing their volume.
You may have to add additional access or deny rules to this file as you may not want to mount the NFS volume on all hosts. The NFS volume should only be added to the required hosts. The new configuration file should be copied to the client host by executing cfagent with the configuration file failsafe. Once the new configuration file nfs-mount. Now the new configuration file nfs-mount. We defined a class any and defined a bundlesequence for the bundle nfsexport under the common control body.
Next we specified the file where we needed to add the lines. Following this we defined that the file needs to be created if it does not exist. In the next promise file named nfs-mount. Time for action — setting up a network interface This task looks a bit odd—why would one set up a network service using CFEngine when one knows that: Let's see how we can add additional interfaces on client hosts.
We can configure the primary interface using CFEngine but let's presume that the primary interface was already configured, which will be correct in most cases. The following code snippet should be copied to a CFEngine promise file named network-interface-configure. We should copy the new configuration file from the policy distribution server to the client host using the command cf-agent with the configuration file failsafe. Once the new configuration file has been copied to the client host, let's validate our configuration file with the help of cf-promises as follows: Now we may distribute the file to the respective servers.
Now we may execute the promises with cf-agent. We defined a bundlesequence under the common control body with bundle niface. For the niface agent bundle we defined the string variable lines. We defined the name eth1 to be given to the interface provided.
To configure the interface we defined a file corresponding to the interface to be configured and appended the required network values to the file. Further promises would only be executed once the above class was set. This ensures that if the file editing failed for some reason and the promise was not repaired, the interface was not brought up. Finally, we brought the network up by running ifconfig.
Time for action — adding a jailed user to a system There are various instances where we moght want to jail a user to a specific directory. To achieve this we use an open source tool 'jailkit'. The latest stable version of this tool as of this writing can be downloaded from: Alternatively, you may create an '. The following lines should be copied to a file named installjailkit. You should copy the new configuration file installjailkit. Now that the file has been copied from the policy distribution server to the client host, let's verify the promise using cf-promises.
The promises seem to be good. As the promises have been validated correctly we can go ahead and execute the configuration file with the command: Under the common control body, we defined a bundlesequence for the two bundles installjailkit and jailuser. Next, we provided the command for downloading the tool and installing the software.
Pop quiz In the previous sections we saw how to set up a network interface. On a multi-homed host with the following three IP addresses: How can you schedule a promise to be executed at Hrs on the fifteenth day of a month, if and only if the fifteenth day is a Sunday? There are various instances where we want to know whether the file object is a soft link or hard link.
One such scenario is when you have created a soft link for a MySQL database pointing to an additional disk which was added separately to take care of disk space issues on a host. The highlights of this chapter are: How to configure the CFEngine clients and servers to transfer files between themselves on the basis of the keys, access rules, number of connections and so on. In addition to this, we learned how to define the packages that we want to install after the installation of the operating system.
How to set up web and database services. This is needed when you want to allow third-party users to access your server securely and get or put files on this host. Editing or appending lines in various configuration files using CFEngine.
This automation chapter dealt with most system configuration issues. In the next chapter we'll deal with auditing already installed systems. Let's look at a bit of the theory behind these promises.
In this chapter we shall: We may configure the details of the behavior using the control promise bodies, though. Promises can be made about all kinds of different aspects of a system: These are classes, vars, and report promises.
Also, we may write a combination of these promises in a file to achieve the desired result and hence we may say that the final behavior is 'user defined'. While all promise types used are specific to a particular interpretation, they need a "bundle type" interpreter. There are promises which may be defined in any kind of bundle and these promises are of a generic input or output. These are used to classify the properties of an environment or context in which CFEngine runs. There are two types of classes: System Audit with CFEngine 1.
Hard classes—These are classes which are discovered on CFEngine invocation 2. Soft classes—These are user-defined classes These two types of classes may be a global class or a local class that depends on the bundle type that the classes are defined under.
Classes defined under the "common" bundle type are global classes, whereas classes defined under all other bundle types are local classes. Lets see how we can define CFEngine classes: Lets see a few promise attributes for classes: This can be defined as shown next: This can be defined as given next: The following classes will be generated: We just saw how classes may be defined; lets move ahead and see more about the common, agent, and server control promise types.
Control promises There are promises provided by CFEngine which control the behavior of the components. The control promises are the promises used by all CFEngine components. For example, the "inputs" promise which describes the additional configuration files to be included or the "bundlesequence" promise defining the sequence of bundles to be executed.
Although the promises are hard-coded within the code, one can still control the behavior by altering the control body for each of these. When we talk about the behavior of the promises it means that we can alter the default behavior of the hard-coded promises. For example, [ 78 ] Chapter 3 the "mailmaxlines" promise, by default, sends the 30 lines of output in the e-mail which can then be changed to the desired number of lines that will be sent in the e-mail as follows: A common control promise body refers to those promises which are hard-coded in all the components of CFEngine and therefore affect the behavior of all the components.
Let's look at a few control parameters for different components: User defined behaviors require a promise and therefore should be defined in a bundle type. The bundlesequence control parameter specifies a list of promise bundles to verify in order. As it is a list of promise bundles, the parameter is of vars promise type slist. As it is a list of bundle names there is no default value but not specifying a bundlesequence may result in a compilation error.
Now bundles act as characteristics of a system and hence for different group of servers you may specify a different bundlesequence. The example below sets different bundlesequences for different groups of servers, which have been put in two different categories using classes.
Here's an example: As the parameter specifies a list of files the parameter is a vars promise type slist. It has no default values.
If no files are specified, no other filenames will be included during compilation. It assumes the filenames to be present in the same directory as the file which references it. The next example shows us the usage of this control parameter: We cannot use regular expressions for file names here. We should specify file names that exist. Agent control promises The agent control promise defines the promises made by cf-agent.
Let's look at a few important agent control promises: We need to specify the IP address of the interface and not the name of the interface: This locking time may be specified as follows: This is used to protect promises which may take longer to verify. This may be used to override the global settings. The next example shows how this can be specified: This specifies whether the pppkeys should be labeled by host names or IP. If this is set as 'true' the pppkeys will be labeled by host name. The next example shows how to use this: While specifying the maximum number of connections please note that this value should not breach the kernel limit on total open file descriptors.
The promise can set the value for both the client machine and the server machine. This value can be specified as follows: This list supports regular expressions. The list of files may be specified as follows: We are already aware that a file system has specific permissions for a few important files and directories, by default.
These permissions are set keeping in mind the access each user needs on these files and directories, which in turn builds a layer of security. Lets see the default permissions of a few important files and directories: As we see in the previous screenshot, these are the default permissions assigned to important files and directories by the operating system.
Now these and a few more permissions should be maintained 'as is' unless there are special needs where we want to alter these default permissions. To keep a tab on any changes in this default setup we need to audit the permissions for the above and a few more directories. Let's see how we can do this using CFEngine. Let's verify the promises: If you want to see a more verbose output you may use the -v switch with the command.
Now let's execute the promises and see what happens: Now if you see the previous output you may note that CFEngine gives a warning about a non-existent user shadow. If there are files or directories which do not have the permissions as specified in the promise file, the permissions for the corresponding files and directories will be changed. Let's change the permissions of this directory and try to execute the same promises again: The given promises may be used to audit and fix permissions for files and directories as required.
The objective for the bundle of promises we just discussed was to audit and fix the permissions of files and directories. A list of files, directories, and corresponding permissions is already available with the user, I presume. Here we defined a bundlesequence. There is only one promise bundle and we name it as 'checkpermissions'. After this we defined the list of files and directories under for the agent bundle.
CFENGINE 3 BEGINNERS GUIDE PDF - PDF DESIGN.
Next, we defined the mode, owner, and group for the various files and directories. Please note that all directories that have similar permissions have been grouped and are defined by variable dirlist. We can also group files that have similar permissions and define a single promise for them. Time for action — user and group audit 1. Let's look at another example where we perform a user and group audit. We need to check if specific user groups exist and also that there are no new users or groups added.
The following code snippet may be copied to a file user-group-audit.
CFEngine 3 Beginner's Guide
Let's check our promises: Let's execute the promise and see what the output is: User root exists R: User clark exists R: User peter does not exist R: Group root exists R: Now let's alter these two files and execute the promises again to see what happens if the files altered. The following commands will alter the two files: Retype new UNIX password: Now let's run our promises and see what happens: Group clark exists R: Group peter does not exist!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CFEngine raised a flag that the files have changed, which is exactly what we wanted. The objective of the promises was to check if the given users exist on the system and whether there have been any user related changes that have been made. Any user related changes will affect the two files: After this, we want to check for the existence of three users and groups which are root, clark, and peter. For verifying the existence of the users we use a CFEngine built-in function called userexists and for verifying the existence of the groups we use a CFEngine built-in function group exists.
We also defined a few classes which reports the existence or non existence of users. So the following promise can be interpreted as "for class userOK1 check whether the user root exists"; and report whether the user exists: The body for the baseline is defined such that the md5 sum is calculated for the content and is compared with the md5 sum of the base file. If there are any changes in the contents of the file a note is made while executing the promise. You'll also see that we have defined an action which tells the CFEngine to verify the md5 checksum in the background.
It specifically describes the access policy for the connections made to the server itself. Additionally, we need to provide the access to specific files.
Let's look at a few server control promises and their syntax: The path may be specified as follows: Currently, a server's clock is said to be 'out of sync' when the clock has drifted by an hour.
The control helps in raising a warning flag if the clocks are not synchronized beyond the acceptable limits and preventing Denial Of Service attacks based on clock corruption. The option can be disabled as follows: The list of IP addresses or host names may be specified as follows: The IP addresses and host names which are not allowed to connect can be specified as follows: The list of such hosts may again be specified as in allowconnects.
CFEngine gives an option to say 'yes' or 'no' at the time of accepting the keys at runtime for hosts whose public keys have not already been trusted. You can specify the list of IP addresses and host names as follows: The users may be specified as follows: Time for action — log rotation using CFEngine 1.
Log management is one task that needs to be performed on all servers at regular intervals. The logs may be web server logs, mail logs, application logs, or user access logs, and they need to be rotated or archived regularly on the basis of size or when they were modified. Let's see how this can be done using CFEngine; you may copy the following code snippet to a file rotate-logs. Let's verify the promises written in our file rotate-logs.
Now let's first note the listing of the logs that already exist on the paths that we specified in the promises file: Let's check the list of files specified on the paths in the promises file: In the given example, we wanted to rotate the apache webserver access logs and mail logs and keep only the last ten files. This also requires that the log file be rotated and renamed. Here we use the rotate option for the promise rename. Now because we have to always keep the 10 files always we supply the number 10 to the rotate option.
Let's look at the rename promise and the other options available for it in detail: False The given option if set to true automatically renames and removes permissions. From the given output, we see that the files have been rotated by one level. Access control using CFEngine Access control using an access control list acl may be used to defined access for various users on specific files and directories.
This is an agent control promise. This is available only in CFEngine Nova or above. Let's see the syntax for setting ACLs: The 'aces' constraint type defines the native settings for access control lists. This can be left unchanged nochange , explicitly specified specify and empty clear.
Additionally, the files and directories under the parent directory may inherit the ACL of the parent directory if we specify the 'parent' option. If we want to use the ACL as the starting point and want only the specified entries to exist, we may use the menu option 'overwrite'. If we want to use an existing ACL and want to append a new entry to it we may use the 'append' menu option. The given constraint may be used to specify the platform of the affected file system.
This constraint specifies a list of access control entries that are set on child objects. It is parsed from left to right and allows multiple entries with the same entity type and id. Here's a sample code snippet for such an ACL: We defined a bundlesequence for the common control promise.
We define a single bundle acls in this sequence. Next, we defined the ACL file under the files promise. We also defined the body for promise acl and promisee test. Therefore, the entry will overwrite the existing ACLs and add a single new entry. We define the native access control list settings with the constraint aces.
The native settings are defined as follows: If you want to do this for a specific group, use all: We also define that while doing depth search, the base directory is included. We wrote a promise for rotating files in one of the sections above. Now, if we want to rotate the file's basis size, which other constraint should be used? Which promise constraint may be used for checking if any of the attributes of a file are changed?
It performs rootkit detection, file integrity checking, log analysis, policy monitoring, real time alerting, and active response. Making changes to a group of hosts on the basis of flags raised on a single host. For example, one of your web servers is being bogged down by a DOS attack; OSSEC may detect it on this host and may make changes to the system to block the traffic but it may not be able to do so on all the other hosts in the web server group.
This is where CFEngine may jump in and make the changes to all the other hosts in the web server group so that your web server infrastructure is safe from DOS attacks. Lets see how this can be achieved to build a more robust open source security solution for your IT infrastructure. The complete OSSEC configuration is beyond the scope of this book and we'll cover only a few important scenarios.
You may refer to the manual at http: Now we need to block this IP. This can be done in two ways: You add an IP tables rule. You add the IP to your web server configuration file's blacklist. Let's see how this can be done for the second scenario using CFEngine. Now let's execute the promises: Augment scope AppendIfNoLine with parameter cf3? Deny from cf The objective of the given promises was to add the IP s , for which OSSEC has raised an alert, to the web server configuration file so that the access from the same IP is denied.
Here, we defined the bundlesequence under the common control body. We defined a region MySection to which the lines should be appended. Finally, we defined the start of the section and end of the section. The lines to be added will be added in between the start of the section and end of the section. In the last step we restarted apache so that the changes come into effect. Have a go hero — verifying the web server configuration files after changes In the previous example, we added a few access and deny rules to the Apache web server configuration file and restarted the web server.
What happens if the changes had a syntax [ ] Chapter 3 error and the web server failed to restart? To handle this we need to check for any syntax errors in the web server configuration file. How can this be done using CFEngine? We rotated a log file in one of the previous sections. If we want to create a compressed backup of the log files, which file promise can be used? Now there are various instances where we want to enable functionality or modules for an application. We do it by removing the comments on the corresponding line or lines in the application configuration file.
You may copy the following code to a file apache-unhash. In the previous few chapters we learned how to use CFEngine for system audits. Let's see how CFEngine can be used to monitor systems and processes in this chapter. We will also see a few more control promises. Let's see the other control promises that CFEngine has to offer, and their usage.
Given next is a small example that exhibits a few of these promises types and their usage. In this example we'll try to disable all xinetd services on a system.
You may use the following lines of code in a configuration file: Once the file has been copied we can execute the configuration file using cf-agent. Let's look at the output when we execute the configuration file: Let's see the control promises and constraints that they offer in more detail.
Monitor control promises The monitor control promise settings describe the fixed behavior of promises made by cfmonitord. The various constraints for this type of control promise are as follows: Apart from this I have also listed a few points to be considered while writing the promises so that they are easily understood by the team.
Who is this book is written for? I am sure the book will be useful for System Engineers and System Administrators who deal cfengine 3 beginners guide a large number of systems on a regular basis.
There are a lot of tasks which are repetitive and need to be performed on a large number of systems simultaneously or in an order — CFEngine can take care of both.
We may execute tasks simultaneously or in an order using CFEngine. The book is also useful for folks who maintain the standard cfengine 3 beginners guide for all the hosts in a network. They may use the CFEngine framework not only to deploy the standard stack on large number of hosts but also to audit the hosts and check for anomalies. The framework is so powerful that it may be cfengine 3 beginners guide to perform all sorts of automation tasks, one such example is — backup administrators may configure backups using the CFEngine framework.
Why did I want to write this book? Start reading Book Cfengine 3 beginners guide A step-by-step guide to setting up Cfengine and fully automating the configuration cfengine 3 beginners guide management of your laptop, desktop, server, or mainframe. The first and only book dedicated to the Cfengine framework. Detailed instructions on installing, configuring, and setting up Cfengine and using it to build, secure and monitor your infrastructure. Real world projects and tasks straight from the data centre.
Monitoring, logging and reporting explained with easy-to-understand examples.
Covers all Cfengine commands, promises, variables, functions and best practices. In Detail Cfengine is a compact automation framework primarily used to provide automated configuration and maintenance of laptops, desktops, servers, and mainframes. It is not a very complex framework, but certainly is extensive. There is too much to learn and it is hard to convey in a simple way what the software cfengine 3 beginners guide do.
Armando Walter Country: Pakistan Language:
- BEIJING TRAVEL GUIDE PDF
- BEGINNING SQL JOES 2 PROS PDF
- LEARNING CFENGINE 3 PDF
- LEGEND OF ZELDA TWILIGHT PRINCESS STRATEGY GUIDE PDF
- DEFINITIVE GUIDE TO SOA ORACLE SERVICE BUS PDF
- BEST C PROGRAMMING BOOK FOR BEGINNERS
- EXCHANGE SERVER 2003 STUDY GUIDE PDF
- KALI LINUX PDF BOOKS
- TNPSC GROUP 2 BOOK MATERIALS
- PETER GRAY PSYCHOLOGY 6TH EDITION PDF