Do you want to do remote development on your WSL2 container in Visual Studio Code? Read this.
- On the host set up OpenSSH for Windows
- Run
wsl --update
to make sure you are running the latest WSL - Open WSL and install another SSH server inside WSL with
sudo apt-get install openssh-server
- Now run
sudo systemctl enable --now ssh
to automatically start ssh when WSL starts.
You should not use the Open SSH client that comes with Git for Windows. Instead, Windows 10 has its own implementation of Open SSH that is integrated with the system. To achieve this:
- Start the
ssh-agent
from Windows Services:
- Type
Services
in theStart Menu
orWin+R
and then typeservices.msc
to launch the Services window; - Find the
OpenSSH Authentication Agent
in the list and double click on it; - In the
OpenSSH Authentication Agent Properties
window that appears, chooseAutomatic
from theStartup type:
dropdown and clickStart
fromService status:
. Make sure it now saysService status: Running
.
- Configure Git to use the Windows 10 implementation of OpenSSH by issuing the following command in Powershell:
git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe
Encoder hevc_nvenc [NVIDIA NVENC hevc encoder]: | |
General capabilities: dr1 delay hardware | |
Threading capabilities: none | |
Supported hardware devices: cuda cuda d3d11va d3d11va | |
Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 bgra rgb0 rgba x2rgb10le x2bgr10le gbrp gbrp16le cuda d3d11 | |
hevc_nvenc AVOptions: | |
-preset <int> E..V....... Set the encoding preset (from 0 to 18) (default p4) | |
default 0 E..V....... | |
slow 1 E..V....... hq 2 passes | |
medium 2 E..V....... hq 1 pass |
This document describes one means of running a simple Apache Spark cluster on Cloud Foundry. It makes heavy use of Cloud Foundry's container networking features.
You can see an example running at http://spark-ui-proxy.184.73.108.92.xip.io.
This cluster was deployed using BOSH-Lite on AWS. Note, this Director cannot be targetted with the new BOSH CLI (see cloudfoundry-attic/bosh-lite#424), but you can use the "old" Ruby CLI just fine. You can use the new CLI for local workflows like manifest interpolation, and then the "old" CLI for remote workflows like deploying and SSH.
# CF <= v245 | |
USE ccdb; | |
SELECT | |
apps.id AS AppID, | |
apps.name AS AppName, | |
apps.guid AS AppGUID, | |
apps.state AS AppState, | |
routes.id AS RouteID, | |
routes.host as RouteHost, | |
routes.path AS RoutePath, |
#!/bin/bash | |
# After a 1.7+ opsmanager restarts with a new ip address | |
# ssh into the opsmanager as 'ubuntu' and | |
# Run this file from the opsmanager as follows | |
# sudo su -l postgres < thisfile.sh > | |
# Get the current public ip or hostname from aws metadata | |
HN=$(curl http://169.254.169.254/latest/meta-data/public-hostname) |
#!/usr/bin/env ruby | |
# Usage: ./download_scripts_and_templates <repo> <ref> | |
# Output: Directory of download | |
require 'bundler/setup' | |
require 'logger' | |
require 'octokit' | |
require 'base64' | |
def prereqs |
- Do you sometimes want to run performance benchmarks, stress/load tests, or security vulnerability probes against a shared integration environment, or even a production environment?
- Do you worry about polluting these environments, or not leaving any audit trail when things go wrong?
Here are a couple scripts to setup, and later teardown, a cleanroom environment (user, org, space, quota) for doing just these kinds of experiments.