Monthly Archives: January 2012

Automatically set the hostname during Kickstart Installation

I hate having to manually set the hostname in kickstart file, so when I found a fix, I was very happy. I wish I can take credit, but it was originally made by somebody who was trying to figure out a way to automatically set the hostname for VMWare ESX machines. Unfortunately, I lost that link, so I can’t refer to the other page for credit. So the best I can do is to explain how it is done and hopefully I find that link later and update this post, so that the right person is properly attributed.

To explain how the solution works, its good to understand how Linux boots a system, which this article does a very good job of explaining. However, if you are impatient, this is short version:

  1. Computer turns on (DUH!)
  2. BIOS kick in, which performs POST, local device enumeration and initialization and then searches for active and bootable devices.
  3. Stage 1 (MBR) kicks in, looks for boot loader (in our case, GRUB)
  4. Grub (Stage 2) then loads kernel with an optional ramdisk.
  5. kernel boots, initializes and then starts init (or some other process) that then starts up other processes

Now with that mind, let’s take a look at our grub on jenkins:

[root@jenkins chef]# cat /etc/grub.conf 
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
#          initrd /initrd-[generic-]version.img
#boot=/dev/vda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32-220.2.1.el6.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.32-220.2.1.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb rd_LVM_LV=vg_centos6/lv_root  KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet rd_NO_DM
	initrd /initramfs-2.6.32-220.2.1.el6.x86_64.img

As you can see, it boots the kernel, as well as set parameters such as root file system, language, keyboard and others things needs for the system to boot up properly. That information is actually still available in the running kernel by viewing the following file:

[root@jenkins chef]# cat /proc/cmdline 
ro root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb rd_LVM_LV=vg_centos6/lv_root  KEYBOARDTYPE=pc KEYTABLE=us  rhgb quiet rd_NO_DM
[root@jenkins chef]

Notice that in this file, you will find the same parameters as you find in the grub.conf. In some ways, if init (at least on System-V systems) is the mother of all process, the kernel is the grandmother, quietly hidden in the background.

What if you were to pass a parameter that it doesn’t recognize? In most cases, it will probably ignore it, but it will still in the kernel list. So lets insert:

FOO=BAR

to the kernel line right between “crashkernel=auto” and “rhgb” (either in grub or at kernel line at boot loader page during stage 2):

kernel /vmlinuz-2.6.32-220.2.1.el6.x86_64 ro root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb rd_LVM_LV=vg_centos6/lv_root  KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto FOO=BAR rhgb quiet rd_NO_DM

Now lets view /proc/cmdline again:

[root@jenkins ~]# cat /proc/cmdline 
ro root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb rd_LVM_LV=vg_centos6/lv_root  KEYBOARDTYPE=pc KEYTABLE=us  FOO=BAR rhgb quiet rd_NO_DM
[root@jenkins ~]# 

As we can see, FOO=BAR is in there, with no ill effects to the system boot.

So why would we want to pass a value that the kernel doesn’t use? So that we can do this:

[rilindo@jenkins ~]$ for x in `cat /proc/cmdline`
> do
> case $x in FOO*)
> eval $x
> echo "${FOO}" 
> ;;
> esac
> done
BAR
[rilindo@jenkins ~]$ 

What this script does is to get the output of /proc/cmdline as a series of positional elements (think of it like a list or an array) and loop through it. Then we will test each element through a case statement and if it matches (in this case, FOO), then it evaluates it to a variable. We then echo that variable, which will then return a value. In other words, we look for a section that has “FOO”, and get “BAR” out of it.

That is essentially how we automatically set the hostname in our installation. Using this technique, we put this script in our %pre section of our kickstart: 

%pre
#!/bin/sh
for x in `cat /proc/cmdline`; do
        case $x in SERVERNAME*)
	        eval $x
		echo "network --device eth0 --bootproto dhcp --hostname ${SERVERNAME}.monzell.com" > /tmp/network.ks
                ;;
	        esac;
	done
%end

Here, we look for a value called SERVERNAME and evaluates that value into a variable. We will then echo the network setup with the variable (which we will use as part of the hostname setup) and redirect into the file under /tmp. Then we will include that file in our installation section:

