How to Use Linux Terminal in Windows 10
You can now access most of the Linux command-line utilities and applications on top of Windows 10 OS using Windows Subsystem for Linux (WSL).
Raj Kumar
Although Windows is the most widely used and most popular operating system for desktops and laptops, it is not as secure and open-sourced as Linux OS. That’s is why a lot of software developers and professionals prefer Linux OS.
Microsoft has started a partnership with Canonical, creators of Ubuntu Linux. This paved way for Linux users to use Linux on Windows. Yes, you can run Linux on top of Windows 10 without the need for a dual boot, or using VMWare/VirtualBox, or installing it as your main Operating System.
You can access various Linux commands and software from the Linux terminal in Windows 10. In this article, we’ll give you step-by-step instructions on how to install and run the Linux terminal on Windows 10 OS.
Enable Windows Subsystem for Linux (WSL) and Install Ubuntu in Windows 10
If you intend to run a Linux terminal on Windows 10, you must first turn on the ‘Windows Subsystem for Linux’ feature. Then you can download and install your choice of Linux distribution.
The Windows Subsystem for Linux (WSL) is a feature that creates a GNU/Linux environment that allows you to run core Linux command-line tools and services directly on Windows, alongside your desktop and modern store apps.
By enabling Windows 10’s Linux subsystem, you can install and run various Linux distributions (distros) such as Ubuntu, OpenSuse, SUSE Linux, Fedora, etc.
First, Check your Windows Version
But before we get into how to enable Windows Subsystem for Linux (WSL) and install Linux, you need to check if you are running a compatible version of Windows 10. WSL is only supported on both Windows 10 64-bit (from version 1607) and Windows Server 2019.
To check your Windows version and build, go to ‘Settings’ from Windows Start menu.
Next, click ‘System’ setting.
Then, scroll down and select ‘About’ option at the bottom of the left pane to view About section.
On the About page, under Windows specifications, you can see the ‘Version’ and ‘OS build’ of your Windows 10.
Enable Windows Subsystem for Linux
There are two different types of WSL versions: WSL 1 and WSL 2. While they both provide smooth and continuous integration of Linux within Windows, WSL 2 is the latest and fastest version with supports full Linux kernel and system call compatibility. WSL 1 runs a translation layer which bridges the gap between Linux kernal and Windows.
- To run WSL 2, you must be running Windows 10 x64 bit systems: Version 1903 or higher, with Build 18362 or higher.
- To run WSL 1, you will need Windows 10 x64 bit systems: Version 1709 or higher, with Build 16215 or higher.
It doesn’t matter which version of WSL you want to run you must enable it first to use it. To do this, start type typing ‘Turn Windows features on and off’ into the Start Menu search field.
Select ‘Turn Windows features on and off’ control panel from the search result.
Then, scroll down to ‘Windows Subsystem for Linux’, tick the box in front of it, and click the ‘OK’ button.
Once the changes are applied, click ‘Restart now’ to restart your computer
If you want to only install WSL 1, you can now restart your computer and install your Linux distro.
Enable WSL 1 via PowerShell
You can also enable WSL via the ‘PowerShell’ command-line tool. This does the same job as the Windows Features control panel. For that, open ‘PowerShell’ as an Administrator and run the below command.
Enable WSL 2
We recommend you upgrade your WSL to version 2 for faster performance speed, and to run a real Linux kernel directly on Windows 10. All you need to do is enable the ‘Virtual Machine Platform’ feature in addition to the ‘Windows Subsystem for Linux’ feature on the Windows features control panel (see below).
Wait for the changes to be applied, then restart your computer.
Enable WSL 2 via PowerShell
This first step to enable WSL 2 is enabling the Virtual Machine Platform feature component on Windows. You can also enable WSL 2 via the ‘PowerShell’ command-line tool. To do that, open ‘PowerShell’ as an Administrator and run the following additional command with the WSL 1 command.
Set WSL 2 as the Default Version
Before setting up WSL 2 as your default version for all Linux distributions, download the WSL Linux kernel package update for x64 systems.
Run the .msi installer downloaded and install it. It will take only seconds.
To set WSL 2 as your default version when installing a new Linux distribution, open PowerShell and run this command the following command:
Then restart your system to switch the feature from WSL 1 to WSL 2.
Install your Linux distribution of choice
WSL is enabled, now we will install a Linux distribution. First, search for ‘Microsoft Store’ in the Start Menu search field. Then, open it from the search result.
You’ll see a list of every Linux distributions currently available in the Windows Store which are supported by WSL.
- Ubuntu 16.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 20.04 LTS
- openSUSE Leap 15.1
- SUSE Linux Enterprise Server 12 SP5
- SUSE Linux Enterprise Server 15 SP1
- Kali Linux
- Debian GNU/Linux
- Fedora Remix for WSL
- Pengwin
- Pengwin Enterprise
- Alpine WSL
All of theses distributions are available for free. For our tutorial, we’ll select ‘Ubuntu’.
From the Ubuntu distribution’s page, Click the ‘Get’ button.
Now, Ubuntu distribution will be downloaded and installed automatically on your computer.
Once the installation finished, click the ‘Launch’ button to launch the terminal. You can also launch the app from the Windows Start Menu.
A new Ubuntu terminal window will appear. The first launch will take a few minutes to register the Ubuntu environment with WSL. Once that’s finished, the terminal will prompt you to create a ‘new Unix username’ and ‘new password’. Enter the new username and password and complete the setup.
Once, the set up finished, it will take you to the bash command line. It’s better to update the software right away. In Ubuntu, you can search for, download, and install software updates, all from the apt command.
Enter the below command to update the software. And you’ll be prompted for the password, enter the newly created password to run the command as an administrator.
This ‘update’ command will update the Ubuntu repositories.
Ubuntu will download a series of package lists.
But they are not upgraded yet. To upgrade all available packages, enter the following command:
Enter ‘Y’ at the prompt to continue the installation.
The ‘dist-upgrade’ command upgrade packages to their latest versions.
Upgrade WSL1 to WSL 2 for Ubuntu
If you wish to upgrade the existing WSL 1 version to WSL 2 for a specific distribution. Then, run the below command in PowerShell.
Replace ‘<Distro>’ argument with the name of whichever distribution (Ubuntu in our case) your WSL 1 install runs.
Now, you can access Linux commands and software on a Windows 10 system using this Ubuntu Environment.
bash shell on Windows 10
You now have a full command-line ‘bash’ shell on your system based on the Linux distribution. You can access all the Linux commands and applications via that bash shell.
To run bash shell, type ‘bash’ into the Start Menu search field and click to open the bash command-line tool.
Настройка окружения в CLI. WSL / Windows Terminal
Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже senior yaml developer`ом, пользуется command line interface. Далеко не все задумываются об улучшении рабочего окружения в CLI и повышении продуктивности работы в терминале. Мне хотелось бы поделиться своим опытом настройки окружения для работы с Linux из Windows.
Из статьи вы узнаете, какими средствами и каким терминалом актуально пользоваться в настоящее время для запуска Linux приложений в Windows 10. Речь пойдёт о WSL 2 и Windows Terminal, набирающим всё большую популярность у пользователей, которым для работы нужен Linux. Так как большинство use-case`ов у меня связаны с удалённым подключением через SSH, большая часть информации будет релевантно для случаев удалённых подключений, со всеми особенностями, связанными с этим (пробросом ssh ключей через ssh agent, пробросом X-сервера, управлением подключениями etс).
Внимание! Под катом много картинок и ужатого, но местами объёмного, gif`а, рекомендуется открывать статью при наличии соответствующего доступа к интернету. Заходите под кат, если вам актуален запуск Linux утилит под Windows, оптимизация работы в окружении CLI, или вы просто любите технические тексты и цветные терминалы. Текст я постарался скрасить скринкастами и скриншотами терминала, чтобы было не скучно.
Введение
Как на домашнем, так и на рабочем ноутбуке, единственная ОС сейчас у меня Windows 10, и в этом году я окончательно перешёл на использование только WSL вместо VM / dualboot / Cygwin / MinGW. Теперь мой терминал по умолчанию — это локальный шелл WSL, где я могу запускать практически любые задачи, как в нативном Linux. Кроме этого, в домашней сети работает мини-сервер Intel NUC, на котором развёрнут Proxmox с LXC контейнерами и KVM, в котором крутится Docker. На все VM хожу по SSH, с ключами из директории Windows. Очень много времени в профессиональной деятельности проходит в CLI, с домашним сервером и сетью тоже самое. Поэтому всегда возникает желание разобраться с инструментами для более комфортной работы в терминале, а в Windows всегда с этим были проблемы. Но сейчас всё меняется.
Эта и последующие статьи больше ориентированы на энтузиастов, которые ищут свежие решения и желают прокачать свой шелл. Но и новичкам должно быть что-то интересно, хотя статья получилась с достаточно глубоким погружением в тему и предполагает, что у читателя есть какие-то фундаментальные знания в Linux. Вся информация собрана на основе личного опыта использования WSL, терминала, а так же бесконечного листания Stack Overflow и Github issues в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.
Windows Subsystem for Linux (WSL) 2
В интернете и на Хабре есть несколько нормальных статей про WSL (раз статья про установку/настройку WSL с X-сервером, два заметка про WSL 2, три статья про Python разработку в VSCode с WSL), описывающих установку и настройку системы. Однако не все действия по установке уже актуальны, так же как и ограничений с подводными камнями становится меньше. Я не буду подробно останавливаться на установке, инструкция по установке актуальной (второй) версии WSL есть на сайте Microsoft, также в интернете можно найти краткие туториалы.
Сейчас WSL ещё находится в стадии активной разработки и недавно (июнь 2019) вышла новая версия WSL 2, которая на данный момент доступна только для свежих версий Windows участникам Windows Insiders. При возможности советую сразу проапгрейдить WSL до версии 2, так как в ней улучшили работу системных вызовов, работу с сетью, ФС, и в целом она построена на другой архитектуре и по некоторым данным даёт 20-кратный прирост скорости по сравнению с первой версией.
Посмотреть версию Windows 10 и OS build можно в Start -> Settings ->System -> About, для установки WSL 2 требуется версия Windows 1903 и, как минимум, версия билда 18917. Если вы не участник Windows Insider Program, вероятнее всего, обновления не прилетят до выхода стабильного релиза. Так что если хочется обновиться до последней сборки, можно включить ранний доступ (Fast) в Start -> Settings -> Update & Security -> Windows Insider Program, обновиться и отключить дальнейшие обновления. Стоит учитывать, что устанавливаться будут ещё не оттестированные массово обновления, что может сказаться на стабильности.
Стоит иметь ввиду, что до билда версии 18995 WSL имеет баг при работе с файлами на примонтированных дисках Windows, выражающийся в Input/output error, помогает только перезагрузка WSL (wsl —shutdown в PowerShell). В целом сейчас пофиксено много багов, которые до сих пор присутствуют в WSL версии 1 (который ставится по дефолту) и не-preview дистрибутивах Windows. Если у вас обновления ОС регулируются корпоративными политиками, скорее всего самые свежие обновления прилетать не будут и нужно иметь это ввиду. На одном из ноутбуков у меня стоит билд 18956 и обновлений нет, не смотря на то, что выбрана опция Fast в настройках Insider Program. На другом ноутбуке была установлена чистая система несколько месяцев назад и обновления периодически прилетают и устанавливаются.
Установка WSL 2
Для работы WSL требуется включить Hyper-V, потому что дистрибутивы Linux запускаются в легковесных VM с помощью виртуализации Hyper-V.
Далее я приведу краткую инструкция установки из CLI PowerShell дистрибутива WSL на примере Kali Linux). При предпочтении Ubuntu или другого дистрибутива Linux из доступных, заменить ссылку и названия на соответствующие.
Проверить версию билда Windows:
Get-ItemProperty -Path «HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion» | Select CurrentBuild
Активировать компоненты VirtualMachinePlatform и Microsoft-Windows-Subsystem-Linux:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Перезагрузка.
Дальше либо установить дистрибутив из Microsoft Store (https://aka.ms/wslstore), либо дальше выполнить в PowerShell:
curl.exe -L -o kali.appx https://aka.ms/wsl-kali-linux-new
Add-AppxPackage .\kali.appx
rm .\kali.appx
Запустить консоль WSL (дистрибутив должен был появиться в меню Start, поиск по названию дистра), дождаться приглашения установить нового пользователя, закрыть консоль.
Теперь дистрибутив должен появится в списке, если выполнить в PowerShell:
При необходимости преобразовать дистрибутив в формат WSL версии 2:
wsl —set-version kali-linux 2
wsl —set-default-version 2
Сделать root пользователем по умолчанию (опционально):
kali config —default-user root
Если вы получили ошибку «A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.», значит у вас стоит билд, в котором проявляется очередной (уже исправленный в последних релизах) баг. Как обычно, есть воркэраунд, либо использовать дистрибутив Ubuntu, с ним у меня не было проблем на той же не последней версии билда.
При необходимости, переместить виртуальный диск WSL на другой раздел (отличный от C:) можно по инструкции. Делать это лучше сразу, так как не всё может пройти гладко.
Disclaimer про безопасность. В WSL и на других Linux-серверах в домашней сети я не запускаю никаких критически важных систем, и других пользователей (кроме меня), в сети нет, поэтому я почти везде хожу под root, с ssh аутентификацией через ключи. Я знаю, что это не лучшая практика, однако речь про личное dev-окружение и я не вижу смысла создавать не-root пользователя. Вопросы безопасности в этой статье рассматриваться не будут, об этом я собираюсь когда-нибудь написать отдельно (про то, как в домашней сети без боли организовать взаимодействие сервисов через TLS с централизованным обновлением сертификатов; о синхронизации
/.ssh/config между серверами, пробросе портов и ключей и т.д.).
Конфигурация WSL
Начиная с билда 17093, основной файл конфигурации WSL находится на ФС дистрибутива по адресу /etc/wsl.conf, в нём описываются настройки, которые будут применять при каждой загрузке дистрибутива:
- Automount — автомонтирование дисков Windows
- Network — генерировать файлы resolv.conf, hosts
- Interop — запуск процессов Windows и добавление Windows $PATH в Linux $PATH
[automount]
enabled = true
root = /mnt
options = «metadata,umask=22,fmask=11»
mountFsTab = true
[network]
generateHosts = true
generateResolvConf = true
[interop]
enabled = true
appendWindowsPath = true
Некоторые настойки применяются со значением по умолчанию и с пустым /etc/wsl.conf , но для корректной работы с файлами нужно прописать как минимум параметр options, иначе файлы Windows будут с правами 777 и это нельзя будет изменить из Linux.
Сделать ребут дистрибутива можно из PowerShell командой:
wsl -t kali-linux
После этого можно обновить пакеты и заняться настройкой ОС под себя. Я пока не буду касаться настроек шелла и окружения в Linux, оставлю это для следующей статьи.
apt -y update && apt -y upgrade
Файловая система WSL 2 и производительность
Файлы внутри WSL версии 2 хранятся на виртуальном диске VHDX, в качестве файловой системы используется ext4. Получить доступ к rootfs WSL можно через путь такого формата:
Либо, можно набрать «explorer.exe .» в CLI и откроется обозреватель Windows в текущей директории.
В WSL версии 1 не использовался VHDX и был простой доступ к директории, в которой находились файлы Linux, и Microsoft строго не рекомендовали изменять Linux файлы из Windows. В новой версии WSL доступ к ФС на виртуальном диске обеспечивается с помощью файлового сервера Plan 9 Filesystem Protocol.
В предыдущих версиях WSL были проблемы с производительностью файловой системой, потому что системные вызовы эмулировались через API Windows, доступ к файлам был медленный и нестабильный. В концу 2019 года в WSL 2 архитектура поменялась и используется нативное ядро Linux. Судя по слайду из youtube-презентации The new Windows subsystem for Linux architecture: a deep dive, производительность дисковых операций выросла в 2-5 раз.
Максимальный объём диска ограничен 256GB, при превышении этого объёма необходимо будет делать ресайз, инструкция есть в документации.
Изначально, у WSL были проблемы с тем, чтобы высвобождать ресурсы после использования RAM. В билде 19013 эту проблему решили. Если запускать ресурсоёмкие задачи (например, сборка rust приложения) можно заметить, что процесс Vmmem будет в топе Диспетчера задач, однако потребление памяти значительно снизилось в последних версиях WSL.
Имя хоста (hostname) в Linux берётся из имени PC в Windows, независимо от того, что прописать в /etc/hostname или командой hostnamectl set-hostname.
В отличии от первой версии, в WSL 2 сеть работает через виртуальный Hyper-V свитч:
❯❯ ipconfig.exe | grep IPv4
IPv4 Address. . . . . . . . . . . : 192.168.88.200
IPv4 Address. . . . . . . . . . . : 172.31.160.1
IPv4 Address. . . . . . . . . . . : 172.27.144.1
❯❯ ip -br -4 ad show dev eth0
eth0 UP 172.27.150.196/20
❯❯ ip ro list default
default via 172.27.144.1 dev eth0
В данном случае сеть 172.27.144.0/20 используется под WSL, её первый адрес (172.27.144.1) — это хостовая система Windows.
Из Linux обращаться по сети к хостовым сервисам (запущенным в Windows) можно, например, так:
❯❯ nmap -p 3389 $(cat /etc/resolv.conf | grep nameserver | awk ‘
IP-адрес Windows тут берётся из /etc/resolv.conf, где он генерируется автоматически согласно настройкам wsl.conf.
Наоборот, если нужен коннект к Linux сокету из приложения Windows, необходимо обращаться к IP-адресу WSL. При этом есть нюанс — в Linux сервис необходимо запускать не на localhost (127.0.0.1), а на адресе 0.0.0.0. Например, чтобы быстро поднять SOCKS5 proxy до своего VPS, нужно запустить SSH с параметром dynamic port forwarding:
❯❯ ssh -D 0.0.0.0:2299 -N -f proxy.example.com
После этого в приложении Windows, например Chrome, в качестве адреса SOCKS5 прописать не localhost, а адрес WSL, в данном случае 172.27.150.196. Кстати, таким нехитрым способом туннелирования трафика через VPS в Хроме появляется возможность использовать доступ к сайтам через IPv6.
IP-адрес в Linux после перезагрузки будет каждый раз меняться, так что в сценариях, когда нужно иметь постоянно работающий и автоматически запускающийся port forwarding, нужно искать воркэраунд. Есть много способов решения этой проблемы, разной степени костыльности, почитать подробнее можно в этом issue на github. Я воспользовался утилитой go-wsl2-host, которая реализует Windows Service, добавляющий автоматически IP-адрес WSL в файл hosts Windows, таким образом на хостовой системе можно прописать хостнейм типа ubuntu.wsl и по нему обращаться к Linux. Однако всё это костыли и работает не очень хорошо, остаётся ждать, когда Microsoft пофиксят эти проблемы.
UPD. Пока я писал эту статью, обнаружил, что вышли обновления (билд 18945), в которых появилась возможность достучаться через localhost до сервисов, запущенных в WSL. Правда, оказалось, что есть баг, из-за которого всё равно это не работало у всех, фикс в августовском билде 18970. Так как не всем прилетают обновления, даже если быть участником программы Windows Insiders, я не стал корректировать информацию, может кому-то это поможет настроить сетевое взаимодействие.
OpenSSH в Windows и автозапуск сервисов
Windows 10, как и Windows Server 2019, комплектуется форком OpenSSH, включающем все знакомые утилиты ssh-keygen, ssh-add, scp и другие, а том числе ssh-agent и сам сервер sshd. И клиент, и сервер поставить можно через Apps > Apps and Features > Manage Optional Features, но версия клиента ssh будет не последняя. Я столкнулся с багом, не позволяющим коннектиться к хосту через jump-хост с опцией ProxyJump и оказалось, что эту проблему пофиксили, но нужно вручную обновить SSH клиента. Установить актуальную версию Win32 OpenSSH можно, скачав zip из раздела Releases на гитхабе, и распаковав, к примеру, в C:\Program Files\OpenSSH. Сторонним софтом ssh.exe (например, при использовании Remote Development режима в VSCode) вызывается из $PATH (%SYSTEMROOT%\System32\OpenSSH\), нужно изменить переменную среды. Environment variables изменяются через GUI в Start > Edit the system environment variables (Пуск > Изменение системных переменных среды), там необходимо новый путь поставить выше старой версии.
Так как в WSL не работает Systemd, есть проблема с автозапуском сервисов со стартом системы. Есть несколько способов настроить автостарт ssh сервера в WSL, самый простой — это создать задачу в Task Scheduler, где прописать команду старта сервера. В интернете можно найти разные инструкцииавтозапуска через скрипты vbs, ps1 или bat. Проблема почти всех способов в том, что триггером является запуск основной ОС Windows, то есть, если произойдёт сбой WSL и придётся перезапускать систему (wsl -t), то Linux запустится без запущенного сервиса. При старте Windows дистрибутив WSL запускается только в момент первого обращения к нему.
Я использую SSH-сервер на ноутбуке внутри WSL для того, чтобы удалённо можно было ходить с машины на машину. И, благодаря тому, что я использую техники ssh port forwarding и продуманно настроенный централизованный конфиг SSH клиентов, я могу прозрачно ходить по всем своим серверам, вводя хостнейм вместо адресов. То есть, если даже подключить какой-то из ноутбуков к мобильной сети, autossh демон подключится к jump-хосту и я всё равно смогу зайти на компьютер, никакой NAT не будет помехой. Поэтому мне важно, чтобы sshd всё время был в состоянии up.
Единственный рабочий способ попасть по SSH в WSL — это пробросить порт SSH. Это можно сделать с самого WSL с помощью RemoteForward, либо с другого сервера в домашней сети. Мало лишь кому это надо, да и это уже advanced level, так что просто приведу рабочую команду:
❯❯ ssh -R ‘*:2363:*:22’ -N -f mt.example.com
Теперь при коннекте на адрес mt.example.com:2263 можно попасть прямо в WSL.
Если планируется поднимать SSH-сервер в WSL, нужно не забыть сконфигурировать необходимые параметры запуска сервера в /etc/ssh/sshd_config. Чтобы не было конфликта при бинде сервиса на порт 22, OpenSSH сервер в Windows следует отключить или вовсе удалить, если он установлен (Apps > Apps and Features > Manage Optional Features).
X forwarding
Приятным моментом оказалось, что в Windows 10 есть утилита clip.exe, позволяющая перенаправлять stdout напрямую в буфер обмена Windows. Это удобно использовать в таких программах как tmux, а благодаря пробросу X-сервера текст можно копировать и с удалённых хостов. Чтобы всё работало, необходимо иметь всегда запущенный X-сервер в Windows и правильно прописанную переменную $DISPLAY.
Немного скучной теории. На *nix системах с запущенным X имеются разные типы буферов обмена (primary, secondary, clipboard), в контексте этой статьи это не так важно, но важно для общего понимания механизма работы. Для работы с буферами обмена на Linux есть две утилиты (xclip и xsel). Обе утилиты имеют схожий функционал, в xsel его немного больше, но базовый функционал, необходимый для проброса содержимого буфера, одинаков. В X приложениях выделенный текст попадает в primary selection, вставляется при этом средней кнопкой мышки, в xclip и xsel используется по умолчанию primary selection.
Например, чтобы скопировать в буфер по умолчанию содержимое переменной, нужно передать stdout на stdin утилиты xclip, без дополнительных параметров:
❯❯ echo -n $DISPLAY | xclip
А чтобы вывести содержимое буфера по умолчанию, запустить xclip с ключом -o:
❯❯ xclip -o
172.20.160.1:0
Чтобы буфер обмена перенаправлялся через X-сервер и графические приложения запускались на локальном сервере X, необходимо в переменную $DISPLAY прописать IP-адрес, являющийся default gateway для WSL. Пока что ничего лучше того, чтобы брать его из resolv.conf (который генерируется автоматически Windows), не придумали. Поэтому, самый простой способ — прописать экспорт переменной $DISPLAY в профайле шелла (например,
❯❯ echo «export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk ‘
В качестве X-сервера я выбрал бесплатный VcXsrv, он умеет работать с буфером, имеет разные режимы отображения окон и запускается из командной строки с прописанными опциями. По ссылке на gist можно посмотреть все опции.
Создать задачу автозапуска X-сервера можно в Task Scheduler примерно таким образом:
Triggers: At startup
Actions: Start a program
____Program: «%ProgramFiles%\VcXsrv\vcxsrv.exe»
____Arguments: -wgl -dpi auto -ac -multiwindow
SSH ключи
Чтобы программы из Windows могли использовать SSH ключи (например, редактор при работе с удалённым репозиторием GitHub), и в то же время не было второй копии ключей в WSL, лучше всего сгенерировать ключи в Windows %HOMEPATH%/.ssh и создать симлинки в домашней директории WSL.
ssh-keygen -f /mnt/c/Users/$
ln -sf /mnt/c/Users/$
ln -sf /mnt/c/Users/$
/.ssh/config можно прописать параметр IdentityFile, указав путь к ключам на диске Windows:
Host *
IdentityFile /mnt/c/Users/$
Если ключи были скопированы откуда-то и права на файлы не выставлены правильно, поправить permissions:
chmod 600 /mnt/c/Users/$
chmod 644 /mnt/c/Users/$
chmod 700 /mnt/c/Users/$
Таким образом, при дальнейшей настройке доступа по ключам SSH пользователь идентифицируется однозначно одним набором ключей в одном месте, как при использовании приложений Windows, так и Linux. Теперь можно добавить публичный ключ на сервера/сервисы, куда необходимо будет ходить с этого компьютера. Если в домашней сети есть другие устройства, на которые требуется доступ по SSH, то правильно будет скопировать свой публичный ключ на эти сервера (ssh-copy-id), но не надо копировать ключи одного сервера на другой. Так как при работе через SSH можно (и нужно) использовать ssh-agent, то при коннекте с одного сервера на другой, агент заботится, чтобы авторизация происходила по проброшенному ключу. Чтобы всё работало правильно и ожидаемо, нужно позаботиться о файле
/.ssh/config, в котором надо прописать все необходимые опции.
Host *
TCPKeepAlive yes
ServerAliveInterval 30
ServerAliveCountMax 3
ForwardAgent yes
AddKeysToAgent yes
ForwardX11 yes
ForwardX11Trusted yes
Какой терминал выбрать для работы в Linux на Windows
Сначала хочется сделать небольшое ревью существующих терминальных оболочек под Windows, умеющих запускать WSL. Среди пользователей популярен функциональный комбайн MobaXterm, который умеет создавать различные сессии, в том числе графические (WSL, bash/zsh, Mosh, RDP, VNC и т.п.), позволяет делать макросы и запускать скрипты, имеет много настроек и функциональных возможностей, ssh agent, автозапускаемый ssh port forwarding, и даже имеет встроенный сервер ftp/tftp/http, но продукт closed source и, к тому же, платный. Hyper — другой, более современный эмулятор терминала, позволяющий запускать WSL shell, терминал построен на HTML/JS/CSS и расширяется с помощью плагинов в виде node.js модулей (awesome list). Есть и другие терминалы, позволяющие запускать WSL с разной степенью костыльности (ConEmu, его форк Cmder, WSLtty и др.), но их я оставлю без внимания.
Дальше в этой статье речь пойдёт про Windows Terminal, на который я перешёл с недавних пор, и пока что испытываю только положительные эмоции. Terminal пока что ещё в статусе бета, но работает достаточно стабильно. Из фич на данный момент реализован мультитаб, разделение панелей (splitting), настраиваемые профили терминальных подключений, цветовые схемы, ну и больше нечего перечислить. Но этого функционала вполне хватает, мне даже нравится, что софт не перегружен лишним — как будто бы разработчики придерживаются принципа KISS.
Terminal эволюционировал из проекта Windows Console (ConPTY), научившись поддерживать ANSI/VT последовательности, 24-bit RGB true color и UTF-8. По ссылкам (начало, продолжение) на Хабре замечательный перевод серии постов блога Windows Command-Line: Inside the Windows Console, где рассказывается про историю создания терминалов, связанные с этим стандарты передачи управляющих последовательностей, кодовые страницы, юникод, появление эмуляторов терминалов и в дальнейшем уже эволюцию командной строки Windows. Техногикам это может быть интересно. Инженерный состав, работающий над этим opensource проектом, ведёт девблог Windows Command Line, который более, чем полностью посвящён WSL и Windows Terminal. Никогда бы до этого момента не поверил бы, что буду с интересом наблюдать за развитием продуктов MS, но что они делают в рамках развития WSL, Terminal и VSCode, действительно заслуживает уважения. Как начиналось развитие WSL, описано в Microsoft Open Source Stories (перевод есть на Хабре). Кстати, Microsoft с 2016 года является платиновым участником Linux Foundation .
Установка и настройка Windows Terminal
Установить Windows Terminal можно из Windows Store, либо скачав бинарник из раздела Releases на гитхабе проекта, там же и вся актуальная информация, инструкции и FAQ. Терминал требует, как минимум, версию Windows 1903 и билд 18362. Предпочтительнее устанавливать через Windows Store, так как обновлять в этом случае проще, прямо из стора. Обновления выходят регулярно, на гитхабе выложен план развития (roadmap) первой версии терминала. На данный момент все фичи версии 1 уже реализованы (по плану до конца 2019 года реализовать все улучшения), дальше несколько месяцев работы над устранениями багов и в апреле 2020 планируется официальный релиз Terminal v1.0. Приятно, что MS теперь есть на гитхабе, их софт научился показывать логи, внятные ошибки и любые проблемы легко гуглятся.
Настроек в терминале пока не много, но их хватает для комфортной работы, продукт активно развивается, есть на github, где пользователи могут создать feature request или bug report. Разработчики принимают участие в обсуждении проблем с пользователями, зачастую предлагая воркэраунды, когда обнаруживается баг.
Конфиг хранится в json формате, после сохранения применяется сразу же. Это удобно хотя бы потому, что можно применять хорошие практики управлением конфигурациями рабочего окружения — все линуксовые конфиги я храню в git репозитории, на Windows из рабочего инструмента использую только VSCode, который умеет синхронизировать конфиг через github gist, а локальный конфиг воркспейса сохранять отдельно в dotfiles. Вот и Terminal движется в ту же сторону, используя те же хоткеи и формат конфига, как VSCode. Править конфиг, кстати, удобно через VSCode, особенно если уже пользуетесь этим отличным редактором от MS. Файл конфигурации терминала уже содержит многие дефолтные настройки, а правильный редактор позволяет посмотреть все опции с описанием key и вариантами value из schema (особенно это удобно, когда у проекта ещё нет полноценной документации). Плюсом доступны все фишечки IDE в виде автодополнения, intellisense, проверкой синтаксиса, форматированием и т.д.
Документация для разработчиков доступна тут, а здесь пока что небольшая страничка документации для пользователей. Отдельная страница посвящена настройкам, которые прописываются в json файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:
- Global (профиль по умолчанию, изначальный размер окна терминала, тема и т.д.)
- Key Bindings (настройки сочетаний клавиш)
- Profiles (настройки, специфичные для каждого терминала)
- Schemes (цветовые схемы)
Шрифты
Чтобы терминал по-настоящему радовал пользователя, обязательно надо инсталлировать шрифты с поддержкой спец символов и лигатур. Выбрать можно из:
Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.
Посмотреть название шрифта (настройка терминала fontFace) можно при установке или после в приложении Character Map (Таблица Символов). Кроме этого, в Start -> Settings -> Personalization -> Fonts можно посмотреть, как шрифт рендерится в разных режимах, и заодно проверить, как рисуются лигатуры.
Заключение
Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2, но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть выделенный сервер.
Я надеюсь, что никто не пожалел, что дочитал статью и вынес для себя какие-то новые знания. Если кому-то есть, что добавить, давайте делиться мыслями в комментариях. Если есть какие-то замечания по тексту, пишите в ЛС, хочется поддерживать этот гайд в актуальности.
Ubuntu on WSL
Install a complete Ubuntu terminal environment in minutes on Windows with Windows Subsystem for Linux (WSL).
Access the Linux terminal on Windows, develop cross-platform applications, and manage IT infrastructure without leaving Windows.
Deploying WSL at your company?
We help companies achieve a seamless integration with their WSL deployments. Contact us to learn more about how we support enterprises on the Windows Subsystem for Linux.
What you never thought was possible on Windows
Editors
Run your choice of Linux text editors, including vim, emacs, and nano
Servers
Spin up Node.js, install your dependencies with npm, and start testing your web app
Development
Install compilers and libraries from the Ubuntu repository, maintained by Canonical
Systemd
Develop and run service applications and use snap packages to run popular workflow tools
Containers
Work with LXD and Docker containers on Windows
Scripting
Automate Linux and Windows tasks with advanced bash scripting
Network hardening
Leverage Linux security tools to test and harden your network
Crunch big numbers with tools for R and Python
Kubernetes
Build, test, and deploy Kubernetes clusters on Windows
Why Ubuntu WSL?
The Best of Ubuntu
WSL gives you access to a full Ubuntu terminal environment. Develop cross-platform applications and manage IT infrastructure without leaving Windows.
Data Science
NVIDIA Data Science Stack lets you maximise the performance of your Data Science and Machine Learning projects on top of native Windows NVIDIA drivers.
Web Development
Develop in WSL using native Windows IDEs including VS Code and IntelliJ. Use containers to improve your workflow and benefit from full NodeJS and Ruby support.
Develop Graphical Applications
Develop and preview web and graphical applications on Linux using WSLg. Create multiplatform graphical applications using popular open source development frameworks like Flutter or React Native.
Cross Platform Development
Create and test your CI/CD pipelines locally on an Ubuntu WSL instance. When ready, publish to a cloud production environment running Ubuntu VMs.
Security
Achieve the same first-class, out-of-the-box, compliant security that is synonymous with Ubuntu. With long-term support releases, you’ll have five years of security patches and updates.
Manage IT Infrastructure
From the same workstation, manage mixed Linux and Windows infrastructure both on-prem and across public clouds.
Enterprise support
Ubuntu is certified on WSL through close collaboration with Microsoft. Enterprise support is provided for Ubuntu from Azure to Windows workstations creating a seamless operating environment.
Introduction
I’ve been using a Mac as my daily driver for work for the last few years. While there’s nothing particularly special about MacOS that I love (in fact there’s quite a bit I don’t like), it’s honestly been the terminal and the underlying Unix based operating system that keep me glued to it. With Homebrew, command line tools just work. Python and Node dev environments just work. And using iTerm2 with oh-my-zsh is the best terminal experience I’ve ever had. I often feel like I just pay the premium for Mac hardware to have a reliable and easy to configure *Nix operating system.
But lately I’ve really been wanting to get off the Mac ecosystem and start using Windows 10 on my X1 Carbon as my daily machine. With the Windows Subystem for Linux (WSL) it’s now possible to have a “native” Ubuntu command line on my Windows 10 machine to use for my CLI nerdiness. But the only thing holding me back was the lack of a nice terminal emulator (admittedly, I’m shallow and like pretty things).
This just wasn’t going to cut it:
After much tinkering, I’ve ended up with what I feel is the most comfortable terminal experience I can get on Windows. It supports tabs, splits, mouse mode and has a pretty color scheme to boot:
In this post, I’m going to quickly explain how I got it running and configured, and some of the other options I tried.
First Attempts
I really just wanted the equivalent of iTerm2 in Windows. I wanted to utilize WSL (not Cygwin) and at a minimum needed:
- Pretty colors and fonts
- Tabs (non-negotiable)
- Working mouse support for scrolling and Vim/Tmux
- Tmux support and auto resizing
- Sane copy/paste
I think I tried every major Windows terminal app I could find. Each had their own drawbacks and I eventually gave up. Some of the ones I tried:
The closest I got, and one that I used for a while was Cmder:
Unfortunately, when I started using Tmux it became a problem. I could never get mouse mode to work (scrolling or selecting panes), and resizing windows was problematic. I’d end up with screens like this a lot:
Not gonna cut it for me (though I still do use Cmder regularly for when I need to run Windows cmd.exe)
Linux Terminal Emulators
What I realized in my search and multiple trials was there just wasn’t a good Windows terminal emulator. When I was about to give up, I saw a post on Reddit about someone who got XFCE working on WSL Bash. That was way overkill for what I wanted to accomplish, but reading through the post I learned/realized that if I had an X Server running on Windows, I could use GUI Linux terminal emulators “natively” on Windows! That opened up a ton of possibilities, and one of my favorite Linux terminals, Terminator, was now a possibility!
Installing an X Server
To run an X Window application, I needed to have an X Server installed and running on my Windows 10 machine. After researching, it seemed the two most popular options are:
I went with VcXSrv since it looked like it was more actively maintained, but I tried both and they work the same.
After installing, VcXsrv creates a desktop shortcut to start the server in multi-window mode through the following command:
A taskbar icon shows it’s running, and we can verify by looking at netstat:
It’s important to note that VcXsrv is listening on all interfaces and requests a blanket firewall exception for private networks. AFAIK there is no way to only force it to listen/accept connections from localhost only, so I disallowed the firewall exception request and configured a custom rule to only allow traffic from 127.0.0.1
Configuring Terminator
Once VcXsrv was installed and configured to allow access from 127.0.0.1 , the next step was to install Terminator on WSL Bash:
If I didn’t want to use terminator, any other terminal emulator should work, including Gnome Terminal (which Terminator is based on), Urxvt, or xterm.
After it installed, all that was left was to try launching it by specifying the X Display to connect to ( :0 )
And a nice Terminator windows popped up 🙂
Installing Zsh
The next step I did was install Zsh with oh-my-zsh. Installation is straightfoward:
I set the theme “ys” in .zshrc
The only “gotcha” about using Bash in WSL is it will always run Bash instead of Zsh. To get around that, I add this to the end of my .bashrc which will launch zsh instead when it starts up:
Terminator Colorscheme
The next thing I chose to do was change the default Terminator colorscheme to Solarized Dark. The easiest way to do this IMO, is to use the awesome node package base16-builder
Dircolors
It was looking good so far, but the dircolors were still awful:
I found Solarized dircolors on Github and downloaded them to .dir_colors
Then lastly, added this to my .zshrc to eval the Solarized dircolors on startup:
Finally I had a pretty enough terminal to my liking. Still no iTerm2, but pretty damn close IMO
Launching Terminator Directly
The final hurdle was figuring out a way to launch Terminator directly without having to open a Bash window first and then typing DISPLAY=:0 terminator &
From the command line, I could launch bash with the -c parameter and it would work:
However, this still required me to open a command window. After a lot of trial and error and research on StackOverflow, I figured out how to launch a hidden command window using the WShell Object in VBS. The final script I used is here:
With that script, I was able to create a Desktop shortcut to wscript.exe and execute it with the following command:
The last step was to find a pretty Terminator Icon file for the shortcut and add it to my taskbar for quick launching.
One final note is the “Start In” option. It’s impossible to have Termiator start in my Linux home directory through this method since that path is not “known” to Windows. To get around it, I added this to my .zshrc so it CD’s to my home directory on startup:
Hacky, but it works.
Conclusions
I’ve been using Terminator for WSL for a while now and am loving it. It’s the best terminal experience I’ve been able to get on Windows so far. As long as I have VcXsrv running I’ve had no issues with launching it and it runs very smoothly. Terminator is very configurable, and I’ve configured and changed some of the keyboard shortcuts to suit my liking. Overall I love having the splits/panes/tabs and when I’m SSH’d into multiple boxes through WSL it’s amazing. My workflow now is generally running VS Code on my Windows, with multiple Terminator panes open to /mnt/c/projects/whatever and being SSH’d into my lab. Love it.
Hope this helps someone! Let me know if you have a different/better solution!