I'm running Che on WS2019 under Docker for Windows. When starting Che using the call from the guide (see copy below, custom port added) it pulls the container and sets it up all ok.
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /chedata:/data -e CHE_PORT=8090 eclipse/che start
When I open Che and go to the workspace (localhost:8090) to create a project, the create button is greyed out, and the browser console has the below errors.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://wsagent-http-dev-machine-workspacel90axz6gl3kl3mzl.192.168.1.100.nip.io:8090/api/project-type. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Firefox can’t establish a connection to the server at ws://localhost:32845/wsagent?token=. playground:18015:24
ERROR (org.eclipse.che.ide.projecttype.ProjectTypeRegistryImpl): Can't load project types: org.eclipse.che.ide.commons.exception.ServerDisconnectedException _app-0.js:17942:126
WARNING (org.eclipse.che.ide.websocket.impl.BasicWebSocketEndpoint): Error occurred for endpoint ws://localhost:32845/wsagent?token= _app-0.js:17942:126
Firefox can’t establish a connection to the server at ws://localhost:32845/wsagent?token=. playground:18015:24
WARNING (org.eclipse.che.ide.websocket.impl.BasicWebSocketEndpoint): Error occurred for endpoint ws://localhost:32845/wsagent?token=
To keep firewalls out of the issue, I've disabled windows firewall. Initially I have tried to fix the CORS issue by using CHE_CORS_ENABLED with no such luck.
I've tried specifying CHE_HOST and CHE_DOCKER_IP_EXTERNAL flags with effectively the same result. I have also tried using CHE_SINGLE_PORT=true, with again a similar issue.
I've looked at a lot of the other GitHub issues reported on Che (e.g. https://github.com/eclipse/che-dockerfiles/pull/11) and have been going at this for a good few days to no avail.
Any suggestions would be helpful,
Inci
Related
I have installed and uninstalled and reinstalled GCloud on MACOS Monterey (Chipset M1) and I'm facing the next situation: When I run in Terminal gcloud auth login, it displays the next message:
WARNING: Failed to start a local webserver listening on any port between 8085 and 8184. Please check your firewall settings or locally running programs that may be blocking or using those ports.
WARNING: Defaulting to --no-browser mode.
You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here. Make sure the installed gcloud version is 372.0.0 or newer.
I have tried in many ways to install: The last one was this:
curl https://sdk.cloud.google.com | bash
exec -l $SHELL #restart shell
But I still facing that message.
Anybody couls help me with this?
This happens because my Internet provider has blocked these ports. There will be to make some fixes to the router.
Patch solution for this:
gcloud auth login --no-launch-browser
Follow the instructions given on Terminal
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.
I got into trouble after installing Gitlab on CentOs7. For the first time I was redirected to the admin password creation page and after the password for the admin user, the server sent error.
422
The change you requested was rejected.
I had set the url value based on the site guide.
Set the external_url in /etc/gitlab/gitlab.rb:
external_url "https://example.com/gitlab"
I checked the links below for similar situations. I didn't find the right answer. My server was in the local area and had no internet access.
Error 422 after installing gitlab on Ubuntu 18.04
After Update Error: "422 The change you requested was rejected."
Error 422 after installing Gitlab on Ubuntu 16.04
I made a mistake when installing Gitlab. In the /etc/gitlab/gitlab.rb file I put the local gitlab address with https but due to the local server setup there was no "let's encrypt" service and I did not intend to access the site via ssl. I modified the address in the file and turne "https" to "http". After modifying the following commands, the problem was fixed.
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
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.
I want to expose one blue zone api to external customers via secure-gateway, I am using docker as the client, but I always met below errors (the api server is in DST environment), can anyone help me on this? I have added the host name and port into ACL file, also, I tried adding --allow when I run docker, it will disable 'deny all'
[INFO] (Client ID d83dty5MIJA_rVI) Connection #2 is being established to ralbz001234.cloud.dst.ibm.com:8888
[2017-09-06 20:59:19.210] [ERROR] (Client ID d83dty5MIJA_rVI) Connection #1 to destination ralbz001234.cloud.dst.ibm.com:8888 had error: EHOSTUNREACH
When I add secure-gateway, the resource loacated filed, I choose On-Premises, is this correct?
EHOSTUNREACH is an issue with the underlying system not being able to find a route to the host you've provided. From the machine hosting the docker client, are you able to access the resource located at ralbz001234.cloud.dst.ibm.com:8888? If the host is able to connect, then you could try adding --net=host to the docker run command:
docker run --net=host -it ibmcom/secure-gateway-client <gatewayID> -t <security_token> --allow
If the host is unable to connect as well, then this post may shed more light on routing.