Posts

Showing posts with the label genconfig

Featured Post

Directory environments in Puppet

Environments are individual groups of Puppet agents each environment have there own completely different manifests and module-paths. This basically is useful for testing changes to our Puppet code before implementing them on production machines. There are two types of implementation of environments structure in Puppet one if directory based and another is config file based here we will see bit of an insight about directory based. As usual for more information about this you can visit puppetlabs official website. On the master node: Append following details in puppet.conf which is placed under /etc/puppet or /etc/puppetlabs/puppet:     Under [main] section add a variable called confdir with value as /etc/puppet or /etc/puppetlabs/puppet     confdir=/etc/puppet Then add information regarding environments/manifests and modulepath in it.      #environments     environmentpath = $confdir/environments  ...
Post a Comment
Read more

Manifests

Manifests Puppet programs are called “manifests,” and they use the .pp file extension. The core of the Puppet language is the resource declaration. A resource declaration describes a desired state for one resource. (Manifests can also use various kinds of logic: conditional statements, collections of resources, functions to generate text, etc. We’ll get to these later.) [root@server demo_manifests]# cat add_user.pp user { 'optimus':   ensure => 'present',   home   => '/home/optimus',   shell  => '/bin/bash', } [root@server demo_manifests]# [root@server demo_manifests]# puppet apply /root/Desktop/demo_manifests/add_user.pp notice: /Stage[main]//User[optimus]/ensure: created notice: Finished catalog run in 0.21 seconds [root@server demo_manifests]# Puppet Apply Like resource in the last chapter, apply is a Puppet subcommand. It takes the name of a manifest file as its argument, and enforces the desired state descri...
Post a Comment
Read more

Puppet modules???

*Modules in puppet* Modules are a way of arranging manifests/files/templates in puppet. Why they are arranged like this?? So that they can be automatically called by the puppet master when needed. What is the location of module?? Default location, you can find it by firing below command: [root@puppet modules]# puppet master --genconfig | grep modulepath     modulepath = /etc/puppet/modules:/usr/share/puppet/modules [root@puppet modules]# User defined location, If in-case you want to use the user defined location to fetch the modules so that puppet master can use it you need to use a option called --modulepath while firing the command. [root@puppet manifests]# puppet apply site.pp --modulepath=/tmp/mods/ notice: Finished catalog run in 0.26 seconds [root@puppet manifests]# Structure of a module: modules/ └── ntp     ├── files     │   ├── ntp.conf.debian     │   └── ntp.conf.el     ├──...
Post a Comment
Read more

puppet master???

*Master daemon in Puppet "puppet master"* Puppet master is the central puppet server. Firing this command "puppet master" starts an instance of puppet master and runs as a daemon by default. [root@puppet ~]# /etc/init.d/puppetmaster status puppetmasterd is stopped [root@puppet ~]# puppet master [root@puppet ~]# /etc/init.d/puppetmaster status puppetmasterd (pid  31281) is running... [root@puppet ~]# If you want to enable full debugging mode while executing puppet master you can use the option --debug while firing it. [root@puppet ~]# puppet master --debug --no-daemonize debug: Puppet::Type::User::ProviderPw: file pw does not exist debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist debug: Puppet::Type::User::ProviderLdap: true value when expecting false debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does not exist debug: Failed to load library 'rubygems' for feature 'rubygems' debug: /File[/...
2 comments
Read more