Hi Nate,

Great to read from you :).

In the time between my request and your answer I tried out some things
starting from the codes and googled a lot. As I left the desk soon after I
could add it up to now. I'll try to keep it short and as comprehensible as
possible:

* The issue is related to Python itself, not necessarely Unix. 'wget' on
the URL you also used works fine, so proxying is ok.
* There are bugreports on the 'urllib' libraries (there are three of
them), for the two older ones there is no indication for a fix. Here
https://github.com/kennethreitz/requests/issues/1204
a bug report on the 'requests' module appears, the guys where waiting for
a fix in 'urllib3' (which was finally introduced). But: the tool shed
package comes around with libraries 'urllib' ad 'urllib2', only.
* Generally, it looks like the issue is due to a default behaviour of
Python 2.x's 'ssl' module that may have been no problem in the past: the
handshake is by default performed with SSLv2.3. As on a rising number of
servers SSLv2 gets deactivated for security reasons, connections fail
(SSLv3 is expected and maybe sent - client and server don't unterstand
each other anymore). Check out the second and third highest ranked answer
on this issue:
http://stackoverflow.com/questions/14102416/python-requests-requests-exceptions-sslerror-errno-8-ssl-c504-eof-occurred.
The second also includes a link to relevant line of code. For me it sounds
reasonable, but I am a relative noob on web protocols...

Consequently, the answer to your question is the following:

---
>>> import urllib
>>> urllib.urlretrieve("https://raw.githubusercontent.com/arq5x/gemini/master/versioning/0.18.0/requirements_conda.txt";)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/urllib.py", line 93, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "/usr/lib64/python2.6/urllib.py", line 239, in retrieve
    fp = self.open(url, data)
  File "/usr/lib64/python2.6/urllib.py", line 207, in open
    return getattr(self, name)(url)
  File "/usr/lib64/python2.6/urllib.py", line 441, in open_https
    h.endheaders()
  File "/usr/lib64/python2.6/httplib.py", line 914, in endheaders
    self._send_output()
  File "/usr/lib64/python2.6/httplib.py", line 786, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.6/httplib.py", line 745, in send
    self.connect()
  File "/usr/lib64/python2.6/httplib.py", line 1122, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/lib64/python2.6/ssl.py", line 338, in wrap_socket
    suppress_ragged_eofs=suppress_ragged_eofs)
  File "/usr/lib64/python2.6/ssl.py", line 120, in __init__
    self.do_handshake()
  File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake
    self._sslobj.do_handshake()
IOError: [Errno socket error] [Errno 1] _ssl.c:497: error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol
---

I also encountered the same error message when I try to install or update
Python packages via 'easy_install' or 'pip' - both cannot connect to
repositories. Also I don't know if the failed handshake is at the target
server or our proxy - any idea for a command to check this?

Finally, I am running out of ideas what to do, for me it looks like it is
too deep in the code for establishing a general workaround. On top, if I
interpreted correctly the findings from the above bullet point list, this
may have an impact on many pieces of software. For every case, where
Python 2.x-driven instances try to access repositories on servers not
offering SSLv2 anymore (maybe via proxy server).

Ideas? :)

Cheers,
Sebastian


> On Thu, Feb 11, 2016 at 12:43 PM, Sebastian Schaaf <
> sch...@ibe.med.uni-muenchen.de> wrote:
>
>> Hey all,
>>
>> I am currently trying to install Gemini (v0.18.1) via the test toolshed.
>> It finally fails in dependencies as 'package_gemini_0_18_1' finds
>> dependency 'gemini' to end in error state. There the message looks like
>> the following:
>>
>> ---
>> 2016-02-11 16:34:47 (72.4 MB/s) - `Miniconda-latest-Linux-x86_64.sh'
>> saved
>> [25416725/25416725]
>>
>> Python 2.7.11 :: Continuum Analytics, Inc.
>> Traceback (most recent call last):
>>   File "gemini_install.py", line 190, in <module>
>>     main(parser.parse_args())
>>   File "gemini_install.py", line 80, in main
>>     gemini = install_conda_pkgs(anaconda, remotes, args)
>>   File "gemini_install.py", line 97, in install_conda_pkgs
>>     urllib.urlretrieve(remotes["requirements_conda"], filename=req_file)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/urllib.py", line
>> 98, in urlretrieve
>>     return opener.retrieve(url, filename, reporthook, data)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/urllib.py", line
>> 245, in retrieve
>>     fp = self.open(url, data)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/urllib.py", line
>> 213, in open
>>     return getattr(self, name)(url)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/urllib.py", line
>> 443, in open_https
>>     h.endheaders(data)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/httplib.py", line
>> 1049, in endheaders
>>     self._send_output(message_body)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/httplib.py", line
>> 893, in _send_output
>>     self.send(msg)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/httplib.py", line
>> 855, in send
>>     self.connect()
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/httplib.py", line
>> 1274, in connect
>>     server_hostname=server_hostname)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/ssl.py", line
>> 352,
>> in wrap_socket
>>     _context=self)
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/ssl.py", line
>> 579,
>> in __init__
>>     self.do_handshake()
>>   File "/home/galaxy/tool_libs/python2.7/lib/python2.7/ssl.py", line
>> 808,
>> in do_handshake
>>     self._sslobj.do_handshake()
>> IOError: [Errno socket error] [SSL: UNKNOWN_PROTOCOL] unknown protocol
>> (_ssl.c:590)
>> ---
>>
>
> Hi Sebastian,
>
> I believe the URL that it's attempting to fetch is:
>
>
> https://raw.githubusercontent.com/arq5x/gemini/master/versioning/0.18.0/requirements_conda.txt
>
> Using the Python interpreter that your Galaxy instance is using, what
> happens if you do:
>
>   >>> import urllib
>   >>> urllib.urlretrieve("
> https://raw.githubusercontent.com/arq5x/gemini/master/versioning/0.18.0/requirements_conda.txt
> ")
>
> --nate
>
>
>>
>> Some browsing at Google brought hints on three common cases where this
>> could appear *plus* a fourth one which looks by error code pretty much
>> what I got:
>>
>>
>> http://blog.techstacks.com/2010/03/3-common-causes-of-unknown-ssl-protocol-errors-with-curl.html
>>
>> So, may I be right that there is a typo in an URL needed for downloading
>> during the setup process? Or is it, according to
>>
>> http://stackoverflow.com/questions/10667960/python-requests-throwing-up-sslerror
>> due to some failed SSL certificate check?
>>
>> Some help (or ideas for targeted checking) would be great :).
>>
>> Cheers,
>> Sebastian
>>
>> --
>> Sebastian Schaaf, M.Sc. Bioinformatics
>> Faculty Coordinator NGS Infrastructure
>> Chair of Biometry and Bioinformatics
>> Department of Medical Informatics,
>>  Biometry and Epidemiology (IBE)
>> University of Munich
>> DKTK Munich
>> Marchioninistr. 15, K U1 808
>> D-81377 Munich (Germany)
>> Tel: +49 89 4400 77499
>>
>> ___________________________________________________________
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>   https://lists.galaxyproject.org/
>>
>> To search Galaxy mailing lists use the unified search at:
>>   http://galaxyproject.org/search/mailinglists/
>


-- 
Sebastian Schaaf, M.Sc. Bioinformatics
Faculty Coordinator NGS Infrastructure
Chair of Biometry and Bioinformatics
Department of Medical Informatics,
 Biometry and Epidemiology (IBE)
University of Munich
DKTK Munich
Marchioninistr. 15, K U1 808
D-81377 Munich (Germany)
Tel: +49 89 4400 77499

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to