User:Prathapan

From CDOT Wiki
Jump to: navigation, search

Hi, My name is Pirathapan Sivalingam. Currently enrolled in 6th semester.

My IRC nick is Prathapan.

What else, Finished my CCNP certification and Going take CCVP in few months, then hoping to get CCIE.


Project Release 0.1

Project-SETUP PUPPET

Release 0.1

Puppet

Puppet is an open source automated system configuration management framework, which provides administrators a simplified platform for flexible and consistent administration.

Puppet element includes

1) Puppet master: it is the centralized system that has configuration of the other nodes that is to be applied on the client system.

2) Puppet: it is installed in the clients that are to be managed by puppetmaster.

How puppet works

All clients will communicate with puppet master periodically to see if there are any changes for respective configuration, and download the latest configuration and make sure it is synchronize with that configuration. Once the configuration applied, it will report to the puppet master asking if there is anything needs to be changed.

Usually, the changes on the configuration in puppet master is done, it will be applied every 30 minutes on the clients.

Note: Puppet will only make any changes to the system if the system state does not match the configured state.

Lets look at technically, how puppet works by step by step.

1) Puppet generates the certificate using the system’s FQDN, when puppet starts first time.

2) Puppet submits the generated certificate to the puppetmaster. The puppetmaster will will need to sign the certificate before clients can be considered authenticated.

3)Puppet waits for 300 seconds for the signed certificate. If the puppet does not get the certificate with on 300 seconds(can be configured for different value), it will quit.

4)Puppetmaster signs the certificate. It can be configured such a way to automaticall sign the certificate, but it is NOT good idea. Other way is to manually sign the certificate.

To manually sign the certificate

#puppetca  –sign  <certificate CN>

note: it is done in puppet master. To list the requsete certificate, issu the commad

#puppetca –list

5)Puppet receives the signed certificate. Once the puppet receives the certificate, it will start configuration run immediately.

Note: Make sure the time on the puppetmaster and puppet to be same.

6) The puppet generates all the facts. Most configurations rely on client information to make decisions. When the Puppet client starts, it loads the Facter Ruby library, collects all the facts it can, and passes those facts to the interpreter. When you use Puppet over a network, these facts are passed over the network to the server and the server uses them to compile the client’s configuration.

7) Puppetmaster parses it’s manifests.

Puppet receives the manifests.

9) The puppets applies it’s manofests.

10) While the puppet applies the manifest, it pulls files from the puppetmaster’s fileserver after checking the local checksum against the remote checksum.

11) puppet sends the copy of the configuration file it replace to the puppet master.

12) puppet will send the report to the puppetmaster.

13) puppet waits for next 30 minutes by default for the next run.

Note: the files and templates are transferred using SSL communication.


Supported system platform

Linux

Fedora 7 and late r

SuSE linux 8 and later

RHEL 3 and later

Ubuntu 7 and later

Debian 3.1 and later

Unix

Macintosh OS X and later

Sun solaris 7 and later

HP-UX

Windows


Installing puppet.

Since I will be installing on fedora system, I will be writing the post based on the fedora related configuration.

Installing can be done in many ways whether downloading tarballs and then install or using yum. I would prefer using yum because it will install all the needed repository.

I installed on the fedora11 on my system, believe be it gave huge pain tying to get it working. There was lot missing necessary files and folder left not installed on the system. I tried many times to consult what the problems were behind this installations, even I consulted on #puppet on IRC chat, was not able get problem fixed. I will write about the problem were later on my post.

Eventually I gave up installing on fedora11, and that where Fedora 13 comes on the task. I had to install Fedora13 and then I Installed puppet on the fedora13 system, and it all went very well so far. The entire initial configuration is done on my fedora 13. Therefore, any what I refer here will refer as Fedora13.

This installations were done in fedora 12 systems that are Hongkong & Ireland systems in proximity.on.ca domain.

1) Install puppetmaste and puppet.

On server, In this case it will be Hongkong.proximity.on.ca

 #yum install puppet-server

it will install puppetmaster and puppet on the server which is to be as puppetmaster.

 #yum install mysql-server  ruby-mysql
 #yum install ruby-RRDtool

it will install ruby library.

On client, in this case it will be Ireland.proximity.on.ca

#yum install puppet

it will install puppet client on the client system.

2) the puppetmaster/puppet configuration file is /etc/puppet/puppet.conf

in this file there are four most important section which are

main: Primarily file locations, directory settings and other globals applicable to both the puppet as well as the puppetmaster.