At this point, we are essentially done. To use it, we just need to pass SERVERNAME=X (where X is the name of the hostname you want to set) in our kickstart setup. In our case, we build virtual machines with KVM via virt-install, so we pass that in the following line:

virt-install --name jenkins --disk path=/home/vms/jenkins,size=50,bus=virtio --vnc --noautoconsole --vcpus=1 --ram=512 --network bridge=br0,mac=52:54:00:91:95:30 --location=http://192.168.15.100/mirrors/centos/6.2/os/x86_64/ -x "ks=http://192.168.15.100/mirrors/ks/6.2/kvm/x86_64-Ruby-test.cfg SERVERNAME=jenkins"

Here is my entire kickstart file:

install
url --url http://192.168.15.100/mirrors/centos/6.2/os/x86_64/
lang en_US.UTF-8
keyboard us
text
%include /tmp/network.ks

rootpw  --iscrypted PUTPASSWORDHERE
firewall --service=ssh
authconfig --enableshadow --passalgo=sha512 --enablefingerprint
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=vda --append="crashkernel=auto rhgb quiet"
clearpart --all --drives=vda --initlabel

part /boot --fstype=ext4 --size=500
part pv.EPlgaf-h1b4-YqDI-2wfs-3C7I-SPPt-Agk5O7 --grow --size=1

volgroup vg_centos6 --pesize=4096 pv.EPlgaf-h1b4-YqDI-2wfs-3C7I-SPPt-Agk5O7
logvol / --fstype=ext4 --name=lv_root --vgname=vg_centos6 --grow --size=1024 --maxsize=51200
logvol swap --name=lv_swap --vgname=vg_centos6 --grow --size=1008 --maxsize=2016

repo --name="Local CentOS 6 - x86_64"  --baseurl=http://192.168.15.100/mirrors/centos/6.2/os/x86_64
repo --name="Local CentOS 6 - x86_64 - Updates"  --baseurl=http://192.168.15.100/mirrors/centos/6.2/updates/x86_64
repo --name="Local Custom Installs" --baseurl=http://192.168.15.100/mirrors/customrepos/centos/x86_64

%packages
@base
@console-internet
@core
@debugging
@directory-client
@hardware-monitoring
@large-systems
@network-file-system-client
@performance
@perl-runtime
@scalable-file-systems
@server-platform
gcc
gcc-c++
pax
oddjob
sgpio
certmonger
pam_krb5
krb5-workstation
nscd
pam_ldap
nss-pam-ldapd
perl-DBD-SQLite
ruby-1.9.3p0
rubygems-1.8.12
%end

%pre
#!/bin/sh
for x in `cat /proc/cmdline`; do
        case $x in SERVERNAME*)
	        eval $x
		echo "network --device eth0 --bootproto dhcp --hostname ${SERVERNAME}.example.com" > /tmp/network.ks
                ;;
	        esac;
	done
%end

%post --log=/root/my-post-log

setsebool -P use_nfs_home_dirs on
mkdir /home/users
mkdir /etc/chef

URLPOSTCONF="http://192.168.15.100/mirrors/ks"
curl ${URLPOSTCONF}/6.2/repos/CentOS-Custom.repo -o /etc/yum.repos.d/CentOS-Custom.repo
curl ${URLPOSTCONF}/6.2/autofs/auto.master -o /etc/auto.master
curl ${URLPOSTCONF}/6.2/autofs/auto.home -o /etc/auto.home
curl ${URLPOSTCONF}/keys/cacert.pem -o /etc/openldap/cacerts/cacert.pem


curl ${URLPOSTCONF}/chef/validation.pem -o /etc/chef/validation.pem
curl ${URLPOSTCONF}/chef/client.rb -o /etc/chef/client.rb
curl ${URLPOSTCONF}/chef/first-run.json -o /etc/chef/first-run.json
rpm --import ${URLPOSTCONF}/keys/legacy.key
rpm --import ${URLPOSTCONF}/keys/custom.key

