nykma

Let Clash handle all local network traffic.

Setup

# Create a separate user to run Clash
useradd clash
# Note down UID
id clash
# Use rest of the file in this gist as usual.

fepitre

#!/bin/bash

# Frédéric Pierret <frederic.pierret@qubes-os.org>

# Adapted from previous work:
# - https://gist.github.com/daktak/f887352d564b54f9e529404cc0eb60d5
# - https://gist.github.com/jpouellet/d8cd0eb8589a5b9bf0c53a28fc530369
# - https://gist.github.com/Joeviocoe/6c4dc0c283f6d6c5b1a3f5af8793292b

[ "$DEBUG" = 1 ] && set -x

dhkatz

Using MSYS2 with Visual Studio Code is extremely easy now thanks to the Shell Launcher extension by Tyriar.

First, install the extension and reload Visual Studio Code.

Then, open the settings.json to edit your settings.

Add the field shellLauncher.shells.windows. I recommend using autocompletion here so that all the default shells are added.

You should having something like this now:

mingrui

When installing latest docker-ec 18, I encountered libseccomp2 version problem

https://www.ubuntuupdates.org/ppa/ubuntu_sdk_release?dist=xenial

add this to update libseccomp2

then install docker-ce

deviantony

Portainer compose deployment with admin password preset

This file aims to explain how to deploy Portainer inside a compose file with the admin password already set.

Generate the admin password

For this example, we'll use the password superpassword.

Use the following command to generate a hash for the password:

Joeviocoe

#!/bin/sh
# Inspired by https://gist.github.com/daktak/f887352d564b54f9e529404cc0eb60d5
# Inspired by https://gist.github.com/jpouellet/d8cd0eb8589a5b9bf0c53a28fc530369

ip() { qvm-prefs -g -- "$1" ip; }
netvm() { qvm-prefs -g -- "$1" netvm; }

forward() {
	local from_domain=$1
	local to_domain=$2

mgoodness

kubectl -n kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller

jonathan-kosgei

I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).

A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.

And it was a dream!

All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.

And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go

hongster

package main

import (
	"fmt"
	"net"
	"time"
	"bufio"
)

func handleConnection(conn net.Conn) {

hyper0x

package main

import (
	"bufio"
	"bytes"
	"fmt"
	"io"
	"log"
	"net"
	"os"