irvingpop

Note to customers have used the data purging feature (—remove-partitions) introduced in Reporting 1.3.0

Due to a bug in the upgrade process, If you’ve removed any of the 2015 data partitions the upgrade will fail. To determine if this applies to you, as well as to resolve the issue, run the following steps on your Standalone or Primary Backend Chef Server:

1. To see if you’ve removed them, query the list of reporting tables and verify that you have node_run_2015_* and node_run_detail_2015_* tables (12 of each):

# sudo -u opscode-pgsql /opt/opscode/embedded/bin/psql opscode_reporting -c "\dt"
could not change directory to "/root"
                    List of relations

irvingpop

Chef Server

• The Chef Server runbook: https://docs.chef.io/runbook.html
• Tuning the Chef Server for scale: http://irvingpop.github.io/blog/2015/04/20/tuning-the-chef-server-for-scale
• pgAdmin 3: https://www.pgadmin.org/

Linux

• Brendan Gregg - Linux Performance: http://www.brendangregg.com/linuxperf.html
• Brendan Gregg - USE method: http://www.brendangregg.com/usemethod.html

Postgres

irvingpop

#!/bin/bash
# Tune the elasticsearch shard and replica count after chef-backend has been setup, but before any Frontends have been configured
# based on the following docs:
#   https://www.elastic.co/guide/en/elasticsearch/guide/current/replica-shards.html
#   https://www.elastic.co/guide/en/elasticsearch/guide/current/_scale_horizontally.html
#   https://www.elastic.co/blog/clustering_across_multiple_data_centers
#
#  This process will change once this Chef Server PR has been accepted: 
#    https://github.com/chef/chef-server/pull/988

irvingpop

#!/bin/bash -ex
# All of this is to be run from the Automate server, assumes you have a ChefDK installed there

# Step 0, supply the right windows IP, username, password

WINDOWS_HOST='10.42.46.165'
WINDOWS_USER='Administrator'
WINDOWS_PASSWORD='VerySecurePassword'

irvingpop

{
    "mycookbook": {
        "attribute1": "${attribute1}",
        "attribute2": "${attribute2}"
    },
    "run_list": [
        "recipe[${recipe}]"
    ]
}

irvingpop

# Create a systemd service that runs at shutdown to remove one's node and client from the chef server,
#  useful in AutoScale and Terraform-managed scenarios
#  not useful in cases where you may want to shutdown (but not terminate) a node

systemd_unit 'chef-cleanup.service' do
  content('Unit' => {
            'Description' => 'Delete my own Chef node and client objects at shutdown/termination',
            'DefaultDependencies' => 'no',
            'Before' => 'shutdown.target halt.target',
          },

irvingpop

AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  KeyName:
    Type: AWS::EC2::KeyPair::KeyName
    Description: Name of an existing EC2 KeyPair to enable SSH access to the ECS instances.
  VPC:
    Type: AWS::EC2::VPC::Id
    Description: Select a VPC that allows instances access to the Internet.
  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>

irvingpop

From 4fb2f312c60cd10f57c08051d4243d3e62b1fbfb Mon Sep 17 00:00:00 2001
From: Irving Popovetsky <[email protected]>
Date: Fri, 18 Aug 2017 13:05:55 -0700
Subject: [PATCH] Fix notifications habitat binds so that they can be optional
 and remove an unneeded one for database

---
diff --git a/notifications/habitat/config/env b/notifications/habitat/config/env
index faa23c642..19d70da22 100644
--- a/notifications/habitat/config/env

irvingpop

# ssh key generator data source expects the below 3 inputs, and produces 3 outputs for use:
#  "${data.external.ssh_key_generator.result.public_key}" (contents)
#  "${data.external.ssh_key_generator.result.private_key}" (contents)
#  "${data.external.ssh_key_generator.result.private_key_file}" (path)
data "external" "ssh_key_generator" {
  program = ["bash", "${path.root}/../ssh_key_generator.sh"]

  query = {
    customer_name = "${var.customer_name}"
    customer_group = "${var.customer_group}"

irvingpop

MY_INSTANCEID
MY_SERVER
user-data.txt
.zshrc
.gitconfig
.ssh
.byobu
.oh-my-zsh