phrawzty

Keybase proof

I hereby claim:

• I am phrawzty on github.
• I am phrawzty (https://keybase.io/phrawzty) on keybase.
• I have a public key whose fingerprint is AD02 9B5B 8E50 C37A 19B8 3B3A 7BFE B7A5 4571 BB21

To claim this, I am signing this object:

phrawzty

iOS:

2017-05-19 10:15:13,011 (7fcfcde91700) :  DEBUG (runtime:717) - Handling request GET /music/audioaddict/channel?thumb=http%3A%2F%2Fstatic.audioaddict.com%2F2%2F9%2F0%2F1%2Fe%2Ff%2F2901ef5c923bb0f9ff856ac4007975f0.png&title=Chill+%26+Tropical+House&url=http%3A%2F%2Fprem2.radiotunes.com%3A80%2Frtchillntropicalhouse_hi%3F67b893d2c95e1c1&fmt=mp3&include_container=True&summary=The+sounds+of+Chill+%26+Tropical+House+are+expertly+made+for+lounging+and+dancing+alike+with+its+deeper+house+vibes.+%5Bmp3%2C+320%5D+%5Bhttp%3A%2F%2Fprem2.radiotunes.com%3A80%2Frtchillntropicalhouse_hi%3F67b893d2c95e1c1%5D&bitrate=320&includeBandwidths=1
2017-05-19 10:15:13,016 (7fcfcde91700) :  DEBUG (runtime:814) - Found route matching /music/audioaddict/channel
2017-05-19 10:15:13,018 (7fcfcde91700) :  CRITICAL (runtime:889) - Exception (most recent call last):
  File "/usr/lib/plexmediaserver/Resources/Plug-ins-4955e31cf/Framework.bundle/Contents/Resources/Versions/2/Python/Framework/components/runtime.py", line 843, in handle

phrawzty

// See photo of whiteboard.

digraph model {
    "Firefox" -> "CDN / Cloudfront";
    "Kinto Origin" [label="Kinto Origin (ELB & EC2)"];
    "CDN / Cloudfront" -> "Kinto Origin";
    "Kinto Origin" -> "Heka";
    "Kinto Origin" -> "PG" [label="RO"];
    "Kinto Admin" [label="Kinto Admin (EC2 & EIP)"];
    "Kinto Admin" -> "PG" [label="RW"];

phrawzty

#!/usr/bin/env bash

set -e

TFORM_VERSION="0.5.3_linux_amd64"

gem install puppet puppet-lint
puppet-lint --with-filename --no-80chars-check --no-autoloader_layout-check --fail-on-warnings puppet/
puppet parser validate `find puppet/ -name '*.pp'`

phrawzty

variable "environment" {}
variable "access_key" {}
variable "secret_key" {}
variable "secret_bucket" {}
variable "subnets" {}
variable "collector_cert" {
    default = {
        prod  = ""
        stage = ""
    }

phrawzty

AWS ELBs have a series of "policies" which group different HTTPS (read: TLS and SSL) profiles together. It is possible that the "2011-08" policy would be appropriate for this purpose (remains to be verified), otherwise we can define a custom policy that fits our needs. Unfortunately for us, these policies cannot currently be managed in Terraform, so this may end up be trickier than we'd first envisioned.

One possible workaround is to use local-exec to apply the policy manually, as suggested by t0m on IRC: http://paste.scsys.co.uk/488127

  provisioner "local-exec" {
    command = "aws elb create-load-balancer-policy --region ${var.region} --profile ${var.account} --load-balancer-name ${aws_elb.extelb.name} --policy-name EnableProxyProtocol --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=Tru

phrawzty

#!/usr/bin/env python2

import SimpleHTTPServer
import SocketServer
import logging

PORT = 8000

class GetHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):

phrawzty

S3 as Yum repo

There are two parts to this:

• Managing access to non-public S3 resources.
• Building RPM repositories in an automated, deterministic way that Yum can use.

Environment

In general, a CentOS 7 x86_64 box in AWS EC2; in specific, this Packer profile.

phrawzty

Roles and Types

There are a number of "roles" in the Socorro infra. The resource profiles for these roles are not identical, ergo there will be different AWS instance types for different roles.

The roles are:

• Admin
• Collectors
• Crash-Analysis
• Elasticsearch
• Middleware

phrawzty

Managing multiple user accounts within the cloud-based Socorro infrastructure is a fool's errand; instead, the plan is use a single login (role acccount) with multiple accepted SSH keys (one per user). These keys are managed from the Source of Truth and implanted during the node provisioning step.

In order to keep track of things, however, it will be helpful to tag the public SSH keys with an identifier of the user that possesses the associated private key. Normally this is what the "comment" field is for:

ssh-rsa <big_ol_key> [comment]

The issue here is that the "comment" section isn't exported, announced, or otherwise relevent at all from a system perspective. Instead, I propose adding a small environment variable that does the job:

environment="SSH_KEY=happyuser" ssh-rsa <big_ol_key> [comment]