neděle 4. listopadu 2018

Nginx Proxy With lets encrypt using Docker compose

I invested some work in managing my little hosted server more efficiently.
I use docker to run my services for a long time now. My budget for hosted machine is too small to start even single node Kubernetes which is my preferred way to manage containers. I ended up in using docker compose.

There is a little drawback in using compose. Every compose file creates it's own network by default and for my scenario, when I use the single server to host multiple domains through nginx proxy container it did not work as expected.

When multiple compose configurations are started, each has its own config and by default each runs in separate network.

Here is a simple trick which will do it.

 Create dedicated network prior starting it all and connect all the compose configurations to this network by default instead letting the compose create a network per configuration.

I start my reverse proxy containers using following compose:

version: '2'

services:

  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "nginx-proxy-vhosts:/etc/nginx/vhost.d"
      - "nginx-proxy-html:/usr/share/nginx/html"
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "nginx-proxy-certs:/etc/nginx/certs"

  letsencrypt-nginx-proxy-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    volumes_from:
      - "nginx-proxy"

volumes:
  nginx-proxy-vhosts:
  nginx-proxy-html:
  nginx-proxy-certs:
 

networks:
   default:
     external:
        name: proxy      


The last lines starting with networks will do it.

If you want to expose the service through this proxy, add the same section at the end of compose file. Eg:

version: '2'

services:
  some.service.name:
    image: php:apache
    environment:
      VIRTUAL_HOST: your.own.domain
      LETSENCRYPT_HOST:
your.own.domain
      LETSENCRYPT_EMAIL: your.own@email.xxx
    volumes:
      - "./html:/var/www/html"

networks:
  default:
    external:
      name: proxy





And that is all ... for today

úterý 2. ledna 2018

IOTA IRI remote authentication

When installing IOT IRI atm you can start it with authentication enabled. As the IRI developers really like trytes and trits and their home made curl hash (which by the way was proved a bit broken), the authentication uses the curl  for hashing the password. No documentation for this feature so some code digging was necessary to find the answer on how to configure remote authentication.

The configuration option can look like this:
  • in iri.ini
    REMOTE_AUTH =iota:DRDR...SRCJ
  • in command line arguments
    --remote-auth iota: DRDR...SRCJ
Above config means when prompted for password, you enter username "iota" and password "password".

To generate passwor hash use following script:

const Curl=require("iota.lib.js/lib/crypto/curl/curl.js")
const a2t=require("iota.lib.js/lib/utils/asciiToTrytes.js")
const conv=require("iota.lib.js/lib/crypto/converter/converter.js")
const IOTA=require("iota.lib.js")

let password=process.argv[2]
if ( ! password ) {
console.log("Usage: node hash-password.js ascii-password-to-hash")
process.exit(1)
}
let pwdTrytes = a2t.toTrytes(password)
let pwdTrits = conv.trits(pwdTrytes)
let curl=new Curl()
curl.initialize()
curl.absorb(pwdTrits, 0, pwdTrits.length)
let out=[]
curl.squeeze(out, 0, Curl.HASH_LENGTH)
console.log(conv.trytes(out))


This example is part of iota-experiments.