chef / chef-server

Chef Infra Server is a hub for configuration data; storing cookbooks, node policies and metadata of managed nodes.

Chef Infra Server

Umbrella Project: Chef Infra Server

Project State: Active

Issues Response Time Maximum: 14 days

Pull Request Response Time Maximum: 14 days

NOTE: we know we have a backlog, and are working through it, but this applies for new requests.

This repository is the central repository for the Chef Infra Server.

If you want to file an issue about Chef Infra Server or contribute a change, you're in the right place.

If you need to file an issue against another Chef project, you can find a list of projects and where to file issues in the community contributions section of the Chef docs.

Getting Help

We use GitHub issues to track bugs and feature requests. If you need help please post to our Mailing List or join the Chef Community Slack.

• Chef Community Slack at https://community-slack.chef.io/.
• Chef Mailing List https://discourse.chef.io/

Components of the Chef Infra Server

This repository contains the core services that make up the Chef Infra Server.

|-- oc-chef-pedant: A comprehensive test suite for the Chef Infra Server API
|-- omnibus: Omnibus build configuration for the Chef Infra Server
|-- scripts: Utility scripts
`-- src
    |-- bookshelf: S3-compatible engine for storing cookbook data
    |-- oc-id: OAuth2 provider for extensions like Supermarket
    |-- oc_bifrost: Chef Infra Server's authorization service
    |-- oc_erchef: The core REST API server
    |-- chef-server-ctl: The Chef Infra Server's command line management utility

Working on the Chef Infra Server

The quickest way to get a Chef Infra Server development environment is to follow the instructions in the dev directory. This environment is based on Vagrant and features hot reloading of code.

Building a Chef Infra Server package locally

You can build a Chef Infra Server package locally with HashiCorp Vagrant and Test Kitchen.

cd omnibus/
make dev dev-build

Once the build is complete, the package should be in omnibus/pkg. By default the dev-build target will create an Ubuntu 18.04 build.

Habitized Chef Infra Server

The following components now exist as Habitat packages and are available here:

• nginx
• bookshelf
• oc_id
• oc_erchef
• oc_bifrost
• chef-server-ctl

To build the packages locally:

./habitat_pkgs_build.sh

A top-level docker-compose.yml file exists for running Chef Infra Server from Habitized Docker images:

docker-compose down && docker system prune --volumes -f && docker-compose up

Running pedant tests:

docker-compose exec chef-server-ctl chef-server-test

Running chef-server-ctl:

docker-compose exec chef-server-ctl chef-server-ctl command (subcommands)

Dependencies contained in other repositories

• knife-ec-backup, used to backup your Chef Infra Server for disaster recovery or migrations.
• knife-opc, used to provide administrative command-line control to the Chef Infra Server from the console

Major Technologies used in Chef Infra Server

• Erlang
• PostgreSQL
• Redis
• Elasticsearch
• Nginx (openresty with lpeg library addition)
• Runit for service supervision

If you're looking to contribute to certain parts of the Chef Infra Server, familiarity with the following related tools is also beneficial, depending on the area.

• rebar (used for dependency management in Erlang)
• sqitch (database migrations)
• lua (routing rules in openresty)

Chef Expeditor

The chef/chef-server repository, like many other Chef Software repositories, leverages an internal utility called Chef Expeditor to create a pub-sub model of actions across our various CI/CD utilities.

Contributing

For information on contributing to this project see https://github.com/chef/chef/blob/main/CONTRIBUTING.md

License & Authors

Copyright: 2008-2022, Chef Software, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License. 

chef-server's Issues

Confusing error message if hostname cannot be found in configuration file

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.

Reconfigure doesn't handle not having a hostname set well

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.

Refactor cleanup_procs_and_nuke used by p-s-c/c-s-c uninstall or cleanse

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.

Improvement: Maintenance Mode

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.

LDAP system recovery password set up error

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.

private-chef-cookbooks: is_data_master? Guard Unnecessary In Embedded nginx Recipe

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.

CS12rc6 upgrade of OSC 11.1.4 leaves OSC's runsvdir tree running

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.

Attempting to disassociate an admin in an org results in a broken organization

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.

Can't upload cookbooks after certificate update

Chef Server 11.1.6

Server tail shows this error:

==> /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

Client error

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

depsolver concurrency limitations

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

Add show-versions Subcommand to Omnibus-ctl

chef/omnibus-ctl#19

Sorting not working for search API

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

Installing local packages is indeterminate if you have multiple packages of the same version in the install dir

Say you have opscode-reporting_1.0.0.deb and opscode-reporting_1.0.1.debin 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.

undefined method on chef-server-ctl password

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:

• User ec_sync_user:

[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>'

• User tiago_cruz:

[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

Manual partybus init

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.

Ubuntu 14.10: chef-server-ctl reconfigure fails if procps is already running

Version:

chef server 12 rc5

Environment:

Ubuntu 14.10 x64

Scenario:

install chef server package

Steps to Reproduce:

chef-server-ctl reconfigure

Problem:

/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

Log:

==> 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

Password-based auth will fail for installations upgraded from early 11.x EC and 1.4

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.

Impacts

• If an installation of chef server originated at 11.1.x or earlier, password data for users created prior to 11.2.x is kept in the older sha1 hash format until they log in successfully via web ui.
• if a certain upgrade path is followed, users will not be able to log into manage under 12.x (or directly authenticate against the /authenticate_user endpoint) until a password reset is performed for that user account.

Who Impacted

• Installations of chef server that have upgraded from 11.1 or 1.4 -> 11.2
• Installations of chef server that have upgraded from 11.x -> 12.x

Not impacted

• Users created after installation 11.2 or higher
• New installations that started after 11.2 or higher
• users imported via upgrade from OSC 11.

Exceptions

• if a user logged in while 11.2.x was installed, their password would have have been updated to the new format in the process of logging in.

Potential race condition with ACL & group editing

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.

When you create a user via chef-server-ctl add-user with --filename pointed at invalid path, the user is created, but the key is not put on the filesystem.

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.

c-s-c chef12-upgrade-download command has two -d options

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

Unable to remove users from Admin Group

Unable to remove a user from the admin's group, (at least from the WebUI) it does not say something but the following data base conflict:

** Sorry for the log as an attachment. There is no way I can get the logs from the client. Super secure data center.

Running on:

• Chef-Server 12 rc.5
• RHEL 6.5

Manage 1.6.2+ Account Link Controller Depends On Next Release of erchef/Chef 12.0.x

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

Chef Server 12: Document RBAC and Tools

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

1. Recreate all standard groups and perms as during an org creation.
2. Add orphaned users back to the Users group, orphaned admins back to the Admins group.
3. If at all possible, a process by which things can be set back to a known good working state. Failing that, fall back on documentation of the oc_bifrost schemas and RBAC system’s functioning to decipher the issue.

The number one unrepresented use-case for RBAC is #32

Small typo with org-disassociate

Page: https://docs.getchef.com/server_orgs.html

Command: org-disassociate

• Wrong:

[root@chef12-server2 ~]# chef-server-ctl | grep org-disassociate

• Right:

[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

Chef 12 Pedant Failure On First Run

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

chef server core 12.0 rc6 rpm thinks its newer than ga

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

hosted Enterprise Chef: Query Adjustments for /cookbooks/_recipes Endpoint

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)

opscode-expander-reindexer can likely be removed

opscode-expander-reindexer's intended purpose was for reindexing the entire Chef Server. In theory you would do this:

1. Turn off opscode-expander
2. Run a reindex tool which sends all updates to the /reindex rabbitmq vhost which is read by opscode-expander-reindexer.
3. Once the reindex is complete, restart opscode-expander, processing writes that have come in since step (1).

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.

CORS support

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.

chef-server-ctl upgrade error: ERROR: File chef/cookbooks/var/chef is a directory while file chef/cookbooks/var/chef is a regular file

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

Chef Server 12: Provide Read-Only RBAC Group

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.

Cookbook uploading fails when running nginx on an alternative port

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.

With the default settings:

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]

On the alternative port 10443

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

Running in verbose mode:

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

Relevant log entries on chef server:

==> /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}]}]}}}

Support Multi Factor Authentication in oc-id

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

Temp file leak

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.

Small typo in chef-server-ctl

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

intermittent 401s from Chef Server

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 should pass back metadata.json in a consistent format

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-sync-ctl show-config does not work

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>'

no resolver defined to resolve opscode_account

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!

/organizations/<orgname>/<anything>/_acl enpoint differs between EC11 & CS12

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

Chef 12 Logging Passwords

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}]}]}}}

postgres shared_buffers calculation is broken because values have different units

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.

1. the ohai value in node['memory']['total'].to_i is in kB
2. shmmax value is bytes
3. shared_bytes is assumed to be in kB

My recommendation is that every value should be converted to bytes and then proceed with calculations.

https://github.com/opscode/opscode-omnibus/blob/12.0.0/files/private-chef-cookbooks/private-chef/attributes/default.rb#L377-L385

Multiple version constraints for the same platform in metadata.rb ignored

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']

Impossible to upload cookbooks if non-standard port is used

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') %>"},

Enterprise Chef / Chef Server 12: View Public Keys of all Users

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

Feature Request: Implement requirements check

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.

Better error reporting from gen_servers and other erlang applications

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.

chef-server-ctl user-create throws error if email address has a . in 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.

EC11 to CS12 upgrade uses `make` command which crashes the upgrade when not available

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.

https://github.com/opscode/opscode-omnibus/blob/12.0.0-rc.7/files/private-chef-upgrades/001/014_upgrade_migration_schema.rb#L8

The old way of running the sqitch migration doesn't use make so we haven't run into this problem before.

https://github.com/opscode/opscode-omnibus/blob/12.0.0-rc.7/files/private-chef-upgrades/001/013_bcrypt_users.rb#L7-L10

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

Support Self-Service Org Deletion

OC-11595 Manage: Self-Service Org Deletion