I am at my wits end and have been searching everywhere for a solution to this problem but it seems like I am the only one with it.
I have done multiple different methods of spinnaker installs and have tried multiple versions of it but I cannot seem to restore the state of my spinnaker installation after I reboot the machine. I ssh in
gcloud compute ssh $HALYARD_HOST --project=$GCP_PROJECT -- -L 9000:localhost:9000 -L 8084:localhost:8084
I then redirect my browser to the spinnaker UI
http://localhost:9000
But I get the following showing up on the ssh terminal:
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
channel 6: open failed: connect failed: Connection refused
channel 5: open failed: connect failed: Connection refused
It just continues like that as long as I keep the gui open which just sits at the following screen:
It sometimes lets me proceed past this point, but then the UI is completely useless. Clicking on different menu options just shows a massive spinner which doesn't go anywhere and everything I did before the reboot is now gone.
I have tried the prebaked system provided by google 1-click deploy. I have also tried both the spinnaker computer and container codelabs provided by spinnaker. I have searched a whole host of github questions but no one seems to be running into this problem.
TL;DR; On Google's kubernetes environment install and configure halyard as root and install your spinnaker instance to the cluster and not the halyard VM.
So I figured out the issue. I did not notice that the gcloud ssh command creates a new user on login when I changed workstations. My users at all of my different machines have different usernames (Windows, Linux, Mac, home, office environments)
Secondly, I completed the installation by installing spinnaker directly to the kubernetes cluster from the halyard VM. The halyard installation and configuration I conducted as root.
After trawling a whole log of GitHub questions and answers I noticed that my spinnaker installation was done by the initial user that I logged into the machine as and often I would end up reconnecting to the instance as a different user and end up crying as to why nothing was suddenly working.
Related
When trying to get a psql shell (not using iam user) I am receiving:
> gcloud alpha sql connect pg-instance --database mydb --user myuser --project my-project
Starting Cloud SQL Proxy: [/Users/me/google-cloud-sdk/bin/cloud_sql_proxy -instances my-project:us-central1:pg-instance=tcp:9470 -credential_file /Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json]]
2022/03/15 14:47:59 Rlimits for file descriptors set to {Current = 8500, Max = 9223372036854775807}
2022/03/15 14:47:59 using credential file for authentication; path="/Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json"
2022/03/15 14:48:00 Listening on 127.0.0.1:9470 for my-project:us-central1:pg-instance
2022/03/15 14:48:00 Ready for new connections
Connecting to database with SQL user [myuser].Password:
psql: error: connection to server at "127.0.0.1", port 9470 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
I had the same error message when connecting to Postgres(Cloud Sql) using a service account.
In my setup I did run cloud_sql_proxy inside docker container.
In order to make it work I had to add extra configuration defined in step #9 https://cloud.google.com/sql/docs/sqlserver/connect-docker#connect-client
docker run -d \
-v <PATH_TO_KEY_FILE>:/config \
-p 127.0.0.1:5432:5432\
gcr.io/cloudsql-docker/gce-proxy:1.33.1 /cloud_sql_proxy \
-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:5432 -credential_file=/config
The missing bits were: host ip on port mapping and 0.0.0.0: in cloud_sql_proxy command
There are a few things I would like to point out. The best starting point for me would be the About connection options page; both the Overview and the Before you begin sections are very helpful to get the full idea of the process and how to properly configure the user. But the most important part is the Connection Options, for the message connection to server at "127.0.0.1" I’m guessing it is a private IP, but please make sure this section is covered before starting to debug.
In your case, the logs are saying there was an error in the connection to the server…
I used the Troubleshoot guide that includes the Diagnose issues link to get to the Debug connection issues page that has a lot of useful information on how to debug any connectivity issue.
Generally, connection issues fall into one of the following three areas:
Connecting - are you able to reach your instance over the network?
Authorizing - are you authorized to connect to the instance?
Authenticating - does the database accept your database credentials?
Each of those can be further broken down into different paths for investigation.
Once determining the connection method, there are different questions that will help to guide you through the possible troubleshooting paths.
If using these guides doesn’t get you a solution, please make sure to update your answer with the results, steps, and information followed to provide further help. This would be a good example, as it has the same log error, and this other question shows that there are a few different troubleshooting paths for this specific log message, plus they have useful information for you.
MongoDB shell version v4.4.3
connecting to: mongodb://127.0.0.1:27017/admin?compressors=disabled&gssapiServiceName=mongodb
Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
connect#src/mongo/shell/mongo.js:374:17
#(connect):2:6
exception: connect failed
exiting with code 1
I get this error when I try to run my mongo server, It has worked previously but not it doesn't. I have no idea what to do, please help.
This error can come up for a couple reasons. If I were to begin troubleshooting this connection, I would try restarting the MongoDB service on your local computer; as it looks like you are trying to connect to a local instance of mongodb.
The reason for this error is, you have stopped the mongodb server. Follow these steps to start mongodb server. First open task manager and go to the services tab. Then check the server status. If it is stopped, right click on it and start.
enter image description here
IF you are on window then go to your directory where server files is there.
under that check that mongod.lock file have some value.
Kindly delete the file
After that try to delete the service and then recreate the service
Delete service:
sc delete mongodb
ReCreate the Service:
sc.exe create arbiter binPath= "\"C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe\" --service --config=\"C:\data\mongodb.cfg\"" DisplayName= "mongodb" start= "auto"
Now start the service with the command
net start mongodb
Please give the comment about your attempt. I will be happy to help if problem not solved.
When I install ELM via yarn, I get
-- ERROR -----------------------------------------------------------------------
Something went wrong while fetching the following URL:
https://github.com/elm/compiler/releases/download/0.19.1/binary-for-windows-64-bit.gz
It is saying:
Error: connect ECONNREFUSED 127.0.0.1:443
NOTE: You can avoid npm entirely by downloading directly from:
https://github.com/elm/compiler/releases/download/0.19.1/binary-for-windows-64-bit.gz
When I manually browse to https://github.com/elm/compiler/releases/download/0.19.1/binary-for-windows-64-bit.gz. I get
However other people can access the link and it downloads the file.
EDIT:
HOSTS File:
127.0.0.1 view-localhost # view localhost server
127.0.0.1 mydevsnapcap.com www.mydevsnapcap.com app.mydevsnapcap.com internal.mydevsnapcap.com
0.0.0.1 mssplus.mcafee.com
Edit
This use to work a few days ago.
More tests:
I cannot access it from my phone and pc using my fibre connection, but I can access it on both my phone and mobile using my mobile connection.
It turns out that it was my ISP that was for some reason blocking the link. I switch to using the google dns and all is good in the hood: https://developers.google.com/speed/public-dns/docs/using
Something in your computer or on your network is resolving the domain github.com to 127.0.0.1, i.e. localhost. Hence, everytime you attempt this access, it tries to reach a service running on the very same computer you're making the request from.
Check your DNS settings.
Check that there are no entries for github.com in the hosts file (on Windows C:\Windows\System32\drivers\etc\hosts, everywhere else /etc/hosts).
If you're running something like Pi-Hole on your network, check, that it doesn't catch github.com
Following the tutorial and tool setup as outlined here;
https://hyperledger.github.io/composer/installing/development-tools.html
On the very last step, I executed the script to download and install local Fabric runtime:
cd ~/fabric-tools
./downloadFabric.sh
The resulting log in the console contained this error at the very end:
# Pull and tag the latest Hyperledger Fabric base image.
docker pull hyperledger/fabric-peer:$ARCH-1.0.4
Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/images/create?fromImage=hyperledger%2Ffabric-peer&tag=x86_64-1.0.4: dial unix /var/run/docker.sock: connect: permission denied
What should I do about this warning?
So your issue is a Docker issue - not a Hyperledger Composer issue FYI. I think this may help you https://techoverflow.net/2017/03/01/solving-docker-permission-denied-while-trying-to-connect-to-the-docker-daemon-socket/
Possibly a docker install issue - didn't install correctly? See here https://superuser.com/questions/835696/how-solve-permission-problems-for-docker-in-ubuntu where it talks about being in the docker group. Or else you can find an answer on Google.
I think this answer might be the reason behind it. The shell keeps your session stored. SO, in order to get the updates working, you have to close the shell and restart it again. That's why it worked after the restart.
Please correct me if I'm wrong!
I got this error when start minikube. Can anybody help me? Thanks in advance.
I1105 12:57:36.987582 15567 cluster.go:77] Machine state: Running
Waiting for SSH to be available...
Getting to WaitForSSH function...
Using SSH client type: native
&{{{ 0 [] [] []} docker [0x83b300] 0x83b2b0 [] 0s} 127.0.0.1 22 }
About to run SSH command:
exit 0
Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
In order to have local instance of cluster-like Kubernetes installation there is minikube utility.
This tool can do all the magic of the installation process automatically.
In the short - the process of deploying consist of downloading runtime images, spinning up containers and configuring necessary elements of Kubernetes without any user interaction required. It works like a charm.
You may consider to just drop current installation and start it over?
Looks like
minikube delete && minikube start
may help.
Removing the .minikube file and starting minikube helps.
rm -rf ~/.minikube & minikube start