On Ubuntu 20.04, gcloud installed with snap install google-cloud-sdk --classic...
Today it no longer works. Yesterday there was an auto update.
$ kubectl get all
Unable to connect to the server: error executing access token command "/snap/google-cloud-sdk/188/bin/gcloud config config-helper --format=json": err=fork/exec /snap/google-cloud-sdk/188/bin/gcloud: no such file or directory output= stderr=
Version 188 it is referencing is gone, and it is now at 190. (Version 189 is also present.)
I've uninstalled and deleted the .config/gcloud, and reinstalled, but still have the same error.
Any tips on where to look for that stale path?
The problem is that gcloud stores the absolete reference to the gcloud binary to ~/.kube/config. The solution is to replace /snap/google-cloud-sdk/.*/gcloud -> /snap/bin/gcloud in ~/.kube/config.
Example of accomplishing this with perl on the command line:
perl -i -p -e 's/\/snap\/google-cloud-(sdk|cli)\/.*?\/gcloud/\/snap\/bin\/gcloud/' ~/.kube/config
Related
I am using Neo4j on a remote server (ubuntu 20.4) and would like to stream data from MongoDB to Neo4j. I followed the instructions here. I tried both ways by using the following approaches:
Use the following command:
sudo wget https://github.com/neo4j-contrib/neo4j-apoc-procedures/releases/tag/4.3.0.7/apoc-mongodb-dependencies-4.3.0.7.jar -O /mnt/neo4j/plugins/apoc-mongodb-dependencies-4.3.0.7.jar
Note that the plugins directory has a different path due to mounting. I changed the path in the configuration file accordingly. This should not be causing any problems because I had the same problem before mounting.
Also, I tried to match the same release as the apoc-core file (4.4.0.3) in a separate attempt with no better outcome.
Changing the ownership and read permissions as follows didn't help either:
sudo chown neo4j:neo4j apoc-mongodb-dependencies-4.4.0.3.jar
sudo chmod 755 apoc-mongodb-dependencies-4.4.0.3.jar
Use the following commands:
sudo wget https://repo1.maven.org/maven2/org/mongodb/mongo-java-driver/3.12.11/mongo-java-driver-3.12.11.jar -O /mnt/neo4j/plugins/mongo-java-driver-3.12.11.jar
sudo wget https://repo1.maven.org/maven2/org/mongodb/mongodb-driver/3.12.11/mongodb-driver-3.12.11.jar -O /mnt/neo4j/plugins/mongodb-driver-3.12.11.jar
sudo wget https://repo1.maven.org/maven2/org/mongodb/mongodb-driver-core/4.7.1/mongodb-driver-core-4.7.1.jar -O /mnt/neo4j/plugins/mongodb-driver-core-4.7.1.jar
sudo wget https://repo1.maven.org/maven2/org/mongodb/bson/4.7.1/bson-4.7.1.jar -O /mnt/neo4j/plugins/bson-4.7.1.jar
Note that I used the latest versions. I tried the versions available in the instructions as well with no difference in the outcome.
Now when restarting the neo4j.service, I no longer can access the cypher-shell nor the browser. In the first case, I get "connection refused", while I get a blank page in the browser case. When I check the status, the service is active and running. But I noticed that it is missing a line compared to when I don't have the dependencies.
Starting...
This instance is ServerId{#}
======== Neo4j 4.4.5 ======== (This line is missing with the dependencies downloaded!)
When I delete the dependencies from the plugins directory and restart, everything goes back to normal and functions as expected. One more thing to note is that apoc-core procedures work just fine!
I don't know if I'm doing something wrong here or if there is some sort of underlying problem!
I just installed Minikube for my Kubernetes local setup on Ubuntu 18.04 using the following command:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb
However, when I run the command:
minikube start
I get the following error:
bash: /usr/local/bin/minikube: No such file or directory
I'm really wondering what the issue will be.
I just figured it out after some research and trial.
Here's how I fixed it:
I simply closed that terminal and opened a new one, and ran the command again:
minikube start
OR
minikube start --driver=virtualbox
And it worked fine.
Note: By default minikube attempts to use Docker as the driver, but you specify VirtualBox as your preferred driver, which has some advantages.
Another way would have been to reload the Ubuntu bash terminal:
bash --login
Note:
If all the above techniques do not work, you add the Minikube executable to your path:
sudo mv minikube /usr/local/bin
You can then verify the Minikube executable path:
which minikube.
That's all.
I hope this helps
I installed gcloud SDK with brew cask install google-cloud-sdk
$ gcloud container clusters get-credentials my-gke-cluster --region europe-west4-c
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials)
Unable to write file [/Users/xxxxx/my-repo]: [Errno 21] Is a directory: '/Users/xxxxx/my-repo'
Now all permissions of the folder and recursive files are restricted to 600 (drw-------). Tried to reinstall gcloud but with no effect on its behavior.
I assume you're using macOS and I'm unfamiliar with it.
The gcloud container clusters get-credentials command should write to a file called ${HOME}/.kube/config.
The error suggests that it's trying to write the credentials to /Users/xxxxx/my-repo and this is determined by the value of ${KUBECONFIG}. Have you changed either ${KUBECONFIG} or your ${HOME} environment variable? You should be able to printf "HOME=${HOME}\nKUBECONFIG=${KUBECONFIG}" to inspect these.
You may be able to choose a different destination by adjust the value of KUBECONFIG. Perhaps set this to /Users/xxxxx and try the command again.
Ultimately, this is some sugar to update the local configuration file. It should be possible to create this manually if needs be. If the above don't work, I can update this answer with more details.
I'm just fished connect to my kubernete.
But affter that I need to change the gcloud location from /Download to /usr folder.
Next, I run install.sh file for update the new location in .bash_profile.
Then I check gcloud command. It working well
But when I run kubectl get pod. The error showing.
Unable to connect to the server: error executing access token command "/Users/panda/Downloads/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=fork/exec /Users/panda/Downloads/google-cloud-sdk/bin/gcloud: no such file or directory output= stderr=
Hmm, how to update the location of gcloud sdk for solve this problem.
Thanks for your help.
In your Kubeconfig file (probably in ~/.kube/config) you’ll see it has the old path to your gcloud CLI. Update that file with the new path.
I'm performing usual operation of fetching kubernetes cluster credentials from GCP. The gcloud command doesn't fetch the credentials and surprisingly updates the ownership of the local directory:
~/tmp/1> ls
~/tmp/1> gcloud container clusters get-credentials production-ng
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials) Unable to write file [/home/vladimir/tmp/1]: [Errno 21] Is a directory: '/home/vladimir/tmp/1'
~/tmp/1> ls
ls: cannot open directory '.': Permission denied
Other commands, like gcloud container clusters list work fine. I've tried to reinstall the gcloud.
This happens if your KUBECONFIG has an empty entry, like :/Users/acme/.kube/config
gcloud resolves the empty value as the current directory, changes permissions and tries to write to it
Reported at https://issuetracker.google.com/issues/143911217
It happened to be a problem with kubectl. Reinstalling it solved this strange issue.
If you, like me, have stuck with strange gcloud behavior, following points could help to track an issue:
Checking alias command and if it's really pointing to the intended binary;
Launch separate docker container with gsutil and feed it your config files. If the gcloud container clusters get-credentials ... runs smoothly there, than it's the problem with binaries (not configuration):
docker run -it \
-v $HOME/.config:/root/.config \
-v $HOME/.kube:/root/.kube google/cloud-sdk:217.0.0-alpine sh
Problem with binary can be solved just by reinstalling/updating;
If it's a problem with configs, then you could back them up and reinstall kubectl / gsutil from scratch using not just apt-get remove ..., but apt-get purge .... Be aware: purge removes config files!
Hope this would help somebody else.