expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-08 14:54:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

Revised all WSL documentaiton

Browse Source
This commit is contained in:
Philip Sargent
2022-12-22 15:10:14 +00:00
parent 01a821002e
commit 1be6e5cbfe
4 changed files with 213 additions and 176 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
handbook/computing/wsllaptop.html
View File

@@ -20,7 +20,8 @@
<br>
<a href="winlaptop.html">Setting up a Windows machine for expo bulk data rearrangements</a>
</p>
On 23 November 2022 a new way of installing and using WSL was announced, see <a href="https://www.theregister.com/2022/11/23/wsl_microsoft_store_default_version/">
Windows Subsystem for Linux now packaged as a Microsoft Store app</a> so some of the documentation on this expo site needs to be revised. WSL2 is now noticeably even slower for NTFS files.
<h3>WSL1 and WSL2</h3>
<p>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 nearly identical so far as an expo laptop is concerned, where you just want to use rsync and scp. An old 2011-era PC has
@@ -33,13 +34,13 @@ the Linux bash terminal window. However, if all you want to use it for is rsync,
<p>On some Windows 10 laptops WSL1 fails to install properly and you have to use WSL2.
<p>When running a full troggle development laptop (see separate <a href="../troggle/troglaptop.html">troggle documentation</a>)
you will want to use <var>python venv</var>. This barfs untidily if you have the code on NTFS, e.g. if mounted on <var>/mnt/c/</var>. You almost
certainly have to move all your code to the internal network share e.g. <var>\\wsl$\Ubuntu-20.04\home\expo\troggle\</var> which
certainly have to move all your code to the internal network share e.g. <var>\\wsl$\Ubuntu\home\expo\troggle\</var> which
is how it looks when you are browing from Windows.
(No, don't try to be cute and keep it on <var>/mnt/c/</var> and just put a soft link in <var>/home/expo/</var>. That doesn't work either.)
This means that the code is actually living on a Linux <var>ext4</var> filesystem hidden away on your disc where you can only see it using the
'network' method <var>\\wsl$\Ubuntu-20.04\home\expo\troggle\</var>. This means that file access is somewhat faster too but you probably won't notice.
'network' method <var>\\wsl$\Ubuntu-20.04\home\expo\troggle\</var>. This means that file access is somewhat faster too but you probably won't notice. You will need to make sure that your backup/archive methods access this filesystem though.
<p>rsync doesn't work with NTFS partitions the way that WSL1 does. See <winlaptop.html>Windows laptop</a> for a bit of detail. [Work in progress.]
<p>rsync doesn't work with NTFS partitions the way that WSL1 does.
<p>Read <a href="https://code.visualstudio.com/blogs/2019/09/03/wsl2">WSL & Visual Studio Code</a> and go back and read the bits about VS Code
running remotely in the &#8251;Windows data maintenance laptop page.
@@ -54,9 +55,89 @@ href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">
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.
<h4>WSL - Creating another ssh key</h4>
<p>If you have PuTTY installed and working, but you now want to use WSL rsync, you need to set up a key again within the WSL environment. 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>
</span>
<br />
which puts you into the WSL environment with a new command prompt, e.g.<br />
<span style="font-family:monospace; size=x-small; background-color: lightgray">
<span style="color: green">
philip@Muscogee</span><span style="color: yellow">:/mnt/c/Users/Philip</span>$
</span>
<p>and now you can setup keys in the same way as you would on a Linux machine using ssh-keygen:
<pre>
<tt>$ <b>ssh-keygen -C "philip@muscogee-wsl"</b>
Generating public/private rsa key pair.
Enter file in which to save the key (/home/philip/.ssh/id_rsa): <b>id_rsa_wsl</b>
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in <em>id_rsa_wsl</em>.
Your public key has been saved in <em>id_rsa_wsl.pub</em>.
The key fingerprint is:
SHA256:ySs0YD5IG2ZD50+riUDHWosNq+WJdqpkDlINXh709r0 philip@muscogee-wsl
The key's randomart image is:
+---[RSA 2048]----+
| . o |
| ..+ . |
| oB+* + |
|.=O%.* + o |
|.+*o= = S . |
|.* o = . . . |
|=++.o . . E |
|B o . |
|oo |
+----[SHA256]-----+
$
</tt>
</pre>
The generated key is in the current directory and you need to move them to ~/.ssh/ as is standard on Linux (which is not at all the same place that puTTY uses to keep keys on Windows).
<p>Now you have to complete the <a href="keyexchange.html">key-pair setup</a> with the new key "id_ras_wsl.pub". But you don't need anyone else's help this time as you can use puTTY to ssh into the server and copy your key to the right place yourself: it is a <a href="keyexchange.html#secondmachine">"Second Machine"</a>.
<p>
Now finally you can use all the usual command line tools at yor wsl command line to communicate with the server with ssh, scp, rsync, such as:
<pre>
<tt>rsync -nazv --delete-after --prune-empty-dirs expo@expo.survex.com:expofiles/ expofiles</tt></pre>
<p>But this only works with WSL1 not WSL2 ! Under WSL1 it doesn't matter if your /expofiles/ is mounted on the Linux filesystem,
typically under /home/expo/expofiles, or whether it it in the NTFS filesystem mount for Linux as,
e.g. /mnt/d/expofiles.
but under WSL2 rsync to /mnt/d/expofiles fails, either with a permissions problem or, if you try sudo rsync.. ,
with a ssh authentication failure (why? Given that we explicitly state that we want to be user expo@ ?). Ghastly anyway. See next section, where the
same problem appears on WSL1.
<p>All of which is really a bit ridiculous if all you want to do is to use rsync on a Windows machine to sort out some photos.
<h3 id="permissions">Permissions, permissions..</h3>
<p>Having happily used WSL1 in this manner for a couple of years, it was a rude awakening to try this with a new laptop with a small
hard-drive, so all the expo code was re-mounted on a plugged-in SD card. The problem of permissions that seemed to be a WSL2 issue reappeared with
a vengence on WSL1.
<p>The recommended WSL procedure (Jan.2021) said to mount the drive using
<a href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">a new 'metadata' setting</a>:
<pre><code>sudo umount /mnt/d
sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000,umask=22,fmask=111</code></pre>
<p>This is probably why there is a difference between automatically-mounted drives (e.g. C:, /mnt/c) and plug-in drives:
"<em>By default, WSL will set the uid and gid to the default user with drives that are auto-mounted during instance start. If you mount manually, you will
have to set these explicitly (the default user that gets created when WSL is first installed has a uid=1000 and gid=1000).</em>"
<p>And of course you will need to arrange that this happens automatically whenever you start WSL, so you will need to set
<a href="https://help.ubuntu.com/community/Fstab"><var>/etc/fstab</var></a>, so ensure that the relevant line says:
<pre><code>D: /mnt/d drvfs metadata,uid=1000,gid=1000,umask=22,fmask=11 0 0</code></pre>
<p>See also <a href="https://docs.microsoft.com/en-us/windows/wsl/file-permissions">File Permissions for WSL</a> (Dec. 2021).
<h3 id="bold">"Are you feeling lucky, punk"</h3>
<p>Links to useful articles to help you work this out for yourself:
<ul>
<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>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>.
<li><a href="https://www.hanselman.com/blog/CoolWSLWindowsSubsystemForLinuxTipsAndTricksYouOrIDidntKnowWerePossible.aspx">Cool WSL tricks</a> - running Windows commands from WSL environment and running Linux commands from Windows terminal.
<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
@@ -74,11 +155,10 @@ in the \\wsl$\ ext4 filesystem (WSL2 only, not WSL1).
<tt><a href="https://www.scivision.dev/mount-usb-drives-windows-subsystem-for-linux/">mount-usb-drives-windows-subsystem-for-linux</a></tt>
<tt><a href="https://man.openbsd.org/ssh">ssh command line</a></tt>
<h3>Installing and Configuring the rest of the software you need on Windows</h3>
<p>Now return to &#8251;<a href="winlaptop.html">the Windows data maintenance laptop</a> page to configure all the rest of the software you need.&#8258;
<hr />
Go back to: <a href="basiclaptop.html">Basic laptop</a><br />
Go back to: <a href="surveylaptop.html">Survey laptop</a><br />
Go back to: &#8251;<a href="basiclaptop.html">Basic laptop</a><br />
Go back to: &#8258;<a href="surveylaptop.html">Survey laptop</a><br />
<hr /></body>
</html>