-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Implement SSHStore on top of nix-daemon served over ssh #1053
Conversation
…gisterStoreImplementation
Replaces #997 |
@edolstra I will port over build-remote and nix-copy-closure to this once merged |
@edolstra ping |
else | ||
execlp("ssh", "ssh", "-N", "-M", "-S", socketPath.c_str(), "-i", key.c_str(), uri.c_str(), NULL); | ||
throw SysError("starting ssh master"); | ||
})) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would probably be good to start the SSH master lazily. Otherwise, if you have an SSH store in your binary-caches
setting, the SSH master will be started for every Nix command, even when the SSH store isn't used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is the SSH master cleaned up? On Linux, dieWithParent
is implicit in startProcess()
, but what would happen on OS X?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, will implement laziness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed
|
||
auto socketDir = dirOf(socketPath); | ||
if (chdir(socketDir.c_str()) == -1) | ||
throw SysError(format("changing to socket directory %1%") % socketDir); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing quotes around %1%
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed
Looks good to me. However: Regarding |
@edolstra I don't think it makes sense to implement the entire store API in nix-store --serve, but perhaps a fallback for just the operations already implemented makes sense. Does that sound OK? |
Ugh, there's really no clean way to do that. Maybe it's better to just implement nix-copy-closure on top of the serve API directly and have nix copy be the way of the future. |
@edolstra Alternatively, could we port the nix-daemon changes to 1.11.5 and have a milder compatibility break that way? |
(thanks to @domenkozar for the idea) |
The other alternative I see is that we:
I hate this option, but it's better than rewriting some software for one release. |
Actually, we could also bundle nix-copy-closure.pl with the perl bindings package and have nixops hard-code the path to that one, so main nix is still perl-free. |
OK my preferred solution:
|
I like that. It's the same as my previous suggestion, but with better separation of concerns. Can't really judge how much that spares work over reimplementing it in C++. |
My preferred solution would be to have a minimal A more complicated solution would be to have a full-featured, backward-compatible
|
Why is it worth a decent chunk of work (implementing a C++ nix-store --serve client, rewriting nix-copy-closure again) for features we already know in advance are going away eventually (nix-copy-closure for nix copy, serve-store and 1.11 compat for sshstore) when we already have perfectly good backwards compatibility options in keeping nix-copy-closure perl and distributing it either with nix itself or with a separate package that is bundled by default? |
In either case, are there concerns with this PR? It would be good to have it merged before too much chance for drift happens. |
We could have a non-default --without-perl configure flag, and have --with-perl bring in nix-perl during the compliation process. So people building from source get backwards compat by default, and people building in nixpkgs we can do the bundling however we want (either in separate packages automatically included together or or in a single derivation), and people who are ready to switch to nix copy can do so. |
@edolstra ping |
1 similar comment
@edolstra ping |
@edolstra I will do a dumb rewrite of nix-copy-closure like I did with nix-build if you insist on the backwards compatibility, but what is your thought on this PR (and the build-remote that will be based on it)? |
@edolstra ping |
...I have to say, while its no news things can move slowly around here, I'd hope things could be better the sake of @shlevy getting his pay and those that chipped in getting their Perl-freedom in a timely manner. |
Sorry about the delay, will try to make some progress on this the next few days. |
Friendly bump 😄 I'd hate for this to die/bitrot |
🎉 |
Fixes #986