Register-PSSessionConfiguration fails if SesionConfig folder doesn't exist #4271
Conversation
|
@PaulHigin Windows PowerShell 5.1 needs this change as well before this test will pass, right (since the default remoting endpoint still goes to Windows PowerShell)? If so, I'll change this test to |
|
@SteveL-MSFT I thought that we use a new plugin for PowerShell 6.0. Not sure but I know a new plugin was created for Core. @JamesWTruher can you comment? Regarding PowerShell 5.1, the SessionConfig folder should always be created via Windows manifest. I feel this change is only needed for the case where the folder is inadvertently deleted (through some previous test) or for PowerShell 6.0 when it is never created. |
|
Sync'd with @PaulHigin off line, this test will still fail because the default endpoint still points to 5.1 which doesn't have the fix to expose |
@PaulHigin @SteveL-MSFT Will that be a separate PR? If so, I will merge this one. |
|
@daxian-dbw I'm going to make it part of this PR otherwise the test will still fail |
|
I'm going to make this test |
|
@SteveL-MSFT one question before merging the PR: the test in question has been there for a long time, so why did it start to fail recently? |
|
@daxian-dbw that specific test was added recently by @PaulHigin SteveL-MSFT@7fa0dd0 |
|
It looks like similar implicit remoting tests in Implicit.Remoting.Tests.ps1 are disabled for core and we should do the same for this test. Is there an Issue for this? |
| string destFolder = System.IO.Path.Combine(Utils.DefaultPowerShellAppBase, "SessionConfig"); | ||
| if (!Directory.Exists(destFolder)) | ||
| { | ||
| Directory.CreateDirectory(destFolder); |
There was a problem hiding this comment.
Sorry for being late - what if the user haven't permissions?
There was a problem hiding this comment.
Good catch! For example, on Linux, powershell is installed at /opt/microsoft/powershell, and you don't have permission to create a folder unless using sudo.
There was a problem hiding this comment.
@iSazonov Thanks, we will have to think about how this will work and where configuration information goes for Linux cases, but for now I think letting an "access denied" error propagate is fine since these cmdlets cannot work correctly without access.
There was a problem hiding this comment.
I should mention that these cmdlets are currently implemented only on Windows platform.
There was a problem hiding this comment.
Could you please open a tracking Issue?
| # Blocked by https://github.com/PowerShell/PowerShell/issues/4275 | ||
| # Need a way to created restricted endpoint based on a different endpoint other than microsoft.powershell which points | ||
| # to Windows PowerShell 5.1 | ||
| It "Verifies that Import-PSSession works on a restricted session" -Pending { |
There was a problem hiding this comment.
I just noticed that similar implicit remoting tests are disabled using special checks:
# Skip tests for CoreCLR for now
# Skip tests on ARM
$skipTest = $IsCoreCLR -or $env:PROCESSOR_ARCHITECTURE -eq 'ARM'
if ($skipTest) { return }
We should make this test be the same since remoting really does not work yet with PowerShell 6.0 based endpoints. Or maybe we should mark all tests that aren't supported as "pending" since we no longer support FullCLR.
There was a problem hiding this comment.
@PaulHigin can you open a separate issue for this?
Create SessionConfig folder if it doesn't exist for Register-PSSessionConfiguration