So let's get started.

Getting stored configs working with MySQL

Install Rails:

[root@puppet]# gem install rails -v 2.2.2

Install MySQL server and the MySQL gem:

[root@puppet]# yum install mysql mysql-devel mysql-server

[root@puppet]# gem install mysql -- --with-mysql-config=/usr/bin/mysql_config

Create the puppet database:

[root@puppet]# mysql -u root -p

mysql> create database puppet;
mysql> grant all privileges on puppet.* to puppet@localhost
identified by 'password';

Add table index:

mysql> create index exported_restype_title on resources (exported,
restype, title(50));

Edit your puppet.conf:

storeconfigs = true
dbadapter = mysql
dbname = puppet
dbuser = puppet
dbpassword = password
dbserver = localhost
dbsocket = /var/lib/mysql/mysql.sock

To check it's working:

mysql -u puppet -p -D puppet -e 'select name,last_compile from hosts;'

This should output hosts and last compile time. You may need to run a Puppet agent against the server to see this updating.

Getting Puppet Dashboard working

Install the Puppet Dashboard rpm:

[root@puppet]# rpm -ivf http://downloads.puppetlabs.com/dashboard/puppet-dashboard-1.2.2-1.el6.noarch.rpm

Now, let's configure Dashboard:

[root@puppet]# cd /usr/share/puppet-dashboard/config

Configure settings.yml with your favourite text editor:

a_server: 'puppet.tomhayman.co.uk'

Then configure database.yml, keeping the database details the same as above:

production:
database: puppet
username: puppet
password: password
encoding: utf8
adapter: mysql

test:
database: puppet
username: puppet
password: password
encoding: utf8
adapter: mysql

Create the Dashboard database schema, so go up a level to here (/usr/share/puppet-dashboard)

Then run:

[root@puppet]# rake db:migrate

Copy the Apache vhost config file from the example Puppet Dashboard gives you:

[root@puppet]# cp /usr/share/puppet-dashboard/ext/passenger/dashboard-vhost.conf /etc/httpd/conf.d/puppetdashboard.conf

You will need to alter a few things inside that conf file. Mine is like this but you may want to tune some parameters, depending on your needs.


PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
PassengerStatThrottleRate 120
RailsAutoDetect On
ServerName puppetdashboard.tomhayman.co.uk
DocumentRoot /usr/share/puppet-dashboard/public/
#SetEnv RAILS_ENV production
#RackBaseURI

ErrorLog /var/log/httpd/dashboard.example.com_error.log
LogLevel warn
CustomLog /var/log/httpd/dashboard.example.com_access.log combined

Check the Apache config reports no errors by checking the config:

[root@puppet]# apachectl -t -f /etc/httpd/conf.d/puppetdashboard.conf

Any problems you will obviously need to fix before you restart Apache.

Create logs for Dashboard:

[root@puppet]# touch /usr/share/ puppet-dashboard/log/production.log

[root@puppet]# chmod 0666 /usr/share/ puppet-dashboard/log/production.log

To enable inventory support, first check what you need to do at Puppetlabs.

In a nutshell, you need to change just a few settings. Go to settings.yml and change:

enable_inventory_service: true

Create the SSL certificates:

[root@puppet]# rake cert:create_key_pair RAILS_ENV=production

[root@puppet]# rake cert:request RAILS_ENV=production

Then sign it:

[root@puppet]# puppetca -s dashboard

A little mistake I ran into was the certificates need to be owned by the dashboard user. So, change the ownership of the certs directory so that the puppet-dashboard user can access them:

[root@puppet]# chown puppet-dashboard:puppet-dashboard -R certs/

Add this to /etc/puppet/auth.conf

path /facts
auth any
method find, search
allow *

Then, restart Apache:

[root@puppet]# apachectl restart

Start the Dashboard workers:

[root@puppet]# /etc/init.d/puppet-dashboard-workers start

You may need to run the puppet agent on a node first to see puppet Facts appear on the Puppet Dashboard.

That's it!

Getting Passenger working

Add the following into your puppet.conf:

[master]
ssl_client_header = SSL_CLIENT_S_D
ssl_client_verify_header = SSL_CLIENT_VERIFY

Install the following on our Puppet server:

[root@puppet]# yum install gcc-c++ httpd-devel apr-devel ruby-devel ruby-rdoc

Install some gems:

[root@puppet]# gem install -v=1.0.1 rack

[root@puppet]# gem install -v=2.3.5 activerecord

And Passenger:

[root@puppet]# gem install -v=2.2.11 passenger

And:

[root@puppet]# passenger-install-apache2-module

If this final install of Passenger fails it will tell you where it went wrong so fix as and if needed.

