Странности в развитии PowerShell Remoting

Речь о PowerShell 6/7 в первую очередь. Традиционно для удаленного доступа Windows PowerShell использовал технологию WS-Management, или WSMan. Когда вышел PowerShell 6 там появилась возможность использовать SSH в качестве альтернативы, но при этом была добавлена ограниченная поддержка WSMan на Linux и MacOS. Внезапно эта поддержка прекратилась. При этом никаких ясных заявлений от MSFT не было. По всей видимости произошли внутренние разногласия между различными подразделениями огромной компании по поводу приоритетов и направлений развития. Скорее всего они сами надеялись как-то разрулить ситуацию со временем, но за несколько лет ситуация только ухудшилась, превратилась в абсурдную, когда новое ещё до конца не создано (переход экосистемы на SSH), а старое уже не только не развивается, но и не работает (WSMan на Unix).

Да, WSMan на Unix толком не работает. Причина в том, что реализация жестко привязана к SSL 1.0.0, которая в большинстве систем не устанавливается как устаревшая и небезопасная.

Цепочка зависимостей выглядит так WSMan -> PSRPClient -> libmi — OMI. Проблема в стыке libmi и OMI. В OMI есть проблемы с SSL. Команда MSFT OMI отказывается вносить изменения, так как это deprecated проект и это не соответствует их приоритетам. В свою очередь команда MSFT PowerShell не может исправить libmi. Эта библиотека также объявлена deprecated.

В репозитории PowerShell существует множество вопросов по этому поводу. Только в последнее время команда MSFT PowerShell стала говорить о том, что WSMan не поддерживается на Unix, и все должны использовать SSH транспорт.

При этом существуют обходные пути, как установить более новую версию SSH и создать линки так, чтобы WSMan заработал на Unix. Он еще долго будет нужен, т.к. существует огромная экосистема, где он используется. Включая Облачные сервисы. Даже новый модуль Exchange Online V2 использует WSMan. Пользователи PowerShell на Unix могли бы остаться в стороне, если бы не альтернативный проект поддержки.

Если у вас есть потребность в WSMan на Unix посмотрите эту статью и поддержите проект.

А что MSFT? Протокол SOAP объявлен deprecated. Почему я упомянул его? WSMan на Windows реализован поверх SOAP (MMI.dll).

Таким образом не только Unix, но и Windows системы идут по пути миграции PowerShell Remoting на SSH.

Команда MSFT PowerShell только что начала предпринимать реальные шаги по изживанию Management Instrumentation (libmi.dll/mmi.dll). Сейчас она ведет соответствующие работы над DSC. Конечно это будет постепенный процесс. Посмотрите — это интересно. Хотя похоже на проклятье — жить в эпоху перемен :-)

Реклама

Side-By-Side и другие особенности установки PowerShell Core

С выпуском PowerShell Core 6.1.0 сложилась следующая модель установки.

Пакеты

Поддерживаются следующие пакеты:
1. MSI (Windows)
2. deb (Debian, Ubuntu)
3. rpm (Redhat)
4. pkg (MacOs)

Также есть архивные файлы Zip (tar.gz).

Установка Side-By-Side

Side-By-Side означает, что вы можете установить на одной системе несколько версий PowerShell Core.

Обычно основная версия ставится из пакета в стандартную директорию (для Windows это C:\Program Files\PowerShell\6), а остальные вы можете распаковать из zip архива в любое место.

На Windows это также обеспечивает сосуществование с Windows PowerShell.

Почему пакет устанавливает PowerShell Core в одну и ту же стандартную директорию? Это сделано специально, чтобы обеспечить обновление версий с помощью менеджеров пакетов. На Windows это также обеспечивает получение обновлений через Windows Update и WSUS (это работает для GA версий, но не для Preview/RC). По этой же причине предустановленные модули ставятся в директорию без номера версии в названии. Обновляться они будут пакетом новой версии или через Windows Update/ WSUS.

Для пакетов надо помнить, что есть две независимые ветки — GA и Preview/RC. Имена пакетов соответственно powershell и powershell-preview (для RC также powershell-preview).
Для каждой ветки пакеты устанавливаются и обновляются независимо друг от друга. Это означает, что msi пакет (это верно и других видов пакетов) для версии 6.1.0 заменит версию 6.0.x, 6.1.1 заменит 6.1.0 и т.д., но оставит без изменения любую установленную Preview/RC версию. Аналогично пакет msi для версии 6.2.x-preview1 заменит любую младшую предварительную версию, а например 6.2.0-rc1 заменит 6.2.0-preview1.

Менеджеры пакетов.

