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!
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.
We have been trying to setup concourse 5.0.0 (we already set up 4.2.2) in our AWS. We have created two instances one is for web and another is for worker. We are able to see the site up and running but we are not able to run our pipeline. we checked the logs and noticed that worker throwing the below error.
Workerr.beacon.forward-conn.failed-to-dial","data":{"addr":"127.0.0.1:7777","error":"dial tcp 127.0.0.1:7777: connect: connection refused","network":"tcp","session":"9.1.4"}}
We are assuming worker is struggling to connect to web instance and wondering if this could be due to missing gdn configuration. Concourse 5.0.0 release included both concourse and gdn binaries. we want to try --garden-config file to see if that fixes the problem.
can somebody suggest how do we write garden config file ?
I had this same problem and solved it using #umamaheswararao-meka's answer. (Using ubuntu 18.04 on EC2)
Also had a problem with containers not being able to resolve domain names (https://github.com/docker/libnetwork/issues/2187). Here is the error message:
resource script '/opt/resource/check []' failed: exit status 1
stderr:
failed to ping registry: 2 error(s) occurred:
* ping https: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
* ping http: Get http://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
What I did:
sudo apt-get install resolvconf -y
# These are cloudflare's DNS servers
sudo echo "nameserver 1.1.1.1" >> /etc/resolvconf/resolv.conf.d/tail
sudo echo "nameserver 1.0.0.1" >> /etc/resolvconf/resolv.conf.d/tail
sudo resolvconf -u
cat /etc/resolv.conf # just to make sure changes are in place
# restart concourse service
Containers make use of resolv.conf and as the file is generated dynamically on ubuntu 18.04 this was the easiest way of making containers inherit this configuration.
Also relevant snippets from man resolvconf
-u Just run the update scripts (if updating is enabled).
/etc/resolvconf/resolv.conf.d/tail
File to be appended to the dynamically generated resolver configuration file. To append
nothing, make this an empty file. This file is a good place to put a resolver options
line if one is needed, e.g.,
it was the issue with gdn(garden binary) which was not configured. we had to include CONCOURSE_BIND_IP=xx.xx.x.x ( IP where your gdn is located) and CONCOURSE_BIND_PORT=7777( gdn's port) in wroker.env file. Which solved the problem for us.
Am trying to execute the following winexe command, but it throws 'ERROR: Cannot connect to svcctl pipe. NT_STATUS_ACCESS_DENIED.'
winexe -U domain/username%password //windows_machine ipconfig
debug info shows,
ERROR: smb_raw_open_recv - NT_STATUS_ACCESS_DENIED
ERROR: on_ctrl_pipe_error - NT_STATUS_ACCESS_DENIED
ERROR: Cannot open control pipe - NT_STATUS_ACCESS_DENIED
When i have 'winexesvc.exe' in Windows machine, the command works.
My understanding according to http://opensourceinfo.blogspot.com/ is that winexe itself creates winexesvc service, starts it and tries to connect to control pipe. If that's the case, what setting should i have in Windows to resolve Access Denied error and get the service installed successfully? Please correct me if am wrong.
I also came across similar issue in https://sourceforge.net/p/winexe/bugs/35/ post, but am unable to understand the given resolution 'I was trying to log on via a domain user, but only local users were configured'
Note that I have already set,
1. Network Access: Sharing and security model for
local accounts" to "Classic – local users authenticate as themselves
2. LocalAccountTokenFilterPolicy to 1.
So do we need to manually place winexesvc.exe in Windows machine for winexe to work or can we fix the above Access Denied error?
Thanks in advance.
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.
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