This list has moved to a GitHub repo for easier tracking: https://github.com/coreos/awesome-kubernetes-extensions
Please comment below if you are using Kubernetes Third-Party Resources and I will add you to the list.
Known Users:
minikube start --kubernetes-version=v1.7.0 --extra-config=apiserver.Authorization.Mode=RBAC | |
kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default | |
minikube dashboard |
This list has moved to a GitHub repo for easier tracking: https://github.com/coreos/awesome-kubernetes-extensions
Please comment below if you are using Kubernetes Third-Party Resources and I will add you to the list.
Known Users:
#!/bin/sh -e | |
if [ -z "$SNAPCRAFT_SECRET" ]; then | |
# Run `sh seed.sh` on your local machine so SNAPCRAFT_SECRET is set. | |
exit 0 | |
fi | |
mkdir -p ".encrypted" | |
if [ ! -e ".encrypted/snapcraft.cfg.enc" ]; then | |
echo "Seeding a new macaroon." |
# -*- mode: ruby -*- | |
# vi: set ft=ruby : | |
# Vagrantfile API/syntax version. Don't touch unless you know what you're doing! | |
VAGRANTFILE_API_VERSION = "2" | |
$script = <<SCRIPT | |
source /home/vagrant/.bashrc | |
if [ ! -d /usr/local/go ]; then |
On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.
Support for keeping a long-lived (disk) cache of OCSP responses.
This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server
The following document is intended to be a quick guide to getting you setup for doing local development with Chef. This guide was created on my MacBook, but should work fine with Linux, and Windows workstations as well.
case "$(sw_vers -productVersion)" in | |
10.5.*|10.6.*) | |
alias flush_dns="sudo dscacheutil -flushcache" | |
;; | |
10.8.*|10.7.*) | |
alias flush_dns="sudo killall -HUP mDNSResponder" | |
;; | |
10.9.*) | |
alias flush_dns="sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder" | |
;; |
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
######## start up crap ######## | |
execve("/sbin/ifconfig", ["ifconfig"], [/* 16 vars */]) = 0 | |
brk(0) = 0xda6000 | |
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) | |
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f87bbd5d000 | |
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) | |
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 | |
fstat(3, {st_mode=S_IFREG|0644, st_size=106334, ...}) = 0 | |
mmap(NULL, 106334, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f87bbd43000 |