Вышел PowerShell 7.2 Preview3

Скачать можно тут PowerShell/PowerShell: PowerShell for every system! (github.com). Список измнений Release v7.2.0-preview.3 Release of PowerShell · PowerShell/PowerShell (github.com).

Самое важное, что теперь PowerShell базируется не на .Net 5.0, а уже на .Net 6.0 (6.0.0-preview.1). Как известно эти версии будут LTS (поддержка после выхода 3 года минимум).

Насколько колосальный объем работ запланирован для .Net 6.0 вы можете посмотреть на сайте Themes of .NET (там есть фильтры для убодной навигации). К сожалению планы каманды MSFT PowerShell остаются туманными. Они всё ещё думают о создании рабочих групп, которые бы более активно развивали PowerShell — смотрите PowerShell Working Groups и присоединяйтесь.

Если вы планируете новые проекты на .Net или PowerShell, то самое время заняться тестированием, пока есть несколько месяцев на оперативное устранение багов и добавление новых фич.

Реклама

PowerShell 7.1 Preview7

Вышла последняя предварительная версия PowerShell 7.1 Preview7. Вскоре будет RC и сам релиз. Так что пробуйте, тестируйте и поторопитесь сообщить о проблемах, если они обнаружатся.

Что нового?

1. Команда MSFT начала проект по реструктуризации SMA.dll на подсистемы. Это позволит создавать дистрибутивы с минимальным набором функций.
2. Тип Utf7 более не поддерживается. Вы получите предупреждение, если скрипт использует этот тип. Причина простая — в .Net 5.0 этот тип объявлен как deprecated. В будущем он будет удален вообще. Собственно ничего страшного, так как Uft7 никогда не используется.
3. В Web командлетах теперь можно указать использование Tls13. Так как командлеты используют возможности операционной системы, а поддержка TLS 1.3 во всех ОС сейчас ограниченная, то не стоит ожидать, что это будет работать прямой сейчас.

Стоит отметить, что Preview7 основано на .Net 5.0 Preview8, где удалена встроенная поддержка WinRT. Теперь существует отдельный проект поддержки WinRT API в C#. Это уже породило проблемы с некоторыми модулями. Кое-что уже исправлено в PowerShell, кое-что в .Net. Надеюсь, к моменту выхода .Net 5.0 обратная совместимость будет на высоте.

Странности в развитии 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. Конечно это будет постепенный процесс. Посмотрите — это интересно. Хотя похоже на проклятье — жить в эпоху перемен :-)