Lamont Granquist lamont-granquist

my application cookbooks define attribute like this which define node data in the node['sk_services'] namespace which is designed to be searchable by other nodes and give information (in this case information that an nginx proxy needs to know).

% cat attributes/default.rb
default['sk_services']['www.visibility-project.com']['normal_port'] = 80
default['sk_services']['www.visibility-project.com']['ssl_port'] = 443
default['sk_services']['www.visibility-project.com']['listen_port'] = 8080
default['sk_services']['www.visibility-project.com']['cache_dirs'] = [
  'assets',
]

ChefDK, Test Kitchen Driven NTP Cookbook

This gist uses TK+Berkshelf to drive creating a vagrant virts and converging a simple recipe to install and configure NTPd. This is a simple cookbook that has one recipe, one template (for ntp.conf) and one attribute file. It works on Ubuntu 12.04 and CentOS 6.4 (and derviatives) and the attribute file is used to support both distros.

This should work on Mac (where I developed it) and any chef-supported Linux that you can get Vagrant onto (Ubuntu/CentOS).

Because I use ChefDK and Test Kitchen, I can largely ignore setting up Vagrant and Berkshelf and can get right to work on writing recipe code.

NOTE: Modern (7/6/2014) Recipe Generation

Create a cookbook

$ mkdir /tmp/my_mysql
$ cd /tmp/my_mysql
$ chef generate cookbook .

Add Dependent Cookbooks

Why?

The chef-zero or "local-mode" of chef-client should be used to apply a cookbook to the server that you run it on without involving a full blown Chef Server of any kind. It does this by firing up a mini chef server that requires zero configuration in the background and uploding your cookbooks to it and doing a real chef-client converge against it, completely transparently. This allows you to use all the features of Chef without the need to think about running a server.

Other Options

There is also the chef-solo utility that is similar, but is limited in that it cannot talk to a chef server at all, and therefore features like search are architecturally broken. Ideally, it should not be used for new development work.

The chef-apply utility that can be used to converge resources in a single file against a host without a server and without any cookbook structure at all. Since there is no available structure other than the recipe file features like search, data bags, templates and other res

% cat gem_make.out
/Users/lamont/.rvm/rubies/ruby-2.1.2/bin/ruby extconf.rb
Building nokogiri using packaged libraries.
checking for iconv.h... yes
checking for iconv_open() in iconv.h... no
checking for iconv_open() in -liconv... no
checking for libiconv_open() in iconv.h... no
checking for libiconv_open() in -liconv... no
-----

export PATH=/opt/chefdk/bin:/opt/chefdk/embedded/bin:$PATH
/opt/chefdk/embedded/bin/gem install --no-user-install appbundler
/opt/chefdk/embedded/bin/gem install libyajl2
/opt/chefdk/embedded/bin/gem install ffi-yajl
cd /opt/chefdk/embedded/apps/chef
/opt/chefdk/embedded/bin/bundle update
/opt/chefdk/embedded/bin/appbundler /opt/chefdk/embedded/apps/chef /opt/chefdk/bin

Chef EOFErrors seem to have nothing to do with client bugs.

Transient issues can be caused by S3 being flakey and causing the cookbook downloader to fail. Those will obviously fail in the cookbook downloader with a trace that shows a get request to S3. They could actually be handled better by a retry in Chef::HTTP on EOFError. The net-http-persistent patches may fix this since it needs to retry EOFErrors to deal with persistent connections getting dropped and needing a retry.

One source of the problem can be mismatched jumbo frames settings where a server sets MTU to 9001 and then is not actually on a network that supports jumbo frames so large POSTs/PUTs never get sent correctly and are dropped by the network.

Another source of the problem could be similar with any kind of PMTU issue (jumbo frames on one end and not on the other, IPsec encapsulation in the middle of the connection, etc) and with filtered ICMP messages and broken PMTU discovery.

Those would both show up as issues with POSTs/PUTs over r

% brew install libiconv
==> Downloading http://ftpmirror.gnu.org/libiconv/libiconv-1.14.tar.gz
Already downloaded: /Library/Caches/Homebrew/libiconv-1.14.tar.gz
==> Downloading https://trac.macports.org/export/89276/trunk/dports/textproc/libiconv/files/patch-Makefile.devel
Already downloaded: /Library/Caches/Homebrew/libiconv--patch-44b0cd68279dafc584faa24c9b301186330542ae.devel
==> Downloading https://trac.macports.org/export/89276/trunk/dports/textproc/libiconv/files/patch-utf8mac.diff
Already downloaded: /Library/Caches/Homebrew/libiconv--patch-b47d62b5e516291fd87fd758181eeda4c786c8de.diff
==> Patching
patching file Makefile.devel

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

	Kerbal Space Program - 0.23.0.0 (LinuxPlayer) Steam


	OS: Linux 3.11.0-13-generic Ubuntu 13.10 64bit
	CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (4)
	RAM: 16048
	GPU: GeForce GTX 780/PCIe/SSE2 (3072MB)
	SM: 30 (OpenGL 4.4 [4.4.0 NVIDIA 331.20])