Puppetca: Puppet Certificate Authority (puppetca) settings

Puppetd: puppet client daemon setting.

Puppetmasterd: puppetmaster daemon setting.

3) Make sure all the needed files and folders are created by the installation process.

On the server, Hongkong

#ls /etc/puppet

should have auto.conf , fileserver.conf, manifest puppet.conf


Some of the Puppet resourses

1)Files

2)Services

3)Packages

4)Cron jobs


4) Create a simple manifest.

a) carete sudo.pp, vi /etc/puppet/manifests/class/sudo.pp

 # /etc/puppet/manifests/classes/sudo.pp
 class sudo {
     file { "/etc/sudoers":
         owner => "root",
         group => "root",
         mode  => 440,    }
 }


b) create site.pp, vi /etc/puppet/manifests/site.pp
# /etc/puppet/manifests/site.pp 
import "classes/*"
node default { 
include sudo
}

c) start the puppet master.

#puppetmasterd  –mkusers

this option will create the puppet user that is needed.

Once the puppetmaster daemon is stated, it will create the necessary files and folders under /var/lib/puppet.

#ls /var/lib/puppet

should have bucket, clientsbucket, facts, reports, ssl, yaml, class.txt, client_yaml, l ib, rrd, state

all the details information about these files and folder will be included in the next blog.

 #service puppetmaster start

d) start the puppet client.

On the client, Ireland

#puppetd  –verbose

when the puppet client daemon starts, it creates the necessary certificate and waits for the certificate to be signed by the puppetmaster. 3)sign the certificate.

On the server

#puppetca  –list

this will list the all the requested certificate that are to be signed by puppetmaster.

#puppetca  –-sign  ireland.proximity.on.ca


Release 0.2

Functional with file server

1) file server configuration: For the the configuration to be saved

2) Some of the manifest

puppet main page

puppet wiki page


File server configuration

The last release 0.1 was installing the basic puppet installation and gets the puppet working. In the puppet master there should be service that should store and deliver the needed configuration files. Puppet can be act as the file server.

Puppet has the server and client function in file serving. The server function is configured and initiated by the puppet master daemon. The client function is embedded into the puppet client daemon and retrieves files from the puppet master file server.

Lets see how to specify the puppet file server. It is done by file type resource and using the source attribute

Ex:


file { “resolv.conf”:

Source => “puppet://puppetmaster/etc/resolv.conf”

}

The fileserver configuration is managed by the fileserver.conf that is located in the /etc/puppet directory by default. But using the following command can change the location.

In the puppet master

#puppetmasterd   --fsconfig /usr/local/etc/puppet/fileserver.conf

The fileserver.conf file defines paths to serve files from and it has the access control that specifying which nodes can access these files.

Here is an example


[configuration]
path /var/lib/puppet/files/configuration
allow  *.senecac.on.ca
deny  *

Here the each path being served is called a module. For example , configuration is a module. The use of modules allows puppet to abstract and simplify file system configuration and paths. The path statement specifies the location on the puppet master server where the files being served are located.

Lets see if we want to get the resolv.conf file from the configuration module in the file server, we simply specify as follows

file { “/etc/resolv.conf”:

source => “puppet://puppetmaster/configuration/resolv.conf”

}

what happens above is that, the file resource type need the titled /etc/resolv.conf file that is saved in the configuration module( /var/lib/puppet/files/configurtion/resolv.conf) is retrieved by the puppet.

This is the format for specifying the source:

Puppet://puppetmaster/module/files

Ex:

source => “puppet://puppetmaster/configuration/resolv.conf”

This is for only single file is being down loaded by puppet and applied to the nodes. But if we want to download the full directory, there is a small changed needs to be done when specify the source.


file { “/etc/pam.d”:

source => “puppet://puppetmaster/configuration/pam.d”
recurse => “true”

}

What we have done here is that instead of just specifying the file resource type, we specify the directory /etc/pam.d. Therefore, the puppet will download pam.d directory and applied to the nodes. The recurse attribute and value true tells the puppet server that it should download all the files from the directory.

source:Turnbull, James.Pulling strings with puppet.firstpress

Release 0.3

1)Implement in the arm farm

1) make sure hosts file contain following entry there.I have successfully installed in 192.168.1.112

192.168.1.254 hongkong.proximity.on.ca hongkong puppet

2) install the puppet client in the arm farm

#yum install puppet

for further any detail see the release 0.1

