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  resourcre type.

2)Puppet – fully configuration

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:

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.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

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

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

Radius is a server for remote user authentication, authorization,and accounting using radius protocol. Its primarily used for centralized AAA in the networking IT systems. There are lot of details but the purpose of the this is to install from the source code, so I just going to write about how to install from source.

1) Download the source from

wget://ftp://ftp.gnu.org/gnu/radius/radius-1.6.tar.gz

2) run untar it

$ tar -xvzf radius-1.6.tar.gz

3) change the directory

$ cd radius-1.6

4) Issue the command  ls -al and see if there is any configure file. Of course, there is one and run it

$ ./configure

5) run make, and make install

$ make

# make install (Note: this has to run as root)

Note: After untar the file, look inside what are inside the folder, usually the source file come with instruction( README, INSTALL) that specifically tells you what to do. I install this, only for the purpose of the SBR600 lab and not for the AAA. in that case are some additional option should be required to be issued with ./configure. Maybe later on I’ll write about installing radius for real world scenario  once I done in my home lab.

Lets look at what happen during this process.
when the source code is downloaded, it comes with the Makefile or makefile which contains the necessary script or coding to required for the process. when running the make which is specialized script language to build the software, will execute the makefile script ( makefile or Makefile ) and produce the target file or software.

Typical steps are installing from source

1) Download the tar ball
2) Untar it (use tar -xvzf or unzip )
3) Changed the current directory to the directory containing the untarred files.
Note: Issue the ll command and ,see whether INSTALL or README files are there. It is really recommended to read those file because they have the instruction how the source to be installed.
4)Run the ./configure
5) Run make
6) run make install

Ex: Compiling and installing Nled
1) Download the software tarball
$ wget http://cdot.senecac.on.ca/software/nled/nled_2_52_src.tgz
2) unzip it
$ tar -xvzf nled_2_52_src.tgz

3) Change the directoty
$ cd nled_2_52

$ ll and see , there are necessary intermediate files which are needed when the makefile is being executed
4) Run make
Note: Never run “make” as a root!!!!!!
$ make
When I run the make, it gave some errors that saying “ncurses.h: no such file or directory”, this is because of the development library is not installed. I did some rpm query found out -devel is missing, and by using yum this problem can be resolved, just issue the following command as root

# yum install ncurses-devel

then I re run the make command, and it was successfully compiled

5) finally run
$ make install

Here are my links

1)my IRC inck name is Prathapan

2) Link to user page to Seneca wiki
http://zenit.senecac.on.ca/wiki/index.php/User:Prathapan
3) Link to user page to Fedora wiki
https://fedoraproject.org/wiki/User:Prathapan