Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chef_user isn't fully idempotent due to password attribute #83

Open
poliva83 opened this issue Oct 6, 2015 · 8 comments
Open

chef_user isn't fully idempotent due to password attribute #83

poliva83 opened this issue Oct 6, 2015 · 8 comments

Comments

@poliva83
Copy link

poliva83 commented Oct 6, 2015

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

@jkeiser
Copy link
Contributor

jkeiser commented Oct 26, 2015

Note: this is being run as pivotal.

@jkeiser
Copy link
Contributor

jkeiser commented Oct 26, 2015

We need to separate this into two bugs:

  1. Cannot create a user without a password (crash)
  2. User not idempotent if password specified

@poliva83
Copy link
Author

@jkeiser As for priority I'd rank #1 as critical whereas #2 is low.

@poliva83
Copy link
Author

poliva83 commented Mar 1, 2016

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

@lamont-granquist
Copy link
Contributor

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

@thommay thommay added this to the Accepted Minor milestone Dec 7, 2016
@thommay
Copy link
Contributor

thommay commented Dec 7, 2016

Setting as reasonably high since we shouldn't crash.

@lamont-granquist
Copy link
Contributor

We probably should at least error out better on the client rather than relying on the server to 400.

@lamont-granquist
Copy link
Contributor

#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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants