Kirsi Rinnesalo kirsirinnesalo

Permanent WSL DNS Fix (WSL 2.2.1+)

If you're encountering ping github.com failing inside WSL with a Temporary failure in name resolution, you're not alone — this has been a long-standing issue, especially when using VPNs or corporate networks.

This issue is now fixed robustly with DNS tunneling, which preserves dynamic DNS behavior and avoids limitations like WSL’s former hard cap of 3 DNS servers in /etc/resolv.conf.

DNS tunneling is enabled by default in WSL version 2.2.1 and later, meaning that if you're still seeing DNS resolution issues, the first and most effective fix is simply to upgrade WSL. Upgrading WSL updates the WSL platform itself, but does not affect your installed Linux distributions, apps, or files.

To upgrade WSL, follow these steps,

How to automatically start ssh server on boot on Windows Subsystem for Linux

Microsoft partnered with Canonical to create Bash on Ubuntu on Windows, running through a technology called the Windows Subsystem for Linux. Below are instructions on how to set up the ssh server to run automatically at boot.

Edit the /etc/ssh/sshd_config file by running the command sudo vi /etc/ssh/sshd_config and do the following
1. Change Port to 2222 (or any other port above 1000)
2. Change PasswordAuthentication to yes. This can be changed back to no if ssh keys are setup.
Restart the ssh server:
- sudo service ssh --full-restart
With this setup, the ssh server must be turned on every time you run Bash on Ubuntu on Windows, as by default it is off. Use this command to turn it on:

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

Follow standard conventions.
Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
Boy scout rule. Leave the campground cleaner than you found it.
Always find root cause. Always look for the root cause of a problem.

Design rules

If you're like me you have a dir like ~/Workspace/Github where all your git repos live. I often find myself making a change in a repo, getting side tracked and ending up in another repo, or off doing something else all together. After a while I end up with several repos with modifications. This script helps me pick up where I left off by checking the status of all my repos, instead of having to check each one individually.

Usage:

git-status [directory]

This will run git status on each repo under the directory specified. If called with no directory provided it will default to the current directory.

	#!/usr/bin/env bash

	# This script stashes the currently staged changes, and leaves everything else in the working directory as-is.
	# (source: https://stackoverflow.com/questions/14759748/stashing-only-staged-changes-in-git-is-it-possible/39644782#39644782)

	# Prompt for the desired repo path
	REPOPATH=
	read -p "Enter the repo path, or press ENTER for current dir: " REPOPATH

	# Read the desired stash description from the command line, or prompt the user for it if necessary

	onEnter : (String -> msg) -> Attribute msg
	onEnter tagger =
	let
	isEnter code =
	if code == 13 then
	Decode.succeed ""
	else
	Decode.fail ""
	decodeEnter =
	Decode.andThen isEnter keyCode

	# Example makefile with some dummy rules

	.PHONY: all
	## Make ALL the things; this includes: building the target, testing it, and
	## deploying to server.
	all: test deploy

	.PHONY: build
	# No documentation; target will be omitted from help display
	build:

	# Add vi customization to less
	VLESS=$(find /usr/share/vim -name 'less.sh')
	if [ ! -z $VLESS ]; then
	alias less=$VLESS
	fi