<p>خطة PowerShell 6.0</p>

يمكنني كتابة وحدات ثنائية تستهدف Windows PowerShell و PowerShell Core

يعمل هذا بالفعل - استهداف .NET Standard 1.6. الجزء الصعب هو تحميل التجميعات الخاصة بنظام التشغيل - هل نحتاج /lib/{OS}/*.dll تحميل تلقائي لـ RequiredAssemblies ؟

عميل WinRM مع Kerberos ومصادقة شهادة العميل ، من Linux و Mac OS X هو شيء أعتبره ضروريًا. نحن نبحث عن القدرة على نشر كود PowerShell عن بعد لأنظمة Windows من أنظمة غير Windows ، عبر حاويات Docker.

هل سيغطي NTLM هذا السيناريو بطريقة آمنة؟ لست واضحًا بشأن إيجابيات / سلبيات NTLM مقابل Kerberos ، ولكن في كلتا الحالتين ، أعتقد أن مصادقة شهادة العميل ستكون موضوعًا منفصلاً.

LMK

في صحتك،
تريفور سوليفان

أتفق تمامًا مع ما يقوله @ pcgeek86 ، استهداف WinRM من Linux هو سيناريو غير ودي تمامًا و NTLM غير ممكن مع العديد من العملاء.
توجد وحدة YAML مجتمعية ولكن هل من الممكن دمج أوامر YAML cmdlets بنفس الطرق مثل ConvertTo / ConvertFrom- * الموجود بالفعل لـ CSV / XML / JSON؟

@ pcgeek86fabiendibot حسن الاستماع. ثم أطرح السؤال التالي: هل أنت بخير للانضمام إلى AD في صناديق Linux (أو Mac)؟ أو هل تتوقع أن تتعامل مع الشهادات يدويًا؟

والأفضل من ذلك ، ما هو مانع استخدام PSRP عبر SSH من Mac / Linux إلى Windows؟ هل لديك نوع من حل الشهادات أبسط من أزواج المفاتيح العامة / الخاصة؟

لدينا بالفعل نظام منفصل لنشر الشهادات ، لذا يتم الاهتمام بهذا الأمر.

يجب أن أرى كيف يعمل PowerShell Remote عبر SSH قبل أن أتمكن من التعليق أكثر على هذا السيناريو. اعتبارًا من هذه النقطة ، لست على علم بأي تنفيذ وظيفي لها. يجب أن يعمل الحل على أنظمة تشغيل Windows ذات المستوى الأدنى.

أود أيضًا إضافة بعض التركيز حول بناء الوحدات الثنائية المحيطة بـ .NET Standard. يسعدني أن أرى أنه تمت إضافة هذا هناك. ربما يجب أن نضيف شيئًا ما حول تحميل تجميعات .NET في PowerShell ، والاتصال بها؟ أعرف أن الكثير قد تغير في .NET Core ، فيما يتعلق بـ AppDomains والانعكاس وما إلى ذلك ... أعتقد أن هذا المجال يمكن أن يستحوذ على بعض الاهتمام.

أوافق على كل من Jaykul و @ pcgeek86
سيكون نوعًا من مجلد بوويرشيل أو مجلد مكتبة جيدًا ...
سيساعدنا هذا في إدارة التجميعات التي تستخدمها / تثبتها وحداتنا المقابلة ...
أعتقد أن العقدة / بيثون لديها هذا المفهوم أيضًا ...

joeyaiello نقوم بتكوين kerberos باستخدام مربعات Linux الخاصة بنا لبعض السيناريوهات (اتصالات SQL Server في الغالب). بالنسبة لي ، Win32-SSH ليس جاهزًا للإنتاج ، لذا لم أنظر إليه في الوقت الحالي.

هل يعمل .NET Framework 4.6.1 على نظام التشغيل Windows 7؟

نعم
https://www.microsoft.com/en-us/download/details.aspx؟id=49981&e6b34bbe-475b-1abd-2c51-b5034bcdd6d2= صحيح

أنظمة التشغيل المدعومة:
• Windows 7 SP1 (x86 و x64)
• Windows 8 (x86 و x64)
• Windows 8.1 (x86 و x64)
• نظام التشغيل Windows 10
• Windows Server 2008 R2 SP1 (x64)
• Windows Server 2012 (x64)
• Windows Server 2012 R2 (x64)

ماذا عن ميزات الفصل؟
تنفيذ الواجهة لا يزال مفقودًا.

كانت هذه خارطة الطريق في نهاية عام 2014:

يجب أن يكون PowerShell صلبًا عند 6.0 ( https://en.wikipedia.org/wiki/SOLID_ (object-oriented_design))

مجال اللغة بحاجة إلى مزيد من الاهتمام ، وخاصة هذه القضايا:
https://github.com/PowerShell/PowerShell/issues/2223
https://github.com/PowerShell/PowerShell/issues/2642
https://github.com/PowerShell/PowerShell/issues/2225
https://github.com/PowerShell/PowerShell/issues/2217

شكرا لك !

ربما يكون من المفيد رسم خريطة الطريق هذه باستخدام مشروع (مشاريع) GitHub.

سيكون وجود واجهات أمرًا رائعًا!

iSazonov @ نظرنا في استخدام GitHub Projects ، لكننا قررنا (في الوقت الحالي) أنه سيكون من الأسهل تتبع التقدم كمربعات اختيار في مشكلة

في هذا الوقت ، يتمثل تفكيرنا في الاستثمار في تجربة المطور (تحسينات الفئة بالإضافة إلى أشياء مثل الارتباطات باللغات الأخرى ، وتأليف أوامر cmdlets بلغات أخرى ، وما إلى ذلك ...) لنشر 6.0 بدلاً من الاستمرار في إضافة ميزات إلى الإصدار 6.0.

حسنًا ، الآن تجربة المطور ليست جيدة! ISE هي مزحة بدون ISESteroids ، و VS CODE هي عربات التي تجرها الدواب مثل الجحيم. هذا يتركنا مع PowerShell Studio كخيار وحيد ، لكن التحسس لا يوجد ما يقرب من لا شيء.
لذلك ، ربما يكون الشيء الصحيح الذي يجب فعله هو الاستثمار في تطوير IDE جيد ، مع دعم ميزات PS 5-6.

@ g8tguy خطتنا هي الاستثمار في VS Code على وجه التحديد عبر PowerShellEditorServices لأنها مفتوحة المصدر ومتعددة المنصات. إذا كانت هناك أية مشكلات أو إمكانات محددة تمنعك من استخدام VS Code ، فيرجى فتح المشكلات في هذا الريبو.

@ g8tguy إذا كان VS Code هو "buggy as hell" ،

https://github.com/PowerShell/vscode-powershell

آخر مرة حاولت فيها استخدام VS Code ، كانت قبل نصف عام.
وكان language server ينهار باستمرار عندما تقوم بذلك
افتح علامات تبويب من 5 إلى 10 علامات تبويب مخصصة للفصول والتعدادات PS 5 تشير إلى بعضها البعض ، لذلك توقف IntelliSense عن العمل ، وكان IDE يتصرف بطريقة غريبة. كنت أرغب في النقل ، PowerShellEditorServices إلى IDEA ، لكن بدا أن الأمر يتطلب الكثير من العمل لشخص واحد ، لذلك بقيت مع PS Studio . ولكن نظرًا لأنني أشاهد سجل التغيير PowerShellEditorServices الآن ، يبدو بالتأكيد أنه تم حل الكثير من الأخطاء ، وأصبح VS Cod e أكثر نضجًا واستقرارًا ، لذلك سأعطيها فرصة أخرى. وشكراً لكم يا رفاق على المنتج ، أنتم تقومون بعمل رائع ، من خلال الدعوة إلى PowerShell! 👍: 1st_place_medal:

@ g8tguy نعم ، لقد تغير الكثير منذ ذلك الحين. إذا كنت لا تزال تواجه مشكلات في تطوير البرامج النصية مع الفصول في VS Code ، فسيسعدني محاولة إصلاحها. من المؤكد أن جعل خدمات المحررين تعمل في قانون تعليم الأفراد المعاقين (IDEA) أمر ممكن التحقيق ، إذا حاولت مرة أخرى ، فسأكون سعيدًا بإعطائك بعض المؤشرات.

أستطيع أن أؤكد - أحدث إصدارات PS Code جيدة! حدث ذلك في الشهرين الماضيين. شكرا جزيلا لمطوري PS Code!

ماذا عن دعم المسارات الطويلة / أسماء الملفات؟ نظرًا لأن .NET Core يدعمهم الآن ، أعلم أن هناك أملًا في وصول هذا إلى PowerShell في النهاية - https://github.com/dotnet/corefx/issues/645. أنا متأكد من أنه سيكون هناك الكثير من الابتهاج في عالم الأعمال إذا / عندما يحدث هذا.

يدعمitpaul PowerShell Core بالفعل المسارات الطويلة افتراضيًا :)

@ SteveL-MSFT الحلو! شكرا للمشاركة. هل لديك أي فكرة عن متى يمكن أن يصل هذا إلى PS غير الأساسي؟

itpaul PowerShell v5.1 على Win10 يدعمه بالفعل ، ولكن ليس افتراضيًا (نظرًا لأن نظام التشغيل لا يدعمه افتراضيًا ، إذا غير Win10 هذا الإعداد ، فسيعمل تلقائيًا). يمكنك تمكينه باتباع هذا: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

@ SteveL-MSFT رائع! شكرا مرة أخرى لمساعدتكم. سأبدأ في البحث فيه. بعد ردك الأول ، اكتشفت أنه يمكنك تشغيل PowerShell Core بشكل قابل للنقل ، وهو أمر رائع أيضًا! يبدو أنني سأكون قادرًا على تجنب تطبيق Alpha FS في بيئتنا الآن.

itpaul ، أحد القرارات التي أردنا اتباعها مع CoreCLR إلى جانب دعم النظام الأساسي هو أنه يدعم بطبيعته جنبًا إلى جنب ، لذلك يمكنك "تثبيت" (وهو في الحقيقة نسخة xcopy) من PSCore6.0 وسيتم تشغيله لحسن الحظ بجانب Windows PowerShell v5.x دون التأثير على البرامج النصية / التطبيقات الحالية التي تعتمد على v5.x

@ SteveL-MSFT يمكن للخنازير أن تطير حقًا في عالم Nadella Microsoft. لقد حان عيد الميلاد بالتأكيد في وقت مبكر من هذا العام.

1. يبدو أن لدينا مشاكل مع conhost المشار إليها في بعض القضايا. هذا ليس فقط شريط التقدم.
2. للحصول على أداء شريط التقدم فتح # 2822.
3. سيكون من الجيد أن يكون لديك تحليل كود للأداء (الأمان ، الجودة ، التنسيق).
4. يمكننا الحصول على تعليقات رائعة من Windows 10 Preview إذا تم دمجها في هذا البرنامج. (في WSL أيضًا)
5. لم تذكر الخطة WSL (نظام Windows الفرعي لنظام Linux). يمكن أن يكون هذا منصة رائعة لاختبار وتعزيز Powershell Core. الآن لدينا مشكلات مع WSL.

عمل عظيم! هل تخطط لدعم Docker أيضًا (نخطط لشحن وحدات PowerShell Core)؟ هل يمكنك أيضًا تحميل الملاحظات أو تسجيل RFC الثاني من فضلك كما فعلت للأولى؟

HemantMahawar هل التسجيل جاهز

iSazonov : هل يمكن أن تربطني ببعض هذه القضايا المخادعة؟ يبدو الاثنان اللذان لديّهما أعلاه ، رقم 2138 و 1625 كمشاكل تقدم بالنسبة لي. (في رأيي ، حتى لو كانت بسبب مضيفي وحدة التحكم الأساسيين ، فنحن لدينا القليل جدًا من التحكم في المضيفين الأساسيين عبر الأنظمة الأساسية التي تؤدي إلى تقدم الوظائف هو ما يحتاج إلى إعادة هيكلة أو حتى تقييد). تمت أيضًا إضافة # 2822. 👍

أنا أتفق معك في تحليل الكود. ربما يستطيعJamesWTruher أو @ SteveL-MSFT طرح مشكلة لأضيفها هنا؟

أسمعك على دعم WSL ، لكنني أعتقد أننا نعطي الأولوية لتوزيعات Linux و macOS في الوقت الحالي بسبب عدم وجود سيناريوهات مقنعة لاستخدام PowerShell من WSL. علاوة على ذلك ، أعتقد أنهم في النهاية (هذا فقط من المعرفة العامة مع عدم وجود معرفة داخلية بالجداول الزمنية أو كيفية عمل الوظيفة) يخططون للتشغيل البيني مع عمليات Windows ، وفي هذه الحالة لن تحتاج إلى تشغيل "PowerShell على Linux" من الداخل WSL ولكن فقط "PowerShell Core 6.0 على Windows".

إذا كنت لا توافق على بياني حول "سيناريوهات مقنعة" ، فيرجى إبلاغي بذلك. أحب أن أكون مخطئًا في هذه الأنواع من الأشياء :)

@ ChristophB125 : هل يمكنك توضيح ما تعنيه بعبارة "دعم Docker"؟ لدينا حاليًا Docker مدرج كمنصة ، وننشر عددًا كبيرًا من الصور على Docker Hub (بما في ذلك الصور الليلية ، على الرغم من أنه يبدو أننا نسينا نشر alpha.15 ، فأنا أتابع).

إذا كنت تقصد ، هل لدينا وحدة PowerShell لإدارة Docker ، فقد قام فريق Hyper-V

بدافع الفضول من "نحن"؟ أود التحدث أكثر عن كيفية استخدامك PowerShell 6.0 :)

أيضا ، تلقيت بعض الأخبار السيئة. يبدو أنه لا يتم تحديد مربعات الاختيار تلقائيًا عند إغلاق المشكلات (على الأقل ليس في المستوى L3). لقد أغلقت # 2245 ولم يتم فحصها بنفسها (وهذا هو الخط الذي يكون فيه السطر بأكمله هو رقم الإصدار فقط ....) 👎

joeyaiello إرسال طلب ميزة إلى GitHub 😸

@ ChristophB125 تسجيل مكالمة المجتمع الثانية متاح الآن على PowerShell & DSC Team Channel / cc: @ SteveL-MSFT & joeyaiello

تضمين التغريدة

هل يمكن أن تربطني ببعض من هذه القضايا الخادعة؟

أوه ، من الصعب القيام بذلك ولكن يبدو أنني جمعت بشكل رئيسي معًا (أعتقد أن هناك تعليقات مفيدة أخرى فاتتنا.)

إذا كنت لا توافق على بياني حول "سيناريوهات مقنعة" ، فيرجى إبلاغي بذلك. أحب أن أكون مخطئًا في هذه الأنواع من الأشياء :)

أوافق ولكن لا تزال هناك "سيناريوهات مقنعة".
تعلن Microsoft عن WSL كميزة مطور "قتل":

تم تصميم وبناء WSL بواسطة فريق Windows Kernel وتم تسليمه بالشراكة مع Canonical ، لمساعدة مطوري Windows 10 على استخدام النظام البيئي والأدوات الغنية لمطوري Linux جنبًا إلى جنب مع الأدوات الرائعة التي يستخدمونها بالفعل في Windows ، دون الحاجة إلى التمهيد في نظام تشغيل آخر أو VM. هذه بالتأكيد ميزة Windows 10 "للمطورين ، للمطورين" ، وهي مصممة خصيصًا لإزالة القليل من الاحتكاك من سير العمل اليومي للمطورين.

كمستخدم لنظام Windows ، حاولت استخدام Powershell Core ضمن WSL وفشلت 😕
انا اريد:

1. تطوير واختبار البرامج النصية بوويرشيل
2. تطوير واختبار وحدات بوويرشيل الثنائية
3. بناء Powershell الأساسية من المصادر
4. تطوير وتصحيح ميزات Powershell Core

أعتقد أن هذا يتوافق تمامًا مع إعلان Microsoft WSL.
سيكون من الرائع أن تطلب من فريق Kernel مساعدتنا في تشغيلها.

joeyaiello شكرا لك على الإجابة. نعم ، صور عامل إرساء PowerShell هي ما كنت أبحث عنه. سيكون هذا رائعًا لأنه بعد ذلك يمكن شحن PowerShell كجزء من النشر (لدينا خوف من أن عملائنا قلقون بشأن وجود IP الخاص بـ Microsoft على أجهزة Linux الخاصة بهم ، وبالتالي يمكن أن يساعدنا عامل الإرساء في إخفاء ذلك على الأقل في وقت التثبيت). بالمناسبة ، "نحن" نشير بشكل فضفاض إلى الفريق في شركتي الذي أعمل فيه ، وهو أمر لا يمكنني الكشف عنه هنا. على الرغم من أننا شركاء Microsoft Gold ، فإن المعلومات الواردة من فريق التطوير مباشرة تعتبر ذات قيمة كبيرة بالنسبة لنا. نظرًا لأن GitHub لم يعد يسمح بالمراسلة الخاصة ، فقد أرسلت إليك طلبًا على LinkedIn بدلاً من ذلك إذا كنت تريد معرفة المزيد حول كيفية استخدامنا لـ PowerShell.

HemantMahawar شكرا على هذا الجهد. إنني أتطلع إلى الانضمام إلى المكالمة التالية!

iSazonov - https://github.com/dotnet/corefx/issues/12452 - لذلك لا تتطلب إصلاحًا في Windows - يمكن لأي شخص الانتقال لإصلاحها (على الرغم من أنه يبدو مثل أنه قد لا يكون إصلاحًا بسيطًا أو أنه قد تم إصلاحه بالفعل.)

وبعد قراءة تحديث للمشكلة ، ربما يأتي الإصلاح من WSL. سوف نرى.

lzybkr شكرا! بناء 15025 لا يزال لديه الخلل. في انتظار البناء القادم.

joeyaiello # 2882 انتقل إلى dotnet-resgen (دعم ترجمة "file.En-Us.resx") و csproj.

iSazonov : أنت تقول إن هذين العنصرين منفصلين ، أليس كذلك؟ الأول هو أحد متطلبات الترجمة (شيء نحتاج إلى مناقشته مع @ PowerShell /owershell-Committee ، لست متأكدًا من كيفية إنجاز ذلك اليوم) ، والأخير هو مطلب للانتقال إلى .NET Core 2.0 (مطلب لدعم NET Standard 2.0).

joeyaiello لدينا حل مخصص لـ res-gen اليوم ، ولكن يجب أن ننتقل إلى طريقة dotnet المدعومة. csproj ينتقل إلى msbuild ، على الرغم من أننا تحدثنا عن ذلك ، لا أرى مشكلة في ذلك.

joeyaiello قال ستيف بوضوح أكبر من I. لدينا بالفعل مشكلة dotnet resgen ويجب علينا فتح مشكلة لـ csproj. ويجب علينا تضمين المشكلات في الخطة ضمن "dotnet 2.0"

تمت إضافة الخير csproj / MSBuild ، لا يزال يتعين علينا التحدث عن resgen وما إذا كان مطلوبًا لـ 6.0.

قد يكون هذا أكثر من Hyper-V من PowerShell (أو أجزاء متساوية من Hyper-V و PowerShell) ، لكنني اعتقدت أنني سأذكرها للتأكد: أعتقد أنه من المهم جدًا أن يكون لديك PowerShell Direct يعمل مع Linux VMs وكذلك Windows VMs .

@ SteveL-MSFT شكرًا لك على التركيز على تجربة المطور كأولوية على إضافة ميزات جديدة. أنا أتفق بشدة مع اتجاهك. ابدأ بإنشاء أساس متين ، وأضف ميزات ما بعد 6.0. / ccjoeyaiello

صورة التطبيق # 2024 في Packaging, Installation, and Deployment

تم إصلاحjoeyaiello # 2138 و # 1625 - لقد وضعت علامات في الخطة.

أعتقد أنه يجب تضمين مصادقة NTLM عبر SSH في الإصدار نفسه كما في WinRM

تم إصلاحjoeyaiello # 3140 - لقد وضعت العلامة في الخطة.

mnaiman أنا في الواقع لست متأكدًا مما إذا كان هذا الطلب منطقيًا من منظور التشفير. أتحداك أن تجرب ما تحاول القيام به والإبلاغ إذا لم ينجح الأمر. نحن ندعم مصادقة كلمة المرور لحسابات المجال وغير المجال في الاتصال عن بُعد المستند إلى SSH (سواء مع PSRP أو بدونه). لست متأكدًا من أنه يمر بأي نوع من طبقات NTLM (لأنني لست متأكدًا من أن SSH يدعم NTLM) ، لكنني لا أعتقد أنه يجب أن يكون مهمًا من منظور وظيفي.

تحرير: ربما يستطيع manojampalam التعليق هنا.

mnaimanjoeyaiello حاليا، فإننا لا نؤيد SSO كما SSH نفسها افتراضيا تفضل لوحة المفاتيح التفاعلية المصادقة التي تعمل على ما يرام مع NTLM و Kerberos ضد إلى Win32 المفتوح. لذلك هذا يختلف عن نظام WinRM عن بُعد ، ولكنه متوافق مع SSH.

joeyaiello @ موفر SSO SSO SteveL-MSFT هو "gssapi-with-mic" (NTLM & Kerberos).

يسمح بتسجيل الدخول الفردي على النوافذ دون كتابة كلمة المرور أو حفظ المفتاح الخاص في مكان ما.
جزء من gssapi موجود بالفعل هنا https://github.com/SimonWilkinson/gss-openssh/
هنا تنفيذ للعميل https://github.com/Lax/net-ssh-kerberos
الخوادم المجانية / التجارية التي تدعم gssapi PowershellServer و Bitwise SSH.

هنا طلب بالفعل في https://github.com/PowerShell/Win32-OpenSSH/issues/96

أنا أقوم بتشغيل بوويرشيل على جهاز ماك.

$psversiontable
Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.13
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

لكن الأمر send-mailmessage لا يعمل بالنسبة لي. تصلني الرسائل أدناه.

send-mailmessage
send-mailmessage : The term 'send-mailmessage' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.
At line:1 char:1
+ send-mailmessage
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (send-mailmessage:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

أواجه مشكلة مع PS 5.0 عند تشغيل استدعاء webrequest ... إذا كانت الاستجابة تأتي مع علامات اقتباس في قيمة utf-8 ، فستفشل. هل سيتم إصلاح ذلك في إصدار GA (https://stackoverflow.com/questions/36275618/why-is-invoke-webrequest-and-invoke-restmethod-failing-and-succeeding-at-the-sam)

pradeepprakhar الآن تم نقل "إرسال بريد إلكتروني".

jsburckhardt الرجاء فتح العدد الجديد مع وصف كامل مشكلتك أو سؤالك.

تم إصلاحjoeyaiello # 929 و # 2227.

تم إجراء بعض التحديثات على القائمة أعلاه حول ما تم إغلاقه / اكتماله وما تم قطعه من 6.0.0 ومن المحتمل أن يهبط في 6.1.0 بدلاً من ذلك

هل هناك خطط لإضافة دعم للتعليق (أو على الأقل تجاهلها) في القائمة مقابل ConvertFrom-Json ؟

erichiller يرجى فتح إصدار جديد ، يمكننا النظر في 6.1.0

ما عليك سوى تضمين دعم Kerberos من فضلك (وربما WinRM أيضًا) ثم ننظر إلى هذا مرة أخرى.

VGerris إذا كنت تقصد بـ WinRM WSMan ، فهذا الدعم مضمن بالفعل. هناك دعم Kerberos تجريبي لـ WSMan على غير Windows ، على الرغم من أنه معقد للغاية في الوقت الحالي لتشغيله.

لا ، أعني Kerberos و WinRM تمامًا كما كتبت. يرجى التركيز على الحصول على هذا الدعم ، حتى لا يضطر المرء إلى الاعتماد على البرامج النصية لجهات خارجية. ما نريده أساسًا هو طريقة لمراقبة جهاز يعمل بنظام Windows بكفاءة عبر حل بدون وكيل ولتمكّن من تشغيل الأوامر عن بُعد بطريقة آمنة. يتضح من الموضوع أن هذه سمة رئيسية في مرتبة الاهتمامات ، أليس كذلك؟ شكرا لك.

VGerris لا أفهم ما WinRM ثم لأن ذلك مدعوم على Windows (ويعمل بالفعل مع PSCore6) و WinRM هي ميزة Windows فقط (Windows Remote Management). WSMan هو البروتوكول الذي يطبقه WinRM.

قد يساعد مخطط البنية التالي من هنا في فهم WinRm-WSMan:

أنا أفهم بشكل أفضل قليلاً سبب رسم هذا المخطط كما هو عندما نظرت إلى المدونة من أجله ، لكنه مضلل قليلاً. الطريقة الأساسية للتفكير في الأمر هي أن WSMan هو البروتوكول / المعيار (اختصار لـ WS-Management) وأن WinRM هو تنفيذ هذا البروتوكول كخدمة في Windows.

VGerris كما قال @ SteveL-MSFT ، ما تتحدث عنه يمكن أن يعمل تقنيًا ، ولكن من الصعب للغاية تكوينه ويتطلب أن يكون جهاز Linux الخاص بك مرتبطًا بمجال AD (وهو أمر يصعب أيضًا إيقافه). لهذه الأسباب ، لا ندعم هذا السيناريو رسميًا حاليًا.

ومع ذلك ، فإن الاتصال عن بُعد المستند إلى WSMan ليس بلا وكيل. لا يزال يتعين عليك تشغيل خدمة WinRM على جهاز Windows الخاص بك: هذا وكيل. في الإصدار التالي من Windows 10 و Windows Server ، سيكون OpenSSH نفسه متاحًا كميزة مدعومة عند الطلب ، لذلك سيكون لديك دعم البريد الوارد من الطرف الأول للاتصال عن بُعد المستند إلى SSH كنظير للاتصال عن بُعد المستند إلى WSMan.

أنا أيضًا أغلق هذه المشكلة نظرًا لأنها تجاوزت فترة فائدتها. يجب أن نواصل تتبع هذا العمل في القضايا التي تم إنشاؤها. إذا كنت شغوفًا بشيء هنا ليس به مشكلة ، فالرجاء فتح واحدة حتى نتمكن من تتبعها هناك.

أخطط أيضًا لإصلاح المشاريع في مرحلة ما ، وأنا أعلم أن هذا في حالة تعطل نوعًا ما الآن. آسف لذلك يا رفاق ....