Cannot install krew on Windows #631
Comments
|
Can you please run with Also, please bear in mind that admin privileges are required to install plugins on Windows due to the use of symlinks (#375 (comment)). |
|
Since I have developer mode enabled, it's not the admin privileges. I ran the following as admin anyway, just to make sure: |
|
Running into similar issue. Suspect same. For the work around I grabbed the files from:
I then ran: And it worked.
Looks like I would need to do this for each plugin I would want. |
|
We have other windows users reporting it works on their machines with PowerShell running as Administrator. Could there be something controlling fs access such as an antivirus software or corporate machine policy? |
|
It could be, But what is odd, The ingress-nginx gave me the same problem as krew. But change-ns installed without issue. |
|
I need a better answer than "could be". :) If there's an AV program on your system, it's not worth trying to understand why it silently blocks or deletes certain binaries. There's little to none we can do about that. |
Regarding my original issue, I'm pretty sure it has to do with file locking, which is much more reasonable than randomly deleting binaries. :)
Well, that's not entirely true, since the workaround is already implemented, just not used. FYI, |
|
Thanks for pointing it out. It seems the same issue as this one golang/go#36568. |
|
I meant to point this out. The issue doesnt occur with some of the plug-ins. I wasn't able to do krew, or the ingress-nginx. But change-ns went in with no complaint. I am not sure how they handle their respective "installs" different. I haven't had a chance to look. |
|
I think an interesting test would be attempting to install every single plugin available (you can put them all in the same krew install command). Then running |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
k8s-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale (Can I do that?) |
k8s-ci-robot
removed
the
lifecycle/stale
|
/lifecycle frozen |
k8s-ci-robot
added
the
lifecycle/frozen
|
Yeah, so to add a little technical colour, some AV implementations hook in post-write, opening and scanning the file after it is written to disk. No implication of TOCTOU race, since they could also have a JIT check in place. But an IO pattern of:
will race with the AV scanners
Note that the AV scanner is multi threaded, making many of these calls overlapped: trying to thread the needle between them with high frequency attempts is impossible and just increases CPU utilisation. To fix that, either: don't perform that IO pattern, or use a retry-with-backoff strategy on the rename. A 10 step Fibonacci sequence retry (in ms, so 1,1,2,3,5,8,13,21,34,55, sum(delay)=143(eep!)) has eliminated reports of this bug for us in Rustup, which drops several hundred MB of HTML on disk in a few seconds - more than enough to cause a backlog for virus scanners that use this particular strategy. Most users get great performance, a few with terrible AV implementations get poor performance. (I say terrible because these files don't need to be scanned immediately - waiting for some indication they are going to be read would be a better strategy, and safe installation idioms like this represent are extremely common on other platforms than Windows - which is why so many non-Windows heritage programs run into this problem. |
|
|
ahmetb
added
kind/bug
|
I have a similar error: failed to retrieve plugin indexes: failed to list the remote URL for index default: command execution failure, output="": exit status 1 Is there a possibility to fix this bug? |
|
@TheHunter the error does not at all look similar, please open a new issue. |
|
Meanwhile to not be blocked by this stuff, I made some script for this, providing this script via our company portal and is executed as a local-admin, it will bluntly copy krew into the any available user in Re-use by your own liking... |
|
Add this to your Powershell profile. Make sure to add it to the correct profile for your Powershell version and adjust accordingly (Powershell 5 = powershell.exe and Powershell 7 = pwsh.exe) The script basically checks for the command "krew" and if detected, it will check if your current Powershell session is elevated (running as admin) or not. If yes, then it'll just process whatever command you feed to it, e.g. "krew update". If Powershell session is not elevated, it'll prompt you to run Powershell as admin. As the script is added to your Powershell profile, it will load automatically on every new Powershell process that is launched. |
|
@chaoscreater If your AV is giving you trouble, as in my original report, elevation does not help at all. |
Just because something is simpler, doesn't mean it's a good solution. If that were the case, there'd be no need for security and Microsoft may as well just enable developer mode for all new WIndows installations by default. There'd be no need for UAC, etc. Allowing unsigned apps to be installed without any security intervention is bad practice, hence why it's called "developer" mode and not "production" mode. My script works perfectly fine. It allows UAC elevation when required. Anyway, for those who wants to try the 'enable developer mode' method, make sure to first delete the .krew folder from your user profile (C:\Users\Your_User_Name). Then run a new instance of Powershell and then you can do krew install krew and krew update to test if it works. |
|
@chaoscreater But that's besides the point: I mostly replied to you to point out to anyone who comes across this issue that your script does not fix the problem described in the OP. |
There have been multiple comments posted in this repo about running Powershell as admin to fix the issue and I can confirm that definitely works. My script simply prompts the user to run elevated Powershell whenever the "krew" command is detected in the console. Does the app need elevation? Probably not. Does my script change or alter its intended installation behaviour? No. It doesn't change how Powershell works either. The user is only prompted to run as admin temporarily for just that instance of Powershell session. Your fix on the other hand, changes the entire system permanently, until you decide to toggle that setting to off at least. If you're running this in a sandbox or test environment, that's fine. But in production? That's a bad idea. Again, there's a reason why this is called the developer mode and why it's off by default.
You're making a point about how this app shouldn't require admin rights to run, and yet your solution is to expose your entire system. How ironic. Good job. Let me guess, you probably have all the security related settings on your system turned off, have local administrator account enabled and password set to never expire, never use MFA and also antivirus disabled. Because it makes everything so much "easier". Probably don't even use screen locks either because hey it's one extra step to unlocking the phone. |
|
Before this thread derails any further: I'm not sure what changed in the meantime, but I can no longer reproduce the original issue with the latest version of krew. Somehow, the race described in #631 (comment) no longer seems to block installations, or at least I cannot reproduce the failure anymore. Therefore, I'm closing this issue. |
Pretty sure you need to re-enable developer mode, then either rename or delete .krew from your C:\Users\username folder, then open Powershell as normal user and try the commands. I can still replicate the issue on the latest krew version. Tested this on a new VM. Either my script or your developer mode fix will work, but the issue is definitely still there without the fix. |
|
I just tried the following, in a regular (non-elevated) pwsh, with developer mode enabled (since I need it to be enabled anyway for my daily development work):
I cannot exclude the possibility that IT changed our AV configuration in the meantime (I have no insight into that), but I did not run into any errors this time. When I originally opened this issue, the above steps failed consistently. |
How is that even a test? You've mentioned in an earlier comment that you've enabled developer mode and that allows you to use krew without issues. So how is keeping developer mode enabled supposed to help you test whether krew works or not? Of course it's still going to work. |
|
Sorry to be blunt @chaoscreater, but please finally read the first few comments in this thread in their entirety: The issue you're commenting on originally caused the installation to fail even if you could already create symbolic links (thanks to elevation / developer mode). That no longer happens - if you can create symbolic links, the installation now works. If you think that the fact that symlinks are used in the first place is a bug, please open a new GitHub issue, because this is not the correct thread for that. |
Installing krew 0.3.4 on my Windows machine fails consistently with the following error message:
I suspect that this issue may be caused by the anti-virus software installed on the corporate laptop, which I cannot disable.
I saw that you already created a fallback for renaming the directory in #375 to fix another edge case. Is there any reason why this fallback cannot be enabled unconditionally? I'm pretty sure that would resolve my issue.
The text was updated successfully, but these errors were encountered: