James Cuzella trinitronx

Format Changes to Test Kitchen's kitchen.yml File

This is happening thanks to a refactoring of the data manipulation code formerly in Kitchen::Config.

There are now 3 main configuration blocks that can be placed in the various levels:

driver: Configurtation relavent to Kitchen drivers. This is a combination of what was driver_plugin and driver_config. Backwards compatability is guarenteed with the legacy formats for a time, then will be deprecated (with a warning when encountered), then will be removed in a future release.
provisioner: Configuration relating to the automation tool being used. Currently supporting "chef_solo" and "chef_zero". Previously several Chef-related config paths were dumped in a Suite block, namely data_path, data_bags_path, environments_path, nodes_path, roles_path, etc. These will be supported for backwards compatability, then will be deprecated (with a warning when encountered), then will be removed in a future release.
busser: Configuration rela

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

I have spent quite a bit of time figuring out automounts of NFS shares in OS X...

Somewhere along the line, Apple decided allowing mounts directly into /Volumes should not be possible:

/etc/auto_master (see last line):

#
# Automounter master map
#

+auto_master # Use directory service

Removal of McAfee from OSX

Note: This was written in 2015, it may be out of date now.

There are a lot of commands here which I use sudo if you don't know what you're doing with sudo, especially where I rm you can severely screw up your system.

There are many reasons which you would want to remove a piece of software such as McAfee, such as not wanting it to hammer your CPU during work hours which seems like primetime for a virus scan.

I intend this to be a living document, I have included suggestions from peoples' replies.

Verify and Repair Disk Permissions via Terminal (Mac OS X)

Verify Permissions

diskutil verifyPermissions /

Repair Permissions

diskutil repairPermissions /

	---
	# This has been tested with ansible 1.3 with these commands:
	# ansible-playbook -i hosts ansible_conditionals_examples.yaml --extra-vars="hosts=myhosts isFirstRun=false"
	# ansible-playbook -i hosts ansible_conditionals_examples.yaml --extra-vars="hosts=myhosts isFirstRun=true"
	# ansible-playbook -i hosts ansible_conditionals_examples.yaml --extra-vars="hosts=myhosts"
	# NB: The type of the variable is crucial!

	- name: Ansible Conditionals Examples
	hosts: $hosts
	vars_files:

	module Serverspec
	module Type
	class Supervise < Base
	def initialize(name)
	@name = name
	end

	def status
	ret = backend.run_command("svstat /service/#{@name} \| awk '{print $2}'")
	ret[:stdout].chomp

	# Usage: IE={box} vagrant up
	#
	# Eg. IE=XPIE6 vagrant up

	boxes = {
	"XPIE6" => "http://aka.ms/vagrant-xp-ie6",
	"XPIE8" => "http://aka.ms/vagrant-xp-ie8",
	"VistaIE7" => "http://aka.ms/vagrant-vista-ie7",
	"Win7IE8" => "http://aka.ms/vagrant-win7-ie8",
	"Win7IE9" => "http://aka.ms/vagrant-win7-ie9",

	INTRO
	I get asked regularly for good resources on AWS security. This gist collects some of these resources (docs, blogs, talks, open source tools, etc.). Feel free to suggest and contribute.

	Short Link: http://tiny.cc/awssecurity

	Official AWS Security Resources
	* Security Blog - http://blogs.aws.amazon.com/security/
	* Security Advisories - http://aws.amazon.com/security/security-bulletins/
	* Security Whitepaper (AWS Security Processes/Practices) - http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf
	* Security Best Practices Whitepaper - http://media.amazonwebservices.com/AWS_Security_Best_Practices.pdf