mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-25 16:52:00 +00:00
WSL updates
This commit is contained in:
Philip Sargent
parent
71f3e762eb
commit
f32035e5a7
@ -2,7 +2,7 @@
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>CUCC Expedition Handbook: Programmers manual</title>
|
||||
<title>CUCC Expedition Handbook: Basic expo laptop</title>
|
||||
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
||||
</head>
|
||||
<body>
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>Key-Pair Setup (Expo handbook)</title>
|
||||
<title>Expo handbook - Key-Pair Setup</title>
|
||||
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
||||
</head>
|
||||
<body>
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>CUCC Expedition Handbook: Programmers manual</title>
|
||||
<title>CUCC Expedition Handbook: Windows expo laptop</title>
|
||||
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
||||
</head>
|
||||
<body>
|
||||
@ -30,8 +30,8 @@
|
||||
- using rsync <br />
|
||||
- large-scale updating of several folders at once on expofiles without overwriting other people's work (which means using rsync)<br />
|
||||
- well not "hard" exactly, but complicated with lot of steps that are easy to get wrong and with poor feedback as to whether you have done each step correctly.
|
||||
<li><a href="#bold">Things for the bold</a><br />
|
||||
- using WSL2, Linux virtual machines and Docker containers.
|
||||
<li><a href="#bold">The easier way to do it</a><br />
|
||||
- using WSL: Windows System for Linux
|
||||
</ul>
|
||||
|
||||
<h3 id="well">Things that already work well</h3>
|
||||
@ -88,7 +88,7 @@ it downloads a <em>copy</em> of the contents of essentials.gpx and not a link.
|
||||
|
||||
<h3 id="hard">Things that are really quite involved</h3>
|
||||
<p>The core problem is integrating the PuTTy key management software (pagent.exe) with a terminal window. We need a terminal window to run rsync as none of the packaged software (Filezilla, PuTTy) includes an rsync client.
|
||||
<p>The solution we have now for rsync is to use WSL1 and to create another key, distinct from the PuTTy one, and to upload that key to the expo server. Because this is treating WSL as if it were a different machine requiring its own key quite separate from the Windows key, we expect this to continue to work when WSL2 becomes the default behaviour on Windows10.
|
||||
<p>The solution we have now for rsync is to use WSL and to create another key, distinct from the PuTTy one, and to upload that key to the expo server. Because this is treating WSL as if it were a different machine requiring its own key quite separate from the Windows key. (This works the same way in WSL1 and WSL2)..
|
||||
<p>So on a machine with WSL enabled, create an ordinary cmd window and get into the WSL environment using the wsl command:<br />
|
||||
<span style="font-family:monospace; size=x-small; background-color: lightgray">
|
||||
D:\CUCC-Expo\expoweb\ <font color=red>wsl</font>
|
||||
@ -141,21 +141,22 @@ Now finally you can use all the usual command line tools at yor wsl command line
|
||||
<li>PowerShell terminal window - nope, no rsync.
|
||||
<li>bash window - installed by default when you install <A href="https://gitforwindows.org/">gitforwindows</a>. Unfortunately while this <a href="https://en.wikipedia.org/wiki/MinGW">MINGW32</a> setup includes a command-line git executable it doesn't include rsync.
|
||||
<li>cygwin - a cmd terminal where you have downloaded and installed <a href="https://www.cygwin.com/">Cygwin</a>. Yes, if you have selected the rsync package you will be able to run the rysnc executable, but it won't have access to the cyptographic key so it can't connect to the expo server. Please feel free to work out how to make this work. A more recent, graphical variant is <a href="https://hackaday.com/2017/03/29/swan-better-linux-on-windows/">Swan</a>.
|
||||
<li><img src="wsl.jpg" align="right" hspace="10"><a href="https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux">Windows Subsystem for Linux</a> aka WSL1 available on all Windows10 machines since November 2019.
|
||||
<li><img src="wsl.jpg" align="right" hspace="10"><a href="https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux">Windows Subsystem for Linux</a> aka WSL available on all Windows10 machines since November 2019.
|
||||
<ul>
|
||||
<li>WSL <a href="https://docs.microsoft.com/en-us/windows/wsl/install">Install it like this</a>. This does what we need. This works using a key generated by its own version of ssh-keygen if you follow the instructions above about putting it in the right place.
|
||||
<li>WSL1: <a href="https://hackaday.com/2019/12/23/linux-fu-wsl-tricks-blur-the-windows-linux-line/"> Converting Windows paths to Linux paths and vice-versa</a>.
|
||||
<li>WSL1 is being made obsolete by <a href="https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux#WSL_2">WSL2</a> - the new wonderful system which will solve all our problems, make the tea and carry our gear up to topcamp. Allegedly. WSL2 solves the filenaming problems because it is a full virtual Linux running on a Linux filesystem (ext4) inside Windows. Note that WSL2 has hardware requirements that WSL1 does not have, so an old machine may have to use WSL1.
|
||||
<li>WSL: <a href="https://hackaday.com/2019/12/23/linux-fu-wsl-tricks-blur-the-windows-linux-line/"> Converting Windows paths to Linux paths and vice-versa</a>.
|
||||
<li>In WSL you can choose whether to store the files in the WSL view of NTFS, e.g. /mnt/c/expo/ or in an ext4 filesystem e.g. \\wsl$\Ubuntu-20.04\home\expo . Our experience is with /mnt/c/expo/ .
|
||||
<li>WSL now installs as WSL2 by default, but older machines (mostly laptops) may not have the Hyper-V Virtualization hardware and may have to run WSL1. This is fine: the behaviour is identical so far as an expo laptop is concerned. Even if you have the hardware, you may have to enable it in your BIOS and install the Windows Feature to do it. Instructions <a href="https://www.omgubuntu.co.uk/how-to-install-wsl2-on-windows-10">here</a> and <a href="https://www.windowscentral.com/how-install-wsl2-windows-10">here</a>.
|
||||
|
||||
|
||||
</ul>
|
||||
<li><a href="https://www.theregister.co.uk/2019/12/18/multipass/">Canonical Multipass</a> - a completely different alternative to WSL: more isolation, more understandable behaviour (?)
|
||||
<li>A full <a href="https://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/">virtual Linux machine</a> running using a hypervisor such as <a href="https://www.virtualbox.org/">VirtualBox</a> which has its own virtual Linux filesystem. This setup has the advantage that you don't have to partitition your hard drive but the disadvantage that you can't get at any of the files from Windows itself except via a network protocol \\wsl$. Which may be no hardship.
|
||||
<li>A full <a href="https://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/">virtual Linux machine</a> running using a hypervisor such as <a href="https://www.virtualbox.org/">VirtualBox</a> which has its own virtual Linux filesystem. This setup has the advantage that you don't have to partitition your hard drive but the disadvantage that you may not have easy access to the files from Windows.
|
||||
<li><a href="https://github.com/canonical/multipass">Canonical Multipass</a> - a VM alternative (Ubuntu only).
|
||||
</ul>
|
||||
|
||||
<h4>WSL1 tricks and tips</h4>
|
||||
<h4>WSL tricks and tips</h4>
|
||||
|
||||
<p>WSL1 unfortunately introduces a wonderful new problem of file permissions. Every file on the Windows filesystem NTFS has a set of permissions managed by the filesystem. Every NTFS file that WSL knows about (if mounted with -o metadata) acquires a completely parallel set of file permissions that are fundamentally different things and are never in sync in any sense. <a href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">All sorts of fun</a> results. This is fixed by WSL2 which has <a href="https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes">an entirely separate filesystem</a>, a Virtual Hardware Disk (VHD).
|
||||
<p>WSL unfortunately introduces a wonderful new problem of file permissions. Every file on the Windows filesystem NTFS has a set of permissions managed by the filesystem. Every NTFS file that WSL knows about (if mounted with -o metadata) acquires a completely parallel set of file permissions that are fundamentally different things and are never in sync in any sense. <a href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">All sorts of fun</a> results. The alternative is to store all your data in the \\wsl$\ ext4 filesystem (WSL2 only, not WSL1).
|
||||
|
||||
<p>If you are disturbed by the instructions to produce an entirely different key for WSL to use when your PC already has a perfectly good PuTTy key installed on the server, then you are right. It is inelegant. But it works, the instructions are shorter and there are fewer things that go wrong. If you are terribly offended by that then you can set your PC up to use one key shared between WSL and normal-Windows as described in <a href="https://devblogs.microsoft.com/commandline/sharing-ssh-keys-between-windows-and-wsl-2/">this October 2019 article</a>. (Don't set up a password on the key because then you don't need to install keychain.) But beware, this sort of thing goes out of date quite rapidly.
|
||||
|
||||
@ -165,7 +166,7 @@ Now finally you can use all the usual command line tools at yor wsl command line
|
||||
<li><a href="https://code.visualstudio.com/blogs/2019/09/03/wsl2">deep integration</a> - Don't use gitforwindows, install the linux git client in WSL2
|
||||
|
||||
<li><a href="https://blog.anaisbetts.org/using-github-credentials-in-wsl2/">using-github-credentials-in-wsl2</a> - How to use gitforwindows and WSL to connect to GitHub.
|
||||
<li><a href="https://code.visualstudio.com/blogs/2019/09/03/wsl2">WSL2 & Visual Studio Code</a>
|
||||
<li><a href="https://code.visualstudio.com/blogs/2019/09/03/wsl2">WSL & Visual Studio Code</a>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>CUCC Expedition Handbook: Programmers manual</title>
|
||||
<title>CUCC Expedition Handbook: Your laptop</title>
|
||||
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
||||
</head>
|
||||
<body>
|
||||
|
||||
@ -39,8 +39,7 @@ http://expo.survex.com/repositories/troggle/.git/tree/README.txt
|
||||
|
||||
<h3>WSL on Windows</h3>
|
||||
<p>The standard documentation for Ubuntu or debian below all works, but you should first skim the
|
||||
<a href="../computing/winlaptop.html">Windows expo laptop</a> description of WSL1 and WSL2. The default
|
||||
is that WSL2 will be installed, but all our practical experience so far is with WSL1.
|
||||
<a href="../computing/winlaptop.html">Windows expo laptop</a> configuration too. So far as expo software is concerned, WSL1 and WSL2 behave identically.
|
||||
|
||||
|
||||
<h2 id="python">Installing python</h2>
|
||||
@ -213,7 +212,7 @@ We have at one time made localsettings in /_deploy/ appropriate for
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
WARNING: only the WSL and debian variants are current in October 2021. All the others are so old that
|
||||
WARNING: only the WSL and debian variants are current in December 2021. All the others are so old that
|
||||
they will need serious work to be useable. Copy what you need from WSL and debian variants of
|
||||
localsettings.py
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user