We are trying to connect to the snowflake instance using snowflake-sqlalchemy library (latest version).
Getting next error:
[2020-09-28 14:47:47,558] {{connection.py:409}} WARNING - Certificate did not match expected hostname: xxxxxxx.europe-west4.snowflakecomputing.com. Certificate: {'subject': ((('commonName', '*.us-west-2.snowflakecomputing.com'),),), 'subjectAltName': [('DNS', '*.us-west-2.snowflakecomputing.com'), ('DNS', '*.snowflakecomputing.com'), ('DNS', '*.global.snowflakecomputing.com'), ('DNS', '*.prod1.us-west-2.aws.snowflakecomputing.com'), ('DNS', '*.prod2.us-west-2.aws.snowflakecomputing.com'), ('DNS', '*.us-west-2.aws.snowflakecomputing.com')]}
Seems like the certificates for the snowflake instance do not match the host.
Is there any way to resolve this issue?
This is on a trial account if that matters.
As noted by #Suzy Lockwood, the domain being generated is wrong. The reason it ends up pointing to *.us-west-2.snowflakecomputing.com is because the target, lacking the gcp or azure ends up getting a redirect to us-west-2, where (of course) the certificate is wrong for what was expected.
The solution (for me) turned out to be that region needs the .azure suffix, not just the region. I'd given it that information under 'account' - I'm not sure if the presence of the region parameter got in the way, or if both are needed. But, it is working now, and I'm loathe to touch it more today. :)
I noticed europe-west4. Is that a GCP account? If so, I think your URL/hostname is supposed to look like this, but you can double-check in the UI:
XXXXX.europe-west4.GCP.snowflakecomputing.com
The airflow snowflake objects are built for AWS, and not compatible for GCP so I will need to find GCP versions or create GCP compatible versions.
I think this is how you would solve the issue. The account name should also contain the gcp. as shown in the article above
{
"account":"xxxxx.us-central1.gcp",
"warehouse":"COMPUTE_WH",
"region":"us-central1",
"database":"CITIBIKE",
"schema":"PUBLIC"
}
Related
I have been developing Standard Logic Apps with SQL Server successfully for some time, but suddenly can no longer connect. I'm using Azure AD Integrated as my Authentication Type, which I know is OK as I use the same credentials in SSMS. If I try to create a new credential, it is apparently successful but on save the Logic App says "The API connection reference XXX is missing or not valid". Something has changed, but I don't know what ... help!
per above, this was submitted to M/S and has been resolved as follows: the root cause is if a Logic App Parameter name includes an embedded space the problem with SQL connections is triggered. This is a pernicious problem, as the error message is quite unrelated to the root cause. Further, since embedded spaces are supported in Logic Apps e.g. in Step Names, it is easy to assume the same applies across the board.
I have successfully installed SnowSQL Client version 1.2.5 and while trying to get log into my snowflake account, using account id, username and password, I am somehow unable to connect and get following error:
snowsql unable to log in
This appears to be networking issue. Have you tried to set that debug logging as directed?
To assist in situations like this, Snowflake has a tool which could help you determine if your client host is able to access all required network endpoints for your Snowflake account, it's called SnowCD, the documents are here and the installation is fairly straightforward:
https://docs.snowflake.com/en/user-guide/snowcd.html
I'd recommend trying SnowCD as your first step, the next step would be to review any required proxy settings your organization might have. I'd also double-check your "account name" argument, the URL looks OK to me but there is a nice writeup on the account name construction at this link:
https://docs.snowflake.com/en/user-guide/connecting.html#your-snowflake-account-name
I hope this helps...Rich
THANKS Rich for doing some R&D and sharing proposals. I got successfully logged into snowsql by providing my account id till ".aws". Hope it will help others struggling so far, like myself:
https://docs.snowflake.com/en/user-guide/getting-started-tutorial-log-in.html
demo log in
I am trying to access Datastore Admin on Google App Engine but I get Unable to resolve the server's DNS address error.
The url that cannot be translated is: [https protocol]ah-builtin-python-bundle-dot-[myapp].gene.com/_ah/datastore_admin/?app_id=s~gene.com:[myapp]&adminconsolecustompage
I tried with adding exceptions to coookies because when I try directly access it with [http protocol][myapp].gene.com/_ah/datastore_admin I get error with redirect loop.
Any idea? Any workarounds are also welcomed - I just need to copy datastore to local environment.
Witek
Thank you, Patrick.
Your guess turned out to be the right one. The domain is not set up properly and this is the reason of problems.
I tried to set up WordPress under Google App Engine earlier tonight (following the instructions here: https://developers.google.com/appengine/articles/wordpress).
It runs fine locally, but when I push to remote I get a database error (visible at https://wp-dot-frontiermediag.appspot.com/). If we throw on a /wp_admin/install.php you get:
This either means that the username and password information in your
wp-config.php file is incorrect or we can't contact the database server
at :/cloudsql/frontiermediag:fmwp. This could mean your host's database
server is down.
Here's the relevant code in wp-config:
/** MySQL hostname */
if(isset($_SERVER['SERVER_SOFTWARE']) && strpos($_SERVER['SERVER_SOFTWARE'],'Google App Engine') !== false) {
define('DB_HOST', ':/cloudsql/frontiermediag:fmwp');
}else{
define('DB_HOST', 'localhost');
}
frontiermediag:fmwp is showing "Status Runnable" in Developers Console > Cloud SQL.
I did this once before and it worked so I'm not sure what I'm missing here. I thought it might have been because I'm using WP 3.8.1. but rolled back to 3.5.1 and same thing's happening.
Any ideas? frontiermediag is listed as an authorized application on the :fmwp ACL.
This situation happened to me earlier.However, I edited my Cloud SQL instance , and set "Preferred Location" as "Follow App Engine App" from Google Developers Console. This database connection problem was solved in my case.
I tried the instructions with wordpress 3.5.1 and the instructions seem to work for me. The code snippet you have above seems right and I am not sure what could be wrong without looking at rest of your code. Can you try the instructions from the beginning one more time with 3.5.1?
I had this issue, because "Follow App Engine App" doesn't seem to be an option for second generation instances in my case, and so the instance connection name includes the region setting.
Look at the instance details, and under properties, find "Instance connection name". That is the text that should follow :cloudsql/.
I am a DBA, not a developer, so forgive me if this is a silly question. But we are having issues with a SQL Server 2005 Web Service end point. On the local network I am able to add the reference in Visual Studio 2010 with out any issues. It uses digest as the authentication scheme.
However, when anyone tries to add the web reference on another network, such as a developer in New Zealand (we are in Dayton, OH USA) he receives this error:
There was an error downloading
'http://server.domain.net:1280/release-single-address?wsdl'. The
request failed with HTTP status 505: HTTP Version not supported.
Metadata contains a reference that cannot be resolved:
'http://server.domain.net:1280/release-single-address?wsdl'. The
remote server returned an unexpected response: (505) HTTP Version not
supported. The remote server returned an error: (505) Http Version Not
Supported. If the service is defined in the current solution, try
building the solution and adding the service reference again.
Again, this works in Visual Studio as Right Click add Reference -> Advanced -> Add Web Reference when done on the local subnet as the server.
When done on any other network the service does not import. We have tried it w/o any proxy. There is a cross domain trust involved but that does not seem to be the issue as the error occurs using accounts from either domain. When I download the raw XML to my hdd I can use that to create the web reference. I believe firmly this is some sort of transport layer issue, such as a proxy, but captures when the proxy server settings are disabled are not conclusive.
Today, years after I posted this question, we finally found the answer to this question. It was not a Squid proxy server as we had come to believe. We continued experiencing issues like this with various web services/sites. The last straw was when we finally needed to deploy an SVN server that was used by multinational software engineering teams. Every single member of the different Ops teams we spoke to swore to us there was nothing between the sites that could break our services.
By a stroke of luck the company's Chief Information Security Officer was visiting our site and a colleague happened to run into him and asked about the issues we were having and what might be the cause of it. He said immediately that there were Riverbed appliances doing caching and layer 7 inspection on all WAN traffic. We finally managed to catch these devices in the act of attempting to "normalize" HTML and XML and we were able to perform a capture of data coming from a machine in New Zealand. We performed a diff on HTML pages that were served as well as XML coming from a web service to compare how it looked on the local network vs. across the WAN. In the pages/XML that were being served across the WAN the closing tags were inserted that were not needed or that actually made the XML malformed. Some tags were even commented out entirely if the appliance didn't know what to do with them. And the smoking gun? A custom header...
X-RBT-Optimized-By: cch-riverbed-1 (RiOS 6.5.6a) SC
"Optimized" You keep using that word, but I do not think that it means what you think that it means.
I'm not a pro of SOAP with VS but it may be that version of SOAP is incompatible with sql server 2005?
If I recall correctly, there is two versions of SOAP: 1.1 and 1.2.
Check the HTTP GET command format is correct?
HTTP GET http:// mydomain.com HTTP/1.1\
note there is a SPACE between 'http://' and 'mydomain.com'. The server can not match this format. The result is 505
I am not sure but, I think you should check your firewall or your IIS configuration.