cheffish
cheffish copied to clipboard
chef_user isn't fully idempotent due to password attribute
The chef_user will not work unless I specify :password
attribute. I'll get 400 bad request error if I try to comment attribute out.
Net::HTTPServerException
------------------------
400 "Bad Request"
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/bb_chef_server_cluster/recipes/manage_rbac.rb
63: chef_user user do
64: display_name user
65: email "#{user}@#{org}.com"
66: #password "pass0wrd"
67: source_key_path key_path
68: chef_server url_root
69: action :nothing
70: subscribes :create, 'ruby_block[only modify rbac content on master backend]', :immediately
71: end
However even though the user is already created it keeps trying to update password in sequential chef-client runs. I can not get this resource to skip and report (update to date).
* chef_user[poliva] action create
- update user poliva at https://127.0.0.1/users
- update password from nil to "passw0rd"
* chef_user[anbrown] action create
- update user anbrown at https://127.0.0.1/users
- update password from nil to "passw0rd"
* chef_user[bbuczynski] action create
- update user bbuczynski at https://127.0.0.1/users
- update password from nil to "passw0rd"
* chef_user[eyurchenko] action create
- update user eyurchenko at https://127.0.0.1/users
- update password from nil to "passw0rd"
I noticed related comment here, so maybe known already, but didn't see any issue reported on this. https://github.com/chef/cheffish/blob/master/lib/chef/resource/chef_user.rb#L25
Note: this is being run as pivotal.
We need to separate this into two bugs:
- Cannot create a user without a password (crash)
- User not idempotent if password specified
@jkeiser As for priority I'd rank #1 as critical whereas #2 is low.
@jkeiser Was any progress made on trying to solve Cannot create a user without a password (crash)
bug? I need to figure out workaround for this.
"Cannot create a user without a password" feels like a feature not a bug. What about feeding it a string of 32 randomly generated characters?
Setting as reasonably high since we shouldn't crash.
We probably should at least error out better on the client rather than relying on the server to 400.
#106 has much better information on this -- the problem is related to trying to update the user, likely due to the server using a RESTful verb model, while the password has been one-way hashed so that doing a GET+POST doesn't work. The server should probably be changed to not require the password field on a POST and be "patchier".