mholt

Keybase proof

I hereby claim:

• I am mholt on github.
• I am mholt (https://keybase.io/mholt) on keybase.
• I have a public key whose fingerprint is 7C5D 8989 09D4 E407 20B8 1FF3 1DAA D2EB EC55 EA33

To claim this, I am signing this object:

mholt

// Comcast Cable Communications, LLC Proprietary. Copyright 2014.
// Intended use is to display browser notifications for critical and time sensitive events.
var _ComcastAlert = (function(){
	return {
		SYS_URL: '/e8f6b078-0f35-11de-85c5-efc5ef23aa1f/aupm/notify.do'
		, dragObj: {zIndex: 999999}
		, browser: null
		, comcastCheck: 1
		, comcastTimer: null
		, xmlhttp: null

mholt

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

mholt

config_server "https://etcd.local:2379"

service users {
  endpoint: "/users",
  proxy: "{{services.users.ip}}:{{services.users.port}}"
}


# In this example 'services.users' would be a directory with a json key for every user service container / application. 
# Using this we could template the proxy and any other information in the services block, and it would just work with caddy.

mholt

fff.red {
    header / {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Content-Security-Policy "default-src https:*"
        Public-Key-Pins "pin-sha256=\"ckOIjdimiwD3mfMmkmCh7uiJCBtXvoqoBoKKB1K5UIM=\"; pin-sha256=\"QiTyymM4e635OgWkx9d7nq5xvEuqmgV7HiDjIIGyymo=\"; max-age=2592000"
        X-Frame-Options SAMEORIGIN
        X-XSS-Protection "1; mode=block"
        X-Content-Type-Options nosniff
    }
}

mholt

Supervisors

A supervisor's main task, is to start a specified process (in a specified environment), watch it running, and do something when it ends - usually based on the exit code.

Systemd

From my experience, the environment setup can be a complex task (consult some config management for the required ports, actualize the config file from the central config management...), and this is where the most featureful supervisor (systemd, AFAIK) falls short:

• it can setup & manage the listening sockets, and pass it to your app (if it can accept it - not hard, just have to be ready for it),

mholt

#!/bin/bash
# *As root*

cd ~
killall caddy
rm -rf ~/caddy
mkdir caddy && cd caddy
curl -SL 'https://caddyserver.com/download/build?os=linux&arch=amd64&features=hugo' > caddy.tgz
tar xzf caddy.tgz 

mholt

// This program was used to build Caddy up to (but not including) v0.10.
// On April 20, 2017, it was replaced by a new releaser script that
// integrates with the autonomous build server. It bundles assets into
// an archive format that best fits the target OS. It could use `go build`
// to compile, but the way I configured it was to run the build.bash
// script that ensured the Caddy binary had proper version information
// embedded.
//
// I'm posting this here because it is no longer available in the Caddy
// repository and maybe you will find it useful for your own (simple?)

mholt

example.com

# specifying an empty root is not strictly necessary but not a bad
# idea if all you are serving on this site is the backups
root empty_www/

# authentication is required when using the Caddy plugin;
# this line assumes all requests are protected
basicauth / user pass

mholt

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.

1. 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