I've been following through Confluent's official tutorial as found on YouTube https://www.youtube.com/watch?v=oI7VAS9KSS4
When it comes to the section (roughly starting 5'28'') about Confluent CLI, confluent login --save couldn't work without a --url flag, see the following screenshot
and by default the url is "https://confluent.cloud". So I had to do confluent login --save --url "https://cofluent.cloud" then was prompted to type in the username and password, and then I was stuck with this Error: Get "https://confluent.cloud:8090/security/1.0/authenticate": dial tcp :8090: i/o timeout Does anybody know how to solve this?
I'm using a Ubuntu on WSL(Windows Subsystem for Linux) on a Windows 10 PC.
Ok, I figured this out by myself. Upgrading Confluent solved the problem.
Prior to upgrading I was on version v1.22.0, with which even confluent update wasn't an option. See the following screenshot for verification.
The I upgraded with the command as shown below:
If you compare before VS. after upgrading, you'll notice that some new command options were enabled, including the highlighted cloud-signup command.
The I ran the confluent cloud-signup command, was prompted to type in the following info: email, First Name, Last Name, Two-letter country code, Organization, Terms and Policy Agreement (y/n), and it told me "Error: Failed to sign up". Why? Because I had signed up all these info on https://confluent.cloud UI already. So if you've never signed up on the UI before, you definitely can do this via the CLI.
Since I already signed up, I ran command login. This time, with the newer version, it doesn't throw the complaint that login must be appended with the --url flag any more. And I could login without any issue.
After confluent login worked out, I ran confluent login --save and Confluent writes the credentials to a netrc file it creates called "<my_home_directory>.netrc" so that in the future I don't have to manually type in the credentials again.
Related
I am trying to follow tutorial of Kubernetes but I am kinda lost on first steps when trying to use Katacoda... When I just try to open minikube dashboard I encounter error:
failed to open browser: exec: "xdg-open": executable file not found in $PATH
and dashboard itself remains unavailable when I try to open it through host 1.
Later steps like running hello-world work fine and I am able to run it locally using my own minikube instance but I am a bit confused with this issue. Can I debug it somehow to access dashboard during course? This is particularly confusing because I am a bit afraid that I might encounter same or similar issue during potential exam that also runs online...
Founder of Katacoda here. When running locally, then xdg provides the wrapper for opening processes on your local machine and installing the package would resolve the issue. As Katacoda runs everything within a sandbox, we cannot launch processes directly on your machine.
We have added an override for xdg-open that displays a friendly error message to users. They'll now be prompted to use the Preview Port link provided. The output is now:
$ minikube dashboard
* Verifying dashboard health ...
* Launching proxy ...
* Verifying proxy health ...
* Opening %s in your default browser...
Minikube Dashboard is not supported via the interactive terminal experience.
Please click the 'Preview Port 30000' link above to access the dashboard.
This will now exit. Please continue with the rest of the tutorial.
X failed to open browser: exit status 1
Looks like this command works:
apt install xdg-utils
I have been following the same tutorial in Katacoda and had the same issue.In my case, using these commands helpt me to solve the problem :
apt-get update
apt install xdg-utils
I been trying to install kubernetes for the first time, after the initial setup, I was finally able to execute the kube-up.bash script:
kubernetes/cluster/kube-up.bash
Everything goes well and I even see the list of cluster services installed:
Then the book I am checking says:
"Go to: https//your_master_ip/ui/"
But when I try I can only see the following:
I assumed I did not performed a proper setup on during the auth process, so I did:
gcloud auth list
But my active account is there with my Google email, so I am not sure what I am doing wrong.
I am able to access the Google Cloud Platfrom and see the project I created for this, I can see the traffic also.
Also, the kubectl commands are not working on my system, it throws a bash error that It was not able to locate the order.
Can someone please assist me?
Regards
I am getting the below error message while trying to access my google cloud storage from one of my Google Compute Engine instance using gsutil command. Below is the command and error message.
Command:
gsutil ls gs://my-storage-bucket
Error message:
Your "Oauth 2.0 User Account" credentials are invalid. For more help, see "gsutil help creds", or re-run the gsutil config command (see "gsutil help config").
Failure: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed.
I also tried authenticating the SDK using gcloud auth login and gsutil config and was also able to generate authorization code from the link generated after running the command gsutil config. The command again exited with the same error message. I did not get any solution even after searching for hours. The command was working fine few days before and it is not throwing any error in my local machine and other instances. Please help me out.
Are you using an old version of gsutil? There have been a lot of upgrades in the past few versions to the libraries that gsutil depends on for handling HTTP requests. I've seen ~5 mentions of this error in the past couple weeks, and nearly all of them have been fixed by updating gsutil.
However, if it's not possible for you to update gsutil, check for any recent updates your system's OpenSSL package. I've seen one person mention that this happened after moving from 1.0.1 to 1.0.2, and that moving back to 1.0.1 made the error stop appearing. However, I'd generally not advise downgrading a security library, and would suggest trying all reasonable alternatives before resorting to that.
I know, it's been late to answer here.
But I have faced such situation and it got fixed by upgrading the gcloud.
Here is the link of my blog post, hope it helps.
https://easyonror.wordpress.com/2018/10/24/anexperience-with-fixing-gsutil/
I'm trying to deploy an application via web deploy to a windows 2012 r2 server.
First tried installing iis, web deploy using the msi. After getting an unreachable error I saw somewhere that I needed wmsvc to be installed and installed it via powershell command Install-WindowsFeature Web-Mgmt-Service.
I stopped getting the unreachable error and started getting this error ->
Error: Could not complete the request to remote agent URL 'http://xx.x.xx.xx:8172/MSDEPLOYAGENTSERVICE'.
Error: The operation has timed out
On the server's event viewer under system I get the following error ->
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 1203.
Any idea of what could be going on? Did I miss something on the installation?
After this I also tried installing everything but without iis and I get the same error.
So, this is really not a PoSH issue.
Maybe you should consider movin gthis question to another forum.
Anyway, you have either real server config issues (this can sometimes mean wipe and rebuild - very ugly option - but if it's a virtual machine and you have a snapshot, just roll back), or an app causing this.
Typically for Schannel type of error, it has to do with application or service in machine not able to complete any SSL connection sort of connection.
The error state parameter of 1203 means client error connecting to server, ie invalid ClientHello from the client
See if you can collect more data by...
https://support.microsoft.com/en-us/help/260729/how-to-enable-schannel-event-logging-in-iis
I realized this is an old question, but in case somebody ran into the same issue, here are my solution.
I had to follow this guidelines : https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/configuring-server-environments-for-web-deployment/configuring-a-web-server-for-web-deploy-publishing-web-deploy-handler
Copy the resulting publishsetting file. In the Publish/Profile page import it.
In the Publish/Connection page, change the server to the server address with the 8172 port. Add the password. Change the Destination URL to the site to go to after the publish is completed.
Then after Validate connection was completed, go ahead and publish it!
I use gsutil tool for download archives from Google Storage.
I use next CMD command:
python c:\gsutil\gsutil cp gs://pubsite_prod_rev_XXXXXXXXXXXXX/YYYYY/*.zip C:\Tmp\gs
Everything works fine, but if I try to run that command from corporate proxy, I receive error:
Caught socket error, retrying: [Errno 10051] A socket operation was attempted to an unreachable network
I tried several times to set the proxy settings in .boto file, but all to no avail.
Someone faced with such a problem?
Thanks!
Please see the section "I'm connecting through a proxy server, what do I need to do?" at https://developers.google.com/storage/docs/faq#troubleshooting
Basically, you need to configure the proxy settings in your .boto file, and you need to ensure that your proxy allows traffic to accounts.google.com as well as to *.storage.googleapis.com.
A change was just merged into github yesterday that fixes some of the proxy support. Please try it out, or specifically, overwrite this file with your current copy:
https://github.com/GoogleCloudPlatform/gsutil/blob/master/gslib/util.py
I believe I am having the same problem with the proxy settings being ignored under Linux (Ubuntu 12.04.4 LTS) and gsutils 4.2 (downloaded today).
I've been watching tcpdump on the host to confirm that gsutils is attempting to directly route to Google IPs instead of to my proxy server.
It seems that on the first execution of a simple command like "gsutil -d ls" it will use my proxy settings specified .boto for the first POST and then switch back to attempting to route directly to Google instead of my proxy server.
Then if I CTRL-C and re-run the exact same command, the proxy setting is no longer used at all. This difference in behaviour baffles me. If I wait long enough, I think it will work for the initial request again so this suggests some form on caching taking place. I'm not 100% of this behaviour yet because I haven't been able to predict when it occurs.
I also noticed that it always first tries to connect to 169.254.169.254 on port 80 regardless of proxy settings. A grep shows that it's hardcoded into oauth2_client.py, test_utils.py, layer1.py, and utils.py (under different subdirectories of the gsutils root).
I've tried setting the http_proxy environment variable but it appears that there is code that unsets this.