Install mod_ssl:

[root@puppet]# yum install mod_ssl

Create the document root:

[root@puppet]# mkdir -p /usr/share/puppet/rack/puppetmasterd/public

Now we need to create the Apache configuration in /etc/httpd/conf.d/puppet.conf:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11
PassengerRuby /usr/bin/ruby

Listen 8140

SSLEngine on
SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
SSLCertificateFile /var/lib/puppet/ssl/certs/test.tomhayman.co.uk.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/test.tomhayman.co.uk.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
# CRL checking should be enabled; if you have problems withApache complaining about the CRL, disable the next line
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars

# The following client headers allow the same configuration to work with Pound.
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

RackAutoDetect On
DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/

Options None
AllowOverride None
Order allow,deny
allow from all

Check the Apache configuration with an apachectl configtest and again fix any errors you encounter.

Now, copy the Rack config:

[root@puppet]# cp /usr/share/puppet/ext/rack/files/config.ru /usr/share/puppet/rack/puppetmasterd/

Give Puppet correct permission to access the Rack config:

[root@puppet]# chown puppet:puppet /usr/share/puppet/rack/puppetmasterd/config.ru

Stop the Puppet server with a service puppetmaster stop so it won't interfere with Passenger. Remember to deactivate the puppetmaster service via chkconfig too. Then start Apache and you should have Passenger working.

To check from our Puppet client:

[root@pclient]# puppetd --noop --test --server puppet.tomhayman.co.uk --port 8140

In part three we will get stored configurations working and also Puppet Dashboard. I hope this has helped and if you run into any problems let me know and I'll try and give you a hand.

Firstly, ensure the FQDN (i.e. puppet.tomhayman.co.uk) is set up properly on the server otherwise your Puppet clients will not be able to connect.

In this example, we're going to have the following setup:

puppet.tomhayman.co.uk 192.168.1.10 = Puppet server

pclient.tomhayman.co.uk 192.168.1.20 = Puppet client

Next, add a puppet.repo to /etc/yum.repos.d/ on both server and client:

[puppetlabs]
name=Puppet Labs Packages
baseurl=http://yum.puppetlabs.com/el/6/products/x86_64/
enabled=1
gpgcheck=0
[puppetlabs2]
name=Puppet Labs Packages Deps
baseurl=http://yum.puppetlabs.com/el/6/dependencies/x86_64/
enabled=1
gpgcheck=0

Also, add the EPEL repository.

Now, install Puppet server on the server:

[root@puppet]# yum install puppet-server

And install the Puppet client on the client:

[root@pclient]# yum install puppet

Start the Puppet server to generate the SSL certificates:

[root@puppet]# service puppetmaster start

Check the SSL certificates have been generated by verifying their existence in /var/lib/puppet/ssl.

Let's see if the Puppet server and client can communicate with each other.  Note, you may need to open up your firewall for this to work, so open port 8140 on the Puppet server to allow the Puppet client access.   For iptables:

[root@puppet]# iptables -I INPUT -s 192.168.1.20 -m tcp -p tcp --dport 8140 -j ACCEPT

Save the iptables and restart the service.

Next, on the client, generate a SSL certificate request:

[root@pclient]# puppetd --waitforcert 30 --server puppet.tomhayman.co.uk -v

On the server check whether it has received the request:

[root@puppet]# puppetca -l

If it has worked, the output should be similar to:

pclient.tomhayman.co.uk xxxxxxxxxxxxxxxx

Then sign the request:

[root@puppet]# puppetca -s pclient.tomhayman.co.uk

If you run into any problems with generating or signing the certificates, check in the /var/lib/puppet/ssl directory and remove them if necessary.  You can also run puppetca -c pclient.tomhayman.co.uk which revokes the certificate.

Check if everything is working by running this on the client:

[root@pclient]# puppetd  --debug --server puppet.tomhayman.co.uk

This will output any errors if there are any.

Now you should have a working Puppet server communicating with a Puppet client, in part two we will get Passenger installed.

Let's create the text file with the listed packages on server1:

[root@server1]# rpm -qa > installed.txt

Then let's copy installed.txt from server1 using scp to server2, like this:

[root@server1]# scp installed.txt tom@server2:/home/tom

Now ssh to server2 and do this:

[root@server2 tom]# yum -y install $(cat installed.txt)

This will now install all the packages listed in installed.txt on server2. This has helped me out a few times and hope it helps anyone else out there too.

(N.B. This example was carried out on two Centos 5.6 servers but could easily work on other distributions. However, it goes without saying that each server will need to have the same architecture and distribution for this to work properly.)

First, create a directory where the partition will be mounted:

