chef / chef-server Goto Github PK
View Code? Open in Web Editor NEWChef Infra Server is a hub for configuration data; storing cookbooks, node policies and metadata of managed nodes.
Home Page: https://www.chef.io/chef/
License: Apache License 2.0
Chef Infra Server is a hub for configuration data; storing cookbooks, node policies and metadata of managed nodes.
Home Page: https://www.chef.io/chef/
License: Apache License 2.0
Say you have opscode-reporting_1.0.0.deb
and opscode-reporting_1.0.1.deb
in a directory /tmp
.
When running the local install command:
chef-server-ctl install opscode-reporting --path /tmp
it is indeterminate which will be installed. I think it just picks the first one it finds that matches the package regex.
We should probably have --path
point to the actual package file, such as --path /tmp/opscode-reporting_1.0.1.deb
instead of --path /tmp
so we know which package is being used.
Along with completed complete documentation from #19 , customers' most commonly sought use case for RBAC is a read-only group that while not capable of changing the system can view as many aspects of the system as are allowed to members of the Users group.
We should ship this as a built-in group into which Admin group members can assign other users.
A customer is seeing passwords appear in the following logs upon error as shown in the log snippet below. The password location is marked with "xxxxxxxxxxxxxxx". EC11 had a way to mask sensitive outputs like these. Did that not make it across, or is this a special case because of the thrown exception?
opscode-erchef/erchef.log
opscode-erchef/@400000005486357d04dbd004.u
opscode-erchef/crash.log
opscode-erchef/erchef.log.2
opscode-erchef/current
opscode-erchef/crash.log.2
opscode-erchef/erchef.log.0
opscode-erchef/crash.log.0
-----------------
erchef.log.2:2014-12-06 02:51:07.944 [error] {<<"method=POST; path=/authenticate_user; status=500; ">>,{error,{error,badarg,[{erlang,iolist_to_binary,[[null,"--",<<"xxxxxxxxxxxxxxx">>,"--"]],[]},{crypto,hash,2,[{file,"crypto.erl"},{line,228}]},{chef_password,sha1,3,[{file,"src/chef_password.erl"},{line,104}]},{chef_password,verify,2,[{file,"src/chef_password.erl"},{line,92}]},{oc_chef_wm_authenticate_user,verify_user,5,[{file,"src/oc_chef_wm_authenticate_user.erl"},{line,99}]},{oc_chef_wm_authenticate_user,process_post,2,[{file,"src/oc_chef_wm_authenticate_user.erl"},{line,87}]},{webmachine_resource,resource_call,3,[{file,"src/webmachine_resource.erl"},{line,186}]},{webmachine_resource,do,3,[{file,"src/webmachine_resource.erl"},{line,142}]}]}}}
I could use some guidance tracking down a frustrating intermittent issue we've been having with open source Chef Server. This issue started when we were running version 11.0.8 on CentOS 6.4 and has continued after upgrading to 11.6.1. We interact with Chef Server frequently using chef-api gem v0.5.0.
Here is an example of the error from the user's view:
/usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/chef-api-0.5.0/lib/chef-api/connection.rb:413:in `error': The Chef Server requires authorization. Please ensure you have specified the correct client name and private key. If this error continues, please verify the given client has the proper permissions on the Chef Server. (ChefAPI::Error::HTTPUnauthorizedRequest)
{"error":["Invalid signature for user or client 'bethany'"]}
Corresponding logs on Chef server:
=> /var/log/chef-server/erchef/requests.log.2 <==
2014-10-16T21:19:42Z [email protected] method=GET; path=/cookbooks/pp-chef-server?num_versions=1; status=401; user=bethany; req_id=8tlCJk/Z9R+mPVS/ztvVzw==; msg=bad_sig; req_time=3; rdbms_time=0; rdbms_count=2;
==> /var/log/chef-server/erchef/crash.log <==
2014-10-16 21:19:42 =ERROR REPORT====
{<<"method=GET; path=/cookbooks/pp-chef-server; status=401; ">>,"Unauthorized"}
==> /var/log/chef-server/erchef/erchef.log <==
2014-10-16 21:19:42.950 [error] {<<"method=GET; path=/cookbooks/pp-chef-server; status=401; ">>,"Unauthorized"}
It happens for GET,POST and PUT requests for nodes, cookbooks, searches, and for many different users in our organization. Re-trying the request seconds later always works. I've yet to see a 401/bad_sig from using knife, but we also rarely use knife. I can reliably trigger the intermittent 401s by looping through calls using chef-api, but there is no pattern to the 401s. I can't reliably trigger a 401 by looping through knife
commands.
System load on the server is always low, plenty of available memory, and no iowait or other disk-related performance issue markers for /var/opt/chef-server/ which is a DRBD disk on SSD. Requests come in via a Heartbeat-managed virtual IP but there is no additional layering of load-balancing or proxy-ing. I feel that time sync is not a variable because all of the servers in question are synched to the same NTP server, and I've confirmed that they are not drifting or being corrected frequently.
Any ideas what might be causing the client to only occasionally get a response of invalid signature? Should I be looking more closely at the chef-api gem rather than the chef server itself?
OS: CentOS release 6.5 (Final)
Chef Server version: chef-server-11.1.6-1.el6.x86_64
Chef-API gem version: 0.5.0
Chef Server 11.1.6
==> /var/log/chef-server/erchef/current <==
2014-11-03_12:24:56.99894 [error] Checking presence of file (checksum: <<"9b378f40549e5917e1e58b46df798354">>) for org <<"00000000000000000000000000000000">> from bucket "bookshelf" (key: "organization-00000000000000000000000000000000/checksum-9b378f40549e5917e1e58b46df798354") raised exception error:{aws_error,{socket_error,{conn_failed,{error,"certificate unknown"}}}}
2014-11-03_12:24:56.99895
ERROR: Server returned error 500 for https://servername/sandboxes/000000000000a7d895cf567bab4c97a0, retrying 1/5 in 4s
I found this, but can't find any solution from that post: https://tickets.opscode.com/browse/CHEF-5144?focusedCommentId=50388&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50388
There're tons of tools around Chef and each of them can compile and format cookbook's metadata.json in it's own way prior to uploading. And currently chef server will return the format of metadata.json you uploaded.
Instead it should be formatting metadata.json on it's own and return the same format every time not depending on how you uploaded it.
This came from berkshelf/ridley#287 (comment)
chef server 12 rc5
Ubuntu 14.10 x64
install chef server package
chef-server-ctl reconfigure
/etc/init.d/procps start
exits with code 1 if it's running
It's very likely ubuntu bug cause I don't see reason why /etc/init.d/procps start
exit with 1 even if it's running but it prevents successful installation of chef server package on Ubuntu 14.10
==> env-manager-cibuild1: ================================================================================�[0m
==> env-manager-cibuild1: �[31mError executing action `start` on resource 'service[procps]'�[0m
==> env-manager-cibuild1: ================================================================================�[0m
==> env-manager-cibuild1:
==> env-manager-cibuild1: �[0m
==> env-manager-cibuild1: Mixlib::ShellOut::ShellCommandFailed�[0m
==> env-manager-cibuild1: ------------------------------------�[0m
==> env-manager-cibuild1: Expected process to exit with [0], but received '1'
==> env-manager-cibuild1: ---- Begin output of /etc/init.d/procps start ----
==> env-manager-cibuild1: STDOUT:
==> env-manager-cibuild1: STDERR: start: Job is already running: procps
==> env-manager-cibuild1: ---- End output of /etc/init.d/procps start ----
==> env-manager-cibuild1: Ran /etc/init.d/procps start returned 1�[0m
==> env-manager-cibuild1:
==> env-manager-cibuild1: �[0m
==> env-manager-cibuild1: Resource Declaration:�[0m
==> env-manager-cibuild1: ---------------------�[0m
==> env-manager-cibuild1: # In /opt/opscode/embedded/cookbooks/private-chef/recipes/postgresql.rb
==> env-manager-cibuild1:
==> env-manager-cibuild1: 68: service "procps" do
==> env-manager-cibuild1: 69: action :nothing
==> env-manager-cibuild1: 70: end
==> env-manager-cibuild1: 71:
==> env-manager-cibuild1: �[0m
==> env-manager-cibuild1:
==> env-manager-cibuild1: �[0m
==> env-manager-cibuild1: Compiled Resource:�[0m
==> env-manager-cibuild1: ------------------�[0m
==> env-manager-cibuild1: # Declared in /opt/opscode/embedded/cookbooks/private-chef/recipes/postgresql.rb:68:in `from_file'
==> env-manager-cibuild1:
==> env-manager-cibuild1: service("procps") do
==> env-manager-cibuild1: action [:nothing]
==> env-manager-cibuild1: supports {:restart=>false, :reload=>false, :status=>false}
==> env-manager-cibuild1: retries 0
==> env-manager-cibuild1: retry_delay 2
==> env-manager-cibuild1: guard_interpreter :default
==> env-manager-cibuild1: service_name "procps"
==> env-manager-cibuild1: pattern "procps"
==> env-manager-cibuild1: cookbook_name :"private-chef"
==> env-manager-cibuild1: recipe_name "postgresql"
==> env-manager-cibuild1: end
==> env-manager-cibuild1: �[0m
Initial issue in chef repo chef/chef#2323
When running chef-server-ctl upgrade
to migrate from open source chef-server 11.6.0-1 to 12.0.0-rc4 on Centos 6.5, I get the following error:
Downloading data from the open source Chef 11 server
Running knife download
ERROR: File chef/cookbooks/var/chef is a directory while file chef/cookbooks/var/chef is a regular file
Full output here
Stop flailing at the runsvdir process tree and shut it down properly.
If initctl doesn't properly shutdown the process tree then there is
a bug that needs to be identified and fixed.
Saw these errors occur on the first run of a looping chef-server-ctl test
run.
This system had at least one existing org and other objects present.
So far, 29 additional runs have succeeded.
Failures:
1) Data Bag API endpoint with data bags that have items a request to /data/<bag> GET shows a full data bag
ESC[31mFailure/Error:ESC[0m ESC[31mget(named_data_bag_url, requestor).should look_like fetch_full_data_bag_success_responseESC[0m
ESC[31mResponse should have HTTP status code 200 ('OK'), but it was actually 404 ('Not Found')ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-expectations-2.14.5/lib/rspec/expectations/fail_with.rb:32:in `fail_with'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-expectations-2.14.5/lib/rspec/expectations/handler.rb:36:in `handle_matcher'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-expectations-2.14.5/lib/rspec/expectations/syntax.rb:53:in `should'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/bundler/gems/chef-pedant-dad401df0955/spec/api/data_bag/complete_endpoint_spec.rb:358:in `block (6 levels) in <top (required)>'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in `instance_eval'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:254:in `with_around_each_hooks'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:111:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:390:in `block in run_examples'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in `run_examples'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:371:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:372:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in `map'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:28:in `block in run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/reporter.rb:58:in `report'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/command_line.rb:25:in `run'ESC[0m
ESC[36m # /opt/opscode/embedded/service/gem/ruby/1.9.1/gems/rspec-core-2.14.8/lib/rspec/core/runner.rb:80:in `run'ESC[0m
ESC[36m # ./bin/oc-chef-pedant:16:in `<main>'ESC[0m
2) ACL API /<type>/<name>/_acl endpoint for data type /data/<name>/_acl/update endpoint PUT /data/<name>/_acl/update normal user with all permissions except GRANT returns 403
ESC[31mFailure/Error:ESC[0m ESC[31mpost(creation_url, setup_user,ESC[0m
ESC[31mResponse should have HTTP status code 201 ('Created'), but it was actually 403 ('Forbidden')ESC[0m
ESC[36m # ./spec/api/account/account_acl_spec.rb:887:in `block (5 levels) in <top (required)>'ESC[0m
3) opscode-account user association user not in org can be invited to the org by an admin when the inviting admin is removed from admins group, invites issued by that admin cannot be accepted
ESC[31mFailure/Error:ESC[0m ESC[31mlet(:test_user) { platform.create_user(test_username) }ESC[0m
ESC[31mRuntimeErrorESC[0m:
ESC[31mUnknown key type. Must be String or OpenSSL::PKey::RSA. nilESC[0m
ESC[36m # ./lib/pedant/multitenant/platform.rb:106:in `new'ESC[0m
ESC[36m # ./lib/pedant/multitenant/platform.rb:106:in `create_user'ESC[0m
ESC[36m # ./spec/api/account/account_association_spec.rb:612:in `block (5 levels) in <top (required)>'ESC[0m
ESC[36m # ./spec/api/account/account_association_spec.rb:625:in `block (5 levels) in <top (required)>'ESC[0m
Finished in 2 minutes 28.3 seconds
ESC[31m130 examples, 3 failures, 2 pendingESC[0m
Hello,
I have some users:
[root@chef12-server2 ~]# chef-server-ctl user-list -w
ec_sync_user: https://127.0.0.1/users/ec_sync_user
pivotal: https://127.0.0.1/users/pivotal
tiago_cruz: https://127.0.0.1/users/tiago_cruz
But I can't use chef-server-ctl password command:
[root@chef12-server2 ~]# chef-server-ctl password ec_sync_user
(eval):17:in `block (2 levels) in load_files': undefined method `[]' for nil:NilClass (NoMethodError)
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:177:in `call'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:177:in `block in add_command_under_category'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:555:in `run'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/bin/omnibus-ctl:31:in `<top (required)>'
from /opt/opscode/embedded/bin/omnibus-ctl:23:in `load'
from /opt/opscode/embedded/bin/omnibus-ctl:23:in `<main>'
[root@chef12-server2 ~]# chef-server-ctl password tiago_cruz
(eval):17:in `block (2 levels) in load_files': undefined method `[]' for nil:NilClass (NoMethodError)
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:177:in `call'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:177:in `block in add_command_under_category'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/lib/omnibus-ctl.rb:555:in `run'
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/omnibus-ctl-0.3.0/bin/omnibus-ctl:31:in `<top (required)>'
from /opt/opscode/embedded/bin/omnibus-ctl:23:in `load'
from /opt/opscode/embedded/bin/omnibus-ctl:23:in `<main>'
Version: chef-server-core-12.0.0_rc.5-1.el5.x86_64.rpm
Behavior:
A chef-server-ctl reconfigure dies with the error: FATAL: RuntimeError: Please add a server section for to /etc/opscode/private-chef.rb!
This appears to be due to the server not having a valid hostname set, therefore cookbooks/private-chef/recipes/default.rb:87 indexes into the config with nil or "" and doesn't find the local host and complain. It would be cleaner to just error if the host name is 0 characters.
As a customer of Enterprise Chef/Chef Server 12
"I want to be able to set permissions or have the default permissions for users(In the Users group, not members of Admins) to be able to see the public key, full name, and email address of other users in the same org.
"As a user you are only allowed to see basic information of other users. We use Chef-Vault and as a user they are not allowed to add admins of the vault unless they can see their public key. Since it is just the public key I would think that information could be shared more freely than it is today."
I should be able to do knife user show USERNAME
as a user that is a member of only the standard Users group, but currently, the requirement is that the user be a member of the Admins group to view this unprivileged information.
Additionally, the same access should be allowed for https://github.com/opscode-cookbooks/chef-vault#chef_vault_secret running on managed client nodes to users/nodes public keys through the RBAC system by default in Chef Server 12.
Found in ZenDesk 474 and HelpSpot 18264
(cross-filing as requested in chef-boneyard/chef-provisioning#112)
Using Open Source Chef Server 11.1.5 (but really ever since Chef 11) there seems to be a hard limit on the number of concurrent cookbook dependency resolutions.
We are running chef-client
at regular intervals on all our hosts, but occasionally we want to kick them off immediately on one or more hosts, so we pdsh over them. This means that N (where N is the pdsh fanout) chef-client runs start at almost exactly the same time, and since they look up their cookbooks very early they nearly simultaneously hit the depsolvers.
Correlating with general chef-server load and the number of cookbooks / cookbook versions, it used to be that we could do this to no more than 5-10 nodes at the same time, in line with the default number of depsolvers (5). I bumped the erchef['depsolver_worker_count']
to 20 now and can do this to ~30 nodes at once without hitting errors, but see errors at 40. Since they're probably not perfectly in sync it looks to me like this is just hitting the new, higher limit again.
To sum up, it looks like each depsolver worker can only do one dependency resolution at a time, and it is not possible to have more than depsolver_worker_count
simultaneous chef-client runs. Is that so, and is that by design or a known issue, or (quoting @jkeiser) "bad mojo"?
I upgraded an Open Source Chef (OSC) Server 11.1.4 to Chef Server 12rc6 successfully. The upgrade process stopped all OSC server's Chef services but the runsvdir process tree was left running and its init file wasn't deleted from /etc/init/chef-server-runsvdir.conf
. This means upon a reboot the OSC Chef services will try to start.
Also, you can't just run initctl stop chef-server-runsvdir
because its config file has a pre-stop script that calls /usr/bin/chef-server-ctl stop
but chef-server-ctl
is already linked to the CS12 chef-server-ctl
.
I think this is from chef-server at least. I have 638,722 empty temp files that never got cleaned up.
General pattern looks like this:
ubuntu@ip-172-31-15-15:~$ sudo ls -l /tmp/d20140924-12202-nkfe2n
total 0
-rw-r--r-- 1 root root 0 Sep 24 02:31 400c668688b091ef0cb3aee2ad8d1219770c2a3e9f2a2c210d895ab13592688d
-rw-r--r-- 1 root root 0 Sep 24 02:31 548ae55d18d71e3151d67201d7c6aa899c277b37a50cba9aa0682fad9f8ed711
-rw-r--r-- 1 root root 0 Sep 24 02:31 5bf9909149ded65378e05a370ecc3920d5110a58f1acf8ffabf2af9f9749a73c
-rw-r--r-- 1 root root 0 Sep 24 02:31 91d83fb7cbd53be4dd52dea28e48a459a4cd83705d0f3d5932d61382061dfde8
-rw-r--r-- 1 root root 0 Sep 24 02:31 c77c67e97162d49566f1ff0e5ede680986d419506f5d7e6a94ed94da68742e69
-rw-r--r-- 1 root root 0 Sep 24 02:31 d7f21df8b6c7ad1e42ff41ca278404e179a5d86cfae4dce745dbc52bfbf5cf37
-rw-r--r-- 1 root root 0 Sep 24 02:31 e5f18bfa9cb9540beacbcb196fa4558aa9d29948a00f3b3fa3dc431680b8b87d
-rw-r--r-- 1 root root 0 Sep 24 02:31 fe5020ce36ad65ede596c906b13bf0bea63a385762d063a6087d99d4a8a64c94
Going to have to clean them up so if this can't be repro'd I might not be able to help.
A system with 64GB of memory couldn't just install CS12 and have it work because the postgres['shared_buffers']
value was being set too high. This kept postgresql from starting because it was trying to shmget
more space than shmmax
allowed.
The problem is that everything in the calculation code linked below uses values that have different units. Some are in kB and some are in bytes.
node['memory']['total'].to_i
is in kBMy recommendation is that every value should be converted to bytes and then proceed with calculations.
I am trying to setup system recovery password for an LDAP user [Chef 11], but getting
the
below error when I run the command "private-chef-ctl password Test.User10"
"406 Not Acceptable
Password for Test.User10 successfully enabled for System Recovery."
This message looks kind of confusing with the first line error message and
second line success message!
But, when I try to login to manage UI with system recovery password [LDAP
down], I get the below error -
"Incorrect username or password, or system recovery is not enabled for this
account. If you think system recovery should work for your account, please
contact your system administrator."
When I drilled down further, it is the "http://127.0.0.1:9465/users/Test.User10" request that is failing and returning the error.
Header contains Accept and Content-Type as 'application/json'
I tried doing a curl with accept, X-Ops-Sign, X-Ops-Userid, X-Ops-Timestamp, X-Ops-Content-Hash headers against the URL "http://127.0.0.1:9465/users" and I got a response -
{"error":"Failed to authenticate as pivotal. Synchronize the clock on your host."}
My system in on EST.
The knife recipe list
command regularly returns HTTP 500 response codes to users on Hosted Chef. The command calls the following endpoint:
/organizations/ORGNAME/cookbooks/_recipes
Erchef console logs show the following stack trace for the 500:
=ERROR REPORT==== 3-Oct-2014::17:18:46 ===
{<<"method=GET; path=/organizations/jeremiah-opscode/cookbooks/_recipes; status=500; ">>,
{error,
{throw,
{error,invalid_ejson},
[{jiffy,encode,2,[{file,"src/jiffy.erl"},{line,34}]},
{chef_json,encode,1,[{file,"src/chef_json.erl"},{line,41}]},
{chef_wm_cookbooks,to_json,3,
[{file,"src/chef_wm_cookbooks.erl"},{line,85}]},
{webmachine_resource,resource_call,3,
[{file,"src/webmachine_resource.erl"},{line,186}]},
{webmachine_resource,do,3,
[{file,"src/webmachine_resource.erl"},{line,142}]},
{webmachine_decision_core,resource_call,1,
[{file,"src/webmachine_decision_core.erl"},{line,48}]},
{webmachine_decision_core,decision,1,
[{file,"src/webmachine_decision_core.erl"},{line,558}]},
{webmachine_decision_core,handle_request,2,
[{file,"src/webmachine_decision_core.erl"},{line,33}]}]}}}
This same endpoint works against Opsmaster which is running EC 11. This error occurs even in organizations with no uploaded cookbooks.
As a note, the underlying sql request for this operation is incredibly slow:
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=641401.80..641401.81 rows=1 width=547) (actual time=5792.717..5792.717 rows=1 loops=1)
-> Sort (cost=641401.80..641401.81 rows=1 width=547) (actual time=5792.717..5792.717 rows=1 loops=1)
Sort Key: cookbook_versions_by_rank.name
Sort Method: quicksort Memory: 26kB
-> Subquery Scan on cookbook_versions_by_rank (cost=591894.61..641401.79 rows=1 width=547) (actual time=3989.823..5792.689 rows=2 loops=1)
Filter: ((cookbook_versions_by_rank.org_id = 'a62cf91ce3e54ce586838956dd54eab2'::bpchar) AND (cookbook_versions_by_rank.rank = 1))
Rows Removed by Filter: 800203
-> WindowAgg (cost=591894.61..629977.06 rows=761649 width=608) (actual time=3986.977..5693.600 rows=800205 loops=1)
-> Sort (cost=591894.61..593798.73 rows=761649 width=608) (actual time=3986.946..4505.346 rows=800205 loops=1)
Sort Key: v.cookbook_id, v.major, v.minor, v.patch
Sort Method: external merge Disk: 483416kB
-> Hash Join (cost=22338.35..311822.70 rows=761649 width=608) (actual time=254.845..2682.368 rows=800205 loops=1)
Hash Cond: (v.cookbook_id = c.id)
-> Seq Scan on cookbook_versions v (cost=0.00..161855.49 rows=761649 width=567) (actual time=0.002..875.538 rows=800205 loops=1)
-> Hash (cost=12126.60..12126.60 rows=479660 width=45) (actual time=254.663..254.663 rows=489068 loops=1)
Buckets: 16384 Batches: 8 Memory Usage: 4780kB
-> Seq Scan on cookbooks c (cost=0.00..12126.60 rows=479660 width=45) (actual time=0.003..114.830 rows=489068 loops=1)
Total runtime: 5887.263 ms
(18 rows)
Building upon this PR: chef-boneyard/opscode-omnibus#104
There are several things that need to be correct/implemented on a server before we can install Chef Server. Currently there is no pre-flight or requirements check. This often results in unclear error messages and undelightful install process. Particularly in secure environments.
Please implement checks for the items in the requirement doc: https://docs.getchef.com/server/install_server_pre.html
Additionally, we should test if the Chef Server is in an offline or proxy mode, and needs additional config to reach the internet.
The new way of running the sqitch migration uses make
but if that's not available then the upgrade crashes. It wasn't available in my test environment and I saw it crash another user's environment.
The old way of running the sqitch migration doesn't use make
so we haven't run into this problem before.
@sdelano suggested to me that "We should just fix it not to run make"
In the meantime, the requirement has been added to the upgrade docs.
We check if we are the data master while notifying nginx to restart, but we actually want that restart to happen both on a Standalone and on all frontends in a Tiered/HA system. backends don't matter in this case, because dispatch happens on the frontend.
opscode-expander-reindexer
's intended purpose was for reindexing the entire Chef Server. In theory you would do this:
However, with the erchef rewrite, we no longer have a tool that does (2). Further, it is likely that if we were to write a installation-wide reindex tool, it would be the moral equivalent of:
SAFTEY_TIMER=30
for org in $(chef-server-ctl org-list); do
redis-cli HSET dl_org_$org 503_mode true
sleep $SAFTEY_TIMER
/opt/opscode/embedded/service/opscode-erchef/bin/reindex-opc-organization complete $org
redis-cli HDEL dl_org_$org 503_mode
done
We might consider removing this component from the chef-server as there is nothing that currently uses it.
That's a legit email address, per the RFC if memory serves. Also the error message is nonsensical:
chef-server-ctl user-create foo John Q Public "[email protected]" some_password*
ERROR: Conflict
Response: User 'foo' already exists
The user doesn't actually exist. If I give it a more normal-looking [email protected] email address things work fine.
Small typo in chef-server-ctl:
org-list
List all organizationsin the chef server.
Supposed to be "organizations in" :)
Version: chef-server-core-12.0.0_rc.5-1.el5.x86_64
root@vagrant:~# chef-server-ctl user-create test test test [email protected] testtest --filename /<invalid_folder>/file.key
ERROR: Errno::ENOENT: No such file or directory - /path/to/file.key
root@vagrant:~# chef-server-ctl user-create test test test [email protected] testtest --filename /<valid_folder>/file.key
ERROR: Conflict
Response: User 'wtf' already exists
So it creates the user just fine, and you get a conflict when you try to re-create it (valid), but you won't have the key on your filesystem. There are other ways to get the key, but that's annoying.
If the hostname of a given machine does not have a server configuration block in chef-server.rb, you will receive an error message like the following:
[root@backend1 opscode]# chef-server-ctl reconfigure
the ffi-yajl and yajl-ruby gems have incompatible C libyajl libs and should not be loaded in the same Ruby VM
falling back to ffi which might work (or might not, no promises)
ffi-yajl/json_gem is deprecated, these monkeypatches will be dropped shortly
the ffi-yajl and yajl-ruby gems have incompatible C libyajl libs and should not be loaded in the same Ruby VM
falling back to ffi which might work (or might not, no promises)
ffi-yajl/json_gem is deprecated, these monkeypatches will be dropped shortly
Starting Chef Client, version 11.12.2
Compiling Cookbooks...
Recipe: private-chef::default
* directory[/etc/opscode] action create (up to date)
* directory[/etc/opscode/logrotate.d] action create (up to date)
================================================================================
Recipe Compile Error in /opt/opscode/embedded/cookbooks/private-chef/recipes/default.rb
================================================================================
NoMethodError
-------------
undefined method `[]' for nil:NilClass
Cookbook Trace:
---------------
topology "ha"
/opt/opscode/embedded/cookbooks/private-chef/libraries/private_chef.rb:170:in `generate_secrets'
/opt/opscode/embedded/cookbooks/private-chef/libraries/private_chef.rb:471:in `generate_config'
/opt/opscode/embedded/cookbooks/private-chef/recipes/default.rb:87:in `from_file'
Relevant File Content:
----------------------
/opt/opscode/embedded/cookbooks/private-chef/libraries/private_chef.rb:
163: else
164: PrivateChef[k][pk] = p
165: end
166: end
167: end
168:
169: me = PrivateChef["servers"][node_name]
170>> ha_guard = PrivateChef['topology'] == 'ha' && !me['bootstrap']
171:
172: PrivateChef['rabbitmq']['password'] ||= generate_hex_if_bootstrap(50, ha_guard)
173: PrivateChef['rabbitmq']['jobs_password'] ||= generate_hex_if_bootstrap(50, ha_guard)
174: PrivateChef['rabbitmq']['actions_password'] ||= generate_hex_if_bootstrap(50, ha_guard)
175: PrivateChef['postgresql']['sql_password'] ||= generate_hex_if_bootstrap(50, ha_guard)
176: PrivateChef['postgresql']['sql_ro_password'] ||= generate_hex_if_bootstrap(50, ha_guard)
177: PrivateChef['drbd']['shared_secret'] ||= generate_hex_if_bootstrap(30, ha_guard)
178: PrivateChef['keepalived']['vrrp_instance_password'] ||= generate_hex_if_bootstrap(50, ha_guard)
179: PrivateChef['oc_bifrost']['superuser_id'] ||= generate_hex_if_bootstrap(16, ha_guard)
Running handlers:
[2014-12-19T17:23:39+00:00] ERROR: Running exception handlers
Running handlers complete
[2014-12-19T17:23:39+00:00] ERROR: Exception handlers complete
[2014-12-19T17:23:39+00:00] FATAL: Stacktrace dumped to /opt/opscode/embedded/cookbooks/cache/chef-stacktrace.out
Chef Client failed. 0 resources updated in 2.495912147 seconds
[2014-12-19T17:23:39+00:00] FATAL: NoMethodError: undefined method `[]' for nil:NilClass
This is often the result of a typo. A better error message would be:
ERROR: Cannot find configuration for this-host.example.com in /etc/opscode/chef-server.rb!
Preferably without the large, unhelpful stack trace.
The fix is at chef-boneyard/oc_chef_wm@37887e4
In order for LDAP account linking to completely work, we need to release this in a version of Chef Server 12 > 12.0.0
Attempting to disassociate an admin in an organization results in an expected error message:
Response: Members of an organization's admins group cannot delete themselves. Remove yourself from the admins group, then retry this operation.
However, further attempts by this user to make API requests against this organization with this user fail:
ERROR: You authenticated successfully to https://localhost/organizations/anorg/ as usera but you are not authorized for this action
Response: 'usera' not associated with organization 'anorg'
If you attempt to invite the user back to the org, attempts to accept the invitation fail with an HTTP 500:
2014-10-29T13:24:23Z [email protected] method=PUT; path=/users/usera/association_requests/6437260d8bcb67453ff112160c07f514; status=500; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAABhXQAAAAAAAAAA; org_name=anorg; msg={usag_creation_failed,{conflict,<<"duplicate key value violates unique cons"...>>}}; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=134; rdbms_time=6; rdbms_count=7; authz_time=5; authz_count=1; user=pivotal;
Any additional attempts to invite the user will fail with a 409 conflict as an invitation for that user already exists.
The code to disassociate a user from an organization in the oc_chef_wm repo is:
delete_resource(Req, #base_state{organization_guid = OrgId,
chef_db_context = DbContext,
requestor_id = RequestorId,
resource_state = #association_state{user = #chef_user{id = UserId }}} = State ) ->
case oc_chef_object_db:safe_delete(DbContext,
#oc_chef_org_user_association{org_id = OrgId, user_id = UserId},
RequestorId) of
ok ->
remove_user(Req, State);
not_found ->
% Because we pre-checked membership, htis would only occur in a race condition.
{{halt, 404}, Req, State#base_state{log_msg = association_not_found}};
{error, What} ->
{{halt, 500}, Req, State#base_state{log_msg = What}}
end.
remove_user(Req, #base_state{organization_name = OrgName,
resource_state = #association_state{ user = #chef_user{username = UserName} = User} } = State ) ->
case oc_chef_wm_base:user_in_group(State, UserName, <<"admins">>) of
true ->
Text = <<"Members of an organization's admins group cannot delete themselves. Remove yourself from the admins group, then retry this operation.">>,
Message = {[{<<"error">>, Text}]},
Req1 = chef_wm_util:set_json_body(Req, Message),
{{halt, 403}, Req1, State#base_state{log_msg = cannot_dissociate_self_while_admin}};
false ->
RequestorId = oc_chef_authz:superuser_id(),
case oc_chef_associations:deprovision_removed_user(State, User, RequestorId) of
ok ->
EJ = chef_user:assemble_user_ejson(User, OrgName),
{true, chef_wm_util:set_json_body(Req, EJ), State#base_state{log_msg = {removed, UserName, from, OrgName}}};
{warning, Warnings} ->
lager:error("Warnings in deprovision of ~p from ~p: ~p", [UserName, OrgName, Warnings]),
EJ = chef_user:assemble_user_ejson(User, OrgName),
{true, chef_wm_util:set_json_body(Req, EJ), State#base_state{log_msg = {warning_in_deprovision, Warnings}}};
{error, Error} ->
lager:error("Error in deprovision of ~p from ~p: ~p", [UserName, OrgName, Error]),
{{halt, 500}, Req, State#base_state{log_msg = {error_in_deprovision, Error}}}
end
end.
Note that we call:
oc_chef_object_db:safe_delete(DbContext,
#oc_chef_org_user_association{org_id = OrgId, user_id = UserId},
RequestorId)
before we check if the user is the only admin and fail. My hunch is that the function above is partially removing the users association to that org. If this is the case, we would ideally check if the user is the only admin /before/ calling that function.
As I've been working on adding orgs+RBAC to goiardi, I noticed that the behavior oc-chef-pedant expects when you edit the ACL or groups is to provide a list of the actors and groups to be in the group, whereupon the existing actors and groups in the ACL or group is cleared out and the actors and groups in the request are added back in.
This leads to a situation where if two people are simultaneously editing a group or ACL, or if a user is being created at the same moment a group is being edited, one of the changes could be overwritten. This could lead to strange situations where a user that's been added to an org is not in the users group, or trying to remove access from a group or actor gets overwritten and they retain their access.
It may be better to explicitly add and remove users from ACLs and groups to prevent this. It might be a little more cumbersome for the tooling, but I think it would be safer all around.
Currently failures in erlang applications cause stack traces, which are not friendly to end users. Putting a layer in place which caught such errors and gave user friendly error messages would be greatly appreciated as users currently call support or have to parse erlang stack traces.
This request came from an external party.
When configuring nginx to listen on an alternative port, using the following option in /etc/opscode/chef-server.rb:
nginx['ssl_port'] = 10443
Uploading of cookbooks fail with HTTP 500 Internal server error. Other knife commands seem to work normally.
nils@fatty:~/chef-repo-local$ cat .chef/knife.rb
\# See http://docs.getchef.com/config_rb_knife.html for more information on knife configuration options
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name "nils"
client_key "#{current_dir}/nils.pem"
validation_client_name "meh-validator"
validation_key "#{current_dir}/meh-validator.pem"
chef_server_url "https://centos6-1/organizations/meh"
cache_type 'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path ["#{current_dir}/../cookbooks"]
nils@fatty:~/chef-repo-local$ getent hosts centos6-1
10.32.0.4 centos6-1
nils@fatty:~/chef-repo-local$ knife cookbook create empty
** Creating cookbook empty
** Creating README for cookbook: empty
** Creating CHANGELOG for cookbook: empty
** Creating metadata for cookbook: empty
nils@fatty:~/chef-repo-local$ knife cookbook upload empty
Uploading empty [0.1.0]
Uploaded 1 cookbook.
nils@fatty:~/chef-repo-local$ knife cookbook delete empty
Do you really want to delete empty version 0.1.0? (Y/N)Y
Deleted cookbook[empty version 0.1.0]
nils@fatty:~/chef-repo-local$ cat .chef/knife.rb
\# See http://docs.getchef.com/config_rb_knife.html for more information on knife configuration options
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name "nils"
client_key "#{current_dir}/nils.pem"
validation_client_name "meh-validator"
validation_key "#{current_dir}/meh-validator.pem"
chef_server_url "https://centos6-1:10443/organizations/meh"
cache_type 'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path ["#{current_dir}/../cookbooks"]
nils@fatty:~/chef-repo-local$ knife cookbook list
chef-client 3.9.0
chef_handler 1.1.6
cron 1.6.1
logrotate 1.7.0
ssh 0.1.0
starter 1.0.0
time 0.1.0
users 0.1.0
windows 1.34.8
nils@fatty:~/chef-repo-local$ knife cookbook create empty
** Creating cookbook empty
** Creating README for cookbook: empty
** Creating CHANGELOG for cookbook: empty
** Creating metadata for cookbook: empty
nils@fatty:~/chef-repo-local$ knife cookbook upload empty
Uploading empty [0.1.0]
ERROR: Server returned error 500 for https://centos6-1:10443/organizations/meh/sandboxes/ae7303275706e1d0e4ff6dc7686995b7, retrying 1/5 in 4s
nils@fatty:~/chef-repo-local$ knife cookbook upload empty -VV
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::JSONToModelOutput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Authenticator#handle_request
DEBUG: Signing the request as nils
DEBUG: Chef::HTTP calling Chef::HTTP::RemoteRequestID#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Initiating GET to https://centos6-1:10443/organizations/meh/cookbooks?num_versions=all
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: Accept: application/json
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: X-OPS-SIGN: algorithm=sha1;version=1.0;
DEBUG: X-OPS-USERID: nils
DEBUG: X-OPS-TIMESTAMP: 2014-12-11T13:43:50Z
DEBUG: X-OPS-CONTENT-HASH: 2jmj7l5rSw0yVb/vlWAYkK/YBwk=
DEBUG: X-OPS-AUTHORIZATION-1: QcuM1fxXOY+Nn4nbuMA6pVVwmDZkAwtZVWjyMJPwev5RwPrSkcPT2vxlqBZk
DEBUG: X-OPS-AUTHORIZATION-2: na5er6czBINoC+Mk5ioJlQ/10ot9n9H1ic71QC2uVcnuAnu2w2CGVEjuiwWJ
DEBUG: X-OPS-AUTHORIZATION-3: +D8aqgomypsCSL4himp9iIjw5D5u/AElK85ZbuwylHgweYGuyTiB00Zx8UGm
DEBUG: X-OPS-AUTHORIZATION-4: dJ7MrtlGCOblVJsfnDptJFoZcq1XfeP/6DUpDdg6CL0+CVTuSuBiqvu2Lf54
DEBUG: X-OPS-AUTHORIZATION-5: 63ka+jJofr04UOKPJWiebCxZ2kYLoY8sRqJeWXHtGiDWpFTsL6T13+pe1/F2
DEBUG: X-OPS-AUTHORIZATION-6: S01oPgmN/nePMPbRhGPSp8zUI6nhZTVknbRXzIkcnA==
DEBUG: HOST: centos6-1:10443
DEBUG: X-REMOTE-REQUEST-ID: 783f1700-1367-4896-a04c-aa9195b17e22
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 200 OK
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:49 GMT
DEBUG: content-type: application/json
DEBUG: transfer-encoding: chunked
DEBUG: connection: close
DEBUG: x-ops-api-info: flavor=cs;version=12.0.0;oc_erchef=0.29.3
DEBUG: content-encoding: gzip
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: HTTP server did not include a Content-Length header in response, cannot identify truncated downloads.
DEBUG: Chef::HTTP calling Chef::HTTP::RemoteRequestID#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Authenticator#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: decompressing gzip response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::JSONToModelOutput#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_response
Uploading empty [0.1.0]
INFO: Validating ruby files
DEBUG: Ruby file /home/nils/chef-repo-local/.chef/../cookbooks/empty/metadata.rb is unchanged, skipping syntax check
DEBUG: Ruby file /home/nils/chef-repo-local/.chef/../cookbooks/empty/recipes/default.rb is unchanged, skipping syntax check
INFO: Validating templates
INFO: Syntax OK
INFO: Saving empty
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::JSONToModelOutput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Authenticator#handle_request
DEBUG: Signing the request as nils
DEBUG: Chef::HTTP calling Chef::HTTP::RemoteRequestID#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Initiating POST to https://centos6-1:10443/organizations/meh/sandboxes
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: Content-Type: application/json
DEBUG: Accept: application/json
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: X-OPS-SIGN: algorithm=sha1;version=1.0;
DEBUG: X-OPS-USERID: nils
DEBUG: X-OPS-TIMESTAMP: 2014-12-11T13:43:50Z
DEBUG: X-OPS-CONTENT-HASH: Tf5EsKz4yLjblQK5gdpAezCGlP8=
DEBUG: X-OPS-AUTHORIZATION-1: aTBVBQBDja3uc1jQ4q13+0wvEIjHVMP/4xjgh31DxBIC6kNehE9QR+AFFBPE
DEBUG: X-OPS-AUTHORIZATION-2: uD3CZY26pCAzyxMhSg+nu8QA1e7/VR2MRSCiJv/Sni88JgZ2vq5r3eCLI5xF
DEBUG: X-OPS-AUTHORIZATION-3: 2AIo2yoMtK/fUwgcVCzN9QOPHA/FUNpJmZkZrWoPPD3CCCo5RAgEOLFtUPeW
DEBUG: X-OPS-AUTHORIZATION-4: pfDTB4UaDyI2egd7SxUyk5SqwDlaJrptOs9pNjVRruwnPqV+Ie0YxHFh0Rj+
DEBUG: X-OPS-AUTHORIZATION-5: s0NF8xtCWPmvKvMrxe8MOEKp4rDx51RTFEnyc2dMXhI5hUCjv9TcZDFjmpWb
DEBUG: X-OPS-AUTHORIZATION-6: T1QF2McXOvXdi1sYyetroqy+L2XkQL6z4RH7ABlD+g==
DEBUG: HOST: centos6-1:10443
DEBUG: X-REMOTE-REQUEST-ID: 783f1700-1367-4896-a04c-aa9195b17e22
DEBUG: Content-Length: 175
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 201 Created
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 1397
DEBUG: connection: close
DEBUG: x-ops-api-info: flavor=cs;version=12.0.0;oc_erchef=0.29.3
DEBUG: location: http://centos6-1:10443/organizations/meh/sandboxes/ae7303275706b33ac7eb13e14431b19a
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: Content-Length validated correctly.
DEBUG: Chef::HTTP calling Chef::HTTP::RemoteRequestID#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Authenticator#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::JSONToModelOutput#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_response
INFO: Uploading files
INFO: Uploading /home/nils/chef-repo-local/cookbooks/empty/CHANGELOG.md (checksum hex = 8d8f6ea573078cf28515b3095d82844b) to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-8d8f6ea573078cf28515b3095d82844b?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=q9y19bGXWhyLD/QBUDRhSnqROtQ%3D
INFO: Uploading /home/nils/chef-repo-local/cookbooks/empty/recipes/default.rb (checksum hex = 7811a4e3d56e21739f395de9ef19ae1a) to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-7811a4e3d56e21739f395de9ef19ae1a?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=gdcj6MFDsTyUfzlEmG8VNGYMOV8%3D
INFO: Uploading /home/nils/chef-repo-local/cookbooks/empty/README.md (checksum hex = 293c80dcfa10f4db57cf711be5df7142) to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-293c80dcfa10f4db57cf711be5df7142?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=W4EBiq3zD7JF69kQtOZyuOGJbRw%3D
INFO: Uploading /home/nils/chef-repo-local/cookbooks/empty/metadata.rb (checksum hex = c86cfa40f581bd0aa6037ba233436940) to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-c86cfa40f581bd0aa6037ba233436940?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=LGsZjawlw%2BjJcb9UVHqqzdKu25s%3D
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Initiating PUT to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-293c80dcfa10f4db57cf711be5df7142?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=W4EBiq3zD7JF69kQtOZyuOGJbRw%3D
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: content-type: application/x-binary
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Initiating PUT to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-8d8f6ea573078cf28515b3095d82844b?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=q9y19bGXWhyLD/QBUDRhSnqROtQ%3D
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: content-type: application/x-binary
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: content-md5: KTyA3PoQ9NtXz3Eb5d9xQg==
DEBUG: Initiating PUT to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-c86cfa40f581bd0aa6037ba233436940?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=LGsZjawlw%2BjJcb9UVHqqzdKu25s%3D
DEBUG: content-md5: jY9upXMHjPKFFbMJXYKESw==
DEBUG: accept: application/json
DEBUG: accept: application/json
DEBUG: X-Ops-Sign: algorithm=sha1;version=1.0;
DEBUG: X-Ops-Userid: nils
DEBUG: X-Ops-Timestamp: 2014-12-11T13:43:50Z
DEBUG: X-Ops-Content-Hash: +3wFiIrVrs9mkK4TuHzaNFVKQMA=
DEBUG: X-Ops-Authorization-1: dMmXVh4N+xQ78NEpTqghdlFUedIMMyCZaFNWBTQAq/LGrFVmivyjm563yK/o
DEBUG: Initiating PUT to https://centos6-1:10443/bookshelf/organization-0b9c6e274c175682cf44ae7303275706/checksum-7811a4e3d56e21739f395de9ef19ae1a?AWSAccessKeyId=901561e2dbf7b640e4589503be41f5c3cda4f7bb&Expires=1417797470&Signature=gdcj6MFDsTyUfzlEmG8VNGYMOV8%3D
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: content-type: application/x-binary
DEBUG: content-md5: eBGk49VuIXOfOV3p7xmuGg==
DEBUG: accept: application/json
DEBUG: X-Ops-Sign: algorithm=sha1;version=1.0;
DEBUG: X-Ops-Userid: nils
DEBUG: X-Ops-Timestamp: 2014-12-11T13:43:50Z
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: content-type: application/x-binary
DEBUG: content-md5: yGz6QPWBvQqmA3uiM0NpQA==
DEBUG: accept: application/json
DEBUG: X-Ops-Sign: algorithm=sha1;version=1.0;
DEBUG: X-Ops-Userid: nils
DEBUG: X-Ops-Timestamp: 2014-12-11T13:43:50Z
DEBUG: X-Ops-Authorization-2: xBuMIv5XW0Txr/nJv7+MJXmxFu2dOJ2yGvwQ0TATh/171e780Yx4EcxiCuW8
DEBUG: X-Ops-Authorization-3: 4IdR22WDelKson/BN/LeDxQVNPrullLo8G8JS6nxzc3vXZa+f6hjD4E60Upr
DEBUG: X-Ops-Content-Hash: GOaozZ/PdO0RCVqp6WQj/tmiGNs=
DEBUG: X-Ops-Authorization-1: pHG1aLMYytLynXM6YgYwwpXPDyn5LWr3lbwby6layrsQkdyZLP3MppQ6TmYF
DEBUG: X-Ops-Authorization-2: MllFvB4bjlScmmtIepssBuzF4KhrtEV+k1wHWahoj0DrRHDMTYHbM49/tFll
DEBUG: X-Ops-Authorization-3: HJA06rO+XLJOPyzgtka30rVd8zsH/MX+K9dVkFd4xRHvtmyU2+2p9JsYZVpL
DEBUG: X-Ops-Authorization-4: nXswuoCo/KqyUJGDS12S6fdEdy+XNLXbNMx+yS4SduDVKmSYs/2zYnoan0IG
DEBUG: X-Ops-Authorization-5: qUmelQr0BWNdFT5FNIF5pbVzfHi8iPyenXYu1FDDUsItIzU4n0u6o2nGZZuA
DEBUG: X-Ops-Authorization-6: NnrCUPO9DhtANHAJV4qtT8S75cft3ZKJHgu+WHGgZg==
DEBUG: X-Ops-Sign: algorithm=sha1;version=1.0;
DEBUG: X-Ops-Userid: nils
DEBUG: X-Ops-Timestamp: 2014-12-11T13:43:50Z
DEBUG: X-Ops-Content-Hash: gM+dlDyvO4H4YksPuRyVTyed4sM=
DEBUG: X-Ops-Authorization-1: XbNC/tspO/U+P/jwwOORCr9OMIy3gxK6sg0jNE1vSezRGCHJSW6/voGJzqtC
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: Content-Length: 1440
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: X-Ops-Authorization-2: sFwVEpDhCYuk+5zI6I4v9oTGQp9r7aKJBf0gnDe+5CNe/BkmifbLdgg8VJ1U
DEBUG: X-Ops-Authorization-3: x+3MMGdldX9gUDMyUtqVo6XXkPmyE7f15r1aoPgM21YyGfRYgRO2eWuAXQhz
DEBUG: X-Ops-Authorization-4: mBX8qVAzI4ARpiRKo7+MRqEHXhIiIrNQD/4BWVJWX1G7x/NyjJOAO7FTY6nN
DEBUG: X-Ops-Authorization-5: zejLvTO+njBRmBziUGza5qIBiJkFPBRSned5LL0fHUucHZlBxL5g1u4y4SPp
DEBUG: X-Ops-Authorization-6: /70Ucx9lSyMJYalzbJs1a6tiAqkt8ROSWNJqbv3ROw==
DEBUG: X-Ops-Content-Hash: yKkHYWE1SRXaJd0l6pWgzcQYaYQ=
DEBUG: X-Ops-Authorization-4: 8os1JGOVlnVH4xF/yqkDlKAUCod9gNoHXrP0ABbKLOZa1sKCa8Hf3yu/e2cX
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: X-Ops-Authorization-1: sTi/QfK9rdOqup6RRyKFn7pHo8IgAmm2nvbtzq7TbzzxJUM6OP6YrhueXUvK
DEBUG: X-Ops-Authorization-5: pG+7B0wVpwyZUjf4JeGtMIQtke+PSmnrR/ufGD/aESUCWGUQet8c8lFNxvxd
DEBUG: Content-Length: 131
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: X-Ops-Authorization-6: djEqgCPH12S1pxP1/BCwzt46xY8ZTj4IPuZ66UTC+Q==
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: Content-Length: 447
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: X-Ops-Authorization-2: IP3l8hCk6/3Gak3X0NAkSN31ASsLdxXhXOsuS/96o+pmpcz4XZ9vFicJDeDs
DEBUG: X-Ops-Authorization-3: HqTnLxaImy8xATVFnsOwUm8E6T3/cKH4Z+sp9zjY2E74t42BdMMrhFPin+jC
DEBUG: X-Ops-Authorization-4: vJk9qAHn8oNexnzV3hwyYdGX0fDJ38qtNsFFAy7ej4+GSnedQkjT/hlhVsex
DEBUG: X-Ops-Authorization-5: zWX4asmP6Dqn2gGhORWsVwU/DR1sFSfS8N41pVI6kHgUowfL993yQdCYqTLI
DEBUG: X-Ops-Authorization-6: wgCGcpiKOMMZKRR0vhNgA7pyQ3U4iXLOplory+kEvA==
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: Content-Length: 274
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 204 No Content
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 0
DEBUG: connection: close
DEBUG: x-amz-request-id: g2gCZAATYm9va3NoZWxmQDEyNy4wLjAuMWgDYgAABYliAAwnmmIAAy+4
DEBUG: etag: eBGk49VuIXOfOV3p7xmuGg==
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 204 No Content
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 0
DEBUG: connection: close
DEBUG: x-amz-request-id: g2gCZAATYm9va3NoZWxmQDEyNy4wLjAuMWgDYgAABYliAAwnmmIAAv6j
DEBUG: etag: KTyA3PoQ9NtXz3Eb5d9xQg==
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 204 No Content
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 0
DEBUG: connection: close
DEBUG: x-amz-request-id: g2gCZAATYm9va3NoZWxmQDEyNy4wLjAuMWgDYgAABYliAAwnmmIAAzoK
DEBUG: etag: yGz6QPWBvQqmA3uiM0NpQA==
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 204 No Content
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 0
DEBUG: connection: close
DEBUG: x-amz-request-id: g2gCZAATYm9va3NoZWxmQDEyNy4wLjAuMWgDYgAABYliAAwnmmIAAz4V
DEBUG: etag: jY9upXMHjPKFFbMJXYKESw==
DEBUG: ---- End HTTP Status/Header Data ----
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_response
DEBUG: Committing sandbox
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::JSONToModelOutput#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Decompressor#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::Authenticator#handle_request
DEBUG: Signing the request as nils
DEBUG: Chef::HTTP calling Chef::HTTP::RemoteRequestID#handle_request
DEBUG: Chef::HTTP calling Chef::HTTP::ValidateContentLength#handle_request
DEBUG: Initiating PUT to https://centos6-1:10443/organizations/meh/sandboxes/ae7303275706e939f72732e3c4a682bd
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: Content-Type: application/json
DEBUG: Accept: application/json
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: X-OPS-SIGN: algorithm=sha1;version=1.0;
DEBUG: X-OPS-USERID: nils
DEBUG: X-OPS-TIMESTAMP: 2014-12-11T13:43:50Z
DEBUG: X-OPS-CONTENT-HASH: oMRtV6loUDnbKJuGcW6nqBbF8ww=
DEBUG: X-OPS-AUTHORIZATION-1: HAUujYXnWtCh8sRzF8X/0L4i2/0FTC/LqlrddwoT7QmTWGevJYcw4rgfaZOT
DEBUG: X-OPS-AUTHORIZATION-2: n/qTMr0vFnvtNxzeQuZK0ARAmSwn9mKacaK4yWBsaiSgACtvXH58YO4fZjHi
DEBUG: X-OPS-AUTHORIZATION-3: +N+OOPK2sxr3ThPnKWNWk5Wvsmg+o2LGKf095BkeASvCK4SgLYIP0Oc1bR+r
DEBUG: X-OPS-AUTHORIZATION-4: ciqOgY1LbCKm5tM7WsKiD0vPZe1FpL1WAvUGHpoTGddGe7OvKu+Z+Yirqoy8
DEBUG: X-OPS-AUTHORIZATION-5: 2h1JW2LrsEJ+hjE75aJuBITUT17t7JPdL2LKKfzkW3BYru0QjdasakruQqBT
DEBUG: X-OPS-AUTHORIZATION-6: iShTFZhbVOo3Bgdp8eyDScNZqo0GJleHpFHbZKYk3Q==
DEBUG: HOST: centos6-1:10443
DEBUG: X-REMOTE-REQUEST-ID: 783f1700-1367-4896-a04c-aa9195b17e22
DEBUG: Content-Length: 21
DEBUG: ---- End HTTP Request Header Data ----
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 500 Internal Server Error
DEBUG: server: ngx_openresty/1.4.3.6
DEBUG: date: Fri, 05 Dec 2014 16:22:50 GMT
DEBUG: content-type: application/json
DEBUG: content-length: 36
DEBUG: connection: close
DEBUG: x-ops-api-info: flavor=cs;version=12.0.0;oc_erchef=0.29.3
DEBUG: ---- End HTTP Status/Header Data ----
ERROR: Server returned error 500 for https://centos6-1:10443/organizations/meh/sandboxes/ae7303275706e939f72732e3c4a682bd, retrying 1/5 in 4s
==> /var/log/opscode/opscode-erchef/crash.log <==
{<<"method=PUT; path=/organizations/meh/sandboxes/ae7303275706e1d0e4ff6dc7686995b7; status=500; ">>,{error,{throw,{checksum_check_error,4},[{chef_wm_named_sandbox,validate_checksums_uploaded,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,144}]},{chef_wm_named_sandbox,from_json,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,99}]},{webmachine_resource,resource_call,3,[{file,"src/webmachine_resource.erl"},{line,186}]},{webmachine_resource,do,3,[{file,"src/webmachine_resource.erl"},{line,142}]},{webmachine_decision_core,resource_call,1,[{file,"src/webmachine_decision_core.erl"},{line,48}]},{webmachine_decision_core,accept_helper,1,[{file,"src/webmachine_decision_core.erl"},{line,612}]},{webmachine_decision_core,decision,1,[{file,"src/webmachine_decision_core.erl"},{line,517}]},{webmachine_decision_core,handle_request,2,[{file,"src/webmachine_decision_core.erl"},{line,33}]}]}}}2014-12-05 17:22:50 =ERROR REPORT====
Checking presence of file (checksum: <<"c86cfa40f581bd0aa6037ba233436940">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-c86cfa40f581bd0aa6037ba233436940") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50 =ERROR REPORT====
Checking presence of file (checksum: <<"293c80dcfa10f4db57cf711be5df7142">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-293c80dcfa10f4db57cf711be5df7142") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50 =ERROR REPORT====
Checking presence of file (checksum: <<"8d8f6ea573078cf28515b3095d82844b">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-8d8f6ea573078cf28515b3095d82844b") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50 =ERROR REPORT====
Checking presence of file (checksum: <<"7811a4e3d56e21739f395de9ef19ae1a">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-7811a4e3d56e21739f395de9ef19ae1a") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50 =ERROR REPORT====
{<<"method=PUT; path=/organizations/meh/sandboxes/ae7303275706e939f72732e3c4a682bd; status=500; ">>,{error,{throw,{checksum_check_error,4},[{chef_wm_named_sandbox,validate_checksums_uploaded,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,144}]},{chef_wm_named_sandbox,from_json,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,99}]},{webmachine_resource,resource_call,3,[{file,"src/webmachine_resource.erl"},{line,186}]},{webmachine_resource,do,3,[{file,"src/webmachine_resource.erl"},{line,142}]},{webmachine_decision_core,resource_call,1,[{file,"src/webmachine_decision_core.erl"},{line,48}]},{webmachine_decision_core,accept_helper,1,[{file,"src/webmachine_decision_core.erl"},{line,612}]},{webmachine_decision_core,decision,1,[{file,"src/webmachine_decision_core.erl"},{line,517}]},{webmachine_decision_core,handle_request,2,[{file,"src/webmachine_decision_core.erl"},{line,33}]}]}}}
==> /var/log/opscode/opscode-erchef/requests.log.1 <==
2014-12-05T16:18:18Z [email protected] method=PUT; path=/organizations/meh/cookbooks/empty/0.1.0; status=201; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAO9TAAAAAAAAAAA; org_name=meh; msg={created,<<"empty">>}; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=290; rdbms_time=70; rdbms_count=8; user=nils;
2014-12-05T16:18:26Z [email protected] method=GET; path=/organizations/meh/cookbooks/empty; status=200; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAO+ZgAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=26; rdbms_time=10; rdbms_count=7; authz_time=7; authz_count=1; user=nils;
2014-12-05T16:18:29Z [email protected] method=DELETE; path=/organizations/meh/cookbooks/empty/0.1.0; status=200; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAO+ywAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=173; rdbms_time=96; rdbms_count=7; authz_time=12; authz_count=1; s3_time=38; s3_count=1; user=nils;
2014-12-05T16:22:24Z [email protected] method=GET; path=/organizations/meh/cookbooks?num_versions=1; status=200; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPKEgAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=74; rdbms_time=23; rdbms_count=7; authz_time=44; authz_count=1; user=nils;
2014-12-05T16:22:41Z [email protected] method=GET; path=/organizations/meh/cookbooks?num_versions=all; status=200; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPLHQAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=28; rdbms_time=7; rdbms_count=7; authz_time=14; authz_count=1; user=nils;
2014-12-05T16:22:41Z [email protected] method=POST; path=/organizations/meh/sandboxes; status=201; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPLZgAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=255; rdbms_time=45; rdbms_count=8; user=nils;
2014-12-05T16:22:41Z [email protected] method=PUT; path=/organizations/meh/sandboxes/ae7303275706e1d0e4ff6dc7686995b7; status=500; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPMEwAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=26; rdbms_time=5; rdbms_count=6; authz_time=9; authz_count=1; s3_time=3; s3_count=1; user=nils;
2014-12-05T16:22:49Z [email protected] method=GET; path=/organizations/meh/cookbooks?num_versions=all; status=200; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPM3wAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=29; rdbms_time=8; rdbms_count=7; authz_time=11; authz_count=1; user=nils;
2014-12-05T16:22:50Z [email protected] method=POST; path=/organizations/meh/sandboxes; status=201; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPNKAAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=332; rdbms_time=65; rdbms_count=8; user=nils;
2014-12-05T16:22:50Z [email protected] method=PUT; path=/organizations/meh/sandboxes/ae7303275706e939f72732e3c4a682bd; status=500; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEDAAPNzwAAAAAAAAAA; org_name=meh; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=33; rdbms_time=5; rdbms_count=6; authz_time=6; authz_count=1; s3_time=13; s3_count=1; user=nils;
==> /var/log/opscode/opscode-erchef/erchef.log <==
2014-12-05 17:22:41.735 [error] {<<"method=PUT; path=/organizations/meh/sandboxes/ae7303275706e1d0e4ff6dc7686995b7; status=500; ">>,{error,{throw,{checksum_check_error,4},[{chef_wm_named_sandbox,validate_checksums_uploaded,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,144}]},{chef_wm_named_sandbox,from_json,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,99}]},{webmachine_resource,resource_call,3,[{file,"src/webmachine_resource.erl"},{line,186}]},{webmachine_resource,do,3,[{file,"src/webmachine_resource.erl"},{line,142}]},{webmachine_decision_core,resource_call,1,[{file,"src/webmachine_decision_core.erl"},{line,48}]},{webmachine_decision_core,accept_helper,1,[{file,"src/webmachine_decision_core.erl"},{line,612}]},{webmachine_decision_core,decision,1,[{file,"src/webmachine_decision_core.erl"},{line,517}]},{webmachine_decision_core,handle_request,2,[{file,"src/webmachine_decision_core.erl"},{line,33}]}]}}}
2014-12-05 17:22:50.352 [error] Checking presence of file (checksum: <<"c86cfa40f581bd0aa6037ba233436940">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-c86cfa40f581bd0aa6037ba233436940") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50.352 [error] Checking presence of file (checksum: <<"293c80dcfa10f4db57cf711be5df7142">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-293c80dcfa10f4db57cf711be5df7142") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50.352 [error] Checking presence of file (checksum: <<"8d8f6ea573078cf28515b3095d82844b">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-8d8f6ea573078cf28515b3095d82844b") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50.354 [error] Checking presence of file (checksum: <<"7811a4e3d56e21739f395de9ef19ae1a">>) for org <<"0b9c6e274c175682cf44ae7303275706">> from bucket "bookshelf" (key: "organization-0b9c6e274c175682cf44ae7303275706/checksum-7811a4e3d56e21739f395de9ef19ae1a") raised exception error:{aws_error,{socket_error,{conn_failed,{error,econnrefused}}}}
2014-12-05 17:22:50.354 [error] {<<"method=PUT; path=/organizations/meh/sandboxes/ae7303275706e939f72732e3c4a682bd; status=500; ">>,{error,{throw,{checksum_check_error,4},[{chef_wm_named_sandbox,validate_checksums_uploaded,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,144}]},{chef_wm_named_sandbox,from_json,2,[{file,"src/chef_wm_named_sandbox.erl"},{line,99}]},{webmachine_resource,resource_call,3,[{file,"src/webmachine_resource.erl"},{line,186}]},{webmachine_resource,do,3,[{file,"src/webmachine_resource.erl"},{line,142}]},{webmachine_decision_core,resource_call,1,[{file,"src/webmachine_decision_core.erl"},{line,48}]},{webmachine_decision_core,accept_helper,1,[{file,"src/webmachine_decision_core.erl"},{line,612}]},{webmachine_decision_core,decision,1,[{file,"src/webmachine_decision_core.erl"},{line,517}]},{webmachine_decision_core,handle_request,2,[{file,"src/webmachine_decision_core.erl"},{line,33}]}]}}}
The "sort" parameter in the search API is not working. Also reported in CHEF-2121.
This is causing Chef Manage(chef/chef#2279) and 'knife search' commands to display unsorted lists. Here are some "knife search" results to show the issue:
[apop@mymac chef-repo]$ knife search role "*:*" --id-only --sort asc -VV
...
DEBUG: Initiating GET to https://api.opscode.com/organizations/ap-org1/search/role?q=*%253A*&sort=asc&start=0&rows=1000
...
3 items found
windows_web
linux_base
windows_base
Same unsorted list returned with these commands:
knife search role "*:*" --id-only --sort name
knife search role "*:*" --id-only --sort name+desc
knife search role "*:*" --id-only --sort "name desc"
knife search role "*:*" --id-only --sort ascending
knife search role "*:*" --id-only --sort asc
knife search role "*:*" --sort asc
knife search role "*:*" --sort description
When doing a fresh CS12 install (in this case on REHL 5, on the backend of a tiered setup) the following error pops up:
[2014-11-11T17:20:15-05:00] FATAL: RuntimeError: ruby_block[migration-level file sanity check] (private-chef::partybus line 53) had an error: RuntimeError: ERROR:
The /var/opt/opscode/upgrades/migration-level file is missing or corrupt! Please read http://docs.opscode.com/upgrade_server_ha_notes.html#pre-flight-check and correct this file before proceeding
* If this is a new installation:
run: "cd /opt/opscode/embedded/service/partybus ; /opt/opscode/embedded/bin/bundle exec bin/partybus init"
* If you have upgraded a previous installation:
copy the /var/opt/opscode/upgrades/migration-level file from a not-yet-upgraded FrontEnd node
Error message No such file or directory - /var/opt/opscode/upgrades/migration-level
[root@ec2-54-148-65-220 ~]# cd /opt/opscode/embedded/service/partybus ; /opt/opscode/embedded/bin/bundle exec bin/partybus init
We should look into this error and determine how to avoid it/make it clearer.
Page: https://docs.getchef.com/server_orgs.html
Command: org-disassociate
[root@chef12-server2 ~]# chef-server-ctl | grep org-disassociate
[root@chef12-server2 ~]# chef-server-ctl | grep org-dissociate
org-dissociate
Version: chef-server-core-12.0.0_rc.5-1.el5.x86_64.rpm
Hello,
I created a new user:
# chef-server-ctl user-create teste teste teste [email protected] teste123
Tried to put this new guy on my organization created during the upgrade:
# chef-server-ctl org-user-add myorg teste
ERROR: bad gateway
Response: <html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>ngx_openresty/1.4.3.6</center>
</body>
</html>
Logs:
==> /var/log/opscode/nginx/error.log <==
2014/12/05 14:04:12 [error] 639#0: *252 no resolver defined to resolve opscode_account, client: 127.0.0.1, server: chef.infra.myorg.com.br, request: "POST /organizations/myorg/association_requests HTTP/1.1", host: "127.0.0.1:443"
==> /var/log/opscode/nginx/access.log <==
127.0.0.1 - - [05/Dec/2014:14:04:12 -0500] "POST /organizations/myorg/association_requests HTTP/1.1" 502 "0.040" 182 "-" "Chef Knife/11.12.2 (ruby-1.9.3-p547; ohai-7.4.0; x86_64-linux; +http://opscode.com)" "-" "-" "-" "11.12.2" "algorithm=sha1;version=1.0;" "pivotal" "2014-12-05T19:04:12Z" "O4TqHyxsBd83E2SpWYkQXy0qoRM=" 1081
And also:
[root@libras ~]# chef-server-ctl org-list
ERROR: bad gateway
Response: <html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>ngx_openresty/1.4.3.6</center>
</body>
</html>
Logs:
==> /var/log/opscode/nginx/error.log <==
2014/12/05 14:03:41 [error] 639#0: *250 no resolver defined to resolve opscode_account, client: 127.0.0.1, server: chef.infra.myorg.com.br, request: "GET /organizations HTTP/1.1", host: "127.0.0.1:443"
==> /var/log/opscode/nginx/access.log <==
127.0.0.1 - - [05/Dec/2014:14:03:41 -0500] "GET /organizations HTTP/1.1" 502 "0.000" 182 "-" "Chef Knife/11.12.2 (ruby-1.9.3-p547; ohai-7.4.0; x86_64-linux; +http://opscode.com)" "-" "-" "-" "11.12.2" "algorithm=sha1;version=1.0;" "pivotal" "2014-12-05T19:03:41Z" "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 983
Do you have some idea how to fix this?
Thanks a lot!
Using chef-server-core-12.0.0_rc.5-1.el5.x86_64.rpm
[root@chef12-server1 ~]# chef-sync-ctl show-config
Starting Chef Client, version 11.12.2
Compiling Cookbooks...
================================================================================
Recipe Compile Error
================================================================================
Chef::Exceptions::RecipeNotFound
--------------------------------
could not find recipe show_config for cookbook chef-sync
Running handlers:
Running handlers complete
[2014-10-28T20:02:11+00:00] FATAL: Stacktrace dumped to /opt/chef-sync/embedded/cookbooks/cache/chef-stacktrace.out
Chef Client failed. 0 resources updated in 1.929839187 seconds
[2014-10-28T20:02:11+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Details:
[root@chef12-server1 ~]# cat /opt/chef-sync/embedded/cookbooks/cache/chef-stacktrace.out
Generated at 2014-10-28 20:02:11 +0000
Chef::Exceptions::RecipeNotFound: could not find recipe show_config for cookbook chef-sync
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/cookbook_version.rb:226:in `load_recipe'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context.rb:165:in `load_recipe'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context/cookbook_compiler.rb:140:in `block in compile_recipes'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context/cookbook_compiler.rb:138:in `each'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context/cookbook_compiler.rb:138:in `compile_recipes'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context/cookbook_compiler.rb:75:in `compile'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/run_context.rb:88:in `load'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/policy_builder/expand_node_object.rb:73:in `setup_run_context'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/client.rb:265:in `setup_run_context'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/client.rb:429:in `do_run'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/client.rb:213:in `block in run'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/client.rb:207:in `fork'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/client.rb:207:in `run'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/application.rb:217:in `run_chef_client'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/application/solo.rb:221:in `block in run_application'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/application/solo.rb:213:in `loop'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/application/solo.rb:213:in `run_application'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/lib/chef/application.rb:67:in `run'
/opt/chef-sync/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.2/bin/chef-solo:25:in `<top (required)>'
/opt/chef-sync/embedded/bin/chef-solo:23:in `load'
/opt/chef-sync/embedded/bin/chef-solo:23:in `<main>'
As a customer, I would like CHEF to support more secure auth methods in their products.
Manage ticket for the same OC-11782
Most likely implementation point according to OC-11782 https://github.com/chef/chef-server/tree/master/src/oc-id
Aha! Link: https://chef.aha.io/features/SH-3038
The chef12-upgrade-download command has two options that have a short option of -d. I believe in this case the last one will win, but they should have unique short options. The work around for now is to just use the long option names.
See https://github.com/opscode/opscode-omnibus/blob/master/files/private-chef-ctl-commands/chef12_upgrade_download.rb#L27 and https://github.com/opscode/opscode-omnibus/blob/master/files/private-chef-ctl-commands/chef12_upgrade_download.rb#L53
The final portion of this change which invoked chef-mover to upgrade users to bcrypt-sha1 encryption was never merged in:
https://github.com/opscode/opscode-omnibus/pull/212/files#diff-065818c635e5d9c58ec887ed71a64cbdR22
Note that the underlying schema change exists in the current 'migration 13', but the migration does not include the execution of chef-mover to update the data: https://github.com/opscode/opscode-omnibus/blob/master/files/private-chef-upgrades/001/013_bcrypt_users.rb
Because the conversion is never done, data is not migrated from the legacy password (sha1) to the new password form (sha1-bcrypt intermediate stage, or bcrypt).
Secondarily, oc_erchef
no longer looks in users.serialized_object
field to validate a user's password, instead expecting them to exist in the password-related columns of the user table.
/authenticate_user
endpoint) until a password reset is performed for that user account.It would be great to have the ability in erchef to set the overall status to maintenance mode. Currently the overall good status looks like this:
{"status":"pong","upstreams":{"chef_solr":"pong","chef_sql":"pong"}}
When set to maintenance mode, I would like to see a different status result:
{"status":"maintenance","upstreams":{"chef_solr":"pong","chef_sql":"pong"}}
Here the use case: We would like to add two instances of Chef into a loadbalancer, those being active and passive. Our LB would call this status page and ensure the status is OK. The secondary chef server is placed into maintenance mode and hence removed from the load balancing. Now we'd like to upgrade to the latest Chef version by upgrading the secondary instance, run the backup/restore procedure to fill the ugpraded instance with data and switch it by enabling maintenance mode on the primary instance and disabling it on the secondary. The LB would automatically change the active node in the pool and we'd have a clean switch.
I understand that this would not include any Chef-Client status reports. These would probably still run as usual since they don't check the server status. Same thing for knife, which would be required to work (we'd like to pull a backup using knife-backup while an instance is in maintenance mode).
Again this is just an idea after recently doing an upgrade with the above scenario. Making the switch something we can control on the application side would be much better than an active change in the Loadbalancer.
In Enterprise Chef 11, /organizations/ORGNAME/ANYTHING_AT_ALL/_acl
endpoint queries would return the ACLs for ORGNAME.
Where as in Chef Server 12, only the /organizations/ORGNAME/organization/_acl
endpoint returns such info.
This breaks "knife download ..." and "knife ec backup ..." when used against chef server 12 (as well as any other ChefFS-based tools).
/cc @stevendanna @jkeiser
Workaround (https://github.com/opscode/chef/blob/master/lib/chef/chef_fs/file_system/acls_dir.rb#L57):
organization.json
-> organizations.json
Not for the initial release, but it is critical to have full documentation for the RBAC system and reasonable tools to manipulate it.
OPC/EC have presented a tough nut to crack in this regard, so clarification on standard procedure would really help.
The following abilities would be stellar
The number one unrepresented use-case for RBAC is #32
Attempting to upgrade from chef server 12 rc6 to the ga release prompted the following.
$ rpm -Uvh chef-server-core-12.0.0-1.el6.x86_64.rpm
warning: chef-server-core-12.0.0-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
Preparing... ########################################### [100%]
package chef-server-core-12.0.0_rc.6-1.el6.x86_64 (which is newer than chef-server-core-12.0.0-1.el6.x86_64) is already installed
I'm referring to bug #2457 in chef-client
Consider the following "platform constraints" in metadata.rb or Cookbook „example“
supports 'redhat', '~> 6.5'
supports 'redhat', '~> 7.0'
supports 'centos', '~> 6.5'
supports 'centos', '~> 7.0'
This actually leads to the following merge:
# run_context.cookbook_collection['example'].metadata.platforms
@platforms={"redhat"=>"~> 7.0", "centos"=>"~> 7.0"}
It's obvious why this i happening. I'd have been exspecting something like this:
@platforms={"redhat"=> ["~> 6.5", "~> 7.0"], "centos"=> ["~> 6.5", "~> 7.0"]}
Unfortunately this would introduce a breaking change.
Also there's a related bug which could be fixed with a similar approach.
I'd like to help - but I'm not sure which notation would be best.
Should we use:
supports 'centos', '~> 6.5'
supports 'centos', '~> 7.0'
or
supports 'centos', '~> 6.5', '~> 7.0'
or
supports 'centos', ['~> 6.5', '~> 7.0']
As a user, I would like Chef server responses to contain Cross Origin Resource Sharing headers so I can use the Chef server with HTTP clients that have a same-origin security policy.
This could be implemented by including some Nginx configuration and attributes in the configuration that could customize that configuration for my Chef server.
Basic support for this is enabled in Chef Zero.
My chef-server.rb:
nginx['non_ssl_port'] = 8081
nginx['ssl_port'] = 4000
After running chef-server-ctl reconfigure I can't upload cookbook:
INFO: Uploading /var/default/chef-data/cookbooks/squeeze64-1.13.0/yum/templates/default/main.erb (checksum hex = e5ab84fe45a83c038ff442722be03dbd) to https://127.0.0.1:4000/bookshelf/organization-55800a42d41ca4067b8d9cc3f9d1ab51/checksum-e5ab84fe45a83c038ff442722be03dbd?AWSAccessKeyId=e737796ac367dbe4a94c96ad3ed439d9a3099d17&Expires=1419376039&Signature=clYmIZ0ViZA3dXgosSXDTiH9LfA%3D
INFO: HTTP Request Returned 500 Internal Server Error: internal service error
ERROR: Server returned error for https://127.0.0.1:4000/organizations/default/sandboxes/9cc3f9d1ab51f248e5ce1ccd3913b6da, retrying 1/5 in 3s
INFO: HTTP Request Returned 500 Internal Server Error: internal service error
ERROR: Server returned error for https://127.0.0.1:4000/organizations/default/sandboxes/9cc3f9d1ab51f248e5ce1ccd3913b6da, retrying 2/5 in 8s
INFO: HTTP Request Returned 500 Internal Server Error: internal service error
ERROR: Server returned error for https://127.0.0.1:4000/organizations/default/sandboxes/9cc3f9d1ab51f248e5ce1ccd3913b6da, retrying 3/5 in 10s
Reason:
incorrect erchef template which assumes that default protocol port is used. Attempt to specify vip parameter with port (e.g. 1.1.1.1:4000) causes issue because normalize_host method parses specified string as IPv6
{chef_objects, [
{s3_access_key_id, "<%= node['private_chef']['bookshelf']['access_key_id'] %>"},
{s3_secret_key_id, "<%= node['private_chef']['bookshelf']['secret_access_key'] %>"},
{s3_url, "<%= node['private_chef']['nginx']['x_forwarded_proto'] %>://<%= @helper.vip_for_uri('bookshelf') %>"},
OC-11595 Manage: Self-Service Org Deletion
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.