Skip to content

Instantly share code, notes, and snippets.

🎯
Focusing

Seth Thomas cheeseplus

🎯
Focusing
Block or report user

Report or block cheeseplus

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@cheeseplus
cheeseplus / workaround.md
Last active Jul 16, 2019
Chef Infra License Errors in Test-kitchen and Packer
View workaround.md

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/
       
View keybase.md

Keybase proof

I hereby claim:

  • I am cheeseplus on github.
  • I am cheeseplus (https://keybase.io/cheeseplus) on keybase.
  • I have a public key ASCO0ZkHwiaSWXMGKgkuAX3PfdVUfel-8QNiCT0_7ueYtAo

To claim this, I am signing this object:

View bootstrapping.md

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.

a brief detour regarding validation

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

@cheeseplus
cheeseplus / gist:dce1713c982057a6f417d3edfb30c9ac
Created Feb 7, 2018
vagrant log for erlang.org gzip inflation diagnosis
View gist:dce1713c982057a6f417d3edfb30c9ac
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
View gist:e5099a493d9ac1f8ef9d29320067ce6d
chef-repo → tree .
.
├── README.md
├── cookbooks
│   ├── chefignore
│   └── starter
│   ├── attributes
│   │   └── default.rb
│   ├── files
│   │   └── default
View gist:2766890167814003e109e24182f0e73a
### 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:
View gist:dfd17a66e1fd925813ec57c5ddf3c1bf
<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
View gist:2ce5998bba2da173424794837bc09c76
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
View chef-solo-packer-hang
{
"builders": [
{
"boot_command": [
"<esc><wait>",
"<esc><wait>",
"<enter><wait>",
"/install/vmlinuz<wait>",
" auto<wait>",
View kitchen-vagrant-caching.md

tl;dr

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

Caching mechanism

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.

You can’t perform that action at this time.