Глава 3. Сборка смешанных практик

WSL позволяет независимо настраивать конфигурации запуска для всех пакетов дистрибутивов независимо при помощи файла, размещённого в /etc/wsl.conf и при каждом запуске WSL эта конфигурация применяется автоматически. Этот файл настроек следует формату файла INI, который является стандартным файлом формата конфигурационных файлов для программного обеспечения с базовой структурой, составляющейся из [разделов], свойств и значений (пар ключ=значение, хранимых в текстовом файле. Этот файл не создаётся по умолчанию и, если его нет в вашей среде WSL, вы также можете создать его самостоятельно.

Подсистема Windows для Linux определит этот файл и выполнит его синтаксический разбор эого файла при запуске для получения настроек конфигурации, которые поступают в трёх различных разделах:

Вы вначале начнём с раздела [automount] и рассмотрим некоторые примеры чтобы получше разобраться с ним.

Как и предполагает его название, данный раздел управляет тем как автоматически монтировать различные файловые системы в вашем дистрибутиве Linux при его запуске. Эти настройки способны управлять тем как и где фиксированные монтируются в WSL устройства файловой системы вашего Windows.

Таблица 3-1 предоставляет некий перечень свойств и их соответствующие значения, которые допускаются в этом разделе.

По умолчанию, WSL монтирует устройства вашей файловой системы Windows в папке /mnt/ в вашем дистрибутиве Linux, как /mnt/c для устройства C:\, /mnt/d для устройства D:\ при помощи подключаемого модуля файловой системы WSL с названием drvfs. Мы окунёмся поглубже в drvfs и файловые системы позднее в нашей книге. Пока же, давайте предположим, что мы желаем смонтировать свои фиксированные устройства при помощи поглубже в drvfs в отличном от /mnt/ каталоге и потому мы можем задать это в свойстве root в качестве его значения в разделе [automount].

Как это показано на Рисунке 3-1, когда у нас имеется настроенным каталог /test/ в свойстве root из файла /etc/wsl.conf в качестве папки по умолчанию для монтирования устройств Windows и мы перезпускаем WSL, тогда он при следующем его запуске автоматически смонтирует фиксированные устройства, в моём случае C:\ и D:\, в папке /test/ моего дистрибутива Linux.

 

Рисунок 3-1

Корневая папка для монтирования устройств Windows

	Замечание
	Чтобы ваши изменения вступили в силу, вам придётся перезапустить службу lxssManager или прекратить и запустить заново вашу подсистему Windows для Linux. Пока вы это не сделаете, вы не можете наблюдать свои устройства Windows смонтированными в вашем корневом каталоге.

Теперь, если проверить все смонтированные в моём WSL устройства и выбрать только имеющие ключевое слово drvfs, что отображено на Рисунке 3-2, тогда это отобразит лишь те устройства, что мы смонтировали в разделе [automount] своего файла wsl.conf. Использованная в нашем примере команда grep фильтрует/ отыскивает заданный шаблон букв (в нашем случае drvfs) и отображает все содержащие этот шаблон строки, которые в конвейере передаются из командыmount.

 

Рисунок 3-2

Проверка смонтированных устройств и их файловых систем

В этом разделе существует ещё одно свойство, именуемое options, которое будет автоматически добавлять в конец значения для вариантов монтирования drvfs, что является неким способом контроля полномочий для файлов Windows без метаданных Linux. Такие варианты монтирования под этим свойством могут содержать следующие элементы:

Как нам демонстрирует Рисунок 3-3, после того как мы настроили это свойство в файле wsl.conf и перезапустили свой дистрибутив WSL, он будет добавлять в конец те варианты монтирования, которые мы предоставили в монтируемые папки.

 

Рисунок 3-3

Установка опций монтирования drvfs через файл wsl.conf

Теперь давайте рассмотрим раздел [network] и разберёмся как мы можем применять его для настройки записей DNS и соответствия хоста IP адресу в среде WSL.

Раздел [network] в файле настроек WSL предоставляет два важных свойства, перечисленных в Таблице 3-2, которые можно применять для регулирования и управления разрешением необходимых доменных имён и тот способ, которым ваш файл хостов (соответствие хостов IP адресации) настраивается в вашей подсистеме Windows для Linux.

Самым первым свойством в подразделе [network] является generateHosts и основная цель этого свойства состоит в автоматической генерации файла хостов: /etc/hosts в WSL с соответствием IP адресации хостам на основании файла хостов Windows: %WINDIR%\System32\drivers\etc\hosts.

Рисунок 3-4 показывает, что после того как я удалил свой файл хостов в WSL и перезапустил её, а к тому же когда свойство generateHosts установлено в значение true в файле настроек /etc/wsl/conf, будет автоматически создан соответствующий файл хостов на основании файла хостов Windows.

 

Рисунок 3-4

Автоматическая выработка файла /etc/hosts из файла хостов Windows

Вторым свойством в этом разделе выступает generateResolvConf, которое будучи установленным в true создаёт перечень сервером доменных имён, которым будет пользоваться подсистема Windows для Linux. В нашем следующем примере, как это демонстрирует шаг 1 на Рисунке 3-5, я отключил свойство generateResolvConf, установив его в false в файле wsl.conf. Теперь, если я попытаюсь выполнять ping к любому вебсайту (шаг 2), он получит отказ в разрешении всех имён хостов в их надлежащие IP адреса, потому как нет никакого сервера службы доменных имён для обеспечения такого разрешения имён. Давайте вернёмся назад и восстановим эту установку как на шаге 3 и остановим мой дистрибутив WSL (шаг 4) для того чтобы настройки конфигурации вступили в действие.

 

Рисунок 3-5

Автоматическая выработка серверов доменных имён в WSL

После внесения этих изменений, когда ваш дистрибутив WSL перезапущен, вы будете наблюдать автоматическую выработку /etc/resolv.conf с именами серверов. Давайте попробуем отправить запросы ICMP к некоторым вебсайтам, просто чтобы убедиться работает ли разрешение имён или нет; далее, когда, как вы можете это наблюдать на Рисунке 3-6, мы имеем возможность разрешить google.com и попасть на IP адрес его целевого сервера для того чтобы начать получать его отклики ping.

 

Рисунок 3-6

После выработки файла “resolv.conf” разрешение имён работает

Давайте рассмотрим третий и последний раздел в wsl.conf, именуемое [interop],которое дополнительно определяет будет ли запускаться процесс Windows из WSL и будут ли разделяться переменные PATH Windows между обеими операционными системами.

Этот раздел файла wsl.conf имеет дело с двумя важными установками взаимодействия Windows - Linux, которые упоминаются в приводимой ниже Таблице 3-3.

Как показано на Рисунке 3-7, первым свойством в этом подразделе выступает enabled. Если enabled установлено в false, WSL не поддерживает запуск никаких процессов Windows, таких как notepad.exe, из Linux. Шаг 1 этого рисунка показывает, что когда мы пытаемся запускать notepad.exe из bash, он не способен запускать программы в формате Windows и распространяет ошибку. Чтобы решить эту проблему, измените установленное значение свойства enabled на true и перезапустите свой дистрибутив чтобы снова заставить процессы Windows работать.

 

Рисунок 3-7

Теперь приложения Windows запускаются из дистрибутива Linux

Другим свойством из этого подразделы является AppendWindowsPath, и, как и предполагает само назыание, когда это свойство установлено в “true”, в переменной chtls Linux $PATH будут добавляться в конец переменные PATH Windows, как это отражено на Рисунке 3-8. Кроме того, когда AppendWindowsPath отключается установкой в false, тогда элементы переменной Windows PATH не добавляются в конец переменной среды Linux $PATH. Чтобы эти изменения вступали в действие, не забывайте прекращать и повторно запускать свой дистрибутив Linux.

 

Рисунок 3-8

Добавление путей из переменной PATH Windows в переменную $PATH среды Linux

Этим заканчиваются три подраздела файла Co/etc/wsl.confde, а все лежащие в основе этого файла цели состоят в том, чтобы позволить продвинутым пользователям регулировать настройки [interop], [[interop]] и [network], которые позволят им лучше собирать смешанные практики. Это способствует наведению мостов между вселенными Windows и Linux с тем, чтобы мы имели возможность перемещать всё что нам нужно везде и работать с наиболее подходящими для определённой задачи инструментами вне зависимости от лежащей в основе платформы и множество прочих возможностей, которые ранее заключались по отдельности в экосистемах Windows и Linux.

Теперь мы научились выводить такие смешанные между Windows и WSL решения на новый уровень, за счёт возможности совместного применения переменных среды с настраиваемыми в операционных системах значениями, причём они могут существовать по обе стороны и транслировать пути файловой системы из Linux в Windows и наоборот. Давайте вначале начнём с с трансляции путей.

wslpath это утилита, которая выполняет трансляцию из пути WSL в путь Windows и наоборот. Ниже приводится синтаксис для применения этой утилиты, а Таблица 3-4 перечисляет все выходные параметры, которые могут применяться в wslpath.

Синтаксис:

wslpath [-m|-u|-w|-h] NAME[:line[:col]]
 	   

Для более лучшего понимания этого инструмента, Листинг 3-1 и Рисунок 3-9 демонстрируют некоторые образцы выполнения трансляции путей.

# по умолчанию транслируются путь Windows в путь WSL, эквивалентно `-u`
wslpath 'C:\Users'

# вы также можете применять '-a' для трансляции пути Windows в формат абсолютного пути WSL
wslpath -a 'temfile.txt'

# трансляция пути WSL в путь Windows при помощи '-w'
wslpath -w '/mnt/c/Users'

# трансляция пути WSL в путь Windows с применением '-m'
# однако с передачей слешей '/' вместо обратных слешей '\'
wslpath -m '/mnt/c/Users'
 	   

 

Рисунок 3-9

Применение утилиты wslpath для трансляции путей

Эта утилита может оказаться очень полезной, когда мы желаем запускать файлы из WSL в операционной системе Windows, подобно следующему примеру на Рисунке 3-10, в котором я запускаю некий сценарий, размещённый в моей файловой системе Windows и, применяя, wslpath, я способен транслировать их в надлежащие пути Unix и запускать этот файл сценария PowerShell через pwsh (которая является версией с открытым исходным кодом PowerShell, которая исполняется в Linux) внутри подсистемы Windows для Linux. Если мы пристальнее вглядимся в следующий пример, мы применяем команду wslpath внутри $(); это носит название подстановки команды и делает возможной подстановку получаемого вывода данной команды и заменять саму команду, что для нашего образца является путём Linux файла Windows сценария PowerShell. Bash осуществляет это расширение выполняя соответствующую команду в $(<command>) через среду встроенной оболочки и затем замещает данную команду, подставляя её вывод в данной команде.

 

Рисунок 3-10

Применение утилиты wslpath для запуска Windows PowerShell

Теперь, когда мы понимаем как работает трансляция пути, давайте рассмотрим как WSL делает для нас возможным совместно использовать переменные среды в Windows и Linux.

Начиная со сборки 17063 Windows Insider и далее, WSLENV это особая переменная среды , которая делает возможным совместное применение между Windows и дистрибутивом Linux переменных среды, когда одна из них вызывается из другой; в предыдущих версиях Windows 10 единственной переменной среды Windows, которая была доступна в WSL была PATH. WSLENV совместно разделяется между средами Windows и WSL и она содержит список общих переменных среды.

Все выполняемые в переменной WLSENV изменения не будут сохранены после закрытия соответствующего сеанса WSL. Чтобы превратить эти изменения в постоянные, вам придётся изменить соответствующий соответствующий файл настроек, например, .profile, .bash_rc и тому подобные, что установит WSLENV в желаемые значения при каждом запуске нового сеанса WSL.

Собственно трансляцией переменных между WSL и Windows можно управлять одним из следующих флагов, перечисляемых в Таблице 3-5, причём эти флаги при необходимости могут комбинироваться вместе.

	Замечание
	Вы можете устанавливать значение переменной WSLENV во что пожелаете. Хотя, когда вы устанавливаете некий путь файловой системы напрямую, вместо соответствующих названий переменных среды, тогда трансляция пути не будет работать. Следовательно, рекомендуется устанавливать WSLENV для соответствующей переменной среды содержащей необходимый файл с верными флагами трансляции.

В качестве примера, давайте создадим некую переменную в WSL и затем добавим её в WLSENV с флагом /p, как на Рисунке 3-11; теперь, когда мы попытаемся считать установленное значение этой переменной из cmd.exe, она покажет вам транслированный путь, теперь доступный также и в Windows. Обратите внимание, что когда вы не обладаете полномочиями администратора в учётной записи Windows, вы можете не увидеть некоторых переменных среды, созданных в WSLENV:

$ export MYPATH=/mnt/c/Users
$ export WSLENV=MYPATH/p
$
$ cmd.exe
Microsoft Windows [Version 10.0.17763.348]
 (c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\admin> echo %MYPATH%
C:\Users
 	   

 

Рисунок 3-11

Настройка переменной среды в Windows из WSL

Давайте рассмотрим другой пример чтобы показать как некий список разделённых двоеточием (:) значений может назначаться WSLENV с флагом /l, который транслирует эти пути в раделяемые точкой с запятой значения при доступе к этой переменной среды из Windows, как это отражено на Рисунке 3-12:

$ export MYPATHLIST=/mnt/c/Users:/mnt/c/temp
$ export WSLENV=MYPATHLIST/l
$
$ echo $MYPATHLIST
/mnt/c/Users:/mnt/c/temp
$
$ cmd.exe
Microsoft Windows [Version 10.0.17763.348]
 (c) 2018 Microsoft Corporation. All rights reserved.
C:\Users\admin>echo %MYPATHLIST%
C:\Users;C:\Temp
 	   

 

Рисунок 3-12

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

Флаг WSLENV /u можно применять для указания того, что соответствующие переменные среды создаются из Windows только для WSL. Он также может работать в сочетании с флагом /p (и оба могут сочетаться в виде /up) для трансляции значения пути в специфичный для Linux формат, как это демонстрируется Рисунком 3-13. С другой стороны, флаг /W работает в точности наоборот и создаёт переменную среды при запуске Windows из WSL.

 

Рисунок 3-13

Настройка переменной среды из Windows для WSL

Переменная WSLENV также позволяет нам определять множество совместно используемых переменных среды с различными вариантами доступных флагов. Давайте посмотрим как это работает.

Синтаксис:

WSLENV=FORWSL/u:FORWIN/w:MYPATHLIST/l:TEMPDIR/p
 	   

Здесь WSLENV определяется со списком множества переменных среды, за которыми следуют соответствующие флаги WSLENV и разделители двоеточием. Именно это идеально в тех ситуациях, когда мы желаем разделять большое число совместных переменных различными способами. например, мы можем запустить в WSL приводимые ниже команды и получить вывод Рисунка 3-14:

$ # создание переменных среды и совместное использование в Windows при помощи WSLENV
$ export FORWSL=/mnt/c
$ export FORWIN=/mnt/c/Data
$ export MYPATHLIST=/mnt/c/Users:/mnt/c/Data
$ export TEMPDIR=/mnt/c/temp
$ export WSLENV=FORWSL/u:FORWIN/w:MYPATHLIST/l:TEMPDIR/p
$ # проверка значений переменных среды в Windows
$ cmd.exe # launch cmd prompt from WSL
C:\WINDOWS\system32> echo %FORWSL%
%FORWSL%
 
C:\WINDOWS\system32> echo %FORWIN%
/mnt/c/Data

C:\WINDOWS\system32> echo %MYPATHLIST%
C:\Users;C:\Data
C:\WINDOWS\system32> echo %TEMPDIR%
C:\Temp
		

 

Рисунок 3-14

Настройка за раз более одной переменной

В этой главе мы изучили различные конфигурации запуска WSL с применением файла настроек wsl.conf и его три раздела, а также необязательные настройки в этом файле: [automount], [network] и [interop]. Сочетание этих настроек запуска способно монтировать устройства, настраивать разрешение имён, вырабатывать файлы хостов и включать взаимодействие, предоставляя вам возможность запуска приложений Windows из WSL. Далее в этой главе мы также рассмотрели утилиту трансляции путей Windows - Linux “wslpath” и разделение переменных среды между операционными системами Windows и Linux при помощи WLSENV. В своей следующей главе мы рассмотрим управление дистрибутивами подсистемы Windows для Linux, такое как настройка, резервное копирование и восстановление, а также персонализацию дистрибутивов.