Matt Holt 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),

Date: Mon, 5 Oct 2015 16:34:03 -0700

Apache caches an OCSP response for one hour by default. Unfortunately, once the hour is up, the response is purged from the cache, and Apache doesn't attempt to retrieve a new one until the next TLS handshake takes place. That means that if there's a problem contacting the OCSP responder at that moment, Apache is left without an OCSP response to staple. Furthermore, it caches the non-response for 10 minutes (by default), so for the next 10 minutes, no OCSP response will be stapled to your

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.

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

CT For Server (Developers)

Intro

Similar to my advice regarding OCSP Stapling for servers/server developers, based on questions I've received about "CT best practices," I wanted to write something similar for those writing server software. That is, this isn't targeted at server operators, but for those writing software like Apache, nginx, Caddy, etc.

At the most basic level, the deployment of Certificate Transparency to date has largely tried to focus the burden on CAs, rather than on server developers. If the CA is doing everything right,

	// 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

	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.

	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
	}
	}

	#!/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

	package main

	import (
	"github.com/kardianos/service"
	"log"
	"flag"
	)

	type Service struct {}

	// Handler that calls generate
	func ok(w http.ResponseWriter, r *http.Request) {
	// res := make([]int64, 0, 100000)
	var res [100000]int64
	fibonacci.Generate(&res)
	// fmt.Println(suc)
	// fmt.Printf("%T", res)
	// fmt.Println(res[50])

	fmt.Fprintf(w, "OK")