Вы можете использовать стандартные apt-get, yum, zypper, dnf. Особенность в том, что пакеты лежат только в репозитории Microsft (https://packages.microsoft.com), и его нужно предварительно зарегистрировать на системе. В документации описано, как это сделать.
В дальнейшем планируется размещение пакетов в стандартных репозиториях и, возможно, в Windows Store.

Есть также Windows Docker Files and Images https://hub.docker.com/r/microsoft/windowsservercore/ и https://hub.docker.com/r/microsoft/nanoserver/

Недавно появился Snapcraft https://snapcraft.io/powershell и https://snapcraft.io/powershell-preview

Полезные ссылки:

1. https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell?view=powershell-6
2. https://github.com/PowerShell/PowerShell/blob/master/README.md
3. https://github.com/PowerShell/PowerShell/releases/
4. https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6#snap-package

PowerShell Core 6.1.0 RC1

Приближается дата выпуска PowerShell Core 6.1.0. Предварительная дата — 13 сентября 2018 года.
А пока выпушена версия RC1 — самое время попробовать установить и сообщить о проблемах на https://github.com/PowerShell/PowerShell/
Ничего нового в RTM по сравнению с RC1 не добавится — как что стартуйте!

Загрузка https://github.com/PowerShell/PowerShell/releases/tag/v6.1.0-rc.1

1. Вы можете устанавливать предварительные версии одновременно с релизами. Это разные пакеты и они ставятся независимо. На Windows даже иконка предварительной версии будет иной. Предварительные версии имеют суффикс «-preview».
2. Добавлены пакеты в формате Snap.
3. Используется .Net Core 2.1.2 (2.1.302)
Были обнаружены некоторые проблемы производительности. Кое-что уже исправлено.
1. Одна проблема связана с OrderedDictionary класс. https://github.com/dotnet/corefx/issues/31972
Суть в том, что невозможно проверить состояние любого свойства, например, что объект пуст и не имеет добавленных элементов, без выделения памяти под внутренние структуры. PowerShell Core использует OrderedDictionary в базовом классе PSObject В результате PowerShell Core потреблял огромное количество ненужной памяти. Исправлено в [#7435](https://github.com/PowerShell/PowerShell/pull/7435).
2. Еще одна проблема с потреблением памяти и производительностью исправлена в [#7413](https://github.com/PowerShell/PowerShell/pull/7413)
В результате командлет Import-Csv стал работать быстрее до 10 раз (!) и потреблять меньше памяти.
3. Командлеты Convertfrom-Json и Invoke-RestMethod стали до 7 раз быстрее делать преобразование Json в PSObject
[#7482](https://github.com/PowerShell/PowerShell/pull/7482)
4. Значительно ускорена работа Group-Object cmdlet [#7410](https://github.com/PowerShell/PowerShell/pull/7410)
5. Было сделано еще несколько улучшений произвидительности в движке. Работа в этом направлении продолжается. Смотрите [#7112](https://github.com/PowerShell/PowerShell/issues/7112)

Что еще нового?
1. Появятся командлеты для рендеринга Markdown [6926](https://github.com/PowerShell/PowerShell/pull/6926)
Это направление работы связано с добавлением прямой поддержки файлов помощи в формате Markdown. Сейчас документация готовится в формате Markdown (https://github.com/PowerShell/PowerShell-Docs), но конвертится в MAML, чтобы мы могли использовать её в Get-Help.
2. Был удален VisualBasic из Add-Type [#7284](https://github.com/PowerShell/PowerShell/pull/7284)
Гланая мотивация — уменьшение размера дистрибутива на 5 Мб. С другой стороны мы имеем запрос на добавление поддержки F#. Посмотрим что скажут пользователи, т.е. мы с вами.
3. Была добавлена поддержка экспериментальных фичей [#7242](https://github.com/PowerShell/PowerShell/pull/7242)
Теперь в предварительных версиях возможно появление опциональных/несовместимых фичей, которые могут быть включены/выключены в конфиге для выборочного тестирования.
4. Добавлена поддержка истории в Set-Location, «cd -» — вывод предыдущей команды. [#5051](https://github.com/PowerShell/PowerShell/pull/5051)
5. Вернули акселераторы ADSI и WMI [#7085](https://github.com/PowerShell/PowerShell/pull/7085)
Собственно благодаря добавлению Windows Compatibility Pack 2.0.0 [#6958](https://github.com/PowerShell/PowerShell/pull/6958) — он оказался нужен в ядре для поддержки совместимости Windows PowerShell модулей.
6. Invoke-Item теперь работает на всех платформах [7198](https://github.com/PowerShell/PowerShell/pull/7198)
Т.е. теперь на Linux и MacOs должно работать Invoke-Item(«https://www.microsoft.com/»)
7. Теперь работает Basic Auth over HTTPS [#6890](https://github.com/PowerShell/PowerShell/pull/6890)
8. Добавлены новые командлеты для распараллеливания работы — ThreadJob модуль [#7169](https://github.com/PowerShell/PowerShell/pull/7169)
Принципиально ничего нового: используется стандартные возможности ядра, которые достаточно медленные, но стало очень удобно — попробуйте!
9. Measure-Command поддерживает скрипт-блоки [#6934](https://github.com/PowerShell/PowerShell/pull/6934)
Пример, @{prop = 3} | measure-object {$_.prop}

Там ещё много чего нового — смотрите Release Notes.

Как обычно я продолжил чистку кода. Удалено много p/invoke вызовов в FileSystem провайдере. Выполнено переформатирование Utility и Management модулей. Усправлена куча проблем в стилях и формтировании, которые репортятся в CodeFactor (StyleCop). Это работа идет медленно, так как она непроизводительная и не создает нового. Хотя приводит код в порядок и облегчает работу другим. Очень надеюсь, что удастся довести эту работу до конца в ближайшие месяцы.

Осталось напомнить, что идет процесс портирования модулей Windows. Их уже можно потестировать в последних сборках Windows 10 Preview. Читайте https://blogs.msdn.microsoft.com/powershell/2018/07/31/increased-windows-modules-coverage-with-powershell-core-6-1/ , а также попробуйте [Windows PowerShell Compatibility module](https://github.com/PowerShell/WindowsCompatibility)
Если какой-то Windows модуль не работает в PowerShell Core, то сообщить об этом можно сюда [PowerShellModuleCoverage](https://github.com/PowerShell/PowerShellModuleCoverage).

Также пишите в [основной репозиторий](https://github.com/PowerShell/PowerShell), если вы обнаружили проблемы в PowerShell Core (ошибки или плохая производительность) или имеете предложения по развитию.