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

November 9, 2014December 1, 2014 / Christopher Paquin

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

How to Create a Vagrant Base Box from an Existing One

Some brief notes on Docker

Vmware Vcenter Operations Manager Unregister a Vcenter Server via the CLI

September 27, 2014November 28, 2014 / Christopher Paquin

So my Windows based Vmware Vcenter Server went belly up again. Something to do with the SSO database not starting. Not being a lover of Windows I decided to give the Vcenter Server Appliance a shot. Install was great and I am kicking myself a bit as to why I spent so much time fighting with Windows. My new Vcenter Server, which has a different IP address then the original Windows box (might make a great Veeam server) was not registered with Vcenter Operations Manager. I was not prepared to reinstall that thing again. So I needed to figure out how to manually unregister a Vcenter instance and add register another one in its place.

Since VCOPs runs Linux, I decided to ssh into the server and see if I could figure it out. First thing I found that I needed to do was figure out the registered Vcenter Server name and Vcenter Name (whatever that's supposed to be) I was able to do this using the vcops-admin command.

admin@vcops:~> vcops-admin summary

This command output a bunch of stuff, but the important bits for this task are below.

Registration Details
——————–
vCenter Server address = https://vc00.lab.localdomain/sdk
vCenter Server name = Lab Vcenter

So now we need to unregister the sucker above. Note that this command takes a bit to unregister

admin@vcops:~> vcops-admin unregister –vc-name Lab\ Vcenter –vc-server https://vc00.lab.localdomain/sdk –user LAB\\userid –password mypassword–force

vCenter Server unregister = success

So flip on over to your browser and log in. The unregister process will cause the webUI to reload, so if you were already logged in you will find that you still need to log in again.

Now you can register your new Vcenter Server via the webUI.

Vmware VCenter Virtual Appliance – Death to Windows.. I think.

ESX 5: How to Power On A Virtual Machine from the Command Line

vCenter Operations Manager: VMware's move into cloud monitoring?

VCOPs – VMware's Move into Cloud Monitoring

How to Manage Password Aging in Solaris, AIX, and Linux

April 4, 2014November 28, 2014 / Christopher Paquin

Its possible that sometime in your short, meaningless life, you may need to create an account that has a password that is set to never expire. This is somethimes the case with headless accounts and specialty accounts such as the type you might have to setup for monitoring or security scanning. You might also find yourself setting up shared headless accounts that have locked passwords in order to block direct logins. This second scenario can be especially troublesome when this is some sort of application or database user with cron jobs, as even an account without a password and expire and lock. If this occurs all of a users cron jobs will fail. All because the account expired.

So today we are going to configure a user password not to expire.

Lets start with Solaris. First lets unlock the account just in case.

passwd -d username

Now you can turn off password aging for a user with the command below.

passwd -x -1 username

You can then verify your config with the following.

passwd -s dmadmin

The output of the command above should look similar to what I have below. In this example our user id is myuser.

#passwd -s myuser
myuser  PS

Compare what you see above to the output below for our example myuser1, which includes the date that the password was last changed, the minimum number of days between password changes, the maximum number of days required between password changes, and the number of days of warning a user is given before a password expires. Standard system password aging and expiration still applies.

#passwd -s myuser1
myuser1  PS    09/30/13     7    28     7

Now lets move on to Linux. First lets ulock. Then we will configure the password to not expire. Then we can verify our work with the chage -l command.

passwd -u username

chage -m 0 -M 99999 -I -1 -E -1 username

change -l username

So now lets take a visit to AIX land. Remember to not stay long. Again, its always best to make sure that the current password is not locked. Then we configure the password to not expire. Finally we step back and admire our work.