Make PSWSMan module the only source of libmi and libpsrpclient binaries for PowerShell remoting over WSMan on Linux and macOS?
#15310
Replies: 7 comments 22 replies
-
This is something that I have investigated when someone tried to get this working in Azure Cloud Shell where you don't have root access jborean93/omi#24 (comment) While this does work and allows you to use the fork without root access and the restart there is one catch with
Right now there is no custom import resolver for the S.M.A assembly but I have no idea if that assumption will be true in the future. It also means that any 3rd party code that does this themselves for some reason will not be usable with this module and vice versa. I don't know whether this is really something to be concerned about but I have mostly avoided going that route because I didn't want to paint myself into a corner. I see in your comment you are talking about setting this for the
This is definitely possible but there are 2 wrinkles that make this complicated. The linkage between
I'm not against the idea, I do have some concerns about My only other qualm is how this works from a support perspective, While I'm happy to help out when I can I cannot give any guarantees that any bugs or feature requests will be addressed at all. This is fine if this is a fork and people opt into that knowing the "risks" involved but when something comes with the "official" status that may change the expectation of the users. While I don't wish to cause any offense to anybody who works on this part of PowerShell the builtin implementation is a bit lacking and the fork should provide a better experience it's still not a 1 for 1 comparison with what Windows provides. I see 4 potential options that are available
I know 4 is a pipe dream and I personally don't have time to work on it and the same probably also applies to anybody on the PowerShell team. TLDR: I'm happy to investigate this further but have some concerns around limtations of |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I missed that, and thus deleted my previous comment 😄 In this case, let's use |
Beta Was this translation helpful? Give feedback.
-
Ah my apologies I was just too eager to reply :)
Based on my very limited understanding of this, when PowerShell goes to load |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the supporting story, my words 'advertised "official" repo' were wrong and misleading. We will never say the |
Beta Was this translation helpful? Give feedback.
-
Yes, that's how this event works. PowerShell already registered one, called There may be some complication when the isolated module kicks in (we have a feature work to make module able to be loaded in separate |
Beta Was this translation helpful? Give feedback.
-
To me, '"Promote" PSWSMan as the official-ish way of using WSMan on Linux' is the only realistic option. OMI doesn't support powershell anymore, so powershell cannot support the WSMan remoting on Linux/macOS anymore. If not promoting |
Beta Was this translation helpful? Give feedback.
-
|
Regarding MMI, it's still needed on Windows for CimCmdlets, but is out of scope for this discussion. The only other thing MMI was used for on Linux/macOS was DSC configuration compilation to a mof file. Since we are no longer using MOF for DSC going forward, it is ok to break this dependency. I would think |
Beta Was this translation helpful? Give feedback.
-
|
I guess this also brings into question the "support" statement of the EXO2 module on Linux. The docs https://docs.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2?view=exchange-ps states
In particular it singles out Ubuntu 18.04/20.04 and macOS 10.14 or newer. If WSMan is not going to be in box then what level of support for Linux will they have when it comes to this module as it heavily relies on WSMan to connect to the O365 instance. Basically for their module to work on non-Windows they would need to have a dependency on |
Beta Was this translation helpful? Give feedback.
-
|
This is a good question and totally valid concern. Do you know what the current working status of the EXO V2 module is on different PS 7+ versions for different versions of Ubuntu and macOS today? A matrix of where it works and where it doesn't would be very helpful. Also loop in @joeyaiello for comments. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK if you can get WSMan working then the modules just work on Linux. I've only done very basic sanity tests for EXO2 but it sort off works. My concern is that an official MS supported module now has a dep on something not maintained by MS. |
Beta Was this translation helpful? Give feedback.
-
|
That's absolutely a reasonable concern. AFAIK, @joeyaiello had a conversation with Jeffrery Snover earlier this week about the compatibility issues with Officen365 modules, we are following up on that, but it may take a long time to fully resolve them. |
Beta Was this translation helpful? Give feedback.
-
Who is the person who could give this a boost? @jpsnover? Maybe it's time to create an experimental project and try something like gRPC? |
Beta Was this translation helpful? Give feedback.
-
|
Even though we won't use PowerShell needs some additional changes besides removing those 2 libs -- the code path that creates a new |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to know when it comes to Enterprises that are still paying for overdue Windows PowerShell. It looks ridiculous to put a patch on another patch. :-) We didn't get WSMan in OOB before and never will. Same with SSH. With this suggestion, we stay in the same place again, or even take a step back (well, to a side :-) ).
|
Beta Was this translation helpful? Give feedback.
-
Here we are not talking about Windows PowerShell. Nothing is changed to Windows PowerShell. What do you mean by "a patch on another patch"?
It's not very clear what you mean here, could you please elaborate some more? |
Beta Was this translation helpful? Give feedback.
-
|
It is impossible to deploy PowerShell 7 in Enterprise and get it working in heterogenous environment. |
Beta Was this translation helpful? Give feedback.
-
No matter how you package the problem it remains a problem and it is not possible to use the remoting in Enterprise. |
Beta Was this translation helpful? Give feedback.
-
|
If there are gaps that prevent the SSH remoting from working out of the box, then efforts should be made to close those gaps. |
Beta Was this translation helpful? Give feedback.
-
|
As far as I can tell, it's up to you (Microsoft) to support WSMan and WinRM. It's your tech and your library, and it always has been. Nowadays, we really only need it to connect to your services and your operating systems ... It feels disingenuous to say "it's not supported anymore" as if you'd taken a dependency on some 3rd party library that is no longer being updated. There needs to be a lot better communication about why you're retiring this, and a default-on story for connecting to Windows Servers.... |
Beta Was this translation helpful? Give feedback.
-
@daxian-dbw Even though SSH on Windows continue to improve (Kerberos auth, etc.), using it for PowerShell remoting is still a nonstarter for me until PSRP over SSH supports JEA. It's 2024 and still there's no JEA support. I know it never really caught on as well as it could have but in my opinion, JEA is the killer feature of PSRP. I am only finding more uses for it in a cloud-heavy world, and I find myself still stuck with Windows PowerShell 5.1 and a frustrating lack of support from Microsoft on how to connect to these endpoints from non-Windows platforms. |
Beta Was this translation helpful? Give feedback.
-
|
@daxian-dbw I've had a play with this today and feel like this should work going forward Add-Type -TypeDefinition @'
using System;
using System.Management.Automation;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Runtime.Loader;
namespace PSWSMan
{
public class Resolver : IDisposable
{
private static readonly string PSRP_LIB_NAME = "libpsrpclient";
private string libPath = null;
private IntPtr libHandle = IntPtr.Zero;
public Resolver(string libPath, bool setPwshResolver)
{
this.libPath = libPath;
AssemblyLoadContext.Default.ResolvingUnmanagedDll += ResolvePSRPClient;
if (setPwshResolver)
{
try
{
NativeLibrary.SetDllImportResolver(typeof(PSObject).Assembly, ImportResolver);
}
catch (InvalidOperationException) {} // Only 1 resolver allowed per assembly
}
}
private IntPtr ImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
if (libraryName == PSRP_LIB_NAME)
return GetPSRPClientLibrary(assembly, searchPath);
return NativeLibrary.Load(libraryName, assembly, searchPath);
}
private IntPtr ResolvePSRPClient(Assembly assembly, string libraryName)
{
if (libraryName != PSRP_LIB_NAME)
return IntPtr.Zero;
return GetPSRPClientLibrary(assembly, null);
}
private IntPtr GetPSRPClientLibrary(Assembly assembly, DllImportSearchPath? searchPath)
{
if (libHandle == IntPtr.Zero)
libHandle = NativeLibrary.Load(libPath, assembly, searchPath);
return libHandle;
}
public void Dispose()
{
if (libHandle != IntPtr.Zero)
{
NativeLibrary.Free(libHandle);
libHandle = IntPtr.Zero;
}
AssemblyLoadContext.Default.ResolvingUnmanagedDll -= ResolvePSRPClient;
GC.SuppressFinalize(this);
}
~Resolver() { this.Dispose(); }
}
}
'@
# Will be selected at runtime based on the host environment - just used for testing here
$libPath = "/home/jborean/dev/omi/PSWSMan/lib/glibc-1.1/libpsrpclient.so"
# Will check if pwsh still ships libpsrpclient, if so it's going to call SetDllImportResolver to ensure
# pwsh no longer uses the shipped copy. If not present then SetDllImportResolver is not called
# so that in case pwsh adds it's own resolver won't impact this module
$pwshDir = Split-Path -Path ([PSObject].Assembly.Location) -Parent
$libPresent = Test-Path -LiteralPath (Join-Path $pwshDir libpsrpclient.so)
# Will live for the scope of the module - disposes itself on unload
[PSWSMan.Resolver]::new($libPath, $libPresent)Do you see any glaring problems with this approach? It should work today where the builtin libs are present and in the future where they are no longer present with PowerShell. Things are a bit more complicated on macOS as it needs to set up some symlinks for the OpenSSL libs at runtime but I think I have a separate solution for that which I don't hate too much. The only downside I can see with this approach over the current just copy into the pwsh dir is that someone needs to import this module. If any WSMan commands are run then the existing |
Beta Was this translation helpful? Give feedback.
-
|
This is great! Glad that you get it to work! public Resolver(string libPath, bool setPwshResolver)
{
this.libPath = libPath;
AssemblyLoadContext.Default.ResolvingUnmanagedDll += ResolvePSRPClient; //<=== maybe skip this when 'setPwshResolver' is true?
if (setPwshResolver)
.... private IntPtr ImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
if (libraryName == PSRP_LIB_NAME)
return GetPSRPClientLibrary(assembly, searchPath);
return NativeLibrary.Load(libraryName, assembly, searchPath); //<=== shouldn't you return IntPtr.Zero here?
} |
Beta Was this translation helpful? Give feedback.
-
Right, previously the user only needs to run
I didn't try the native dll loading behavior myself, so the second loading of |
Beta Was this translation helpful? Give feedback.
-
I'll probably just keep it as it is to make the dispose behaviour simpler (always remove the event handler). I can't think of a downside to this except the event is never going to do any work.
I'll have to play around with this a bit more but it looks like you are right and returning
Will be interested to hear more about this when more details are known. Making sure you run
Yea once a native library is loaded it will stay loaded for that assembly (maybe even process wide?). I'm not aware of a way to unload these libraries outside of changing how the code ultimately calls the functions in that library which is outside the control of |
Beta Was this translation helpful? Give feedback.
-
|
@jborean93 Thanks for the clarification! |
Beta Was this translation helpful? Give feedback.
-
|
I wonder we are trying to resolve the fundamental problem with PowerShell remoting based on the principle of minimal change. |
Beta Was this translation helpful? Give feedback.
-
You might be right but until then things need to continue working. Having some new gRPC mechanism, or subsystem for remoting won't magically allow you to connect to Windows hosts (without ssh) or Exchange endpoints. I might disagree with the dropping of work with WSMan while it's still prevalent in today's environments but unless MS change their mind the best I can do is maintain my own fork. |
Beta Was this translation helpful? Give feedback.
-
|
I am very grateful for your work! It will be in demand even if we get alternatives. But we are in an absurd situation for many years now where WSMan remoting does not work well OOB on Unix and SSH remoting on Windows. At the same time, MSFT announced PowerShell Core as the only area for innovation against Windows PowerShell. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
The PowerShell remoting over WSMan on Linux and macOS depends on the WSMan client libraries
libmi.so/libmi.dylibandlibpsrpclient.so/libpsrpclient.dylib, which were from the microsoft/omi repository. The OMI project is in maintenance mode and its team has decided to not support PowerShell anymore. Therefore, the PowerShell WSMan remoting is becoming more and more broken on Linux and macOS.Proposal
How about making the
PSWSManmodule the only source oflibmiandlibpsrpclientbinaries for PowerShell remoting over WSMan on Linux and macOS?The PSWSMan module is created by @jborean93 to install and manage the WSMan client libraries
libmiandlibpsrpclientproduced from his forked omi repository for Linux and macOS.The
libmi/libpsrpclientshipped by PowerShell are not going to be updated. They may still work on some old Linux distros, but very likely not on newer ones. @jborean93, what if PowerShell doesn't shiplibmi/libpsrpclientat all, but instead tell users to leveragePSWSManmodule to enable WSMan remoting support on Linux/macOS?Today, to use
PSWSMan, one has to replace the WSMan client libraries shipped by PowerShell with the ones contained inPSWSManwithInstall-WSMan. The user needs to have root privilege and needs to restart PowerShell for that.If PowerShell doesn't ship those libs, then allPSWSManneeds to do is to set aDllImportResolvercallback for theMicrosoft.Management.Infrastructureassembly upon module loading, which will then be used by the runtime to resolve the P/Invoke's from MMI tolibmi/libpsrpclient.[edit] I missed that
System.Management.Automationalso referenceslibpsrpclientin PInvoke's.NativeLibrary.SetDllImportResolveronly allows one callback per assembly, when it comes toS.M.A, the risk of collision would be too high to be ignored. So, instead of usingDllImportResolver, we can useAssemblyLoadContext.ResolvingUnmanagedDllinstead, which is a multi-cast event. See the algorithm for loading unmanaged lib.I saw in
PSWSMan.psm1that you have a set of steps to resolve which libs to be used based on the runtime/environment. That logic can be put in theResolvingUnmanagedDllhandler. You register the handler toAssemblyLoadContext.Defaultwhen thePSWSManmodule is being loaded, and then unregister it upon module unloading.@jborean93, what do you think about this proposal? This will essentially make your forked omi repository the
advertised "official"recommended repo for WSMan client support in PowerShell./cc @TravisEz13 @SteveL-MSFT @PaulHigin @JamesWTruher
Beta Was this translation helpful? Give feedback.
All reactions