SSL Error while installing any package from conda prompt - ssl

I use Anaconda Navigator for my machine learning experiments. Recently, I have started getting this strange SSL error no matter what I try to install using conda prompt. The error is SSL error. I am posting the error message that I get
Solving environment: failed
CondaHTTPError: HTTP 000 CONNECTION FAILED for url
https://repo.anaconda.com/pkgs/free/linux-64/repodata.json.bz2
Elapsed: -
An HTTP error occurred when trying to retrieve this URL. HTTP errors
are often intermittent, and a simple retry will get you on your way.
If your current network has https://www.anaconda.com blocked, please
file a support request with your network engineering team.
SSLError(MaxRetryError('HTTPSConnectionPool(host=\'repo.anaconda.com\',
port=443): Max retries exceeded with url:
/pkgs/free/linux-64/repodata.json.bz2 (Caused by
SSLError(SSLError("bad handshake: Error([(\'SSL routines\',
\'ssl3_get_server_certificate\', \'certificate verify
failed\')],)",),))',),)
I have an institutional proxy server; the credentials, apt.conf file etc are all OK.
Even then I am not able to install any package using conda.
Interestingly, I have installed numerous packages using conda prompt and I never faced any such error until recently. Also, I am able to follow the links (using the browser) given in the error message which means that the proxy is not blocking the site.
I was asked to use
conda config --set ssl_verify True
but even this did not help. Any help ?
I even entered the proxy server details as given in HTTP error while using conda for installation of any packages

Try copying these files from Anaconda3/Library/bin to Anaconda3/DLLs :
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll

When I had an SSL error related to conda on my work laptop behind a firewall, I had to set ssl_verify to false to get it to work.

This should do the job.
conda config --set ssl_verify False

This is due to .dll error
go to location where you've install anaconda3>Library>bin. search and copy following dll files
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll
and paste to anaconda3>DLLs.
then restart your pc.
issue will get resolved.

The following steps worked for me:
Use this command to see proxy_servers
conda config --show
This will remove saved proxy servers from anaconda configuration.
conda config --remove-key proxy_servers
conda clean --source-cache
Hope this helps you.

Related

NGROK failed to start the tunnel

I have been trying to run the shopify app in my local machine, but this error keeps popping up.
"Ngrok failed to start the tunnel"
Ngrok is successfully installed in my system, and env variable is also set to correct location.
Try using a different version of #shopify/app and #shopify/cli. I had the same problem with version 3.14.0 and I used 3.21.0. This solved my problem.
"#shopify/app": "3.21.0",
"#shopify/cli": "3.21.0",

ClipGrab - Error downloading youtube-dl: SSL handshake failed

I have downloaded YouTube videos using ClipGrab before (v3.8.11), but after updating it (to v3.9.6) I get an error.
First I am informed that an additional dependency "youtube-dl" must be downloaded.
But when I try to do this I get: Error downloading youtube-dl: SSL handshake failed
I tried installing youtube-dl separately using brew install youtube-dl and it appears to have succeeded, but ClipGrab doesn't see this installation, and still gives the SSL error.
I tried going back to my old version of ClipGrab (v3.8.11) but it now gives a different error: Could not retrieve video link. So maybe there is some server issue or other problem not local to the app, that is preventing the old version from working too.
(1) Is there a way to get around the SSL error or make ClipGrab recognize my brew installation of youtube-dl? (2) If there is no way to get the current v3.9.6 working, is there a way to get an older version working?
Thanks
Hopefully this will work for you (it worked for me). I'm on Kubuntu 22.04, I had to manually download yt-dlp:
mkdir -p ~/.local/share/ClipGrab/ClipGrab
wget -P ~/.local/share/ClipGrab/ClipGrab/ \
https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp
After that clipgrab started working
Not sure about Mac using homebrew but with Linux this was my solution.
Running kubuntu 22.04 Same SSL handshake error
Here is the fix that worked for me..
Download the yt-dlp file from:
https://github.com/yt-dlp/yt-dlp#release-files
The yt-dlp file found on that page it is the first file in the recommended listing column.
On your computer:
Allow your file manager to show invisible directories/files. Or navigate with the terminal.
Navigate to home/user/.local/share/ClipGrab/ClipGrab/yt-dlp
Overwrite the existing file which will be there but empty, with the file you downloaded from the above link.
Open ClipGrab and the SSL error will be gone and the app will function.

Elm install always fails with "ConnectionTimeout" error (in WSL)

I'm new to Elm. and I'm not good at English. So, if any ambiguous or wrong thing is there, please let me correct it.
----------- edit -----------
All my problem below is on WSL. when I'm trying on windows, all work fine. then... why elm install doesn't work on WSL? did you have any idea?
-------- problem --------
when I try to elm-test init, it doesn't work like below
$ elm-test init
Here is my plan:
Add:
elm/random 1.0.0
elm-explorations/test 1.2.2
Would you like me to update your elm.json accordingly? [Y/n]:
-- PROBLEM DOWNLOADING PACKAGE -------------------------------------------------
I was trying to download the source code for elm/random 1.0.0, so I tried to
fetch:
https://github.com/elm/random/zipball/1.0.0/
But my HTTP library is giving me the following error message:
ConnectionTimeout
Are you somewhere with a slow internet connection? Or no internet? Does the link
I am trying to fetch work in your browser? Maybe the site is down? Does your
internet connection have a firewall that blocks certain domains? It is usually
something like that!
but my Browser(Chrome) is working beautifully, and even in WSL (the environment that I run elm-test init command at) is too.
$ curl https://github.com/elm/random/zipball/1.0.0/
https://codeload.github.com/elm/random/legacy.zip/1.0.0<body>You are being redirected.</body></html>
then I also try again to redirect the URL
$ curl https://codeload.github.com/elm/random/legacy.zip
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
I think there's no Network Problem. My PC can connect with the repo, and I think it will be downloaded well.
I lastly tried just elm install, and that throws the same error too. it seems like Elm can't connect with the repo, even if My PC can.
$ elm install elm/random
Here is my plan:
Add:
elm/random 1.0.0
Would you like me to update your elm.json accordingly? [Y/n]:
-- PROBLEM DOWNLOADING PACKAGE -------------------------------------------------
I was trying to download the source code for elm/random 1.0.0, so I tried to
fetch:
https://github.com/elm/random/zipball/1.0.0/
But my HTTP library is giving me the following error message:
ConnectionTimeout
Are you somewhere with a slow internet connection? Or no internet? Does the link
I am trying to fetch work in your browser? Maybe the site is down? Does your
internet connection have a firewall that blocks certain domains? It is usually
something like that!
Please help me, what should I do?
I recently had reason to use WSL for elm development. It wasn't much fun and I'm glad to be back on Mac! What I found was that certain disk operations on WSL seemed to go very slowly and that could lead a variety of weird issues.
I was using Webstorm, which does not handle WSL well, so in the end I did everything on C: drive (rather than in /home/...) so that webstorm could run the windows version of elm-format, while my node development environment was run on the linux layer.
That's not a precise answer to your question but just to say that it can be done, but its not an ideal way to write Elm code in my experience
I had same issue and it was solved.
It was due to DNS server settings.
Create a file /etc/resolv.conf and write the following line.
nameserver 8.8.8.8
Then WSL will refer to Google Public DNS and works fine.
However, when restart WSL, the settings revert back.
Therefore, the following settings are also required.
Create a file /etc/wsl.conf and write the following line.
[network]
generateResolvConf = false
wsl --shutdown and restart WSL.
Reference link
https://github.com/microsoft/WSL/issues/4285#issuecomment-522201021

<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)>

I did the manual installation on python 3.7.5 on Debian 8, when I will run the script I get this error:
<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)>
I saw several questions here in the stackoverflow more regarding MacOS, In my case this error is in Linux.
I had the same issue. Here is what I found helped my problem.
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
Please see here for the original answer from markroxor. Hope it will help your problem as well.
I had
<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)>
With python3 3.9.2-3, and other python related packages with the same, or similar, version. On Debian GNU/Linux 11 (Bullseye).
At first, using the suggested
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
managed to solve the problem. Though I do not know if, and which, down sides, or other side effects, this solution has.
Afterwards, I noticed the /etc/ssl/certs/ folder is empty. Installing the ca-certificates package fills in this folder. Which seem to be another solution, in which those 2 python ssl lines are not required. You can see here the detailed list of files the ca-certificates package installed. This article, from 2015, with a last comment from 2017, discusses the location of ca-certificates in various OSs/distributions. I think the ca-certificates package is rather basic, and is usually installed as part of the initial installation of the machine. I do not know how it was missing from that particular machine.
What worked for my MacOs:
Open the finder
Find the version of Python that you are using
Open its folder
Click on the "Install Certificates.command". It will open a terminal and install the certificate.
In my case (Dell computer), the SSL problem was caused by Dell software itself:
reported here. In that case, according to this answer to another question in the SE network, you can solve the problem by running the following command:
sudo cp /usr/lib/x86_64-linux-gnu/libcrypto.so.3 /opt/dell/dcc/libcrypto.so.3
And then, run this:
sudo update-ca-certificates --fresh
It worked for me on a Dell Latitude 7310, LinuxMint21. November 2022.
THIS IS NOT A SOLUTION:
I have encountered that several times, note however that i'm using windows, but i would assume that generally the resolving mehtods should be the same in principle for mac/linux.
What i used to do is to force it to not verify the certificate by using the below:
conda config --set ssl_verify false
Note this is not a solution to the issue, it's just a way to make the code run temporarily, or if you're trying to download a library then that should do the trick until you download it. Note that the suggested below is not usually recommended, if you do it, after running your code/ downloading your library, remember to turn it back on using the below:
conda config --set ssl_verify true
If this happened after you installed a python version manually, inside the python app folder, double click on the "Install Certificates.command" file and it should fix it.

