Archive

Archive for 2018

Running Akamai Sandbox in Docker with HTTPS

October 12th, 2018 1 comment

Akamai’s new Sandbox can be run on local development environments, so you can test changes in development with production like CDN settings. This allows you to more quickly identify issues before rolling out to production.

The Akamai sandbox (or DevPoPs) is a Java app (see https://bit.ly/aka-sb-gh). This Java app can be containerised for portability/ease of setup and use.

I created a simple docker compose setup (https://github.com/NoodlesNZ/devpops-test).

This can be used with a real certificate (which is signed by a CA), but works as well with a self signed certificate using (on a Mac):

openssl req \
    -newkey rsa:2048 \
    -x509 \
    -nodes \
    -keyout server.key \
    -new \
    -out server.crt \
    -subj /CN=www.example.com \
    -reqexts SAN \
    -extensions SAN \
    -config <(cat /System/Library/OpenSSL/openssl.cnf \
        <(printf '[SAN]\nsubjectAltName=DNS:www.example.com')) \
    -sha256 \
    -days 3650

This is included in the conf/config.json file:

{
  "connectorServerInfo": {
    "secure": true,
    "port": 443,
    "host": "0.0.0.0",
    "cert": {
      "certChainPath": "./conf/server.crt",
      "keyPath": "./conf/server.key"
    }
  },
  "originMappings": [
    {
      "from": "",
      "to": {
        "secure": true,
        "port": 8443,
        "host": "host.docker.internal"
      }
    }
  ],
  "jwt": ""
}

Explaining a few options in the config.json file.

In the connectorServerInfo section:
- secure: true - enables https
- port: 443 - listens on port 443
- host: 0.0.0.0 - bind to all ip addresses (needed for docker as binding to 127.0.0.1 doesn't work)
- cert - public/private key as generated with openssl

In the originMappings section:
- from: - the origin hostname in your Akamai property, e.g. origin.example.com
- to - the local/development origin
- secure: true - enabled https on the new origin
- port: 8443 - As the Sandbox is now listening on port 443, the origin needs to be on a different port
- host: host.docker.internal - special docker hostname on mac, which resolves to the host's ip address. This assumes that your dev server is also hosted on your mac.

This setup can also be incorporated into an existing docker compose setup, e.g.

version: '2'
services:
  web:
    image: example/web:latest
    networks:
      - appnet
  devpops:
    image: noodlesnz/devpops:latest
    volumes:
      - ./conf:/opt/devpops/conf
    ports:
      - 443:443
    networks:
      - appnet
networks:
  appnet:
    driver: "bridge"

With web and devpops sharing the same docker network, you can use the host "web" with your config.json, e.g.

{
  "connectorServerInfo": {
    "secure": true,
    "port": 443,
    "host": "0.0.0.0",
    "cert": {
      "certChainPath": "./conf/server.crt",
      "keyPath": "./conf/server.key"
    }
  },
  "originMappings": [
    {
      "from": "",
      "to": {
        "secure": true,
        "port": 443,
        "host": "web"
      }
    }
  ],
  "jwt": ""
}

This also means that the development origin can only be accessed through the Akamai Sandbox, as web doesn't have any ports exposed.

Categories: Uncategorized Tags:

ipv6 workaround for Unifi USG on 2 Degrees UFB

September 20th, 2018 No comments

I had an issue where our USG Pro was not getting ipv6 from 2 Degrees UFB after upgrading our Controller to 5.8. After a lot of messing around with this, I found a workaround originally posted here: https://community.ubnt.com/t5/UniFi-Routing-Switching/USG-DHCPv6-PD-bug-when-using-PPPoE/td-p/2487710.

Digging into the dhcpv6-pd logs shows this:

Dumping out the config I saw that I had two dhcpv6-pd blocks, one under interface eth2 vif 10 and the other under interface eth2 vif 10 pppoe 2 (where it should be):

It was possible to temporarily fix this issue by removing the first block:

This allowed our USG to get ipv6 from our ISP and now all the clients on the network also got ipv6.

To make this more permanent I had to add this file on the USG under /config/scripts/post-config.d/dhcp.sh

To run this script, I added the following on the Controller in /usr/lib/unifi/data/sites/default/config.gateway.json:

This runs the dhcp.sh script 2 minutes after provisioning and then the script removes the scheduled task (as it only needs to run once).

Categories: Uncategorized Tags: