chrisroos

Every so often I have to restore my gpg keys and I'm never sure how best to do it. So, I've spent some time playing around with the various ways to export/import (backup/restore) keys.

Method 1

Backup the public and secret keyrings and trust database

cp ~/.gnupg/pubring.gpg /path/to/backups/
cp ~/.gnupg/secring.gpg /path/to/backups/
cp ~/.gnupg/trustdb.gpg /path/to/backups/

or, instead of backing up trustdb...

taddev

server {
    listen 80;
    listen [::]:80 default server ipv6only=on;
    
    location / {
        proxy_intercept_errors on;
        proxy_pass http://localhost:9000;
    }
    
    error_page 500 502 503 504 /50x.html;

ushu

This is a mix between two sources:

• http://www.alfielapeter.com/posts/8-transferring-s3-bucket-contents-between-accounts-with-s3cmd
• and http://blog.techopsguru.com/2011/12/s3-bucket-copying-with-multiple-accounts.html

basically the first resource is great but didn't work for me: I had to remove the trailing "/*" in the resource string to make it work. I also noticed that setting the policy on the source bucket was sufficient. In the end these are the exact steps I followed to copy data between two buckets on two accounts

Basically the idea there is:

• we allowe the destination account to read the source bucket (in the console for the source account)
• we log as the destination and start the copy

bjaglin

#!/bin/bash

set -eu
shopt -s nullglob

readonly base_dir=/var/lib/docker/registry
readonly output_dir=$(mktemp -d -t trace-images-XXXX)
readonly jq=/usr/bin/jq

readonly repository_dir=$base_dir/repositories

pwalsh

It is easy to get service accounts working with App Engine's app_devserver.py - once you know how.

On the way there, you might have pulled out all your hair following one documentation dead end after another, trying to piece together the right information.

Here are the steps you need to take, in exact order, to get this working. Once you follow these steps, you'll be able to use service accounts in local development, so that you can interact with Google APIs (e.g.: Spreadsheet, Calendar) in a way that is consistent with the deployment environment on App Engine.

In order to follow the instructions, you'll be better off using the latest UI for Google Cloud projects. Older interfaces (such as the dedicated App Engine dashboard) have things in different places, under different names, etc. It is a world of pain there.

Also note that I've tested this on several 1.9.x releases of App Engine; I can't confirm the behaviour of earlier releases.

olov

// You don't want to serve HTTPS supporting for SSL3.0 any longer, see:
// http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting-ssl-30.html
import (
	"crypto/tls"
	"net/http"
)

// This code supports SSL3.0, TLS1.0, TLS1.1 and TLS1.2
// Chances are you currently do this but want to stop due to the POODLE
err := http.ListenAndServeTLS(addr, "crtfile", "keyfile", handler)

jasonbrooks

The kubernetes ansible/vagrant install method can be used with the libvirt, virtualbox or openstack providers. The Vagrantfile requires that vagrant-openstack-provider be installed whether you're using it or not, so install it:

$ vagrant plugin install vagrant-openstack-provider

Alternatively, you can skip the second step above, but you'll need to comment out the require 'vagrant-openstack-provider' line in the Vagrantfile.

$ git clone https://github.com/jasonbrooks/contrib.git

shamasis

/**
 * @module describe-it
 *
 * This module defines global variables to provide unit test case runner functions compatible with mocha and jasmine.
 * The codebase is written for brevity and facilitate being as lightweight as possible.
 *
 * The code is intended to be included in Postman Test Sandbox.
 */

/**

warmfusion

High availability monitoring with Sensu

sensu | May 8, 2013

Redundancy. Availability. Scalability. Should sound familiar to you if you work in the web. Every system I build has to fit those 3 main criterias. I would also throw in manageability. If I can’t use Chef with it, I’m probably trying to use the wrong tool for the job.

There’s always been one exception though: my monitoring tool. Nagios. Zabbix. Zenoss. Shinken. Used them all. Each of them have shortcomings when it comes to the four criterias listed above. Different ones for each.

So, that said, a few months back, I was searching for something fresh. Something I could easily manage with Chef. Because I tend to forget things, and I wanted to automate as much as possible our monitoring solution. Don’t get me wrong, there’s nothing as good as developers to monitor your stuff, but I tend to like to know there’s something wrong before they show up at my desk. Even if it’s only 1-2 minutes ;)

turtlemonvh

a.myhost.com {
  tls off
  root /var/www/
  proxy / localhost:8091
  log log/access.a.log
}

b.myhost.com {
  tls off
  root /var/www/