Cannot accept chef-client license on bootstrapping

Since this morning, I've been unable to run a kitchen converge due to the following error:

       +---------------------------------------------+
            Chef License Acceptance

       Before you can continue, 2 product licenses
       must be accepted. View the license at
       https://www.chef.io/end-user-license-agreement/

       Licenses that need accepting:
         * Chef Infra Client
         * Chef InSpec

       Do you accept the 2 product licenses (yes/no)?

       > Prompt timed out. Use non-interactive flags or enter an answer within 60 seconds.

       If you do not accept this license you will
       not be able to use Chef products.

       Do you accept the 2 product licenses (yes/no)?

       > Prompt timed out. Use non-interactive flags or enter an answer within 60 seconds.
       +---------------------------------------------+
       Chef Infra Client cannot execute without accepting the license
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Converge failed on instance <justone-macos-1014>.  Please see .kitchen/logs/justone-macos-1014.log for more details
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Since this is non-interactive, there's no opportunity to accept the license and the chef-client install fails.

I've considered starting an instance manually, setting the CHEF_LICENSE env variable, and then converging the instance. Is this the procedure for bootstrapping a test instance?

Thanks.

1 Like

Per
https://chefcommunity.slack.com/archives/C2B6G1WCQ/p1557855344164500

@stromweld:

just found a work around that allows chef 15 to work with test-kitchen 1.24 simply add license to client config in provisioner:

provisioner:

name: chef_zero

always_update_cookbooks: true

retry_on_exit_code:

- 35 # 35 is the exit code signaling that the node is rebooting

max_retries: 1

client_rb:

exit_status: :enabled # Opt-in to the standardized exit codes

client_fork: false  # Forked instances don't return the real exit code

environment: _default

chef_license: accept

product_name: chef

product_version: 15

1 Like

I am also having the same issue: https://discourse.chef.io/t/chef-client-chef-license-accept-invalidoption-windows-10/15117

This issue just started today, and unfortunately its happening to all SEs in the office that use chef for kitchen

Have you tried the previous solution I mentioned; setting the license acceptance in the client.rb?

Thanks, Dan-Joe. Updating the provisioner in my .kitchen.yml file worked for me.

@Dan-Joe Here is the configuration for my kitchen.yml file:

---
driver:
  name: vagrant
  customize:
    natdnshostresolver1: 'on'
    natdnsproxy1: 'on'
provisioner:
  name: chef_zero
  always_update_cookbooks: true
client_rb:
  chef_license: accept
verifier:
  name: inspec
  format: <%= ENV['CI'] ? 'junit' : 'cli' %>
  sudo: true
platforms:
  - name: centos1
    driver:
      box: bento/centos-7.3
      box_url: bento/centos-7.3
      customize:
        memory: 2000
        cpus: 2
      network:
        - ["private_network", {ip: "192.168.12.39"}]
        - ["forwarded_port", {guest: 50506, host: 9962}]
        - ["forwarded_port", {guest: 9600, host: 9963}]
        - ["forwarded_port", {guest: 5044, host: 6578}]
  - name: centos2
    driver:
      box: bento/centos-7.3
      box_url: bento/centos-7.3
      customize:
        memory: 2000
        cpus: 2
      network:
        - ["private_network", {ip: "192.168.12.40"}]
  - name: centos3
    driver:
      box: bento/centos-7.3
      box_url: bento/centos-7.3
      customize:
        memory: 2000
        cpus: 2
      network:
        - ["private_network", {ip: "192.168.12.41"}]

suites:
  - name: recent
    run_list:
      - recipe[git_logstash_kafka_indexer_centos::main]
    includes:
      - centos1
      - centos2
      - centos3

My versions for gems are the following:

chef-client --version
Chef: 14.12.3

kitchen --version
Test Kitchen version 1.23.2

Is it really required to install chef 15 for this issue? chef 15 isn't installed using any of the chefdk links on the official website that I can see, referencing both stable and unstable

I don't think you have to install v15 on your workstation, but I think the chef-client that is being bootstrapped onto your instance is going to be v15, pulled from ChefCo.

Since your provisioner is not configured to a specific version of chef, the client that is installed on your test nodes would seem to be chef 15.

Try adding product_version: 14 to the provisioner section, if your intention is not to test on chef-client:latest

@Dan-Joe @jasen

Thank you guys for your help, was able to get it to work with the following configuration

provisioner:
  name: chef_zero
  always_update_cookbooks: true
  product_version: 14
  client_rb:
    chef_license: accept

Will reference this solution on my post as well. Thank you

1 Like

Thank you so much for posting the solution! Tried everything I could think of, but nothing worked until I found this.

Seeing this post earlier would've saved me about 30 minutes. Thank you! I was researching Chef docs and github issues with spotty results. This did it. Thanks, again, and humbly suggest to update .kitchen.yml in git repository.

humbly suggest to update .kitchen.yml in git repository.

The kitchen.yml which git repository?

The kitchen.yml which git repository?

https://github.com/learn-chef/learn_chef_apache2
and/or update documentation here:

You can also force kitchen to bootstrap chef 14 on the node to solve the issue. I like the license option better but there are potential legal issues there if you are not paying for Chef licensing.

provisioner:
  name: chef_zero
  product_name: chef
  product_version: 14
  install_strategy: always

I have the same problem. But for some reason in my Chef i don't have a file "kitchen.yml".
I can create it, but have no idea, should it be on workstation or on server? As well in what folder it should be placed? Thank you.