posener

Function Failure Reporting: Error or OK

Go's "multiple return values" feature, can be used for several purposes. Among them for failure reporting to the function caller. Go has two conventions for failure reporting, but currently, no clear convention for which to use when. I've encountered different programmers that prefer different choices in different cases. In this article, we will discuss the two, and try to make the process of choosing our next function signature more conscious.

The Basics

BrandonPotter

for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler flanneld; do
	systemctl restart $SERVICES
	systemctl enable $SERVICES
	systemctl status $SERVICES
done

restart kubelet/node services

for SERVICES in kube-proxy kubelet flanneld docker; do

systemctl restart $SERVICES

pr1ntf

#!/bin/sh

# Yet Another bhyve Script v0.4
# Use this to try and boot 9front, the Plan9 fork.
# Virtio emulation works better (ported drivers)
# PS/2 Mouse emulation requires updated bhyve(8)
# If you don't have it, patch is uploaded with this Gist
# When partitioning, I have had more success with MBR
# GPT may work for some people

so0k

Kubectl output options

Let's look at some basic kubectl output options.

Our intention is to list nodes (with their AWS InstanceId) and Pods (sorted by node).

We can start with:

kubectl get no

dvirsky

Creating a redis Module in 15 lines of code!

A quick guide to write a very very simple "ECHO" style module to redis and load it. It's not really useful of course, but the idea is to illustrate how little boilerplate it takes.

Step 1: open your favorite editor and write/paste the following code in a file called module.c

#include "redismodule.h"
/* ECHO <string> - Echo back a string sent from the client */
int EchoCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {

ryan0x44

A quick note on how I'm currently handling Blue/Green or A/B deployments with Terraform and AWS EC2 Auto Scaling.

In my particular use case, I want to be able to inspect an AMI deployment manually before disabling the previous deployment.

Hopefully someone finds this useful, and if you have and feedback please leave a comment or email me.

Overview

I build my AMI's using Packer and Ansible.

xrstf

Let's Encrypt on Ubuntu 14.04, nginx with webroot auth

This document details how I setup LE on my server. Firstly, install the client as described on http://letsencrypt.readthedocs.org/en/latest/using.html and make sure you can execute it. I put it in /root/letsencrypt.

As it is not possible to change the ports used for the standalone authenticator and I already have a nginx running on port 80/443, I opted to use the webroot method for each of my domains (note that LE does not issue wildcard certificates by design, so you probably want to get a cert for www.example.com and example.com).

Configuration

For this, I placed config files into etc/letsencrypt/configs, named after <domain>.conf. The files are simple:

mariotalavera

{
  "title": "collectd-post",
  "services": {
    "query": {
      "list": {
        "0": {
          "query": "plugin: \"cpu\" AND plugin_instance: \"0\"",
          "alias": "cpu1",
          "color": "#7EB26D",
          "id": 0,

dominicthomas

ffmpeg -i inputfile.wav -ab 320k outputfile.mp3

gleicon

server {
        listen   80;
        server_name ~^(www\.)?(?<siteid>.+)\.domain\.com$;
        log_format timed_combined '$remote_addr - $remote_user [$time_local]  '
                                    '"$request" $status $body_bytes_sent '
                                    '"$http_referer" "$http_user_agent" '
                                    '$request_time $pipe';

        access_log  /var/log/nginx/static_sites.domain.log timed_combined;
        root /var/www/$siteid;