If you're getting errors like:
+---------------------------------------------+
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/
I hereby claim:
To claim this, I am signing this object:
One of the earliest lessons in a users' journey with using Chef is how to bootstrap a node with knife. Most of the tutorials will very reasonably illustrate some form of knife bootstrap but the immediate follow on question is often, how do I do this in production? The answer to that question is less directly clear because different infrastructure needs will lend themselves to different approaches. With the following I want to break down "bootstrapping" and illustrate a few approaches. This is not meant to be a comprehensive review of evertyhing possible but a deconstruction of the primitives in play.
Since Chef 12.2.0, the default bootstrapping method is "validatorless" - which as the name implies, exists in opposition to the fomer "validator" based approach. The older approach makes use of the unique org "validator" key that is created as part of an organisation on chef-server, you may have seen it referenced as "validation.pem" or "org-validator", which allows an
| Last login: Tue Feb 6 22:47:38 2018 from 172.20.123.177 | |
| vagrant@default-ubuntu-1604:~$ cd /root/ | |
| -bash: cd: /root/: Permission denied | |
| vagrant@default-ubuntu-1604:~$ ls | |
| vagrant@default-ubuntu-1604:~$ sudo su | |
| root@default-ubuntu-1604:/home/vagrant# cd /root/ | |
| root@default-ubuntu-1604:~# ls | |
| otp_src_19.3.tar.gz | |
| root@default-ubuntu-1604:~# ls -alh | |
| total 66M |
| chef-repo → tree . | |
| . | |
| ├── README.md | |
| ├── cookbooks | |
| │ ├── chefignore | |
| │ └── starter | |
| │ ├── attributes | |
| │ │ └── default.rb | |
| │ ├── files | |
| │ │ └── default |
| ### Keybase proof | |
| I hereby claim: | |
| * I am cheeseplus on github. | |
| * I am cheeseplus (https://keybase.io/cheeseplus) on keybase. | |
| * I have a public key ASD_Dy1mTPuj2tp_WpdX_XwN25emB34YXhp7fp0oWogomQo | |
| To claim this, I am signing this object: |
| <powershell> | |
| write-output "Running User Data Script" | |
| write-host "(host) Running User Data Script" | |
| # set administrator password | |
| cmd.exe /c net user Administrator RL9@T40BTmXh | |
| # RDP | |
| cmd.exe /c netsh advfirewall firewall add rule name="Open Port 3389" dir=in action=allow protocol=TCP localport=3389 |
| APP_HOME = '/usr/local/foo/bar' | |
| %w(file1 file2 file3).each do |f| | |
| cookbook_file "#{APP_HOME}/bin/#{f}" do | |
| source "home/#{APP_HOME}/bin/#{f}" | |
| end | |
| end |
| { | |
| "builders": [ | |
| { | |
| "boot_command": [ | |
| "<esc><wait>", | |
| "<esc><wait>", | |
| "<enter><wait>", | |
| "/install/vmlinuz<wait>", | |
| " auto<wait>", |
Enabling the shared folder cache based purely on platform name is overly agressive when the source of the box is unknown. The experience is statistically better if we know at least know that it's a bento box but even then that isn't a guarantee given versions of the hypervisor and vmtools in play. The proposed enhancements should not increase the number of downloads and are targetted at minimizing out of the box breakage for platforms which have an exceedingly low probability of working (i.e. anything not bento or boxcutter).
Shared folders are inherently brittle for a variety of reasons I've outlined on the issue and know far too well from building the bento boxes.
That said the only other alternative proposed is to utilize the transport layer of kitchen to shuttle the installer to the instance which is time consuming. We could test out the rsync shared folder method that vagrant provides which may be better in terms of performance.