Difference between revisions of "User:Prathapan"
(15 intermediate revisions by the same user not shown) | |||
Line 44: | Line 44: | ||
To manually sign the certificate | To manually sign the certificate | ||
− | + | <pre> | |
− | + | #puppetca –sign <certificate CN> | |
+ | </pre> | ||
note: it is done in puppet master. To list the requsete certificate, issu the commad | note: it is done in puppet master. To list the requsete certificate, issu the commad | ||
− | + | <pre> | |
− | + | #puppetca –list | |
+ | </pre> | ||
5)Puppet receives the signed certificate. Once the puppet receives the certificate, it will start configuration run immediately. | 5)Puppet receives the signed certificate. Once the puppet receives the certificate, it will start configuration run immediately. | ||
Line 114: | Line 116: | ||
On server, In this case it will be Hongkong.proximity.on.ca | On server, In this case it will be Hongkong.proximity.on.ca | ||
− | + | <pre> | |
− | + | #yum install puppet-server | |
− | + | </pre> | |
it will install puppetmaster and puppet on the server which is to be as puppetmaster. | it will install puppetmaster and puppet on the server which is to be as puppetmaster. | ||
− | + | <pre> | |
+ | #yum install mysql-server ruby-mysql | ||
+ | </pre> | ||
− | + | <pre> | |
+ | #yum install ruby-RRDtool | ||
+ | </pre> | ||
it will install ruby library. | it will install ruby library. | ||
Line 127: | Line 133: | ||
On client, in this case it will be Ireland.proximity.on.ca | On client, in this case it will be Ireland.proximity.on.ca | ||
− | + | <pre> | |
+ | #yum install puppet | ||
+ | </pre> | ||
it will install puppet client on the client system. | it will install puppet client on the client system. | ||
+ | |||
2) the puppetmaster/puppet configuration file is /etc/puppet/puppet.conf | 2) the puppetmaster/puppet configuration file is /etc/puppet/puppet.conf | ||
Line 146: | Line 155: | ||
On the server, Hongkong | On the server, Hongkong | ||
+ | <pre> | ||
#ls /etc/puppet | #ls /etc/puppet | ||
+ | </pre> | ||
− | + | should have auto.conf , fileserver.conf, manifest puppet.conf | |
Line 165: | Line 176: | ||
a) carete sudo.pp, vi /etc/puppet/manifests/class/sudo.pp | a) carete sudo.pp, vi /etc/puppet/manifests/class/sudo.pp | ||
+ | <pre> | ||
# /etc/puppet/manifests/classes/sudo.pp | # /etc/puppet/manifests/classes/sudo.pp | ||
class sudo { | class sudo { | ||
Line 172: | Line 184: | ||
mode => 440, } | mode => 440, } | ||
} | } | ||
+ | </pre> | ||
+ | |||
b) create site.pp, vi /etc/puppet/manifests/site.pp | b) create site.pp, vi /etc/puppet/manifests/site.pp | ||
+ | <pre> | ||
# /etc/puppet/manifests/site.pp | # /etc/puppet/manifests/site.pp | ||
− | |||
import "classes/*" | import "classes/*" | ||
node default { | node default { | ||
include sudo | include sudo | ||
} | } | ||
+ | </pre> | ||
c) start the puppet master. | c) start the puppet master. | ||
− | + | <pre> | |
− | + | #puppetmasterd –mkusers | |
+ | </pre> | ||
this option will create the puppet user that is needed. | this option will create the puppet user that is needed. | ||
Line 190: | Line 206: | ||
Once the puppetmaster daemon is stated, it will create the necessary files and folders under /var/lib/puppet. | Once the puppetmaster daemon is stated, it will create the necessary files and folders under /var/lib/puppet. | ||
− | + | <pre> | |
+ | #ls /var/lib/puppet | ||
+ | </pre> | ||
should have bucket, clientsbucket, facts, reports, ssl, yaml, class.txt, client_yaml, l ib, rrd, state | 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. | all the details information about these files and folder will be included in the next blog. | ||
− | + | <pre> | |
− | + | #service puppetmaster start | |
+ | </pre> | ||
d) start the puppet client. | d) start the puppet client. | ||
On the client, Ireland | On the client, Ireland | ||
− | + | <pre> | |
− | + | #puppetd –verbose | |
+ | </pre> | ||
when the puppet client daemon starts, it creates the necessary certificate and waits for the certificate to be signed by the puppetmaster. | when the puppet client daemon starts, it creates the necessary certificate and waits for the certificate to be signed by the puppetmaster. | ||
Line 208: | Line 228: | ||
On the server | On the server | ||
− | + | <pre> | |
− | + | #puppetca –list | |
+ | </pre> | ||
this will list the all the requested certificate that are to be signed by puppetmaster. | this will list the all the requested certificate that are to be signed by puppetmaster. | ||
− | + | <pre> | |
− | + | #puppetca –-sign ireland.proximity.on.ca | |
+ | </pre> | ||
== '''Release 0.2''' == | == '''Release 0.2''' == | ||
− | Functional with file server | + | '''Functional with file server''' |
1) file server configuration: For the the configuration to be saved | 1) file server configuration: For the the configuration to be saved | ||
Line 228: | Line 250: | ||
[http://projects.puppetlabs.com/projects/puppet/wiki puppet wiki page] | [http://projects.puppetlabs.com/projects/puppet/wiki 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: | ||
+ | <pre> | ||
+ | |||
+ | file { “resolv.conf”: | ||
+ | |||
+ | Source => “puppet://puppetmaster/etc/resolv.conf” | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | 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 | ||
+ | <pre> | ||
+ | #puppetmasterd --fsconfig /usr/local/etc/puppet/fileserver.conf | ||
+ | </pre> | ||
+ | |||
+ | 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 | ||
+ | <pre> | ||
+ | |||
+ | [configuration] | ||
+ | path /var/lib/puppet/files/configuration | ||
+ | allow *.senecac.on.ca | ||
+ | deny * | ||
+ | </pre> | ||
+ | |||
+ | 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 | ||
+ | |||
+ | <pre> | ||
+ | file { “/etc/resolv.conf”: | ||
+ | |||
+ | source => “puppet://puppetmaster/configuration/resolv.conf” | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | 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: | ||
+ | <pre> | ||
+ | source => “puppet://puppetmaster/configuration/resolv.conf” | ||
+ | </pre> | ||
+ | |||
+ | 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. | ||
+ | |||
+ | <pre> | ||
+ | |||
+ | file { “/etc/pam.d”: | ||
+ | |||
+ | source => “puppet://puppetmaster/configuration/pam.d” | ||
+ | recurse => “true” | ||
+ | |||
+ | } | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | 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 | ||
+ | |||
+ | <pre> | ||
+ | #yum install puppet | ||
+ | </pre> | ||
+ | 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 | ||
+ | |||
+ | #service puppetmaster start | ||
+ | |||
+ | 4) start the client | ||
+ | <pre> | ||
+ | #service puppet start | ||
+ | </pre> | ||
+ | this create the necessary certificate itself for the secure communication. | ||
+ | |||
+ | 5) In puppetmaster issue the folling command | ||
+ | |||
+ | <pre> | ||
+ | #puppetca --list | ||
+ | </pre> | ||
+ | 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. | ||
+ | <pre> | ||
+ | #puppetca --sign cdot-guru-1-2 | ||
+ | </pre> | ||
+ | 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: | ||
+ | <pre> | ||
+ | |||
+ | '''file {“/etc/resolv.conf”: | ||
+ | |||
+ | owner=> “root” | ||
+ | |||
+ | }''' | ||
+ | </pre> | ||
+ | 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 | ||
+ | |||
+ | <pre> | ||
+ | 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”] | ||
+ | |||
+ | ] | ||
+ | |||
+ | } | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | 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: | ||
+ | <pre> | ||
+ | # /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”] | ||
+ | |||
+ | ] | ||
+ | |||
+ | } | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | # /etc/puppet/manifest.pp | ||
+ | |||
+ | import “classs/*.pp” | ||
+ | |||
+ | node ‘node1.example.com’{ | ||
+ | include yp::client | ||
+ | } | ||
+ | |||
+ | node ‘node2.example.com’{ | ||
+ | include yp::client | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | 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, | ||
+ | |||
+ | <pre> | ||
+ | |||
+ | # /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 | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | This again brings little bit more configuration over head. There to over come from this we can do it such a way, | ||
+ | |||
+ | <pre> | ||
+ | |||
+ | #/etc/puppet/manifest/group/desktop.pp | ||
+ | |||
+ | class desktop { | ||
+ | |||
+ | include yp::client | ||
+ | include foo1 | ||
+ | include foo2 | ||
+ | . | ||
+ | . | ||
+ | . | ||
+ | include foo100 | ||
+ | |||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | #/etc/puppet/manifest/site.pp | ||
+ | |||
+ | import “class/*.pp” | ||
+ | node ‘node1.example.com’ { | ||
+ | include desktop | ||
+ | } | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | 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: |
Latest revision as of 15:32, 23 April 2011
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
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
- 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: