We are trying to get the conda install (on windows 8) to work behind a firewall via a proxy server. Currently, we are able to use pip to install packages while on our company network by using this at the command prompt:
pip install pandas --proxy=http://abc.def.xyz.com:1234
No passwords need to be specified, just the proxy server and port. The conda documentation states that proxy servers are possible:
# Proxy settings: http://[username]:[password]#[server]:[port]
proxy_servers:
http: http://user:pass#corp.com:8080
https: https://user:pass#corp.com:8080
I have tried this with various combinations to see if I can get it to work with or without putting in my username and password.
# formats tried:
http: http://user:pass#abc.def.xyz.com:1234
http: http://abc.def.xyz.com:1234
I cannot seem to get it to work. Tried various combinations of quoting things too (passwords have special chars). Also tried with and without the domain\user.
I can see under the hood, conda is using urlib3 (while pip may be using urlib proxy handler?). Note that having your username and password in a file is generally frowned upon.
I know we could set up our own http or file location channel and put all the packages there and add the channel to the .condarc config settings. However I would prefer not to have to manage a repository of packages and versions locally.
So.... is there a way to specify, in the .condarc file the proxy server and port (without user and password) so that conda install works behind a firewall just like pip install on the command line? Or even an inline call like pip has and works... something like:
conda install pandas --proxy=abc.def.xyz.com:1234
Thanks in advance...
PS: I really love conda. I spent last weekend setting up many virtual environments on my home PC. Documentation was great and everything worked flawlessly. Overall, much better than pip... if only we could only get this to work inside our company :)
Well, this is embarrassing, but good news. I solved my problem with one more attempt at a change in the condarc file.
https: https://abc.def.xyz.com:1234
I guess pip worked ok with regular http, while conda's addresses are all https sites:
https://repo.continuum.io/pkgs/free/win-64/
I should have caught that!
Well, I am now just happy that we have a solution to use conda behind our firewall, and without needing a user and password. Awesome!
Late answer but maybe other people faced with this problem can benefit.
Create a .condarc file contaninig :
channels:
- defaults
# Show channel URLs when displaying what is going to be downloaded and
# in 'conda list'. The default is False.
show_channel_urls: True
allow_other_channels: True
proxy_servers:
http: http://172.**.*.***:8080
https: https://172.**.*.***:8080
ssl_verify: False
Change IP adresses with your own proxy settings.
Put this file in your user's main folder (for me : C:\Users\bakayim)
Restart your anaconda prompt
Open Anaconda command and execute below command:
set HTTP_PROXY=http://username:password#proxyurl.com:8080
set HTTPS_PROXY=https://username:password#proxyurl.com:8443
I also set 2 Windows environment variables: (don't know if it was necessary)
Name: http_proxy
Variable: http://username:password#Proxyadresse:Proxyport
Name: https_proxy
Variable: https://username:password#Proxyadresse:Proxyport
what wokred for me was the following .condarc file
channels:
- r
- defaults
proxy_servers:
http: http://username:password#Proxyadresse:Proxyport
https: https://username:password#Proxyadresse:Proxyport
ssl_verify: true
I can confirm that .condarc didn't have desired effect in my case (Windows 7). With conda info I could verify that it was loaded but it didn't have any effect.
I had to set forementioned environment variables in order to get connection from behind a proxy.
I was done as follows in command prompt:
set http_proxy=[protocol:your_proxy_address_here:port]
set https_proxy=[protocol:your_proxy_address_here:port]
Remove brackets. To verify (list) your concurrent settings just type: set
The new version of Anaconda comes with .condar file in the user directory C:\Users\User_name\.condarc.
so all to do is just to edit the content as below:
channels:
- defaults
show_channel_urls: True
allow_other_channels: True
proxy_servers:
http: http://172.**.*.***:8080
https: https://172.**.*.***:8080
ssl_verify: true
That's what worked for me.
Related
I just updated my anaconda distribution using conda update --all. There were a few debug messages during the update but it otherwise finished successfully. However, now I can't update any packages. Any time I try, I now get this error:
I am working through a company proxy, but have verified that the proxy info in my .condarc file is accurate. I've also verified that anaconda.com is not blocked by my company. Additionally, I was previously able to update packages without this error. I get this error regardless of which package I try to update, or whether I specify a specific channel. Does anyone have any idea what this could be?
Here's my .condarc settings (excluding proxy information for obvious reasons):
ssl_verify: false
channel_priority: disabled
channels:
defaults
conda-forge
Here are the results of "conda info":
Any idea what the fix for this is?
found the answer (sort of)! It’s something to do with urllib3. I reinstalled conda and pinned urllib3 to version 1.25.11, and now conda updates fine!
I'm trying to use pip install <package> but it always returns a timeout error as follows:
I'm using Python 3.8 and pip 20.2.1 in Windows Server 2019.
I assume that it's a problem related to pip can't reach pypl.org site.
I checked proxy configuration and it is as follows, i.e., there's no proxy configuration:
What I think is strange is that I can access the site using Chrome and download it manually. I can't find anything that is blocking pip access.
What can that be?
Thanks!
For someone that is facing the same problem, I needed to set a proxy in AWS instance. Now its working like a charm.
I also created two global environment variables
HTTP_PROXY = http://proxyIP:proxyPORT
HTTPS_PROXY = https://proxyIP:proxyPORT
Hope this is usefull for someone else.
Thanks!
I am using conda version 3.19.0 from Ubuntu 14.04 64-bit. When I try conda update conda I receive:
$ conda update conda
Fetching package metadata: .......Error: Could not find URL: http://repo.continuum.io/pkgs/gpl/linux-64/
The output of conda --debug update conda is not very informative in this case. But I did notice at http://repo.continuum.io/pkgs/ that the correct URL now seems to be:
http://repo.continuum.io/pkgs/free/linux-64/
Is there a way to change conda's configuration to look there instead of the gpl/linux-64 URL that appears to be deprecated?
I have never manually adjusted .condarc. Will removing the /gpl/... URL there solve it without requiring me to do additional manual URL management and without compromising any other conda defaults or settings?
As you suspect, this error is caused by an offending entry in your ~/.condarc, namely the following entry under channels:
http://repo.continuum.io/pkgs/gpl
Remove or comment this entry s.t. you're left with the following:
channels:
- http://repo.continuum.io/pkgs/free
i am integrating paypalrestsdk in my AppEngine project. When, using my local dev_appserver, i try to create a payment on the PayPal sandbox, i have the following error:
SSLCertificateError: Invalid and/or missing SSL certificate for URL: https://api.sandbox.paypal.com/v1/oauth2/token
So, i have tried to provide the correct pem file, downloading it from here and setting up the correct ssl_option attribute:
# Setting up the correct path to the .pem file
cert = os.path.join(ROOT, 'certs/api.sandbox.paypal.com_SHA-2_01132018.pem')
logger.info("Using SSL certificate: %s", cert)
return Api(
mode=get_paypal_environment(), # sandbox or live
client_id=flask.current_app.config["PAYPAL_CLIENT_ID"],
client_secret=flask.current_app.config["PAYPAL_CLIENT_SECRET"],
ssl_options={"cert": cert}
)
Here there is the PayPalRestSDK documentation that gives details on how to provide certificate. I have double checked the path created is correct.
I have have found a bug report here that talks about a similar problem.
Also, i have tried the solution suggested here and still does not work.
On a live instance, on appspot, this all works perfectly.
Here's the relevant part of my requirements.txt:
Flask==0.10.1
itsdangerous==0.24
paramiko==1.15.1
pycrypto==2.6.1
Flask-OAuthlib==0.9.1
google-api-python-client==1.4.0
paypalrestsdk==1.11.1
requests[security]==2.9.1
Is anyone having the same issue ?
OK, I believed I've solved this one, at least in my case, which I'll describe below.
This seemed to be due to two issues:
Issue #1) PayPal is migrating to supporting only TLS 1.2, and has started by switching over the sandbox URLs, with the production URLs to come later. This explains why things are broken only when connecting from the sandbox, and why it used to work but doesn't now. More on this here.
Issue #2) My local install of Python didn't support TLS 1.2. Here is an easy way to check:
$ python
>>> import ssl
>>> print ssl._PROTOCOL_NAMES
If you don't see PROTOCOL_TLSv1_2 listed, this is definitely the issue. In my case, I was using the builtin version on Python on Mac OS X 10.11, which had a pretty old version on OpenSSL built in.
So how to fix it? Well, in my case, this worked pretty well (copied mostly from here):
$ brew update
$ brew install openssl
$ brew link openssl --force
$ brew install python --with-brewed-openssl
$ sudo ln -s /usr/local/Cellar/python/2.7.11/bin/python /usr/local/bin/python
Now if you run the test I listed above, you should see the 1.2 protocol listed.
This should make everything work again, good luck!
I am trying to checkout a subversion repository using PIP, since I am under a proxy I am calling PIP using the --proxy parameter:
pip install svn+http://django-compress.googlecode.com/svn/trunk/ --proxy=myproxy:8080
While PIP itself works fine under the proxy, it seen that its not passing the proxy parameter to the SVN client:
Downloading/unpacking svn+http://django-compress.googlecode.com/svn/trunk/
Checking out http://django-compress.googlecode.com/svn/trunk/ to c:\users\canassa\appdata\local\temp\pip-x_w9ct-build
svn: OPTIONS of 'http://django-compress.googlecode.com/svn/trunk': could not connect to server (http://django-compress.googlecode.com)
Complete output from command "C:\Program Files\SlikSvn\bin\svn.exe" checkout -q http://django-compress.googlecode.com/svn/trunk/ c:\users\canassa\appdata\local\temp\pip-x_w9ct-build:
----------------------------------------
Command "C:\Program Files\SlikSvn\bin\svn.exe" checkout -q http://django-compress.googlecode.com/svn/trunk/ c:\users\canassa\appdata\local\temp\pip-x_w9ct-build failed with error code 1
Storing complete log in C:\Users\canassa\AppData\Roaming\pip\pip.log
To make things worst I am under a Windows environment and using the SilkSVN client. I also have to switch off the proxy a few times every day since its a notebook and I have to connect it with the wireless, which don't uses a proxy.
My question is if there is a way to handle the SlikSvn proxy under PIP and Windows. Preferably making easy to switch it off when I need.
It is an open bug[1] and there is not solution to this problem right now.
If you find an answer, please, comment in pip's issue tracker.
[1] - https://github.com/pypa/pip/issues/227