authconfig --enablesssd --enableldap --enableldaptls --ldapserver=kerberos.monzell.com --ldapbasedn="dc=monzell,dc=com" --enableldapauth --update

echo "nameserver 192.168.15.57" >> /etc/resolv.conf
echo "nameserver 192.168.15.71" >> /etc/resolv.conf

gem install chef
chef-client -j /etc/chef/first-run.json
chkconfig chef-client on
chkconfig rpcbind on
chkconfig sssd on
chkconfig ntpd on
sync


%end

reboot

Let me know if this is useful. And again, I didn’t originally came up with this, so I plead innocent to charges of plagiarism. 🙂

Updated to chef-client on FreeBSD (aka part III)

Found the solution.

Essentially, I just need to add this:

supports :status => true, :restart => true, :reload => true

This means that it will start up the service if isn’t running. Now it works as expected when I add chef-client to the run list.

Here is the updated code:

 

when "bsd"
  case node['platform']
    when "freebsd"

      directory "/etc/rc.conf.d" do
        owner "root"
        group "wheel"
        mode "0644"
        action :create
      end
      template "/etc/rc.d/chef-client" do
        source "#{dist_dir}/rc.d/chef-client.erb"
        owner "root"
        group "wheel"
        mode 0755
      end

      template "/etc/rc.conf.d/chef" do
        source "#{dist_dir}/rc.conf.d/chef.erb"
        mode 0644
        notifies :start, "service[chef-client]", :delayed
      end

      service "chef-client" do
        supports :status => true, :restart => true, :reload => true
        action [:start]
      end

    else
      log "You specified service style 'bsd'. You will need to set up your rc.local file."
      log "Hint: chef-client -i #{node["chef_client"]["client_interval"]} -s #{node["chef_client"]["client_splay"]}"
  end
else
  log "Could not determine service init style, manual intervention required to start up the chef-client service."
end

FreeBSD and chef-client – a part II (of sorts)

Finally changed chef-client with an updated recipe to support FreeBSD.

Under the chef-repo/chef-client directory, I added the following files:

./templates/freebsd/rc.d/chef-client.erb
./templates/freebsd/rc.conf.d/chef.erb

And updated:

./recipes/service.rb

The locations corresponds to the directory location under the default #{conf} directory, (which is apparently /etc) The templates are .erb files that corresponds to the configuration files on the server.

chef-client.erb:

[rilindo@chef chef-client]$ cat ./templates/freebsd/rc.d/chef-client.erb 
#!/bin/sh

# PROVIDE: chef
# REQUIRE: LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="chef"
rcvar=`set_rcvar`
stop_cmd="chef_stop"
command="/usr/local/bin/${name}-client"
command_args="-i -s -d -L /var/log/chef/client.log -c /etc/chef/client.rb -P /var/run/chef.pid"
load_rc_config $name
export rc_pid
chef_stop()
{
	pidfile="/var/run/chef.pid"
	rc_pid=`cat ${pidfile}`
        kill $rc_pid
}

run_rc_command "$1"

chef.erb

[rilindo@chef chef-client]$ cat ./templates/freebsd/rc.conf.d/chef
chef_enable="YES"

 With ERB, I could have easily have placeholders in the code so that it can be populated with node-specific information automatically. I did not do that in this case, though. That is for another time.

Finally, I updated the service code from:

when "bsd"
  log "You specified service style 'bsd'. You will need to set up your rc.local file."
  log "Hint: chef-client -i #{node["chef_client"]["client_interval"]} -s #{node["chef_client"]["client_splay"]}"
  
else
  log "Could not determine service init style, manual intervention required to start up the chef-client service."
end

to

when "bsd"
  case node['platform']
    when "freebsd"

      directory "/etc/rc.conf.d" do
        owner "root"
        group "wheel"
        mode "0644"
        action :create
      end
      template "/etc/rc.d/chef-client" do
        source "#{dist_dir}/rc.d/chef-client.erb"
        owner "root"
        group "wheel"
        mode 0755
      end

      template "/etc/rc.conf.d/chef" do
        source "#{dist_dir}/rc.conf.d/chef.erb"
        mode 0644
        notifies :start, "service[chef-client]", :delayed
      end

      service "chef-client" do
        action [:start]
      end

    else
      log "You specified service style 'bsd'. You will need to set up your rc.local file."
      log "Hint: chef-client -i #{node["chef_client"]["client_interval"]} -s #{node["chef_client"]["client_splay"]}"
  end
