Chef Infra (archive)
1

Hi,

I have an execute resource that creates an /etc/crypttab file from infomation
on the server. I’m seeing an odd behavior. On initial run of chef-client, the
file isn’t correct, it’s missing the uuid of the device. However, if I delete
the /etc/crypttab file and re-run chef-client, the /etc/crypttab is correctly
populated.

Here’s what it looks like:

execute "add-to-crypttab-#{device[0]}-uuid" do
	uuid = Mixlib::ShellOut.new("cryptsetup luksUUID #{device[0]}")
	uuid.run_command
	UUID = uuid.stdout.chomp
	command "echo \"#{phys}-luks UUID=#{UUID} /root/#{phys}-luks

luks" >> /etc/crypttab"
not_if "grep #{phys}-luks /etc/crypttab"
end

I’m trying to figure out why it’s not correct on the initial run. Any ideas?
Is it possible to delay this so that it works as expected during the initial
run of the recipe.

Thanks,
Bob

2

On Thursday, March 20, 2014 at 10:31 AM, rob.v.brown@roberthalf.com wrote:

Hi,

I have an execute resource that creates an /etc/crypttab file from infomation
on the server. I'm seeing an odd behavior. On initial run of chef-client, the
file isn't correct, it's missing the uuid of the device. However, if I delete
the /etc/crypttab file and re-run chef-client, the /etc/crypttab is correctly
populated.

Here's what it looks like:

execute "add-to-crypttab-#{device[0]}-uuid" do
uuid = Mixlib::ShellOut.new("cryptsetup luksUUID #{device[0]}")
uuid.run_command
UUID = uuid.stdout.chomp
command "echo "#{phys}-luks UUID=#{UUID} /root/#{phys}-luks
luks" >> /etc/crypttab"
not_if "grep #{phys}-luks /etc/crypttab"
end

I'm trying to figure out why it's not correct on the initial run. Any ideas?
Is it possible to delay this so that it works as expected during the initial
run of the recipe.

Thanks,
Bob

This is a compile-time vs. converge-time issue. Some previous chef resource is doing something to the system which makes the result of "cryptsetup luksUUID #{device[0]}” have the result you expect. However, resources are only converged after all of your recipe code has been evaluated. The best way to work around this for now is to use lazy attribute evaluation, described here: Common Resource Functionality

--
Daniel DeLeo