mkdir /media/ntfs

Find the UUID of the NTFS partition:

sudo blkid

This will output something similar to:

/dev/sda1: UUID="B070ED7770DD452A" TYPE="ntfs"

If you have multiple NTFS partitions you will need to work out which one you want to automatically mount each time you boot.

Backup your fstab configuration (just in case you break something):

cp /etc/fstab /home/you/backup

Then add this line to /etc/fstab changing the UUID:

UUID=B070ED7770DD452A /media/ntfs ntfs rw,auto, uid=1234, umask=0027, nls=utf8 0 0

You can also set the "uid" to your own user id (uid=1234 is the example used here) and you can find this out by issuing id -u at the command line. Mounting file systems with specific user (or group) ids can be useful for the security of your system.
Umask = 0027 means you can read, write, or execute any files in the NTFS partition.

Check if it works:

sudo mount /media/ntfs && df

This should output various file systems including your newly mounted NTFS partition:

/dev/sda1 1 70226940 58935140 11291800 84% /media/ntfs

The next time you reboot the NTFS partition will automatically mount. To add more than one partition (or disk) just repeat the steps above, adding a new line for every additional partition into the fstab configuration file.

Hope this helps.

I logged into the vCenter server, then into the vSphere client with the domain administrator account and the same problem occurred. I carried out a few troubleshooting steps to see if anything was obviously at fault. First of all I used telnet to log into one of the domain controllers on the LDAP port (389) and received a successful response. I checked the event logs on the domain controllers and didn't see any issues so I began some more tests.

It was only when I stopped the VirtualCenter Server service and checked the logon account that I noticed it was using the local administrator's account. When I changed the logon account to the domain administrator, restarted the services,  it came up with the full global address list first time.    Sometimes a simple fix is the best kind.

I haven't managed to find any VMware Knowledge Base articles about this problem yet but I’m sure other people have come across this issue.    I hope this post helps anyone suffering from the same problem.

To query the FSMO (Flexible Single Master of Operation...) roles do the following command on an elevated command prompt:

netdom query fsmo

This will query the FSMO roles on the domain that the server belongs.

To specify another domain issue this command:

netdom query /d:tomhayman fsmo

To specify the server which performs the query:

netdom query /s:myserver fsmo

To find out more about netdom, type:

netdom/help

This is how I did it on a spare Centos server.

Install cups:

yum groupinstall printing

Start cups:

service cups start

Activate automatic startup:

chkconfig cups on

The main conf files are kept in the usual places:

/etc/cups/classes.conf = configure groups of printers
/etc/cups/client.conf = default server
/etc/cups/cupsd.conf = main conf file

To configure the web based gui for Cups, edit /etc/cups/cupsd.conf and add:

Listen 192.168.2.1:631
Listen /var/run/cups/cups.sock

(N.B. 192.168.2.1 is the IP of the server)

Add these to all location directives:

Allow localhost
Allow 192.168.2.*

For example:

"Location /admin/conf
Encryption Required
Order allow,deny
Allow localhost
Allow 192.168.2.*

You will need to restart cups to make these changes take effect:

service cups restart

Then go to:

http://192.168.2.1:631

And you're all set with a brand new cups server.

If you have ever deleted a file by mistake; been clearing up log files, or just used rm without thinking, there is a way of recovering that deleted file. For example, to recover a missing error_log or access_log used by Apache you can search for it via this command:

lsof | grep access_log

Which outputs:

httpd 26120 apache 42w REG 253,0 5852 12222531 /apachelogs/access_log (deleted)

The key word to look for here is deleted in brackets. The good news is a process (26120) still has the file open and without this process keeping the file open we would have lost the file permanently. So, with the Apache daemon helping us out we can view the missing info by looking inside the proc filesystem, the process id (26120), and finally in the file descriptor (fd):

cat /proc/26120/fd/42

This outputs the contents of my deleted access_log which shows the data is still there. All you need to do now is simply redirect the contents back to /apachelogs/access_log, like this:

cat /proc/26120/fd/42 > /apachelogs/access_log

Now you have recovered your access_log with all the data back to its original location. (You should also restart Apache). lsof can do much more, however, this is one example which could save the day.

Does anyone know any other examples of lsof?

Open vSphere PowerCLI and connect to your vCenter Server:

Connect-VIServer -Server 192.168.2.2

When prompted enter your username and password.

Then:

Get-VM * | Get-Snapshot

This will output the name, description, and powerstate of all virtual machines snapshots.

You need to disconnect when you have finished:

Disconnect-VIServer 192.168.2.2

This is just one example of vSphere PowerCLI but this shows how effective and time saving it can be.