Setting up S3 logging in Airflow

This is driving me nuts.
I'm setting up airflow in a cloud environment. I have one server running the scheduler and the webserver and one server as a celery worker, and I'm using airflow 1.8.0.
Running jobs works fine. What refuses to work is logging.
I've set up the correct path in airflow.cfg on both servers:
remote_base_log_folder = s3://my-bucket/airflow_logs/
remote_log_conn_id = s3_logging_conn
I've set up s3_logging_conn in the airflow UI, with the access key and the secret key as described here.
I checked the connection using
s3 = airflow.hooks.S3Hook('s3_logging_conn')
s3.load_string('test','test',bucket_name='my-bucket')
This works on both servers. So the connection is properly set up. Yet all I get whenever I run a task is
*** Log file isn't local.
*** Fetching here: http://*******
*** Failed to fetch log file from worker.
*** Reading remote logs...
Could not read logs from s3://my-bucket/airflow_logs/my-dag/my-task/2018-02-15T21:46:47.577537
I tried manually uploading the log following the expected conventions and the webserver still can't pick it up - so the problem is on both ends. I'm at a loss at what to do, everything I've read so far tells me this should be working. I'm close to just installing the 1.9.0 which I hear changes logging and see if I'm more lucky.
UPDATE: I made a clean install of Airflow 1.9 and followed the specific instructions here.
Webserver won't even start now with the following error:
airflow.exceptions.AirflowConfigException: section/key [core/remote_logging] not found in config
There is an explicit reference to this section in this config template.
So I tried removing it and just loading the S3 handler without checking first and I got the following error message instead:
Unable to load the config, contains a configuration error.
Traceback (most recent call last):
File "/usr/lib64/python3.6/logging/config.py", line 384, in resolve:
self.importer(used)
ModuleNotFoundError: No module named
'airflow.utils.log.logging_mixin.RedirectStdHandler';
'airflow.utils.log.logging_mixin' is not a package
I get the feeling that this shouldn't be this hard.
Any help would be much appreciated, cheers
Solved:
upgraded to 1.9
ran the steps described in this comment
added
[core]
remote_logging = True
to airflow.cfg
ran
pip install --upgrade airflow[log]
Everything's working fine now.