Category: puppet

Puppet – Live Project ”; Previous Next In order to perform the live testing of applying configuration and manifests on Puppet node, we will use a live working demo. This can be directly copied and pasted to test how the configuration works. If the user wishes to use the same set of code, he needs to have the same naming convention as shown in code snippets as follows. Let’s start with the creation of a new module. Creating a New Module The first step in testing and applying the httpd configuration is by creating a module. In order to do this, the user needs to change his working directory to Puppet module directory and create a basic module structure. The structure creation can be done manually or by using Puppet to create boilerplate for the module. # cd /etc/puppet/modules # puppet module generate Live-module Note − Puppet module generate command requires that the module-name takes the format of [username]-[module] to comply with Puppet forge specifications. The new module contains some basic files, including a manifest directory. The directory already contains a manifest named init.pp, which is modules main manifest file. This is an empty class declaration for the module. class live-module { } The module also contains a test directory containing a manifest called init.pp. This test manifest contains reference to the live-module class within manifest/init.pp: include live-module Puppet will use this test module to test the manifest. Now we are ready to add the configuration to the module. Installing a HTTP Server Puppet module will install the necessary packages to run http server. This requires a resource definition that defines the configuration of httpd packages. In the module’s manifest directory, create a new manifest file called httpd.pp # touch test-module/manifests/httpd.pp This manifest will contain all HTTP configuration for our module. For separation purpose, we will keep the httpd.pp file separate from init.pp manifest file We need to put the following code in httpd.pp manifest file. class test-module::httpd { package { ”httpd”: ensure => installed, } } This code defines a subclass of test-module called httpd, then defines a package resource declaration for the httpd package. The ensure => installed attribute checks if the required package is installed. If not installed, Puppet uses yum utility to install it. Next, is to include this subclass in our main manifest file. We need to edit init.pp manifest. class test-module { include test-module::httpd } Now, it’s the time to test the module which could be done as follows # puppet apply test-module/tests/init.pp –noop The puppet apply command applies the configuration present in manifest file on the target system. Here, we are using test init.pp which refers to main init.pp. The –noop performs the dry run of the configuration, which only shows the output but actually does not do anything. Following is the output. Notice: Compiled catalog for puppet.example.com in environment production in 0.59 seconds Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop) Notice: Class[test-module::Httpd]: Would have triggered ”refresh” from 1 events Notice: Stage[main]: Would have triggered ”refresh” from 1 events Notice: Finished catalog run in 0.67 seconds The highlight line is the result of the ensure => installed attribute. The current_value absent means that Puppet has detected the httpd package is installed. Without the –noop option, Puppet will install the httpd package. Running the httpd Server After installing the httpd servers, we need to start the service using other resource deceleration: Service We need to edit the httpd.pp manifest file and edit the following content. class test-module::httpd { package { ”httpd”: ensure => installed, } service { ”httpd”: ensure => running, enable => true, require => Package[“httpd”], } } Following is the list of targets that we have achieved from the above code. The ensure => running status checks if the service is running, if not then it enables it. The enable => true attribute sets the service to run when the system boots up. The require => Package[“httpd”] attribute defines an ordering relationship between one resource deceleration and other. In the above case, it ensures that the httpd service starts after the http package is installed. This creates a dependency between the service and the respective package. Run the puppet apply command to test the changes again. # puppet apply test-module/tests/init.pp –noop Notice: Compiled catalog for puppet.example.com in environment production in 0.56 seconds Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop) Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop) Notice: Class[test-module::Httpd]: Would have triggered ”refresh” from 2 events Notice: Stage[main]: Would have triggered ”refresh” from 1 events Notice: Finished catalog run in 0.41 seconds Configuring httpd Server Once the above steps are completed, we will have HTTP server installed and enabled. The next step is to provide some configuration to the server. By default, httpd provides some default configurations in /etc/httpd/conf/httpd.conf which provides a webhost port 80. We will add some additional host to provide some user-specific facilities to the web-host. A template will be used to provide additional port as it requires a variable input. We will create a directory called template and add a file called test-server.config.erb in the new director and add the following content. Listen <%= @httpd_port %> NameVirtualHost *:<% = @httpd_port %> <VirtualHost *:<% = @httpd_port %>> DocumentRoot /var/www/testserver/ ServerName <% = @fqdn %> <Directory “/var/www/testserver/”> Options All Indexes FollowSymLinks Order allow,deny Allow from all </Directory> </VirtualHost> The above template follows the standard apache-tomcat server configuration format. The only difference is the use of Ruby escape character to inject variables from the module. We have FQDN which stores fully qualified domain name of the system. This is known as the system fact. System facts are collected from each system prior to generating each respective system’s puppet catalog. Puppet uses the facter command to get this information and one can use facter to get other details regarding the system. We need to add the highlight lines in httpd.pp manifest file. class test-module::httpd { package { ”httpd”: ensure => installed, } service { ”httpd”: ensure

