TLDR: Rollup and ES modules give us:
- smaller bundles due to tree-shaking and scope-hoisting, and
- faster runtime perf than CommonJS, by avoiding runtime module resolution
Sources to back up these wild claims:
Launch_Alpine_Linux_3.3.x_on_AWS.md
Create a local VM of Alpine Linux, eg: https://gist.github.com/kennwhite/959d47a77070d365ad60
On your workstation open a terminal and create a new ssh keypair:
ssh-keygen -t rsa -b 4096 -C "[email protected]"
alpine-test
Difficulty | Kraityn | Alira | Oak | Kill All |
---|---|---|---|---|
Normal | +10% to all elemental resistances | +60 base Mana | +40 base Life | 1 passive skill point |
Cruel | +8% Attack Speed | +5% Cast Speed | +16% Physical Damage | 1 passive skill point |
Merciless | +1 Max Frenzy Charge | +1 Max Power Charge | +1 Max Endurance Charge | 1 passive skill point |
AWS have released a new featue called CloudWatch Events, which lets you configure events fired by cloudwatch and direct them to SNS, Lambda functions, etc. Here's the blog post
Here's the motivational image:
First, check your current config (example output in homebrew.mxcl.postgresql.plist.xml
lower down in this gist):
cat ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
Most importantly, note the -D /usr/local/var/postgres
argument.
Second, shut down your current PostgreSQL.
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
If you use Amazon AWS for nearly anything, then you are probably familiar with KMS, the Amazon Key Management Service.
KMS is a service which allows API-level access to cryptographic primitives without the expense and complexity of a full-fledged HSM or CloudHSM implementation. There are trade-offs in that the key material does reside on servers rather than tamper-proof devices, but these risks should be acceptable to a wide range of customers based on the care Amazon has put into the product. You should perform your own diligence on whether KMS is appropriate for your environment. If the security profile is not adequate, you should consider a stronger product such as CloudHSM or managing your own HSM solutions.
The goal here is to provide some introductory code on how to perform envelope encrypt a message using the AWS KMS API.
KMS allows you to encrypt messages of up to 4kb in size directly using the encrypt()/decrypt() API. To exceed these limitations, you must use a technique called "envelope encryptio
#@ /etc/quagga/bgpd.conf (Centos & Ubuntu) | |
hostname <Local OS hostname> | |
password <Any random phrase> | |
enable password <Any random phrase> | |
! | |
log file /var/log/quagga/bgpd | |
!debug bgp events | |
!debug bgp zebra | |
debug bgp updates |
#!/bin/bash | |
# This script requires the following settings | |
# node attributes: | |
# file-copier: script-copy | |
# destdir: /tmp | |
# project properties: | |
# plugin.script-copy.default.command=/data/rundeck_scripts/gateway-copier.sh ${node.ssh-keypath} ${node.jumpNode_user} ${node.jumpNode} ${node.username} ${node.hostname} ${file-copy.destination} ${file-copy.file} | |
# plugin.script-copy.default.remote-filepath=${node.destdir}/${file-copy.filename} | |
KEYPATH=$1 | |
shift |
This uses terraform's template_file
resource to generate a yaml properties file for serverspec to use.
spec
directory and put spec_helper.rb
in ittemplates/properties.tmpl.yml
fileserverspec.tf
terraform apply
Tests will be matched based on roles defined for a given node.