Skip to content
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

Merged
merged 11 commits into from
Nov 9, 2016

Conversation

shlevy
Copy link
Member

@shlevy shlevy commented Sep 2, 2016

Fixes #986

@shlevy
Copy link
Member Author

shlevy commented Sep 2, 2016

Replaces #997

@shlevy
Copy link
Member Author

shlevy commented Sep 2, 2016

@edolstra I will port over build-remote and nix-copy-closure to this once merged

@shlevy shlevy added this to the perl-to-c++ milestone Sep 2, 2016
@shlevy
Copy link
Member Author

shlevy commented Sep 9, 2016

@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");
}))
Copy link
Member

@edolstra edolstra Sep 12, 2016

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.

Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, will implement laziness.

Copy link
Member Author

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing quotes around %1%.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed

@edolstra
Copy link
Member

Looks good to me.

However: Regarding nix-copy-closure, it will need to be backwards compatible. Otherwise, for instance, a NixOps on Nix 1.12 wouldn't be able to copy closures to a pre-1.12 system. From that perspective, it would actually make sense to implement SSHStore on top of the nix-store --worker protocol.

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

@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?

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

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.

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

@edolstra Alternatively, could we port the nix-daemon changes to 1.11.5 and have a milder compatibility break that way?

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

(thanks to @domenkozar for the idea)

@domenkozar
Copy link
Member

domenkozar commented Sep 12, 2016

The other alternative I see is that we:

  1. ship 1.12 with perl only for nix-copy-closure, so it supports both protocols
  2. really remove perl in 1.13 (maybe 2.0)

I hate this option, but it's better than rewriting some software for one release.

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

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.

@shlevy
Copy link
Member Author

shlevy commented Sep 12, 2016

OK my preferred solution:

  1. remove nix-copy-closure from main nix altogether. nix copy is the way for the future
  2. Have nix-perl contain nix-copy-closure (perl version), and include it by default (maybe with a deprecation warning) in user environments, hard-coded in nixops, etc. until it seems safe to not do so, but give users a way to be perl free if they want.

@domenkozar
Copy link
Member

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++.

@shlevy
Copy link
Member Author

shlevy commented Sep 21, 2016

@edolstra ?

@edolstra
Copy link
Member

My preferred solution would be to have a minimal SSHStore that uses nix-store --serve. That would give the least headaches with backward compatibility. We can keep the full-featured SSHStore, renaming it to SSHStoreNG or something like that.

A more complicated solution would be to have a full-featured, backward-compatible SSHStore that uses nix-store --serve, by extending the serve protocol to upgrade to the Nix daemon protocol if both sides support it. So:

  • nix-store --serve sends a server version of 0x203. (Nix 1.11 is 0x202.)
  • If the client sees a server version of 0x203, it sends a client version of 0x203.
  • If the server sees a client version of 0x203, it then switches over to the Nix daemon protocol for the rest of the connection. This would require moving most of nix-daemon into a library so it can be used by nix-store --serve.
  • If the server sees a client version < 0x203, it uses the old --serve protocol.
  • If the client sees a server version < 0x203, it sends a client version of 0x202 and uses the old --serve protocol. Thus SSHStore will only be able to provide a few operations like copying paths.

@shlevy
Copy link
Member Author

shlevy commented Sep 23, 2016

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?

@shlevy
Copy link
Member Author

shlevy commented Sep 23, 2016

In either case, are there concerns with this PR? It would be good to have it merged before too much chance for drift happens.

@shlevy
Copy link
Member Author

shlevy commented Sep 23, 2016

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.

@shlevy
Copy link
Member Author

shlevy commented Oct 2, 2016

@edolstra ping

1 similar comment
@shlevy
Copy link
Member Author

shlevy commented Oct 7, 2016

@edolstra ping

@shlevy
Copy link
Member Author

shlevy commented Oct 12, 2016

@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)?

@shlevy
Copy link
Member Author

shlevy commented Oct 20, 2016

@edolstra ping

@Ericson2314
Copy link
Member

...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.

@edolstra
Copy link
Member

Sorry about the delay, will try to make some progress on this the next few days.

@copumpkin
Copy link
Member

Friendly bump 😄 I'd hate for this to die/bitrot

@edolstra edolstra merged commit b99c6e0 into NixOS:master Nov 9, 2016
@Ericson2314
Copy link
Member

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants