Puppet: How Not To Generate a Certificate with Your Correct Hostname

954f7381089ac290b4690c5ffd9dd7d3_400x400So, I’ve been hacking away in my homelab as of late, building out a CentOS kickstart server, a Git server, and a puppet server. Right now, I am working on how to roll my puppet agent installs into my kickstart process. I just started on this, so I have yet to nail it down.

So currently, when kicking a VM, I am not yet setting my new CentOS node’s hostname before the install process. Sadly I am setting it manually as I am still building my kickstarts, and they are no where near where I want them to be.

Well, this whole hostname mumbo-jumbo just creates all sorts of issues for puppet… the hostname is one thing initially, then puppet installs as part of the post, and the hostname is set manually to finalize the install. Well this is no good, as you are are not going to be able to add your new node properly until you step in and provide a bit of manual persuasion.

Now while its not hard to find documentation on how to troubleshoot puppet node and master certificate issues — see here and here for example — none of it was written to help troubleshoot the mess that I had created.

Here was my specfic error.

Error: Could not request certificate: The certificate retrieved from the master does not match the agent’s private key.
Certificate fingerprint: BE:B6:B6:5E:AC:B8: ..truncated

And here verbatim, is the output that you get in response to the error above.

To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regenerate a certficate.

On the master:
  puppet cert clean localhost.localdomain

On the agent:
  rm -f /etc/puppetlabs/puppet/ssl/certs/localhost.localdomain.pem
  puppet agent -t

So we try that and it doesn’t work. The next cert I generate identifies my node as localhost again.

So heres how to fix the issue.

# rm -rf /etc/puppetlabs/puppet/ssl

Now before we generate another certificate for our node, lets test what hostname a new cert would have using the command below.

#puppet agent –verbose –configprint certname

If the command above does not spit out the correct hostname, then you my friend, are in luck. Edit the file below

# vi /etc/puppetlabs/puppet/puppet.conf

Now change the entry below by removing the localhost.localdomain, and replacing that mess with the correct hostname

certname = correcthostname.localdomain

Now kickoff a puppet run on the node

#puppet agent -t

Log into the UI, or ssh into the puppet master, and accept the new node request.

Kick off another puppet run after you have accepted the request to seal the deal and update the new node properly.

Related articles

How to Create a Vagrant Base Box from an Existing One
Some brief notes on Docker

How to Add and Delete Persistant Routes in AIX

Chatter-phone-300x234Wow, AIX does not like to make anything easy. Nor do they like to make things intuitive. Need to remove a route from AIX, well get ready to have one command to temporariliy remove a route and another command to remove the route for good. Same goes with adding a route. "Quit your bitching, and use Smitty", you say? Well smitty does not make anything any easier, especially since the UI likes to show you fields that you does not necessarily need you to use. Oh, plus they let you type in them. Asking me for a netmask when adding a static route does not seem like a crazy request to me? But jokes on you, you were not supposed to type anything there.

Anyway, I was tasked with cleaning up a few bad routes that were added to a handful of servers. Note that I was not interested in adding the routes temporarily before I added them as persistent routes. These were simple one liners that I felt very comfortable adding to the ODM right out the gate.

So first we need to check the ODM for the routes that we need to remove. In this example we want to delete the route fro 10.11.1.56, so lets find just that route. Note all of these are host routes.

# lsattr -El inet0 | grep 10.11.1.56
route host,-hopcount,0,,-if,en1,,,,-static,10.11.1.56,10.22.13.1 Route True

 

Now lets delete the route above

# chdev -l inet0 -a delroute=10.11.1.56,10.22.13.1

 

We have a second route to delete so lets kill that one too

# chdev -l inet0 -a delroute=10.11.1.57,10.22.13.1

 

Now lets add the correct routes – the format is as shown below

chdev -l inet0 -a route=host,-hopcount,1,-netmask,netmask,network,gateway

 

Now on a few of the servers I was working on I had to remove network routes as well as host routes. You need to know that the syntax is anoyingly different adding network routes. In the example below I first need to remove the network route.

chdev -l inet0 -a delroute="net,-hopcount,0,,,,,,-static,10.11.1.56,10.11.1.254"

 

Now lets add our new and correct route

chdev -l inet0 -a route="host,-hopcount,0,,,,,,-static,10.11.1.56,172.30.150.190"

Related articles

Basic AIX Performance Troubleshooting Commands
How to Add Multiple Routes in Linux Using ip Command Examples
PowerPath, AIX 5.3, and LTG: Solutions

XenServer 6 – Deleting a Storage Repository From the Command Line

8-inch-floppy-disks

So before we get started deleting a Storage Repository, we need to know a few key terms.

In XenServer a Storage Repository is a storage target that contains virtual disks (VDIs) and isos.

A PBD (physical device block) is what they call the interface between a physical host and an attached SR, which is responsible for storing the device config that allows the host to interact with the storage target.

So now that we have gotten that out of the way, lets get started.

First list the SRs on a host.

#xe sr-list uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346

Using the uuid from the you got from the command above, run the command below using the UUID, which for some reason you are calling the sr-uuid.

#xe pbd-list sr-uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346

uuid ( RO) : a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a
host-uuid ( RO): 4a9971f7-1e59-4e02-b849-04d206ee7b2b
sr-uuid ( RO): 9a9e7903-7c0f-4f7e-f0a3-e39c54478346
device-config (MRO): device: /dev/disk/by-id/edd-int13_dev81
currently-attached ( RO): true

Now using the the UUID output of from the command above, unplug the pdb.

#xe pbd-unplug uuid=a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a

Then destroy it….boom.

#xe pbd-destroy uuid=a89b78ca-cb3d-0b44-5d0b-9cf2c8ad755a

Now tell Xenserver to “forget” the SR.

#xe sr-forget uuid=9a9e7903-7c0f-4f7e-f0a3-e39c54478346