maddiem4/goldilocks

Start and stop services based on contents of Bitcoin wallet.

Goldilocks

Start and stop services based on contents of Bitcoin wallet.

Configuration

Goldilocks is run as its own user, from a JSON or YAML config file. If you run it as a different user than specified in the config, it will attempt to switch to that user, and die with a message if it fails. This is for security.

In order to allow Goldilocks the ability to control system-level things without full root access, you will want to customize your /etc/sudoers file. You may want to wrap Goldilocks' behavior in wrapper scripts that ignore all arguments, so as to not even provide unfettered access to the specific commands you want to run.

#!/bin/bash
# /bin/goldilocks_start

service nginx start

#!/bin/bash
# /bin/goldilocks_stop

service nginx stop

# /etc/sudoers

User_Alias GOLD_NG = goldilocks_nginx
Cmnd_Alias GOLD_NG_CMNDS = /bin/goldilocks_start, /bin/goldilocks_stop

GOLD_NG ALL = (root) NOPASSWD: GOLD_NG_CMNDS 

Goldilocks itself is capabable of detecting the current balance in a Bitcoin wallet, and regularly transferring money to a different wallet, via a connection to a local bitcoind process over standard RPC.

{
    "meta": {
        "admin": "Scooby Doo",
        "contact": "1-800-555-1334"
    },
    "rpc_alias": {
        "default" : "https://alladin:opensesame@localhost/"
    },
    "services":  {
        "nginx" : {
            "description" : "Turn nginx on and off",
            "address"     : "<some long bitcoin addr>",
            "threshold"   : "0 BTC",
            "commands"    : {
                "start" : "sudo /bin/goldilocks_start",
                "stop"  : "sudo /bin/goldilocks_stop",
                "status": "pgrep nginx"
            }
        }
    },
    "schedules": {
        "daily_retrieval" : {
            "from" : "<same bt addr as earlier>",
            "to" : "<personal bt addr>",
            "amount" : "0.002 BTC",
            "frequency" : "0 5 * * *"
        }
    },
    "templates": {
        "overview" : {
            "source" : "/srv/goldilocks/templates/overview",
            "output" : "/srv/www/gl/index.html"
        },
        "global_json_dump" : {
            "source" : "core.json",
            "output" : "/srv/www/gl/core.json"
        }
    }
}

Services

Service entries use bitcoin RPC to verify that the address has more money than the threshold, starting or stopping the service as necessary based on the commands specified.

Schedules

Schedule entries regularly move money from one address to another using RPC, using the cron schedule syntax.

Templates

Template entries use the Go template module to produce HTML static files, that are updated whenever Goldilocks internal state updates. You can either serve these directly by saving them to your web server's static file tree, which allows for very efficient/cheap availability.

For more "involved" uses, you can also save a dump of all (non-security-risk) internal state as a JSON, YAML, or bencode file, using special sources "core.json", "core.yaml", and "core.bencode", respectively.

Your OS's filesystem caching should be perfectly sufficient to ensure that this information is cached in-memory for your application, without requiring a disk hit.

goldilocks's Issues

Populate "template" subcommand

We have a placeholder here, we just have to fill it. This subcommand should use the html/template package to write templates to config-specified locations, or stdout.

Use maps in config

Since adjusting the config model such that services, schedules, and templates all have names, store them as maps rather than arrays of things that have Name attrs.

Bitcoin RPC module

Something vital is the connection to a bitcoind application, or compatible API (such as blockchain.info) using the information defined in the config.

Bare minimal functionality

Stuff that needs to get done for goldilocks to be usable, even if it's not friendly, or takes a bit of external setup work.

Add "schedule" subcommand

Code to query RPC interface, and start/stop a service based on wallet contents and service status. May use stub for RPC if not available during development, as that can just be fixed later.

Add "service" subcommand

Services are regularly-scheduled monetary transfers defined in the config. At some point they may have a bigger scope of responsibilities.

The service subcommand should run a transfer immediately according to a given list of service names (or all known services, no service names provided). This will be driven by cron.

Config parsing

Module for reading and parsing JSON config, from a default location, or a location specified in an environ variable if available.

Tests for template subcommand

I don't really know Go well enough to know the best way to do this yet. I'll still make some haphazard shot at it later, if I have to, but I'd love if someone showed up who knew what they were doing. Advice welcome!