Let Clash handle all local network traffic.
# Create a separate user to run Clash
useradd clash
# Note down UID
id clash
# Use rest of the file in this gist as usual.
#!/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 |
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:
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 |
This file aims to explain how to deploy Portainer inside a compose file with the admin password already set.
For this example, we'll use the password superpassword
.
Use the following command to generate a hash for the password:
#!/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 |
#!/usr/bin/env bash | |
# --slave /usr/bin/$1 $1 /usr/bin/$1-\${version} \\ | |
function register_clang_version { | |
local version=$1 | |
local priority=$2 | |
update-alternatives \ | |
--install /usr/bin/llvm-config llvm-config /usr/bin/llvm-config-${version} ${priority} \ |
kubectl -n kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller
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
package main | |
import ( | |
"fmt" | |
"net" | |
"time" | |
"bufio" | |
) | |
func handleConnection(conn net.Conn) { |