else
  log "Could not determine service init style, manual intervention required to start up the chef-client service."
end

I am not sure if this is quite “rubyish”, but it works. 

At that point, I uploaded the cookbook:

knife cookbook upload chef-client

Added the recipe to the freebsd node:

knife node run_list add freebsddev.monzell.com  "recipe[chef-client]"

And ran chef-client. The chef-client program sees the receipe and install the files to the appropriate locations:

freebsddev# /usr/local/bin/chef-client
[Sun, 01 Jan 2012 23:48:28 -0500] INFO: *** Chef 0.10.8 ***
[Sun, 01 Jan 2012 23:48:34 -0500] INFO: Run List is 
] [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Run List expands to [chef-client] [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Starting Chef Run for freebsddev.monzell.com [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Running start handlers [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Start handlers complete. [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Loading cookbooks [chef-client] [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Storing updated cookbooks/chef-client/recipes/default.rb in the cache. [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Storing updated cookbooks/chef-client/recipes/delete_validation.rb in the cache. [Sun, 01 Jan 2012 23:48:34 -0500] INFO: Storing updated cookbooks/chef-client/recipes/service.rb in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Storing updated cookbooks/chef-client/recipes/config.rb in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Storing updated cookbooks/chef-client/attributes/default.rb in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Storing updated cookbooks/chef-client/metadata.json in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Storing updated cookbooks/chef-client/README.md in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Storing updated cookbooks/chef-client/metadata.rb in the cache. [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing directory[/var/run] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing directory[/var/chef/cache] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing directory[/var/chef/backup] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing directory[/var/log/chef] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing directory[/etc/rc.conf.d] action create (chef-client::service line 203) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing template[/etc/rc.d/chef-client] action create (chef-client::service line 209) [Sun, 01 Jan 2012 23:48:35 -0500] INFO: Processing template[/etc/rc.conf.d/chef] action create (chef-client::service line 216) [Sun, 01 Jan 2012 23:48:36 -0500] INFO: Processing service[chef-client] action start (chef-client::service line 222) [Sun, 01 Jan 2012 23:48:36 -0500] INFO: Chef Run complete in 2.340431224 seconds [Sun, 01 Jan 2012 23:48:36 -0500] INFO: Running report handlers [Sun, 01 Jan 2012 23:48:36 -0500] INFO: Report handlers complete

I am mostly done now. I just need to start it up with:

/etc/rc.d/chef-client start

I should be able to start automatically. However,  getting it to start up automatically upon installation has so far just returns me with:

freebsddev# /usr/local/bin/chef-client
[Sun, 01 Jan 2012 23:46:26 -0500] INFO: *** Chef 0.10.8 ***
[Sun, 01 Jan 2012 23:46:32 -0500] INFO: Run List is 
] [Sun, 01 Jan 2012 23:46:32 -0500] INFO: Run List expands to [chef-client] [Sun, 01 Jan 2012 23:46:32 -0500] INFO: Starting Chef Run for freebsddev.monzell.com [Sun, 01 Jan 2012 23:46:32 -0500] INFO: Running start handlers [Sun, 01 Jan 2012 23:46:32 -0500] INFO: Start handlers complete. [Sun, 01 Jan 2012 23:46:32 -0500] INFO: Loading cookbooks [chef-client] [Sun, 01 Jan 2012 23:46:33 -0500] INFO: Storing updated cookbooks/chef-client/recipes/default.rb in the cache. [Sun, 01 Jan 2012 23:46:33 -0500] INFO: Storing updated cookbooks/chef-client/recipes/delete_validation.rb in the cache. [Sun, 01 Jan 2012 23:46:33 -0500] INFO: Storing updated cookbooks/chef-client/recipes/service.rb in the cache. [Sun, 01 Jan 2012 23:46:33 -0500] INFO: Storing updated cookbooks/chef-client/recipes/config.rb in the cache. [Sun, 01 Jan 2012 23:46:33 -0500] INFO: Storing updated cookbooks/chef-client/attributes/default.rb in the cache. [Sun, 01 Jan 2012 23:46:34 -0500] INFO: Storing updated cookbooks/chef-client/metadata.json in the cache. [Sun, 01 Jan 2012 23:46:34 -0500] INFO: Storing updated cookbooks/chef-client/README.md in the cache. [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Storing updated cookbooks/chef-client/metadata.rb in the cache. [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing directory[/var/run] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing directory[/var/chef/cache] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing directory[/var/chef/backup] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing directory[/var/log/chef] action create (chef-client::service line 42) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing directory[/etc/rc.conf.d] action create (chef-client::service line 203) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing template[/etc/rc.d/chef-client] action create (chef-client::service line 209) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing template[/etc/rc.conf.d/chef] action create (chef-client::service line 216) [Sun, 01 Jan 2012 23:46:35 -0500] INFO: Processing service[chef-client] action restart (chef-client::service line 222) [Sun, 01 Jan 2012 23:46:36 -0500] ERROR: service[chef-client] (chef-client::service line 222) has had an error [Sun, 01 Jan 2012 23:46:36 -0500] ERROR: service[chef-client] (/var/chef/cache/cookbooks/chef-client/recipes/service.rb:222:in `from_file') had an error: service[chef-client] (chef-client::service line 222) had an error: Chef::Exceptions::Exec: /etc/rc.d/chef-client stop returned 1, expected 0 /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/mixin/command.rb:127:in `handle_command_failures' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/mixin/command.rb:74:in `run_command' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/provider/service/init.rb:45:in `stop_service' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/provider/service/init.rb:55:in `restart_service' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/provider/service.rb:78:in `action_restart' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource.rb:440:in `run_action' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/runner.rb:45:in `run_action' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/runner.rb:81:in `block (2 levels) in converge' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/runner.rb:81:in `each' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/runner.rb:81:in `block in converge' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection.rb:94:in `block in execute_each_resource' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in `call' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:85:in `step' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/resource_collection.rb:92:in `execute_each_resource' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/runner.rb:76:in `converge' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/client.rb:312:in `converge' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/client.rb:160:in `run' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/application/client.rb:239:in `block in run_application' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/application/client.rb:229:in `loop' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/application/client.rb:229:in `run_application' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/lib/chef/application.rb:67:in `run' /usr/local/lib/ruby/gems/1.9/gems/chef-0.10.8/bin/chef-client:26:in `' /usr/local/bin/chef-client:19:in `load' /usr/local/bin/chef-client:19:in `' [Sun, 01 Jan 2012 23:46:36 -0500] ERROR: Running exception handlers [Sun, 01 Jan 2012 23:46:36 -0500] FATAL: Saving node information to /var/chef/cache/failed-run-data.json [Sun, 01 Jan 2012 23:46:36 -0500] ERROR: Exception handlers complete [Sun, 01 Jan 2012 23:46:36 -0500] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out [Sun, 01 Jan 2012 23:46:36 -0500] FATAL: Chef::Exceptions::Exec: service[chef-client] (chef-client::service line 222) had an error: Chef::Exceptions::Exec: /etc/rc.d/chef-client stop returned 1, expected 0

Essentially, it couldn’t find the PID file in the expected location, which is no surprise, as I had been running chef-client manually without any arguments. Hopefully I can figure out a fix for that soon.

FreeBSD and chef-client – a part I?

As I mentioned before, Chef appears to work well on mostly Debian and Ubuntu. You will have to do a bit more work on the other OSes: In the case of FreeBSD, a lot more.

Here is one example: The recipe chef-client is used to install startup scripts on the nodes (rc scripts for Red Hat, upstart for Ubuntu, etc). it works on most OSes – except for BSD systems. In fact, in the code, when it noticed it is on a BSD systems, it puts out the following:

when "bsd"
  log "You specified service style 'bsd'. You will need to set up your rc.local file."
  log "Hint: chef-client -i #{node["chef_client"]["client_interval"]} -s #{node["chef_client"]["client_splay"]}"
  
else
  log "Could not determine service init style, manual intervention required to start up the chef-client service."
end

in other words, it doesn’t even bother.

I am not sure if it is out of laziness or just having limited resources that they didn’t create rc scripts for BSD (I could understand OpenBSD, but FreeBSD?), so I created the following rc script:

#!/bin/sh

# PROVIDE: chef
# REQUIRE: LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="chef"
rcvar=`set_rcvar`
stop_cmd="chef_stop"
command="/usr/local/bin/${name}-client"
command_args="-i -s -d -L /var/log/chef/client.log -c /etc/chef/client.rb -P /var/run/chef.pid"
load_rc_config $name
export rc_pid
chef_stop()
{
	pidfile="/var/run/chef.pid"
	rc_pid=`cat ${pidfile}`
        kill $rc_pid
}

run_rc_command "$1"

Ordinarily, I shouldn’t have to create a separate function to kill a chef process, but for some reason, the rc functions within FreeBSD can’t find the PID. 

Interestingly enough, during my debugging with the script, through the use of truss I found an undocumented feature where instead of adding the entry to enable a service in /etc/rc.conf, you can put it in /etc/rc.conf.d – which is what I did:

freebsd82# pwd
/etc/rc.d
freebsd82# cd ../rc.conf.d
freebsd82# ls
chef
freebsd82# cat chef
chef_enable="YES"

Apparently it came from NetBSD

With that, I got a working chef init script. Now to see if I can update the chef-client recipe and working on FreeBSD.

Link

verycrispy:

Recently, I have been googling how to make tunnels so I thought I would post what I do. A SSH tunnel allows you to connect to server, A, through server B, from client C.

You generally only want to setup a tunnel when you need to connect to server A but only have access to server B from your…

Always Crispy: SSH Tunnels – 2 ways

Installing Chef on CentOS

I have been playing around with Chef for the past week and while I liked it, it was a pain it setup. It seems to be work well if you run Debian and Ubuntu. Everything else … not so much.

First sign of trouble is when I attempt to bootstrap the install. The install calls for installing Ruby from the RBEL repo. Which I don’t have too much with trouble – in fact, they have binary RPMs of chef already available, so I used that initially and installed with:


yum install rubygem-chef-server --disablerepo=updates --disablerepo=CentOS-Custom --disablerepo=extras

(Centos-Custom is my own repo, by the way).

That went well – until it turns out that it installed Ruby 1.8 along with it.

So I got that removed. I spent the next few hours of trying (and failing) to install Ruby 1.9 while avoiding have to install 1.8. In the end, I gave up. Instead, what I did is the following:

  1. Installed the prerequisites  for ruby (including my build of Ruby 1.9 and Rubygems).
  2. Then, I ran “gem install ruby-shadow”, as there was no RPM for it in the CentOS repo.
  3. Then I installed the EPEL repo (instead of the RBEL repo). That allow to proceed with the install of chef with “gem install chef”. That, in turn, took care of all the requirements and package installation.

The next step is to configure a web proxy, as detail here. I decided to deviate slight and just use Red Hat’s utility with:

genkey chef.monzell.com

And then open the firewall ports.

However, because I had SELinux running, apache is not able to communicate to another application (as they are in different security context. So I had to enable access with:

setsebool -P httpd_can_network_connect on

That got me further, but I still had issues. After tailing the audit log and cat the output to audit2allow, I found that I still need to open a port in SELinux:

#============= httpd_t ==============

allow httpd_t reserved_port_t:tcp_socket name_bind;


I enabled access with:

[root@chef audit]# tail audit.log  | audit2allow -M chef444

******************** IMPORTANT ***********************

To make this policy package active, execute:

semodule -i chef444.pp

Installed the module and got the web access working.

There is more, but that’s for another post. 🙂

(as a side note, is there a tumbler theme that is code friendly – that is, I can paste in code and command line snippets without looking like snot?)

EDIT: Nevermind, looks like I’ll be poking around with CSS again to get it working the way I like.