Puppet – Coding Style ”; Previous Next In Puppet, the coding style defines all the standards which one needs to follow while trying to convert the infrastructure on the machine configuration into a code. Puppet works and performs all its defined tasks using resources. Puppet’s language definition helps in specifying all the resources in a structured way, which is required to manage any target machine that needs to be managed. Puppet uses Ruby as its encoding language, which has multiple inbuilt features that makes it very easy to get things done with a simple configuration on the code side. Fundamental Units Puppet uses multiple fundamental coding styles which is easy to understand and manage. Following is a list of few. Resources In Puppet, resources are known as fundamental modeling unit which are used to manage or modify any target system. Resources cover all the aspects of a system such as file, service, and package. Puppet comes with an in-built capability wherein it allows the users or developers to develop custom resources, which help in managing any particular unit of a machine In Puppet, all the resources are aggregated together either by using “define” or “classes”. These aggregation features help in organizing a module. Following is a sample resource which consists of multiple types, a title, and a list of attributes with which Puppet can support multiple attributes. Each resource in Puppet has its own default value, which could be overridden when required. Sample Puppet Resource for File In the following command, we are trying to specify a permission for a particular file. file { ”/etc/passwd”: owner => superuser, group => superuser, mode => 644, } Whenever the above command gets executed on any machine, it will verify that the passwd file in the system is configured as described. The file before: colon is the title of resource, which can be referred as resource in other parts of Puppet configuration. Specifying Local Name in Addition to the Title file { ”sshdconfig”: name => $operaSystem ? { solaris => ”/usr/local/etc/ssh/sshd_config”, default => ”/etc/ssh/sshd_config”, }, owner => superuser, group => superuser, mode => 644, } By using the title, which is always the same it is very easy to refer file resource in configuration without having to repeat the OS related logic. Another example could be using a service that depends on a file. service { ”sshd”: subscribe => File[sshdconfig], } With this dependency, the sshd service will always restart once the sshdconfig file changes. The point to be remember here is File[sshdconfig] is a declaration as File as in lower case but if we change it to FILE[sshdconfig] then it would have been a reference. One fundamental point that one needs to keep in mind while declaring a resource is, it can be declared only once per config file. Repeating declaration of the same resource more than once will cause an error. Through this fundamental concept, Puppet makes sure that the configuration is well modeled. We even have the capability to manage resource dependency which helps is managing multiple relationships. service { ”sshd”: require => File[”sshdconfig”, ”sshconfig”, ”authorized_keys”] } Metaparameters Metaparameters are known as global parameters in Puppet. One of the key features of metaparameter is, it works with any type of resource in Puppet. Resource Default When one needs to define a default resource attribute value, Puppet provides a set of syntax to archive it, using a capitalized resource specification that has no title. For example, if we want to set the default path of all the executable it can be done with the following command. Exec { path => ”/usr/bin:/bin:/usr/sbin:/sbin” } exec { ”echo Testing mataparamaters.”: } In the above command, the first statement Exec will set the default value for exec resource. Exec resource requires a fully qualified path or a path which looks like an executable. With this, one can define a single default path for the entire configuration. Defaults work with any resource type in Puppet. Defaults are not global values, however, they only affect the scope in which they are defined or the very next variable to it. If one wants to define default for a complete configuration, then we define the default and the class in the very next section. Resource Collections Aggregation is method of collecting things together. Puppet supports a very powerful concept of aggregation. In Puppet, aggregation is used for grouping resource which is the fundamental unit of Puppet together. This concept of aggregation in Puppet is achieved by using two powerful methods known as classes and definition. Classes and Definition Classes are responsible for modeling the fundamental aspects of node. They can say node is a web server and this particular node is one of them. In Puppet, programming classes are singleton and they can get evaluated once per node. Definition on the other hand can be used many times on a single node. They work similarly as one has created his own Puppet type using the language. They are created to be used multiple times with different input each time. This means one can pass variable values into the definition. Difference between Class and Definition The only key difference between a class and definition is while defining the building structure and allocating resources, class gets evaluated only once per node, wherein on the other hand, a definition is used multiple times on the same single node. Classes Classes in Puppet are introduced using the class keyword and the content of that particular class is wrapped inside the curly braces as shown in the following example. class unix { file { ”/etc/passwd”: owner => ”superuser”, group => ”superuser”, mode => 644; ”/etc/shadow”: owner => ”vipin”, group => ”vipin”, mode => 440; } } In the following example, we have used some short hand which is similar to the above. class unix { file { ”/etc/passwd”: owner => ”superuser”, group => ”superuser”, mode => 644; } file {”/etc/shadow”: owner => ”vipin”, group => ”vipin”, mode => 440; }

Puppet – Installation ”; Previous Next Puppet works on the client server architecture, wherein we call the server as the Puppet master and the client as the Puppet node. This setup is achieved by installing Puppet on both the client and well as on all the server machines. For most of the platforms, Puppet can be installed via the package manager of choice. However, for few platforms it can be done by installing the tarball or RubyGems. Prerequisites Factor is the only pre-requisite that does not come along with Ohai which is present in Chef. Standard OS Library We need to have standard set of library of any underlying OS. Remaining all the system comes along with Ruby 1.8.2 + versions. Following is the list of library items, which an OS should consist of. base64 cgi digest/md5 etc fileutils ipaddr openssl strscan syslog uri webrick webrick/https xmlrpc Facter Installation As discussed, the facter does not come along with the standard edition of Ruby. So, in order to get the facter in the target system one needs to install it manually from the source as the facter library is a pre-requisite of Puppet. This package is available for multiple platforms however just to be on the safer side it can be installed using tarball, which helps in getting the latest version. First, download the tarball from the official site of Puppet using the wget utility. $ wget http://puppetlabs.com/downloads/facter/facter-latest.tgz ——: 1 Next, un-tar the tar file. Get inside the untarred directory using the CD command. Finally, install the facter using install.rb file present inside the facter directory. $ gzip -d -c facter-latest.tgz | tar xf – —–: 2 $ cd facter-* ——: 3 $ sudo ruby install.rb # or become root and run install.rb —–:4 Installing Puppet from the Source First, install the Puppet tarball from the Puppet site using wget. Then, extract the tarball to a target location. Move inside the created directory using the CD command. Using install.rb file, install Puppet on the underlying server. # get the latest tarball $ wget http://puppetlabs.com/downloads/puppet/puppet-latest.tgz —–: 1 # untar and install it $ gzip -d -c puppet-latest.tgz | tar xf – —-: 2 $ cd puppet-* ——: 3 $ sudo ruby install.rb # or become root and run install.rb ——-: 4 Installing Puppet and Facter Using Ruby Gem # Installing Facter $ wget http://puppetlabs.com/downloads/gems/facter-1.5.7.gem $ sudo gem install facter-1.5.7.gem # Installing Puppet $ wget http://puppetlabs.com/downloads/gems/puppet-0.25.1.gem $ sudo gem install puppet-0.25.1.gem Print Page Previous Next Advertisements ”;

Puppet – Resource ”; Previous Next Resources are one of the key fundamental units of Puppet used to design and build any particular infrastructure or a machine. They are mainly used for modeling and maintaining system configurations. Puppet has multiple type of resources, which can be used to define the system architecture or the user has the leverage to build and define a new resource. The block of Puppet code in manifest file or any other file is called a resource declaration. The block of code is written in a language called Declarative Modelling Language (DML). Following is an example of how it looks like. user { ”vipin”: ensure => present, uid => ”552”, shell => ”/bin/bash”, home => ”/home/vipin”, } In Puppet, resource declaration for any particular resource type is done in code block. In the following example, the user is made up of mainly four pre-defined parameters. Resource Type − In the above code snippet, it is the user. Resource Parameter − In the above code snippet, it is Vipin. Attributes − In the above code snippet, it is ensure, uid, shell, home. Values − These are the values that correspond to each property. Each resource type has its own way of defining definitions and parameters, and the user has the privilege to pick and choose the way he wants his resource to look like. Resource Type There are different types of resources available in Puppet which have their own way of functionality. These resource types can be viewed using the “describe” command along with the “-list” option. [root@puppetmaster ~]# puppet describe –list These are the types known to puppet: augeas – Apply a change or an array of changes to the … computer – Computer object management using DirectorySer … cron – Installs and manages cron jobs exec – Executes external commands file – Manages files, including their content, owner … filebucket – A repository for storing and retrieving file … group – Manage groups host – Installs and manages host entries interface – This represents a router or switch interface k5login – Manage the ‘.k5login’ file for a user macauthorization – Manage the Mac OS X authorization database mailalias – .. no documentation .. maillist – Manage email lists mcx – MCX object management using DirectoryService … mount – Manages mounted filesystems, including puttin … nagios_command – The Nagios type command nagios_contact – The Nagios type contact nagios_contactgroup – The Nagios type contactgroup nagios_host – The Nagios type host nagios_hostdependency – The Nagios type hostdependency nagios_hostescalation – The Nagios type hostescalation nagios_hostextinfo – The Nagios type hostextinfo nagios_hostgroup – The Nagios type hostgroup nagios_service – The Nagios type service nagios_servicedependency – The Nagios type servicedependency nagios_serviceescalation – The Nagios type serviceescalation nagios_serviceextinfo – The Nagios type serviceextinfo nagios_servicegroup – The Nagios type servicegroup nagios_timeperiod – The Nagios type timeperiod notify – .. no documentation .. package – Manage packages resources – This is a metatype that can manage other reso … router – .. no documentation .. schedule – Define schedules for Puppet scheduled_task – Installs and manages Windows Scheduled Tasks selboolean – Manages SELinux booleans on systems with SELi … service – Manage running services ssh_authorized_key – Manages SSH authorized keys sshkey – Installs and manages ssh host keys stage – A resource type for creating new run stages tidy – Remove unwanted files based on specific crite … user – Manage users vlan – .. no documentation .. whit – Whits are internal artifacts of Puppet”s curr … yumrepo – The client-side description of a yum reposito … zfs – Manage zfs zone – Manages Solaris zones zpool – Manage zpools Resource Title In the above code snippet, we have resource title as vipin which is unique for each resource used in the same file of the code. This is a unique title for this user resource type. We cannot have a resource with the same name because it will cause conflicts. Resource command can be used to view the list of all the resources using type user. [root@puppetmaster ~]# puppet resource user user { ”abrt”: ensure => ”present”, gid => ”173”, home => ”/etc/abrt”, password => ”!!”, password_max_age => ”-1”, password_min_age => ”-1”, shell => ”/sbin/nologin”, uid => ”173”, } user { ”admin”: ensure => ”present”, comment => ”admin”, gid => ”444”, groups => [”sys”, ”admin”], home => ”/var/admin”, password => ”*”, password_max_age => ”99999”, password_min_age => ”0”, shell => ”/sbin/nologin”, uid => ”55”, } user { ”tomcat”: ensure => ”present”, comment => ”tomcat”, gid => ”100”, home => ”/var/www”, password => ”!!”, password_max_age => ”-1”, password_min_age => ”-1”, shell => ”/sbin/nologin”, uid => ”100”, } Listing the Resources of a Particular User [root@puppetmaster ~]# puppet resource user tomcat user { ”apache”: ensure => ”present”, comment => ”tomcat”, gid => ”100”, home => ”/var/www”, password => ”!!”, password_max_age => ”-1”, password_min_age => ”-1”, shell => ”/sbin/nologin”, uid => ”100’, } Attributes & Values The main body of any resource is made up of a collection of attribute-value pairs. Here one can specify the values for a given resource’s property. Each resource type has its own set of attributes that can be configured with the key-value pairs. Describe the sub-command that can be used to get more details about a particular resources attribute. In the following example, we have the details about the user resource along with all its configurable attributes. [root@puppetmaster ~]# puppet describe user user ==== Manage users. This type is mostly built to manage system users, so it is lacking some features useful for managing normal users. This resource type uses the prescribed native tools for creating groups and generally uses POSIX APIs for retrieving information about them. It does not directly modify ‘/etc/passwd’ or anything. **Autorequires:** If Puppet is managing the user”s primary group (as provided in the ‘gid’ attribute), the user resource will autorequire that group. If Puppet is managing any role accounts corresponding to the user”s roles, the user resource will autorequire those role

Puppet – Configuration ”; Previous Next Once we have Puppet installed on the system, the next step is to configure it to perform certain initial operations. Open Firewall Ports on Machines To make the Puppet server manage the client’s server centrally, one needs to open a specified port on all the machines, i.e. 8140 can be used if it is not in use in any of the machines which we are trying to configure. We need to enable both TCP and UDP communication on all the machines. Configuration File The main configuration file for Puppet is etc/puppet/puppet.conf. All the configuration files get created in a package-based configuration of Puppet. Most of the configuration which is required to configure Puppet is kept in these files and once the Puppet run takes place, it picks up those configurations automatically. However, for some specific tasks such as configuring a web server or an external Certificate Authority (CA), Puppet has separate configuration for files and settings. Server configuration files are located in conf.d directory which is also known as the Puppet master. These files are by default located under /etc/puppetlabs/puppetserver/conf.d path. These config files are in HOCON format, which keeps the basic structure of JSON but it is more readable. When the Puppet startup takes place it picks up all .cong files from conf.d directory and uses them for making any configurational changes. Any changes in these files only takes place when the server is restarted. List File and Settings File global.conf webserver.conf web-routes.conf puppetserver.conf auth.conf master.conf (deprecated) ca.conf (deprecated) There are different configuration files in Puppet which are specific to each component in Puppet. Puppet.conf Puppet.conf file is Puppet’s main configuration file. Puppet uses the same configuration file to configure all the required Puppet command and services. All Puppet related settings such as the definition of Puppet master, Puppet agent, Puppet apply and certificates are defined in this file. Puppet can refer them as per requirement. The config file resembles a standard ini file wherein the settings can go into the specific application section of the main section. Main Config Section [main] certname = Test1.vipin.com server = TestingSrv environment = production runinterval = 1h Puppet Master Config File [main] certname = puppetmaster.vipin.com server = MasterSrv environment = production runinterval = 1h strict_variables = true [master] dns_alt_names = MasterSrv,brcleprod01.vipin.com,puppet,puppet.test.com reports = puppetdb storeconfigs_backend = puppetdb storeconfigs = true environment_timeout = unlimited Detail Overview In Puppet configuration, the file which is going to be used has multiple configuration sections wherein each section has different kinds of multiple number of settings. Config Section Puppet configuration file mainly consists of the following config sections. Main − This is known as the global section which is used by all the commands and services in Puppet. One defines the default values in the main section which can be overridden by any section present in puppet.conf file. Master − This section is referred by Puppet master service and Puppet cert command. Agent − This section is referred by Puppet agent service. User − It is mostly used by Puppet apply command as well as many of the less common commands. [main] certname = PuppetTestmaster1.example.com Key Components of Config File Following are the key components of Config file. Comment Lines In Puppet, any comment line starts with (#) sign. This may intend with any amount of space. We can have a partial comment as well within the same line. # This is a comment. Testing = true #this is also a comment in same line Settings Lines Settings line must consist of − Any amount of leading space (optional) Name of the settings An equals = to sign, which may be surrounded by any number of space A value for the setting Setting Variables In most of the cases, the value of settings will be a single word but in some special cases, there are few special values. Paths In configuration file settings, take a list of directories. While defining these directories, one should keep in mind that they should be separated by the system path separator character, which is (:) in *nix platforms and semicolons (;) on Windows. # *nix version: environmentpath = $codedir/special_environments:$codedir/environments # Windows version: environmentpath = $codedir/environments;C:ProgramDataPuppetLabscodeenvironment In the definition, the file directory which is listed first is scanned and then later moves to the other directory in the list, if it doesn’t find one. Files and Directories All the settings that take a single file or directory can accept an optional hash of permissions. When the server is starting up, Puppet will enforce those files or directories in the list. ssldir = $vardir/ssl {owner = service, mode = 0771} In the above code, the allowed hash are owner, group, and mode. There are only two valid values of the owner and group keys. Print Page Previous Next Advertisements ”;