🚧 RFC only, not to merge #1305
Closed
🚧 RFC only, not to merge #1305
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glima
force-pushed
the
test
branch
2 times, most recently
from
de94c6f to
27426ff
Compare
While I've just begun to investigate some weird Linux boxes, that hang on shell.py's "try_connnect"--they absolutely should not, but them we're talking about ancient, weird systems, like 3.x kernel--we must guarantee that that function serves its purpose, which is *to detect Windows boxes*. When I arrived on LISA, it was broken and I made it work (just to find that these weird cases now appear, but anyhow). One internal platform of ours totally depends on talking to Windows boxes via SSH and, well, the nodes need to be recognized as such for things to work. I'd like, in parallel with any fix that will come with this investigation, to have a unit test for such functionality. My initial thoughts were to take advantage of the Windows instance on our CI, the OpenSSH server feature/capability of Windows 10, and have a remote note pointing to self (localhost) in a test, then to assert that it was marked non-POSIX. I'd reach that by enabling the feature, editing configs to allow for key logins, enabling/starting the service, generating keys and using those as credentials to the node, along with user, of course. The test, finally, would only run on Windows (preferably detecting the ones with the service running). Problem is that OpenSSH's situation on Windows is a clusterf*^Wvery poorly handled, and key logins generally only work with luck. Anyone with a better idea on how to test that or with better abilities with Windows + OpenSSH to help me with this? Thanks!
|
Status: waiting for PowerShell/Win32-OpenSSH#1787 (which could be forever) or till someone has a different idea to reach the same goal. |
|
@glima Are there any alternatives that we can explore? Is the issue with open ssh or with windows? |
|
There are issues opened with Windows, yes. Well my question was exactly that--do you know of any? Given we're testing node connections and our business is SSH all across LISA, that's the path I envision would be sane. If you have other paths on your mind, please share :) |
|
Close the old PRs. Feel free to open it, if you are working on it continually. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While I've just begun to investigate some weird Linux boxes, that hang
on shell.py's "try_connnect"--they absolutely should not, but them
we're talking about ancient, weird systems, like 3.x kernel--we must
guarantee that that function serves its purpose, which is to detect
Windows boxes.
When I arrived on LISA, that functionality was broken and I made it work (just to find
that these weird cases now appear, but anyhow). One internal platform
of ours totally depends on talking to Windows boxes via SSH and, well,
the nodes need to be recognized as such for things to work.
I'd like, in parallel with any fix that will come with this
investigation, to have a unit test for such functionality. My initial
thoughts were to take advantage of the Windows instance on our CI, the
OpenSSH server feature/capability of Windows 10, and have a remote
note pointing to self (localhost) in a test, then to assert that it
was marked non-POSIX.
I'd reach that by enabling the feature, editing configs to allow for
key logins, enabling/starting the service, generating keys and using
those as credentials to the node, along with user, of course. The
test, finally, would only run on Windows (preferably detecting the
ones with the service running).
Problem is that OpenSSH's situation on Windows is a clusterf*^Wvery
poorly handled, and key logins generally only work with luck.
Anyone with a better idea on how to test that or with better abilities
with Windows + OpenSSH to help me with this?
Thanks!