-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
salt: 2016.11.5 -> 2017.7.1, patch fix #29020
Conversation
The libcrypto patch didn't work well with `salt-ssh` (that code failed on remote machines), so let's make Nix-based library lookup as fallback. saltstack/salt#43350
@danbst, thanks for your PR! By analyzing the history of the files in this pull request, we identified @aneeshusa, @globin and @dezgeg to be potential reviewers. |
I do realise now, that patch will work not as intended. It may break salt installs on non-NixOS machines (because it will find the libcrypto impurely, potentially wrong version) Unfortunately, original Salt doesn't distinguish host and target when running libcrypto code, so the best solution would be to patch it to copy-over libcrypto.so to target machines. That is a tricky way, and I don't think it should be done on NixOS side. On other hand, Salt devs would say Meh for such a change... |
if lib: | ||
return cdll.LoadLibrary(lib) | ||
+ else: | ||
+ return cdll.LoadLibrary('@libcrypto@') |
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.
What if libcrypto
would be in LD_PRELOAD of salt executable on nixos?
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.
Unfortunately, python dll loading library doesn't support LD_PRELOAD and LD_LIBRARY_PATH. @domenkozar has found it's implementation when investigated #7307. We should patch python then...
@danbst Thanks for the patch! I haven't yet gotten a chance to take it for a spin but will try to do so soon. |
Also I haven't tried this at all, but maybe something like this this is an easier approach than fixing Python dll loading:
|
Or we could add a check for |
I'll try the exception catch way, thanks for the pointer. Python But still, I see this as a defect in Salt itself.
And another problem, now in setup with NixOS on both master and target:
I don't know whether I should report this upstream. First example is very minor ("update libcrypto on target, what's the problem?"), and second is very Nix specific ("why should we solve your bugs?" and "why the hell would you saltify NixOS?")... |
Turns out I already had patched Salt to 2017.7.1 locally and have been using it for a while and forgot, so the Salt update itself LGTM. In general it's reasonable to run Salt between machines of differing OSes and/or |
Fixes NixOS#29020 Patch introduced in PR NixOS#29020 was OK when installing salt on NixOS, but on Linux behavior was switched to less pure variant. Here I'm returning back original behavior (use hardcoded path to `libcrypto` by default), but don't disallow dynamic library lookups (which was essential for `salt-ssh`). "Easier to Ask Forgiveness than Permission" principle at work.
Motivation for this change
Apart from regular update, I've changed the libcrypto patch. It didn't work well with
salt-ssh
(that code failed on remote machines)saltstack/salt#43350
ping @aneeshusa for review
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)