С помощью использования новой функции в WSL можно, например, фиксировать время и дату запусков дистрибутивов Linux в WSL.
6 января 2021 года Microsoft рассказала в своем блоге, что в тестовой сборке Windows 10 Insider build 21286 появилась возможность автоматически выполнять команды Linux при запуске дистрибутивов Linux в подсистеме Windows для Linux (WSL).
Microsoft пояснила, что ее разработчики добавили в настройки WSL параметр, который позволяет запускать необходимую команду Linux при запуске дистрибутива WSL. Это можно сделать путем редактирования файла /etc/wsl.conf в дистрибутиве и создания там параметра под названием “command” (команда) в раздел под названием “boot” (загрузка).
После внесения изменений данная команда будет автоматически запускаться всякий раз, когда запускается определенный дистрибутив WSL.
Microsoft уточнила, что дистрибутивы WSL продолжают работать в течение нескольких минут даже после закрытия последнего процесса Linux внутри них. Чтобы проверить, работает ли еще дистрибутив WSL, нужно запустить в PowerShell команду «wsl --list --verbose». Чтобы вручную закрыть дистрибутив WSL, нужно использовать команду «wsl --shutdown».
В октябре прошлого года пользователи обнаружили, что подсистема WSL 2 обходит правила блокировки встроенного брандмауэра Windows 10. В то время, как первая версия WSL полностью соблюдает все ограничения Windows Advanced Firewall (WAF).
maledog
А что, остальных способов было недостаточно? Например .bashrc, cron...?
staticmain
Они не были разработаны Microsoft.
BrennendeHerz
EEE недостаточно быстрым получается и конфигурирование слишком привязано к общепринятым стандартам, а нужно чтобы было привязано к WSL. И чтобы не не имело «фатального недостатка». То есть все механизмы должны быть либо написаны в Microsoft либо должны находиться под контролем Microsoft. Если есть конкурирующие стандарты вроде cron и systemd timers то надо сделать третий, но свой )) Не делать же вместо этого поддержку зловредного тяжелого systemd — пускай этим сторонние разработчики на Гитхабе занимаются и всякие маргинальные RHEL и Ubuntu его развивают ))
По сути дела в применении к WSL это будет больше похоже выполнение команд подобно тому как гипервизоры позволяют делать по ssh после запуска системы или через свои API. Только почему-то вместо ssh используется файл внутри гостевой машины. Возможно здесь идея в том, что эти команды выполняются еще до старта сервисов, включая демон ssh? Или в том, что ssh поднимать не нужно? Но уход в сторону решений от MS вопросы вызывает. Общая тенденция просто наблюдается — уводить в сторону W от L, чтобы подсевших на WSL не тянуло базовые навыки по L получать, а то пойдут девелоперс неправильной дорогой ))
creker
Идея тут в том, что этот конфиг читает init процесс, который в WSL является pid 1. Systemd у них нет, автозапуска и init системы полноценной тоже. До этого были костыли с bashrc. Теперь будет лучше. И никакой EEE тут не при чем.
Oxyd
В WSL нет
systemd? Серьёзно?OCTAGRAM
Наверное, мог бы быть, но кто его запустит? bashrc?
Oxyd
Внезапно linux kernel.
Alex_ME
А разве это не виртуальная машина с модифицированной Ubuntu или иным дистрибутивом?
OCTAGRAM
Я работал только с WSL1 и активно пользовался его возможностью запускать процессы между подсистемами. Скажем, я могу встроить dcclinux.exe в makefile, стартующий из WSL. И линукс32 трансляторы, стартующие из Windows IDE. Или транслятор в Си, который после того, как в Си перевёл, вызывает собственно транслятор Си и компоновщики, и эти трое исполняются в разных подсистемах. Было неприятно, что надо было с командной строки прописывать поддержку linux32 после каждой перезагрузки. WSL2 не видел, можно ли там так же туда-сюда гулять, не знаю.
Oxyd
Короче. WSL2, как по мне, это в своём роде шаг назад, по сравнению с WSL1 Первая более интегрирована, с остальной системой, чем вторая.
OCTAGRAM
Причём, вроде бы WSL не столько ради линукса затевалась, сколько ради Андроида. Не получилось, выкатили чисто Линукс. И в WSL 2 Андроида всё так же нет.
vikarti
На wsl2 запуск .exe вполне себе работает. И например explorer.exe. откроет текущий каталог в винде, если это /mnt/ — все как обычно откроется а если нет — откроется по «сети» что-то вроде \\wsl$\Ubuntu\home\vikarti
Из windows — можно просто вызвать bash.exe
А то что менее интегированно — ну так это и не скрывают ж. WSL1 такая же подсистема Windows как собственно и Win32 (реально правда многое из win32 — живет в ядре еще с NT4). Из-за этого и совместимость например с файрволлами и проблемы (с тем например что NT Native API все же больше рассчитан на те принципы по которым Win32 работает)
А WSL2 — хитрая виртуалка.
Lsh
Чем же она хитрее обычных и привычных? Ну да, дистрибутивы там немного обрезанные и стартуют без полноценного systemd/sysvinit. А ещё что?
Oxyd
То как она взаимодействует с виндой. Кстати, обратите внимание, init там есть. Собственно ничего не мешает ему там быть. И почему сейчас там нет systemd вызывает очень большие вопросы. Это из презентации MS, когда вторую WSL ЕМНИП только выкатили… ну или собирались выкатить.
vikarti
Интеграция.
Нет, можно конечно настроить и динамическую память и файловые шары по сети прокинуть в оба конца и проброс команд реализовать но тут все — работает. И у всех — одинаково. И (насколько я понимаю) для доступа к файлам не используется TCP/IP а 9P используется.
Oxyd
Да, именно 9P и используется. Причём не только для доступа к файлам, в обе стороны, но и для запуска bash / cmd.exe
Oxyd
WSL2 да, это виртуалка. И почему там нет systemd для меня загадка, великая есть. А вот WSL1, это что-то похожее на вайн или даже точнее на слой совместимости с линукс во FreeBSD.
creker
У меня в башрц запуск докера засунут, из-за чего при запуске у меня просят пароль, т.к. там sudo. Судя по всему, эту штука будет команды от рута запускать. Вот и вполне причина, зачем это делали. WSL2 же не имеет полноценной init системы до сих пор.
BrennendeHerz
Вероятно в данный момент времени Вы решаете проблему с запуском либо через NOPASSWD в sudoers, что можно сделать в том числе для отдельных команд и автоматизировать парой команд, либо через echo «password» | sudo -S. И то и другое является вполне стандартным решением. Как и поддержка либо SysV либо systemd. Поддержку кстати реализуют сторонние разработчики не имея таких ресурсов как у MS — решения есть на GitHub. Но здесь выбрано нестандартное решение, которое с учетом возможностей Microsoft потенциально может породить новый конкурирующий стандарт.
Выше Вы написали что EEE здесь ни при чем. Но EEE — это ведь необязательно заговор менеджеров )) Та же ситуация может быть результатом игнорирования существующих стандартов простыми разработчиками, особенно если эти разработчики из большой компании с большими маркетинговыми возможностями. Менеджменту это может быть просто не важно или просто желательно (молчаливое одобрение), а разработчики работают по привычной схеме «все должно быть написано по своему, как всегда было в Microsoft».
В мире Linux уже безумная фрагментация и только недавно наметились шаги к стандартизации решения подобных задач. Почему загнулся Upstart? Потому что был проигнорирован разработчиками. Здесь же целью WSL являются именно разработчики. WSL создавался во многом для входа на рынок ML и еще чтобы разработчики продолжали на Windows сидеть и не смотрели наLево )) Если разработчики будут писать утилиты в стиле «инициализации» WSL больше шансов, что они не напишут в стиле Systemd как сделали бы работая в виртуалке или непосредственно в современных дистрибутивах Linux. И так кирпичик за кирпичиком и рождаются последние две буквы в EEE. Хотя намерения вероятно благие, как и большинство намерений Microsoft ))
creker
Я не знаю, почему они не используют systemd, но подозреваю, что не от вредности и мифических ЕЕЕ. Все таки WSL интегрирован с виндой и мало ли что этот init процесс при запуске делает. Поднимает шары, пайпы какие-нибудь устанавливает с виндой, память шарит, еще чего. То, что требует специфичного для WSL кода.
Может объективно он нужен, а может это просто рудимент и от нехватки времени. WSL1 очевидно мог требовать свой init. WSL2 вполне мог бы и systemd использовать, но чтобы не ломать то, что уже работало, оставили свой init.
Это было бы справедливо, будь это обычная сборка линукса. Здесь же нет «как всегда было». Такой вещи раньше никогда не было банально.
Oxyd
Линукс, в случае WSL2, находится в почти полностью изолированной песочнице — в виртуалке. И никаким каком не может повредить хостовой винде. Вот полная архитектура взаимодействия из презентации Microsoft.
devopg
это старая диаграмма тут не учтены фишка для реалтайма без хоста. Например запуск докера для виндовс напрямую через wsl2 режим.
Oxyd
А через 9P, так как это сделано для cmd.exe, думаете невозможно?
BrennendeHerz
Да, в этом наверное есть смысл. Просто не хотелось бы чтобы они поспособствовали еще большей фрагментации. Точнее помешали текущему процессу стандартизации, когда появилась устоявшаяся система инициализации и уже поверх нее решения для запуска контейнеров. Текущие тенденции помогают и новым пользователям в Linux входить, и поддержку систем проще осуществлять. А у Microsoft достаточно ресурсов, внимания разработчиков и авторитета, чтобы вбить клин.
Ведь так можно продолжить мысль и для запуска периодических задач внутри WSL тоже изобрести что-то новое вместо cron или таймеров Systemd. Такое, что переплетено на уровне разделяемой памяти с планировщиком задач Windows и облаками Azure заодно )) Ведь раньше не было такого уникального решения как периодические задачи в WSL ))
Хотелось бы наоборот — чтобы разработчики написав решение для одной системы могли тиражировать его на родственные системы. Нельзя сказать что и на Linux за пределами скриптов bash/sh и Systemd это сейчас наблюдается, но со стороны пользователя вижу что есть движение в этом направлении и это радует.
Меня например как одновременно и пользователя Windows и Linux от использования WSL отталкивает именно эта перспектива собственных стандартов Microsoft. Когда то решил посмотреть что будет происходить в течение года-двух. Не начнет ли MS движение в сторону Extend своего несовместимого разлива. Если бы движение пошло в сторону стандартизации, то это была бы веская причина снизить использование виртуалок в пользу WSL, там где приходится работать с Windows. Но пока что паузу продляю ))
При необходимости всего того же самого позволяет добиться headless режим виртуалок с примонтированной с Windows-хоста файловой системой. И затем переносить решения на Linux-системы куда проще.
FTOH
Не знаю на счёт первой версии, но так как WSL 2 — это виртуальная машина, то её запуск может быть из замороженного состояния, никакие запускаторы не сработают.