garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

electerious

mime {
    .atom application/atom+xml
    .json application/json
    .map application/json
    .topojson application/json
    .jsonld application/ld+json
    .rss application/rss+xml
    .geojson application/vnd.geo+json
    .rdf application/xml
    .xml application/xml

AGWA

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

ericclemmons

Using <details> in GitHub

Suppose you're opening an issue and there's a lot noisey logs that may be useful.

Rather than wrecking readability, wrap it in a <details> tag!

<details>
 Summary Goes Here

kennwhite

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

phred

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

hlandau

This is a rough sketch I've put together in my mind of how an 'ACME daemon' might end up looking.

API

acmetool is designed for batch operation which works well for small use cases but large scale deployments will work better with a daemon. This will probably expose a service via an HTTP API, so that arbitrary parts of a service provider's stack can request certificates.

This API will need to be asynchronous as it may take arbitrarily long for 'acmed'

j-mcnally

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.

captncraig

apt-get update
apt-get install -y curl git mercurial make binutils bison gcc build-essential

git clone https://go.googlesource.com/go go14
git clone go14 go15
git clone go14 go16

#build all go versions
cd go14/src

tgulacsi

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