3) I hongkong the puppetmaster is already installed and configured. see the release 0.1

start the puppetmaster

  1. service puppetmaster start

4) start the client

#service puppet start

this create the necessary certificate itself for the secure communication.

5) In puppetmaster issue the folling command

#puppetca  --list

it will the client that need to be signed.

you will probably see there something like similar to "cdot-guru-1-2"

6) In the puppetmaster issue the folling command to sign the above listed client.

#puppetca    --sign   cdot-guru-1-2

this will sign the certificate.

7) for the rest of the implementation on the arm farm do the same step 1, 2,4,5,6. but use the associate host name "cdot-guru-1-x". here X is the associate the host number.

I have include some of the useful configuration down here in the document. Follow the document to configure resoucre type.


2) Fully configuration Documents

Puppet fully documentation

Puppet is open source systems and configuration management tool. It a client-server model, where server (puppetmaster) is the centralized server and client (puppet) is installed in the client system that is to be managed. Every configuration is defined in the puppetmaster, and then it is compiled and pushed out /applied to those clients.

The communication between puppetmaster and puppet is encrypted and authenticated. Puppet generates the certificate itself and signed by the puppet master to be successfully authenticated. The communication between the client and server is by default 3 minutes, if there are any changes made in the server that is to be applied to the client in the next interval of the communication.

The configurations are called resources and group of resources are called collections. Each resource is made of type, title, and attributes.

For example:


'''file {“/etc/resolv.conf”:

owner=> “root”

}'''

The resource type is file, the resource type tells the puppet what type of the resource is managed.

There are few other resources such as services, packages, cron jobs, file system and etc.

The title is “/etc/resolv.conf” that is a file to be managed by puppet.

The attribute here is owner and it has value of root. There are much more attributes available and each has it’s value associated with.

By combining many resources( package,classes, number of configuration, etc) into a collection is called classes. For example Apache is a server application and if you want to manage this, you configure the class, which has the many resource of collection and it applied to the node.

Let see an example and how we can scale the configuration

For example if you want to manage the “ypbind” in the node1

node ‘node1.example.com’{

package{“ypbind”:

ensure=> latest

}

file{“/etc/yp.conf”:
source => puppet://files/yp.conf”,
notify => service [“ypbind”],
require => package[“ypbind”]

}

service {“ypbind”:
enable => true,
ensure =>running,
require =>[
File[“/etc/yp.conf”],
package[“ypbind”]

]

}

}

This is configuration is applied to the node1.exapmle.com. Imagine if there are 100 of node to be managed, this configuration has to done again and again. This does not scale well. To reduce this configuration effort in every nodes, wed can group this in to a class instead and then include the class with each node.

For example:

# /etc/puppet/manifest/classes/yp.pp

class yp::client {

package {“ypbind”:
ensure=> latest
}

file {“/etc/yp.conf”:
source => puppet://files/yp.conf”,
notify => service [“ypbind”],
require => package[“ypbind”]
}

service {“ypbind”:
enable => true,
ensure =>running,
require =>[
File[“/etc/yp.conf”],
package[“ypbind”]

]

}

}
# /etc/puppet/manifest.pp

import “classs/*.pp”

node ‘node1.example.com’{
include yp::client
}

node ‘node2.example.com’{
include yp::client
}

what I have done is that I group the recourses type into class. Then I call the class in to each node. By doing this eliminate the configuring each resources in each node. Just call the class into each node.

But sill it cab be made to scale more. Think if there are few more classes to be applied then each classes has to be called into. For example,


# /etc/puppet/manifest/site.pp

import “classs/*.pp”

node ‘node1.example.com’{
include yp::client
include foo1
include foo2
.
.
.
include foo100

}

node ‘node2.example.com’{
include yp::client

include foo1
include foo2
.
.
.
include foo100

}

This again brings little bit more configuration over head. There to over come from this we can do it such a way,


#/etc/puppet/manifest/group/desktop.pp

class desktop {

include yp::client
include foo1
include foo2
.
.
.
include foo100

}
#/etc/puppet/manifest/site.pp

import “class/*.pp”
node ‘node1.example.com’ {
include desktop
}

What I did was group the classes into another class and apply that group into the nodes. This configuration method pretty scale well.

For the further learning about the puppet resource type, title, attribute and associated attribute value, I found a really good cheat sheet here.

Installing and configuring puppet

Please see the release 0.1

Configuring the file server

Please see the release 0.2

here are some use full links: