Category: puppet

Puppet – Overview ”; Previous Next Puppet is a configuration management tool developed by Puppet Labs in order to automate infrastructure management and configuration. Puppet is a very powerful tool which helps in the concept of Infrastructure as code. This tool is written in Ruby DSL language that helps in converting a complete infrastructure in code format, which can be easily managed and configured. Puppet follows the client-server model, where one machine in any cluster acts as the server, known as puppet master and the other acts as a client known as a slave on nodes. Puppet has the capability to manage any system from scratch, starting from initial configuration till the end-of-life of any particular machine. Features of Puppet System Following are the most important features of Puppet. Idempotency Puppet supports Idempotency which makes it unique. Similar to Chef, in Puppet, one can safely run the same set of configuration multiple times on the same machine. In this flow, Puppet checks for the current status of the target machine and will only make changes when there is any specific change in the configuration. Idempotency helps in managing any particular machine throughout its lifecycle starting from the creation of machine, configurational changes in the machine, till the end-of-life. Puppet Idempotency feature is very helpful in keeping the machine updated for years rather than rebuilding the same machine multiple times, when there is any configurational change. Cross-platform In Puppet, with the help of Resource Abstraction Layer (RAL) which uses Puppet resources, one can target the specified configuration of system without worrying about the implementation details and how the configuration command will work inside the system, which are defined in the underlying configuration file. Puppet − Workflow Puppet uses the following workflow to apply configuration on the system. In Puppet, the first thing what the Puppet master does is to collect the details of the target machine. Using the factor which is present on all Puppet nodes (similar to Ohai in Chef) it gets all the machine level configuration details. These details are collected and sent back to the Puppet master. Then the puppet master compares the retrieved configuration with defined configuration details, and with the defined configuration it creates a catalog and sends it to the targeted Puppet agents. The Puppet agent then applies those configurations to get the system into a desired state. Finally, once one has the target node in a desired state, it sends a report back to the Puppet master, which helps the Puppet master in understanding where the current state of the system is, as defined in the catalog. Puppet − Key Components Following are the key components of Puppet. Puppet Resources Puppet resources are the key components for modeling any particular machine. These resources have their own implementation model. Puppet uses the same model to get any particular resource in the desired state. Providers Providers are basically fulfillers of any particular resource used in Puppet. For example, the package type ‘apt-get’ and ‘yum’ both are valid for package management. Sometimes, more than one provider would be available on a particular platform. Though each platform always have a default provider. Manifest Manifest is a collection of resources which are coupled inside the function or classes to configure any target system. They contain a set of Ruby code in order to configure a system. Modules Module is the key building block of Puppet, which can be defined as a collection of resources, files, templates, etc. They can be easily distributed among different kinds of OS being defined that they are of the same flavor. As they can be easily distributed, one module can be used multiple times with the same configuration. Templates Templates use Ruby expressions to define the customized content and variable input. They are used to develop custom content. Templates are defined in manifests and are copied to a location on the system. For example, if one wants to define httpd with a customizable port, then it can be done using the following expression. Listen <% = @httpd_port %> The httpd_port variable in this case is defined in the manifest that references this template. Static Files Static files can be defined as a general file which are sometimes required to perform specific tasks. They can be simply copied from one location to another using Puppet. All static files are located inside the files directory of any module. Any manipulation of the file in a manifest is done using the file resource. Print Page Previous Next Advertisements ”;

Puppet – File Server ”; Previous Next Puppet follows the concept of client and server where one machine in a setup works as the server machine with Puppet server software running on it and the remaining works as the client with Puppet agent software running on it. This feature of the file server helps in copying the files around multiple machines. This feature of file serving function in Puppet comes as a part of central Puppet daemon. Puppetmasterd and the client function plays a key role in sourcing file attributes as the file object. class { ”java”: package => ”jdk-8u25-linux-x64”, java_alternative => ”jdk1.8.0_25”, java_alternative_path => ”/usr/java/jdk1.8.0_25/jre/bin/java” } As in the above code snippet, Puppet’s file serving functions abstracts the local filesystem topology by supporting the file service module. We will specify the file serving module in the following manner. “puppet://server/modules/module_name/sudoers” File Format In Puppet directory structure, by default the file server configuration is located under /etc/puppet/fileserver.config directory, if the user wishes to change this default configuration file path, it can be done using the new config flag to puppetmasterd. The configuration file resembles INI files but is not exactly the same. [module] path /path/to/files allow *.domain.com deny *.wireless.domain.com As shown in the above code snippet, all the three options are represented in the configuration file. The module name somewhat goes in the brackets. The path is the only required option. Default security option is to deny all the access, so if no allow lines are specified, the module which will be configured will be available to anyone. The path can contain any or all of the %d, %h and %H which are dynamically replaced by its domain name, its host name, and fully qualified host name. All are taken from the client’s SSL certificate (so be careful if one has a mismatch in hostname and certificate name). This is useful is creating modules where the files of each client are kept completely separately. Example, for private host keys. [private] path /data/private/%h allow * In the above code snippet, the code is trying to search for file /private/file.txt from the client client1.vipin.com. It will look for it in /data/private/client1/file.txt, while the same request for client2.vipin.com will try to retrieve the file /data/private/client2/file.txt on the file server. Security Puppet supports the two basic concepts of securing file on the Puppet file server. This is achieved by allowing access to specific files and denying access to the ones which are not required. By default, Puppet does not allow access to any of the files. It needs to be defined explicitly. The format which can be used in the files to allow or deny access is by using IP address, name, or global allow. If the client is not connected to the Puppet file server directly, for example using a reverse proxy and Mongrel, then the file server will see all the connections as coming from the proxy server and not the Puppet client. In the above cases, restricting the host name on the base of hostname is the best practice. One key point to be noted while defining the file structure is, all the deny statements are parsed before the allow statement. Hence, if any deny statement matches a host, then that host will be denied and if no allow statement is written in the upcoming files, then the host will be denied. This feature helps in setting priority of any particular site. Host Name In any file server configuration, file hostname can be specified in two ways either by using a complete hostname or specifying an entire domain name using the * wildcard as shown in the following example. [export] path /usr allow brcleprod001.brcl.com allow *.brcl.com deny brcleprod002.brcl.com IP Address In any file server configuration, the file address can be specified as similar to the host names, using either complete IP address or wildcard address. One can also use CIDR system notation. [export] path /usr allow 127.0.0.1 allow 172.223.30.* allow 172.223.30.0/24 Global Allow Global allow is used when the user wants that everyone can access a particular module. To do this, a single wildcard helps in letting everyone access the module. [export] path /export allow * Print Page Previous Next Advertisements ”;

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 ”;