Как добавить ubuntu в windows terminal

Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже senior yaml developer`ом, пользуется command line interface. Далеко не все задумываются об улучшении рабочего окружения в CLI и повышении продуктивности работы в терминале. Мне хотелось бы поделиться своим опытом настройки окружения для работы с Linux из Windows.

Картинка с сайта: habr.com

Из статьи вы узнаете, какими средствами и каким терминалом актуально пользоваться в настоящее время для запуска 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 всегда с этим были проблемы. Но сейчас всё меняется.

Картинка с сайта: habr.com

Эта и последующие статьи больше ориентированы на энтузиастов, которые ищут свежие решения и желают прокачать свой шелл. Но и новичкам должно быть что-то интересно, хотя статья получилась с достаточно глубоким погружением в тему и предполагает, что у читателя есть какие-то фундаментальные знания в Linux. Вся информация собрана на основе личного опыта использования WSL, терминала, а так же бесконечного листания Stack Overflow и Github issues в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.

Windows Subsystem for Linux (WSL) 2

В интернете и на Хабре есть несколько нормальных статей про WSL (раз статья про установку/настройку WSL с X-сервером, два заметка про WSL 2, три статья про Python разработку в VSCode с WSL), описывающих установку и настройку системы. Однако не все действия по установке уже актуальны, так же как и ограничений с подводными камнями становится меньше. Я не буду подробно останавливаться на установке, инструкция по установке актуальной (второй) версии WSL есть на сайте Microsoft, также в интернете можно найти краткие туториалы.

Картинка с сайта: habr.com

Сейчас 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.

Картинка с сайта: habr.com

Далее я приведу краткую инструкция установки из 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 -l -v

При необходимости преобразовать дистрибутив в формат 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

Изначально WSL идёт без этого конфига, его нужно прописать вручную:

[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.

Картинка с сайта: habr.com

Сделать ребут дистрибутива можно из PowerShell командой:

wsl -t kali-linux

После этого можно обновить пакеты и заняться настройкой ОС под себя. Я пока не буду касаться настроек шелла и окружения в Linux, оставлю это для следующей статьи.

apt -y update && apt -y upgrade

Файловая система WSL 2 и производительность

Файлы внутри WSL версии 2 хранятся на виртуальном диске VHDX, в качестве файловой системы используется ext4. Получить доступ к rootfs WSL можно через путь такого формата:

\\wsl$\{DistroName}\

Либо, можно набрать «explorer.exe .» в CLI и откроется обозреватель Windows в текущей директории.

В WSL версии 1 не использовался VHDX и был простой доступ к директории, в которой находились файлы Linux, и Microsoft строго не рекомендовали изменять Linux файлы из Windows. В новой версии WSL доступ к ФС на виртуальном диске обеспечивается с помощью файлового сервера Plan 9 Filesystem Protocol.

Картинка с сайта: habr.com

В предыдущих версиях 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.

Картинка с сайта: habr.com

Сеть 

Имя хоста (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

Картинка с сайта: habr.com

В данном случае сеть 172.27.144.0/20 используется под WSL, её первый адрес (172.27.144.1) — это хостовая система Windows.

Из Linux обращаться по сети к хостовым сервисам (запущенным в Windows) можно, например, так:

❯❯ nmap -p 3389 $(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')

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. 

Картинка с сайта: habr.com

IP-адрес в Linux после перезагрузки будет каждый раз меняться, так что в сценариях, когда нужно иметь постоянно работающий и автоматически запускающийся port forwarding, нужно искать воркэраунд. Есть много способов решения этой проблемы, разной степени костыльности, почитать подробнее можно в этом issue на github. Я воспользовался утилитой go-wsl2-host, которая реализует Windows Service, добавляющий автоматически IP-адрес WSL в файл hosts Windows, таким образом на хостовой системе можно прописать хостнейм типа ubuntu.wsl и по нему обращаться к Linux. Однако всё это костыли и работает не очень хорошо, остаётся ждать, когда Microsoft пофиксят эти проблемы.

Картинка с сайта: habr.com

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.

Картинка с сайта: habr.com

Единственный рабочий способ попасть по 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 в профайле шелла (например, ~/.zshrc для zsh).

❯❯ echo "export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0" >> ~/.zshrc

Картинка с сайта: habr.com

В качестве 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/${WIN_USER}/.ssh/id_rsa -b 4096
ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa ${HOME}/.ssh/id_rsa
ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub ${HOME}/.ssh/id_rsa.pub

Либо, в ~/.ssh/config можно прописать параметр IdentityFile, указав путь к ключам на диске Windows:

Host * 
    IdentityFile /mnt/c/Users/${WIN_USER}/.ssh/id_rsa

Если ключи были скопированы откуда-то и права на файлы не выставлены правильно, поправить permissions:

chmod 600 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa
chmod 644 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub
chmod 700 /mnt/c/Users/${WIN_USER}/.ssh

Картинка с сайта: habr.com

Таким образом, при дальнейшей настройке доступа по ключам 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 и др.), но их я оставлю без внимания.

Картинка с сайта: habr.com

Дальше в этой статье речь пойдёт про 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 теперь есть на гитхабе, их софт научился показывать логи, внятные ошибки и любые проблемы легко гуглятся.

Картинка с сайта: habr.com

Настроек в терминале пока не много, но их хватает для комфортной работы, продукт активно развивается, есть на github, где пользователи могут создать feature request или bug report. Разработчики принимают участие в обсуждении проблем с пользователями, зачастую предлагая воркэраунды, когда обнаруживается баг.

Картинка с сайта: habr.com

Конфиг хранится в json формате, после сохранения применяется сразу же. Это удобно хотя бы потому, что можно применять хорошие практики управлением конфигурациями рабочего окружения — все линуксовые конфиги я храню в git репозитории, на Windows из рабочего инструмента использую только VSCode, который умеет синхронизировать конфиг через github gist, а локальный конфиг воркспейса сохранять отдельно в dotfiles. Вот и Terminal движется в ту же сторону, используя те же хоткеи и формат конфига, как VSCode. Править конфиг, кстати, удобно через VSCode, особенно если уже пользуетесь этим отличным редактором от MS. Файл конфигурации терминала уже содержит многие дефолтные настройки, а правильный редактор позволяет посмотреть все опции с описанием key и вариантами value из schema (особенно это удобно, когда у проекта ещё нет полноценной документации). Плюсом доступны все фишечки IDE в виде автодополнения, intellisense, проверкой синтаксиса, форматированием и т.д. 

Картинка с сайта: habr.com

Документация для разработчиков доступна тут, а здесь пока что небольшая страничка документации для пользователей. Отдельная страница посвящена настройкам, которые прописываются в json файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:

• Global (профиль по умолчанию, изначальный размер окна терминала, тема и т.д.)
• Key Bindings (настройки сочетаний клавиш)
• Profiles (настройки, специфичные для каждого терминала)
• Schemes (цветовые схемы)

Есть такое понятие, как динамические профили, они появляются в конфиге автоматически и имеют свойство source. Это касается дистрибутивов WSL и Azure Cloud Shell. Чтобы создать дубликат профиля одного и того же дистрибутива WSL (например, Ubuntu), необходимо сгенерировать GUID и прописать все желаемые настройки, кроме source, а в качестве commandline прописать wsl -d {DistroName}.

Шрифты

Чтобы терминал по-настоящему радовал пользователя, обязательно надо инсталлировать шрифты с поддержкой спец символов и лигатур. Выбрать можно из:

• Fira Code
• Hack
• любые другие патченые шрифты

Я использую программерский шрифт Fira Code как в терминале, так и в редакторе. Им поддерживаются большинство символов, используемых в в оформлении CLI программ и консольных интерфейсов, лигатуры, а также нет никаких проблем с отображением эмодзи в терминале.

Картинка с сайта: habr.com

Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.

Посмотреть название шрифта (настройка терминала fontFace) можно при установке или после в приложении Character Map (Таблица Символов). Кроме этого, в Start -> Settings -> Personalization -> Fonts можно посмотреть, как шрифт рендерится в разных режимах, и заодно проверить, как рисуются лигатуры.

Картинка с сайта: habr.com

Заключение

Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2, но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть выделенный сервер.

Я надеюсь, что никто не пожалел, что дочитал статью и вынес для себя какие-то новые знания. Если кому-то есть, что добавить, давайте делиться мыслями в комментариях. Если есть какие-то замечания по тексту, пишите в ЛС, хочется поддерживать этот гайд в актуальности.

References

• Announcing WSL 2 (devblogs.microsoft.com)
• WSL 2 is now available in Windows Insiders (devblogs.microsoft.com)
• Memory Reclaim in the Windows Subsystem for Linux 2 (devblogs.microsoft.com)
• Automatically Configuring WSL (devblogs.microsoft.com)
• wsl2-tutorial (github.com)
• Terminal v1.0 Roadmap (github.com)
• Editing Windows Terminal JSON Settings (github.com)

Эта статья имеет дискуссионный характер и основана на личном опыте автора. В ней описывается предпочтительный способ взаимодействия с удаленными серверами на Linux, используя инструменты WSL, Windows Terminal и Zsh. Если вы уже знакомы с этими инструментами и предпочитаете использовать свои собственные подходы, вы можете адаптировать предложенные рекомендации или добавить свои собственные наработки.

Однако, если вы новичок в этой области или ищете более удобный способ работы с серверами Linux на компьютерах под управлением Windows, я приглашаю вас ознакомиться с предлагаемым подходом. В статье будет рассмотрена установка и настройка указанных инструментов, а также рассмотрены преимущества их использования при подготовке системы к установке Directum RX.

Вступление

Поскольку большинство из нас пользуется Windows, в том случае, когда нам необходимо развернуть Directum RX на сервере под управлением Linux, мы сталкиваемся с вопросом подключения к такому серверу и работе в консоли.
Администратор выдает ip адрес сервера, логин и пароль, часто — vpn, иногда просит отправить ssh ключ.
Чаще всего мы используем Xshell или PyTTY, но я думаю, что нашел более простой, красивый, и что важнее удобный способ взаимодействия с серверами Linux, с беспарольным подключением, автодополнением, подсветкой синтаксиса и возможностью подключаться к нескольким серверам и запускать несколько консольных утилит на одном и том же сервере одновременно.
Windows Terminal позволит запускать Linux прямо в консоли, дает возможность разделять экран и использовать вкладки.
WSL + Ubuntu позволяет подключаться к серверу по ssh, не выходя из терминала.
Oh-My-Zsh помогает сделать консоль более информативной и удобной, добавляя несколько функций, таких как автодополнение, подсветка синтаксиса, исправление ошибок ввода, распаковка zip архивов.

Кратко

В процессе установки и настройки я использую Windows Terminal, WSL с дистрибутивом Ubuntu, а также настраиваю Zsh и oh-my-zsh с плагинами git, extract, zsh-autosuggestions и zsh-syntax-highlighting как на WSL, так и на удаленном сервере. Для иллюстрации этого подхода, мы также рассмотрим установку определенной версии Docker и PostgreSQL на сервере.

Подробно

Чтобы сделать работу в консоли более удобной, предлагаю использовать Windows Terminal. Вы можете скачать его из Windows Store или с GitHub по следующему адресу: microsoft / terminal. Настройку Windows Terminal мы рассмотрим позже, а пока давайте запустим его (откроется окно PowerShell, так как этот профиль установлен по умолчанию) и установим Windows Subsystem for Linux (WSL) для установки Ubuntu, с которым мы будем работать дальше. Для этого выполните команду

wsl --install

Эта команда включит Hyper-V, если он еще не включен, и установит WSL и Ubuntu как дистрибутив по умолчанию, интегрированный в вашу операционную систему. Если по какой-то причине Ubuntu не скачалась, вы можете установить ее из Microsoft Store.

Картинка с сайта: club.directum.ru

После установки дистрибутива Ubuntu в Windows Terminal появится соответствующий профиль, и теперь мы можем запустить Ubuntu просто щелкнув на него. 

Картинка с сайта: club.directum.ru

Ubuntu попросит вас ввести имя пользователя и пароль. При вводе пароля в Linux символы не отображаются, поэтому не пугайтесь, если не видите своего ввода. Также будьте внимательны к раскладке клавиатуры и регистру.
Готово? Отлично! Теперь вы видите стандартное приглашение в виде Ubuntu Server, которое вы также увидите на удаленном сервере. Предлагаю настроить этот интерфейс.

Шаг 1: Настроим цветовую схему и шрифт. 

Давайте беречь наше зрение. Для этого все по той же стрелочке вниз в Windows Terminal перейдем в параметры для профиля Ubuntu, выберем шрифт, его размер и  цветовую палитру. В качестве шрифта я использую MesloLGS NF (ссылка на гитхаб), и я буду рекомендовать его (далее в статье этот шрифт нам будет полезен), ну а все остальное настраивайте исходя из Ваших предпочтений и комфорта.

Шаг 2: Делаем эмулятор терминала нашим другом.

Вся «фишка» Linux и эмулятора терминала в частности, кроме встроенных в ядро Linux драйверов, заключается в возможностях масштабирования — благодаря тому, что последовательность действий заключается в вводе определенных команд, нам достаточно один раз написать все команды, сохранить их, а потом делать Ctrl+C — Ctrl+V. Давайте так и поступим.

Для того, чтобы сделать интерфейс эмулятора терминала более дружелюбным, выполним следующую последовательность команд:
Обновим нашу систему:

sudo apt update && apt upgrade

Установим необходимые утилиты:

sudo apt install git curl wget openssh-server gnupg ca-certificates vim apt-transport-https

Как видите, нужные программы перечисляются через пробел. В результате выполнения нашего запроса система попросит нас ввести пароль и спросит, действительно ли мы хотим установить все это. Вводим «Y«. Так же вы можете избежать этого вопроса, добавив в конец команды «-y«.
Обновляем локальный индекс пакетов снова:

sudo apt update

и устанавливаем oh-my-zsh:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

В результате запустится скрипт, который спросит, хотим ли мы использовать zsh по умолчанию. Соглашаемся вводом «Y«
Скачиваем тему и дополнения для zsh, которые будем использовать:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $ZSH_CUSTOM/plugins/zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-autosuggestions.git $ZSH_CUSTOM/plugins/zsh-autosuggestions

zsh — это командная оболочка, которая заменяет стандартный для большинства Linux дистрибутивов bash, а oh-my-zsh — это менеджер плагинов для него.
Откроем и отредактируем файл конфигурации, который находится в вашей домашней папке:

sudo vim /home/ваше_имя_пользователя/.zshrc

Вы можете просто скопировать эту команду в консоль, или ввести команду вручную. Когда будете вводить путь, достаточно ввести его начало и нажать TAB, после чего система подставит нам первое по алфавиту в списке значение из существующих. Двойное нажатие TAB выведет весь список.
Заодно таким образом можно убедиться, что файл .zshrc существует. Если нет, перезайдите в Ubuntu.
Откроется консольный текстовый редактор vim, которым пугают людей в интернетах, но мы с ним достаточно быстро подружимся.
Если все сделано верно, вы увидите настройки zsh 

Картинка с сайта: club.directum.ru

Стрелочками листаем до строчки

ZSH_THEME

с помощью клавиши Del удаляем все и правой кнопкой мышки вставляем эту строчку

 ZSH_THEME="powerlevel10k/powerlevel10k"

 листаем ниже до строчки

plugins=(git)

нажимаем клавишу «I» и попадаем в режим редактирования текста, где работают привычные правила.
редактируем строчку так, чтобы вышло

plugins=(git extract zsh-autosuggestions zsh-syntax-highlighting)

Опционально вы можете добавить плагин thefuck, если вы часто забываете написать перед командой sudo. 
Сделать это можно, добавив слово thefuck в список плагинов, но обратите внимание, что zsh-autosuggestions и zsh-syntax-highlighting должны стоять в конце списка для корректной работы. Для thefuck, как и для extract, ничего скачивать не нужно, подробнее о них можно почитать тут: extract, thefuck.
Чтобы выйти из режима редактирования в vim. достаточно нажать ESС, далее сохраним файл, введя команду:

:x

Чтобы выйти из vim без сохранения, используйте

:q!

Перезайдем в систему, выполнив exit и открыв Ubuntu снова.
запустится скрипт установки темы powerlevel10k, просто следуйте инструкциям и выбирайте то, что нравится. Это вкусовщина, но у меня получается так 

Картинка с сайта: club.directum.ru

В результате получаем достаточно удобный терминал, в котором мы видим, в какой папке находимся и под каким пользователем, красным отображаются неверные команды, зеленым — верные, более темный шрифт нам подсказывает, что писать, стрелка влево завершает автокомплит, а клавиша TAB теперь нам экономит кучу времени, показывая, что мы можем ввести.

Если вы, как и я, хотите настроить то же самое для суперпользователя и не вводить sudo каждый раз, выполните следующие команды:
Авторизоваться как суперпользователь:

sudo su

Перейти в его домашнюю папку

cd

Снова скачайте тему, дополнения и отредактируйте .zshrc командой vim .zshrc — файл конфигурации свой для каждого пользователя.
Для применения изменений разлогиньтесь и авторизуйтесь снова:

exit
sudo su

• Шаг 3: Устанавливаем беспарольный доступ на сервер.

Итак, у нас есть удобная консоль, vpn, адрес сервера, логин и пароль. SSH не заменяет vpn, так что убедитесь, что он у вас включен перед выполнением операций.
Давайте создадим ключ ssh, который будет пускать нас на этот сервер без пароля:

ssh-copy-id username@server_ip_address

Замените username на имя пользователя на сервере, а server_ip_address на фактический IP-адрес вашего сервера.
При выполнении этой команды вам может быть запрошен пароль пользователя на сервере.
Если операция успешна, ваш публичный ключ будет скопирован на сервер в файл ~/.ssh/authorized_keys для указанного пользователя. Это позволит вам аутентифицироваться на сервере с использованием соответствующего приватного ключа.
Теперь подключаемся к серверу:

ssh username@server_ip_address

Если все сделано верно, вы подключитесь к удаленному серверу Linux, о чем вам скажут следующие строки 

Картинка с сайта: club.directum.ru

Повторим для нашего пользователя на сервере, получив удобный для работы терминал, а заодно воспользуемся всеми преимуществами связки всех этих программ.
В зависимости от дистрибутива Linux команду apt нужно будет заменить на 
apt-get для Alt Linux и Astra Linux 
yum для Рэд ОC

Демонстрация и совсем немного инструкций

Скачаем Directum RX и подготовим наш сервер к его установке:
Скачиваем необходимую версию с саппорта и с помощью проводника Windows копируем архив в \\wsl.localhost\Ubuntu\home\ваше_имя_пользователя (или можно воспользоваться проводником, заглянув в папку Linux в левом меню)
Щелкаем правой кнопкой мышки по окну с ubuntu и выбираем «Разделить вкладку» пару раз, это создаст нам дополнительные удобные области работы. По ним можно перемещаться щелчком мыши или комбинацией клавиш Alt + стрелка, изменять размер окон можно комбинацией клавиш Shift+ Alt + стрелка.

Картинка с сайта: club.directum.ru

В окне, которое авторизовано на сервере (благодаря zsh вы можете проверить, где вы находитесь, на моем скриншоте это замытый участок возле часов, у вас там будет username@address) проверьте, что у нас достаточно места на диске командой

df 

(смотрите на «/»).
В другом окне вводим команду подключения  протоколу sftp:

sftp username@server_ip_address

sftp авторизуется по ssh и мы можем копировать архив DirectumRX.zip на удаленный сервер командой

put /local/directory/DirectumRX.zip /remote/directory/DirectumRX.zip

Если архив находится в домашней папке, или вы хотите положить его в домашнюю папку на сервере, путь можно не писать, например эта команда

put DirectumRX.zip 

скопирует архив DirectumRX.zip из /home/ваше_имя_пользователя/ вашего компьютера на /home/ваше_имя_пользователя/ удаленного сервера.
Аналогично можно пользоваться командой get (или get -r, если мы хотим скачать не файл, а папку).
Проверить, что файл на месте, можно в окне, которое авторизовано на сервере, перейдя в нужный каталог командой 

cd /путь/до/файла/ 

и отобразив все файлы и папки командой

ls -la

Воспользуемся преимуществами zsh и разархивируем файл:

extract DirectumRX.zip

В результате этой команды у нас появится новая папка DirectumRX с распакованным архивом. Перейдем внутрь командой:

cd DirectumRX

и распакуем нужное:

extract Имя_архива.tar.xvf

Удалить лишнее можно командой 

rm -rf имя_файла

Теперь эту папку можно скопировать в более удобное место, я использую /srv:

cp -r /home/ваше_имя_пользователя/DirectumRX /srv

или переместим:

mv /home/ваше_имя_пользователя/DirectumRX /srv

Для установки DirectumRX на Linux нам требуется PosgreSQL и Docker, давайте скачаем нужные версии.

Docker

для Ubuntu, Alt Linux и Astra Linux воспользуемся скриптом из документации:

#Run the following command to uninstall all conflicting packages:
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done
    
#Update the apt package index and install packages to allow apt to use a repository over HTTPS:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg

#Add Docker’s official GPG key:
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

#Use the following command to set up the repository:
echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \

sudo tee /etc/apt/sources.list.d/docker.list > /dev/null


#Update the apt package index:
sudo apt-get update

#List the available versions:
apt-cache madison docker-ce | awk '{ print $3 }'

Обратите внимание, что строки, которые начинаются с # игнорируются.
После выполнения данных команд мы должны увидеть список доступных для скачивания версий докера, установим ее таким образом:

VERSION_STRING=5:24.0.0-1~ubuntu.22.04~jammy
sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin

 Для РЭД ОС воспользуемся командами для того, чтобы показать список доступных версий

sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
yum list docker-ce --showduplicates | sort -r

и установим докер:

VERSION_STRING=5:24.0.0-1~ubuntu.22.04~jammy
sudo yum install -y docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin

PostgreSQL

для Ubuntu, Astra Linux и Alt Linux, покажем доступные версии:

# Create the file repository configuration
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Import the repository signing key
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo tee /etc/apt/trusted.gpg.d/pgdg.asc &>/dev/null

# Update list of available packages
sudo apt update
sudo apt-cache madison postgresql

и установим 

sudo apt-get install postgresql-какая нам нужна-версия

Для РЭД ОС:

# Import the repository signing key
sudo rpm --import https://www.postgresql.org/media/keys/ACCC4CF8.asc

# Create the file repository configuration
sudo sh -c 'cat <<EOF > /etc/yum.repos.d/pgdg.repo
[pgdg$(rpm -E %dist)]
name=PostgreSQL $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/$(rpm -E %rhel)/$(rpm -E %rhel)/$basearch
enabled=1
gpgcheck=1
gpgkey=https://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG-$(rpm -E %rhel)
EOF'

# Update list of available packages
sudo yum update

# List all available PostgreSQL versions
sudo yum list postgresql*

и установим 

sudo yum update
sudo yum install postgresql-server-какая-там-версия-нам нужна.

Не забудьте отредактировать /etc/postgresql/версия/main/postgresql.conf и pg_hba.conf в той же папке,
Откройте postgresql.conf с помощью vim:

sudo vim /etc/postgresql/версия/main/postgresql.conf

пролистайте до этого вывода и настройте параметры

#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

listen_addresses = '*'          # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost'; use '*' for all
                                        # (change requires restart)
port = 5432                             # (change requires restart)
max_connections = 100                   # (change requires restart)

для pg_hba.conf нужно по аналогии с существующими записями добавить своего пользователя после того, как вы его создадите, например

host    all             rxadmin         0.0.0.0/0               trust

Вывод

Настройка эмулятора терминала в Windows Terminal для профиля Ubuntu является важным шагом в создании комфортного и продуктивного рабочего окружения. Правильная настройка цветовой схемы, шрифта и установка необходимых утилит позволяют не только беречь зрение, но и существенно улучшить опыт работы.

Благодаря использованию zsh вместо стандартной оболочки bash и установке oh-my-zsh, мы получаем мощный инструмент с поддержкой тем и плагинов. Тема powerlevel10k добавляет стильный внешний вид и информативность к терминалу, а плагины, такие как zsh-syntax-highlighting и zsh-autosuggestions, облегчают ввод команд и предоставляют полезные подсказки.

В результате всех этих шагов, вы создали оптимизированное рабочее окружение, которое поможет вам повысить производительность, удобство и эффективность вашей работы с Ubuntu в Windows Terminal.

Каждый из этих инструментов универсален и может быть использован далеко не только для установки DirectumRX, а oh-my-zsh и Windows Terminal имеют огромное количество плагинов, которые делают работу с ними проще и удобнее конкретно для вас.

Настраивайте свое рабочее окружение с умом и не бойтесь экспериментировать с различными настройками, чтобы найти наиболее подходящие для ваших потребностей. Удачи в работе и приглашаю в комментарии с вопросами, критикой и дополнениями к статье.