-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
ssh-ng: Set log-fd for ssh to 4
by default
#7659
Conversation
On the other hand, I recall that this wasn't done before because ssh-ng doesn't "normally" use I am correct about that, it may make sense to coordinate with @balsoft who is working on that handshaking in #6628. As I said there, I hope we also get #5265 which will allow more robust remote servers long term. |
aa82ade
to
f589db9
Compare
@Ericson2314 but doesn't build-remote need to pick up these messages anyways somehow? Not sure if I understand what you mean. However: I agree that the solution may not be pretty, but I think that getting rid of that cryptic error message is a fairly useful improvement on its own :) |
@Ma27 so remember |
I think this is wrong, because (IIRC) it will cause ssh errors/warnings to end up in the derivation log. The intent is that ssh's stderr goes to the hook's stderr, which gets processed in |
@edolstra yeah if nothing else I find the SSH situation very complex and confusing. I hope we can merge your #5265 and also do #5025 (comment), and then we will have a baseline thing to test which is far simpler (less indirection, just 1 file descriptor, etc.) |
@edolstra not sure if I missed something, but I don't think so. After removing the relevant entries from
However when I run
|
ping @edolstra did I do anything wrong with my example, AFAIU this doesn't write handshake errors into the derivation's log.
@Ericson2314 Well they do (for ssh-ng://) now because stderr is dup2-ed from logFD (4) which is where that ends up in build-remote? Or can you give me an example where this is problematic (sorry, haven't hacked too much in this area of Nix, so sorry for needing some time to understand 😅 ) |
@Ma27 I don't know all the details myself, but check out |
@Ericson2314 then this shouldn't be a problem, right? The Relevant code from if (dup2(out.writeSide.get(), STDOUT_FILENO) == -1)
throw SysError("duping over stdout");
if (logFD != -1 && dup2(logFD, STDERR_FILENO) == -1)
throw SysError("duping over stderr"); |
@Ma27 the issue is not that this PR changes things, but that we have two sources of truth as to error messages -- stdout errors part of the protocol and the other fd out of band. |
@Ericson2314 ok, now we're talking 😄 I agree, this should be fixed properly, however I think that this is a usability issue IMHO, so we could merge this as workaround now and make it prettier in #6628? |
also gentle ping @edolstra for opinions :) |
Yeah I am happy to defer to others about whether this is a good temporary solution. |
hmm, I guess it makes sense to get input from e.g. @NixOS/nix-team |
Put it on the project board for triage. |
Triaged in the Nix team meeting 2023-03-17: Assigned to @edolstra for another review, asked for by @Ericson2314. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-17-nix-team-meeting-minutes-41/26614/1 |
That's expected by `build-remote` and makes sure that errors are correctly forwarded to the user. For instance, let's say that the host-key of `example.org` is unknown and nix-build ../nixpkgs -A hello -j0 --builders 'ssh-ng://example.org' is issued, then you get the following, somewhat cryptic error: error: cannot open connection to remote store 'ssh-ng://example.org': error: unexpected end-of-file The relevant information (`Host key verification failed`) ends up in the daemon's log, but that's not very obvious considering that the daemon isn't very chatty normally. This can be fixed - the same way as its done for legacy-ssh - by passing fd 4 to the SSH wrapper. Now you'd get the following error: error: cannot open connection to remote store 'ssh-ng://example.org': error: unexpected end-of-file: Host key verification failed. ...and now it's clear what's wrong.
f589db9
to
ed8ff8f
Compare
Rebased against latest master @fricklerhandwerk @Ericson2314 @edolstra |
friendly ping @edolstra |
gentle ping @edolstra @thufschmitt @fricklerhandwerk |
ping @NixOS/nix-team even though this may not be perfect, I still think it's a step forward in terms of useful error messages, so I'd really appreciate this being considered to be merged. |
Closing due to lack of interest. |
That's expected by `build-remote` and makes sure that errors are correctly forwarded to the user. For instance, let's say that the host-key of `example.org` is unknown and nix-build ../nixpkgs -A hello -j0 --builders 'ssh-ng://example.org' is issued, then you get the following output: cannot build on 'ssh-ng://example.org?&': error: failed to start SSH connection to 'example.org' Failed to find a machine for remote build! derivation: yh46gakxq3kchrbihwxvpn5bmadcw90b-hello-2.12.1.drv required (system, features): (x86_64-linux, []) 2 available machines: [...] The relevant information (`Host key verification failed`) ends up in the daemon's log, but that's not very obvious considering that the daemon isn't very chatty normally. This can be fixed - the same way as its done for legacy-ssh - by passing fd 4 to the SSH wrapper. Now you'd get the following error: cannot build on 'ssh-ng://example.org': error: failed to start SSH connection to 'example.org': Host key verification failed. Failed to find a machine for remote build! [...] ...and now it's clear what's wrong. Please note that this is won't end up in the derivation's log. For previous discussion about this change see NixOS/nix#7659. Change-Id: I5790856dbf58e53ea3e63238b015ea06c347cf92
That's expected by `build-remote` and makes sure that errors are correctly forwarded to the user. For instance, let's say that the host-key of `example.org` is unknown and nix-build ../nixpkgs -A hello -j0 --builders 'ssh-ng://example.org' is issued, then you get the following output: cannot build on 'ssh-ng://example.org?&': error: failed to start SSH connection to 'example.org' Failed to find a machine for remote build! derivation: yh46gakxq3kchrbihwxvpn5bmadcw90b-hello-2.12.1.drv required (system, features): (x86_64-linux, []) 2 available machines: [...] The relevant information (`Host key verification failed`) ends up in the daemon's log, but that's not very obvious considering that the daemon isn't very chatty normally. This can be fixed - the same way as its done for legacy-ssh - by passing fd 4 to the SSH wrapper. Now you'd get the following error: cannot build on 'ssh-ng://example.org': error: failed to start SSH connection to 'example.org': Host key verification failed. Failed to find a machine for remote build! [...] ...and now it's clear what's wrong. Please note that this is won't end up in the derivation's log. For previous discussion about this change see NixOS/nix#7659. Change-Id: I5790856dbf58e53ea3e63238b015ea06c347cf92
Motivation
That's expected by
build-remote
and makes sure that errors are correctly forwarded to the user.For instance, let's say that the host-key of
example.org
is unknown andis issued, then you get the following, somewhat cryptic error:
The relevant information (
Host key verification failed
) ends up in the daemon's log, but that's not very obvious considering that the daemon isn't very chatty normally.This can be fixed - the same way as its done for legacy-ssh - by passing fd 4 to the SSH wrapper. Now you'd get the following error:
...and now it's clear what's wrong.
Context
See feefcb3 for the corresponding fix in
ssh://
.cc @edolstra @thufschmitt
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests