Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSRP WSMan client library to C# #8233

Closed
SteveL-MSFT opened this issue Nov 12, 2018 · 21 comments
Closed

PSRP WSMan client library to C# #8233

SteveL-MSFT opened this issue Nov 12, 2018 · 21 comments
Labels
Resolution-External The issue is caused by external component(s). WG-Remoting PSRP issues with any transport layer
Milestone

Comments

@SteveL-MSFT
Copy link
Member

PSCore6 currently depends on OMI native client library for non-Windows to remote PSRP over WSMan. This library currently has a number of limitations and issues. To continue to support WSMan based remoting, we should consider writing a new library in managed code. It also appears that corefx supports Kerberos/NTLM over HttpClient so that should solve one of the immediate limitations with the native library. This library should also be a generally useful public api on nuget for other languages to remote into PowerShell via PSRP.

@SteveL-MSFT SteveL-MSFT added the WG-Remoting PSRP issues with any transport layer label Nov 12, 2018
@SteveL-MSFT SteveL-MSFT added this to the Future milestone Nov 12, 2018
@iSazonov
Copy link
Collaborator

For reference psl-omi-provider
Seems there are no tests. Without them, porting will be problematic.

And should the new library be used on all platforms including Windows?

@SteveL-MSFT
Copy link
Member Author

@iSazonov tests is lacking which is why we get reports of issues that should have been caught by tests. In this case, we would add tests along with this porting work. We would probably use the same library on downlevel Windows that doesn't have WMF4+, however, this library isn't expected to have full parity with WinRM (at least initially) so relying on WinRM in those cases would make sense. Long term, it would make sense to have a single library for all platforms.

@iSazonov
Copy link
Collaborator

In which repository should this be done?
We need at least a test environment.

@SteveL-MSFT
Copy link
Member Author

SteveL-MSFT commented Nov 26, 2018

@iSazonov I created https://github.com/PowerShell/PSRP-Client-Library if you want to experiment. cc @PaulHigin

@PaulHigin
Copy link
Contributor

If we want to create a new managed version of WSMan client, then I feel we should start with an RFC.

@iSazonov
Copy link
Collaborator

... and continue with tests :-)

Seems it will be large and complex RFC.

@SteveL-MSFT SteveL-MSFT changed the title Port PSRP WSMan client library to C# PSRP WSMan client library to C# Nov 26, 2018
@SteveL-MSFT
Copy link
Member Author

I agree with @PaulHigin that the intent here is:

  1. remove dependency on omi-psl-provider native library
  2. provide public api to create remote PSRP session (I'll rename it to PSRP instead of WSMan specific)

So it would make sense to have an RFC for the apis.

@iSazonov
Copy link
Collaborator

How this correlate with https://www.dmtf.org/standards/ws-man ?

@SteveL-MSFT
Copy link
Member Author

@iSazonov PSRP over WSMan relies on the PowerShell Remoting Protocol which is built on top of WS-Man (or SSH now in PSCore6) which is the same as the one you linked to. WS-Man is a SOAP based protocol that goes over HTTP(S).

@iSazonov
Copy link
Collaborator

So we should port this client and get direct dependency on native OMI library?

@SteveL-MSFT
Copy link
Member Author

@iSazonov the goal here is to remove dependency on OMI library altogether and just have C# code

@iSazonov
Copy link
Collaborator

I see OMI project is actively updated. Shouldn't this issue be addressed there? I mean OMI client library ported at first in OMI project? What is a reasonable compromise?

@PaulHigin
Copy link
Contributor

PowerShell remoting uses OMI only as a bridge for non-Windows platforms. Its support of WinRM client is incomplete and problematic. My goal is to completely remove OMI as a dependency. I agree with @SteveL-MSFT that the best way to do this is to investigate implementing WinRM client in cross-platform managed code, resulting in an RFC that outlines the work required.

@iSazonov
Copy link
Collaborator

iSazonov commented Nov 29, 2018

It seems I started to understand :-)

  1. We really will not have a conflict with the OMI project?
  2. Having two client (Windows (WMF) and the new one on Unix) is seems a problem too. CoreFX reimplemented HttpClient to exclude curl and get the same behavior on all platforms.
    I assume that we are doomed to the same thing - to have single managed WinRM client library for all platforms including Windows 10 (not only Windows 7 without WMF4). In other words, PowerShell Core uses the new managed client, Windows PowerShell uses WMF client.
    It even simplified development that could be done on Windows.

@SteveL-MSFT
Copy link
Member Author

@iSazonov I've had discussions with the OMI team internally and there is no conflict or overlap. We should use the same client code for both Windows and non-Windows although that would not happen initially as some capabilities we get from WinRM are not a priority for non-Windows.

@iSazonov
Copy link
Collaborator

@SteveL-MSFT Could you please update the issue description and title that we want to implement WinRM client on managed code?

Is there someones (firms) to whom this may be useful and who could be contribute/test? You could blog post to announce the new project.

Also I hope your team prepares the RFC (I have no idea who else could do it.)
Currently, I can only review a code in the repo and maybe reorganize/cleanup it to make it easier to add the new experimental code.

@SteveL-MSFT
Copy link
Member Author

@iSazonov I think this specific item is pretty specialized and complicated so unlikely for someone in the community to be able to contribute. Since we have the new repo for this work, I'm going to close this item. It's not blocking at this time, but will become blocking in the future if more customers want to use PSRP over WSMan from non-Windows.

@SteveL-MSFT SteveL-MSFT added this to Done in Linux/Mac Usability via automation Nov 30, 2018
@SteveL-MSFT SteveL-MSFT added this to Done in Developer Experience/SDK via automation Nov 30, 2018
@SteveL-MSFT SteveL-MSFT added the Resolution-External The issue is caused by external component(s). label Nov 30, 2018
@iSazonov
Copy link
Collaborator

Today I researched this a bit and came to the conclusion that it could be useful for other projects on managed code. There is nothing on GitHub like WSMan on C#. I hope the project will not be frozen for a long time. Ping me when it will start.

@SteveL-MSFT
Copy link
Member Author

@iSazonov to set expectation, I don't expect to start on this until at least April 2019

@iSazonov
Copy link
Collaborator

@SteveL-MSFT @PaulHigin What is a status of "WSMan on C#"? We receive continuous issues for remoting from Unix-s.

@sakno
Copy link

sakno commented Jun 26, 2020

Guys, any progress on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-External The issue is caused by external component(s). WG-Remoting PSRP issues with any transport layer
Development

No branches or pull requests

4 participants