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.
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?