Recipe execution order - openssh cookbook bug?

Chef Infra (archive)
1

Hello all,

I added the openssh recipe to a role with a few default attributes. I
added this role to a node and ran chef-client. sshd failed to start
because one of the ciphers I’d added isn’t available on CentOS 6. I
removed it from the role and reran chef-client. Same error. I checked
the attribute list on the node and the old value was still present. I
didn’t think it was necessary to do this but I removed all the openssh
attributes from the node to see if it helped. It didn’t. In fact, the
attributes didn’t even reappear. I then tried removing sshd_config to
force chef-client into recreating it. It didn’t. It tried to start sshd
without the file present instead. I then examined the recipe and
realised that it was trying to start sshd before even looking at the
template because the service block appears first. I had to reinstall
openssh manually before it would work again. Is this ordering correct?
It doesn’t seem so but this is obviously a very widely-used cookbook.
The second example on this page suggests that it is wrong.

http://frankmitchell.org/2013/02/chef-events/

If it is correct or if there is at least some justifiable reason for it
then is there a less ugly way for resolving issues like this?

Regards,
James

2

Looks like you are right. We would take a patch to move the template
before the service resource so that this doesn't happen.

  • Julian

On Thu, Jun 5, 2014 at 9:20 AM, James Le Cuirot chewi@aura-online.co.uk wrote:

Hello all,

I added the openssh recipe to a role with a few default attributes. I
added this role to a node and ran chef-client. sshd failed to start
because one of the ciphers I'd added isn't available on CentOS 6. I
removed it from the role and reran chef-client. Same error. I checked
the attribute list on the node and the old value was still present. I
didn't think it was necessary to do this but I removed all the openssh
attributes from the node to see if it helped. It didn't. In fact, the
attributes didn't even reappear. I then tried removing sshd_config to
force chef-client into recreating it. It didn't. It tried to start sshd
without the file present instead. I then examined the recipe and
realised that it was trying to start sshd before even looking at the
template because the service block appears first. I had to reinstall
openssh manually before it would work again. Is this ordering correct?
It doesn't seem so but this is obviously a very widely-used cookbook.
The second example on this page suggests that it is wrong.

Three ways to chain events in Chef | Frank Mitchell

If it is correct or if there is at least some justifiable reason for it
then is there a less ugly way for resolving issues like this?

Regards,
James

--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: Julian Dunn's Blog - Commentary on media, technology, and everything in between. * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]