Getting Started With Puppet: How to Write Your First Module

1361349665_puppet-logoThis post will walk you through the process of writing your first, albeit, a very simple Puppet module. Nothing fancy here, that can come later once we get the basics down.

Before we get started let’s take a minute to go through a couple of prerequisites.

First, we will assume that you are doing your work some sort of Linux workstation or server. Second, we will assume that you have already installed and configured a Puppet Master and a Puppet Client. In this particular case, I am working on my Fedora 20 desktop. It serves as both my master and client. Last, we are assuming that have a basic site.pp and are able to run the Puppet agent without issue or error.

Now lets get down to the meat and potato. Note we are working with opensource Puppet, not Puppet Enterprise.

First lets change directory to our Puppet module directory.

#cd /etc/puppet/modules/

Now lets create a basic manifest from a template, to do this we need to generate a module. Our very simple module is going to be called harden-cron. Run the command below to generate our bare-bones module

#puppet module generate harden-cron

Now that our module has been generated lets change directories once again. This time we need to change to the manifests directory in our newly created module.

#cd harden-cron/manifests/ && vim init.pp

Now we need to edit our manifest. This is, more or less, our playbook. It defines what “work” puppet needs to do.

Our end goal is to create a manifest that will ensure that /etc/cron.allow exists, is owned by root, and has specific file permissions. We also need to make sure that /etc/cron.deny does not exist. In order to accomplish this we use the simple code shown below. Note that we have defined our class has “harden-cron”. This is the same name that we used when creating our module above.

[code language=”css”]

class harden-cron {

file {"/etc/cron.deny":
ensure => absent,
}

file {"/etc/cron.allow":
ensure => present,
owner => "root",
group => "root",
mode => "600"
}
}

[/code]

Now we need to test our syntax and make sure that we have not made any errors. Use the command below to accomplish this. No output from the script below means that you do not have any syntax errors.

#puppet parser validate init.pp

Excellent, so now we have a new module, but its not going to do anything for us until we declare it in our site.pp. So lets change directories and do a bit of editing

# cd /etc/puppet/manifests/ && vi site.pp

Continue reading

Getting Started with Git: Creating a Git Repo

NettutsFetch-1So first off let me start by saying that I know that there is a ton of information out there on how to get started with Git. Heck, when you create your repo in GitLab it spits these instructions right out in front of your nose. However, what I have found is that most instructions tell you what to do to get started with git, however they do not tell you exactly what you are doing. You end up running a few command and then sit back and try to figure out what you actually just did.

 

That being said, getting started with Git has been the hardest part of the process, as most of us traditional grey-beard sysadmins are not that familiar with code management. When I was first getting started in technology, there were developers and there were sysadmins, and those two worlds were extremely separate. Now, we as we enter the age of DEVOPS and automation these two worlds are once again colliding (like they did in the beginning, but more on that another day).

 

 In my lab I decided to build a stand alone vm for Git and Puppet. After doing some research – and asking others– on how and what to do to get Git up and running with a nice front end web interface, I decided to get started by installing the GitLab Omnibus package for Centos 6. This process was quick, easy, and painless.

 

Once I had a working webUI up and running it was time to create my first repo. Instead of trying to accomplish this from my Fedora workstaion, I just clicked on the "New Project" button on the GitLab dashboard and created an empty repo called "General_Scripts".

 

Back on my Fedora workstation I created a new directory in my home dir called git, and inside that directory I created a directory called "General_Scripts" as I had done in the webUI.

 

Now it was time to use Git.

 

First off you need to configure a few global Git options. This only needs to be done once.

#git config –global user.name "Fatmin"

#git config –global user.email "fatmin@fatmin.com"

 

Once these global configs are set you can then you can move on to seeding your repo. Here you see my change directories to the Global_Scripts directory and tell Git to initialize this directory as a repo.

#cd Global_Scripts

#git init

 

Now lets create a file and add it to the repo. Here were are going to create a simple README containing a description of my new repo. The instructions do not tell you that you have to put anything in this initial file, however what good is an empty README anyway

#vi README.md

 

Now tell git that this file needs to be added to the "General_Scripts" repo that we created a few steps ago.

#git add README.md

 

Now lets commit that file with a nice little comment. Commit comments should describe what the file we added or what we changed in an existing file

#git commit -m "Added README.md"

 

Now we need to tell our local git command what remote repo we are going to sync to. Note my git repo url is puppet.lab.localdomain, fatmin is my user's namespace, and General_Scripts is my repo.

#git remote add origin git@puppet.lab.localdomain:/fatmin/General_Scripts.git

 

Now we need to actually push the local files to the remote repo (origin) in the master branch.

#git push -u origin master

 

Now wait a bit and go check out the webUI. You should now see the README.md file in your new remote repo.

Related articles

Super Quick Git Guide
Bashit… Just a Custom Bash Prompt Setup for Git
Git and GitHub LiveLessons

HomeLab: Simple DHCP Service Configuration on a Cisco Router

Cartoon-golfer-009Sometimes when I learn something new in the world of technology, I am often amazed that something that I assumed was technically advanced is rather quite simple.

Such is the case with configuring DHCP on a Cisco Router. I mean, is it just me or do network guys sometimes act as if everything that they do is takes elite technical skills and tons of experience. Don’t get me wrong, I know that networking is not exactly easy. But can we just agree to admit that once in a while some things are easier done than said. Anyway, for me this was the case with configuring a DHCP pool on a Cisco Router.

In this instance I was working on getting a new virtual machine up and running on my ESXi host. This particular appliance needed to boot via dhcp so you could access its web interface. So I jumped on my 2621xm and created the pool.

First we enable the dhcp service

r-2621-1(config)#service dhcp

Then we create a pool

r-2621-1(config)#ip dhcp pool LabPool
r-2621-1(dhcp-config)#network 10.2.0.1 255.255.255.0

Next we set a few bits and bobbles so that clients can route.

r-2621-1(dhcp-config)#dns-server 10.2.0.71
r-2621-1(dhcp-config)#default-router 10.2.0.1
r-2621-1(dhcp-config)#domain-name localdomain

In this case I wanted to exclude a bunch of ips from the range

r-2621-1(dhcp-config)#ip dhcp excluded-address 10.2.0.1 10.2.0.100

Now save your config with copy run start.

The command below shows me all my dhcp clients

r-2621-1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
Hardware address/
User name
10.2.0.101          0050.569a.7dbe          Oct 16 2013 11:21 PM    Automatic

This handy command shows me information pertaining to my pool

r-2621-1#show ip dhcp pool

Pool LabPool :
Utilization mark (high/low)    : 100 / 0
Subnet size (first/next)       : 0 / 0
Total addresses                : 254
Leased addresses               : 1
Pending event                  : none
1 subnet is currently in the pool :
Current index        IP address range                    Leased addresses
10.2.0.102           10.2.0.1         – 10.2.0.254        1
r-2621-1#show ip dhcp conflict

Related articles

HomeLab: Simple Cisco EIGRP Setup
Cisco DHCP Client Lease Time
HomeLab: Simple SSH Setup on a Cisco Router
HomeLab: Cisco 2621 Router Password Recovery/Factory Reset
Configuring InterVLAN Routing on a Layer 3 Switch and providing DHCP to multiple subnets Part 1