didip

[unix_http_server]
file=/tmp/supervisor.sock                       ; path to your socket file

[supervisord]
logfile=/var/log/supervisord/supervisord.log    ; supervisord log file
logfile_maxbytes=50MB                           ; maximum size of logfile before rotation
logfile_backups=10                              ; number of backed up logfiles
loglevel=error                                  ; info, debug, warn, trace
pidfile=/var/run/supervisord.pid                ; pidfile location
nodaemon=false                                  ; run supervisord as a daemon

filterfish

#!/usr/bin/env ruby

require 'pathname'

uri = ARGV[0] || (puts "usage: #{$0} <uri>"; exit 1)

Pathname.new('pipe').open("w") do |fd|
  fd.puts(uri)
end

duydo

If you want, I can try and help with pointers as to how to improve the indexing speed you get. Its quite easy to really increase it by using some simple guidelines, for example:

- Use create in the index API (assuming you can).
- Relax the real time aspect from 1 second to something a bit higher (index.engine.robin.refresh_interval).
- Increase the indexing buffer size (indices.memory.index_buffer_size), it defaults to the value 10% which is 10% of the heap.
- Increase the number of dirty operations that trigger automatic flush (so the translog won't get really big, even though its FS based) by setting index.translog.flush_threshold (defaults to 5000).
- Increase the memory allocated to elasticsearch node. By default its 1g.
- Start with a lower replica count (even 0), and then once the bulk loading is done, increate it to the value you want it to be using the update_settings API. This will improve things as possibly less shards will be allocated to each machine.
- Increase the number of machines you have so

unbracketed

"""
Exports Issues from a specified repository to a CSV file

Uses basic authentication (Github username + password) to retrieve Issues
from a repository that username has access to. Supports Github API v3.
"""
import csv
import requests

moyashi

#!/usr/bin/awk

BEGIN {
    for (i = 0; i <= 255; i++) {
	ord[sprintf("%c", i)] = i
    }
}

function escape(str, c, len, res) {
    len = length(str)

kntyskw

#!/bin/sh

VIP=$1
IF=$2

# Determine the interface's MAC address
MAC=`ip link show $IF | awk '/ether/ {print $2}'`

# Determine ENI ID of the interface
ENI_ID=`curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/$MAC/interface-id`

miketheman

Adding 2 nodes to an existing 3-node ZooKeeper ensemble without losing the Quorum

Since many deployments may start out with 3 nodes and so little is known about how to grow a cluster from 3 memebrs to 5 members without losing the existing Quorum, here is an example of how this might be achieved.

In this example, all 5 nodes will be running on the same Vagrant host for the purpose of illustration, running on distinct configurations (ports and data directories) without the actual load of clients.

YMMV. Caveat usufructuarius.

Step 1: Have a healthy 3-node ensemble

schnell18

#!/bin/sh
# script to automate the creation of chroot jail
# w/ minimal executables to run git

export CHROOT=/var/chroot

function copy_binary() {
    for i in $(ldd $*|grep -v dynamic|cut -d " " -f 3|sed 's/://'|sort|uniq)
      do
        cp --parents $i $CHROOT

pkuczynski

#!/bin/sh
parse_yaml() {
   local prefix=$2
   local s='[[:space:]]*' w='[a-zA-Z0-9_]*' fs=$(echo @|tr @ '\034')
   sed -ne "s|^\($s\)\($w\)$s:$s\"\(.*\)\"$s\$|\1$fs\2$fs\3|p" \
        -e "s|^\($s\)\($w\)$s:$s\(.*\)$s\$|\1$fs\2$fs\3|p"  $1 |
   awk -F$fs '{
      indent = length($1)/2;
      vname[indent] = $2;
      for (i in vname) {if (i > indent) {delete vname[i]}}

btsync-secret

#!/bin/sh
#/ Usage: btsync-secret [option]...
#/ A Bittorrent Sync Secret Generator
set -e

h_flag=false
v_flag=false
e_flag=false
n_flag=false
c_flag=false