Opened 7 years ago
Closed 6 years ago
#1981 closed defect (worksforme)
E120171: Error running context: An error occurred during SSL communication
Reported by: | martinl | Owned by: | martin |
---|---|---|---|
Priority: | blocker | Milestone: | Sysadmin Contract 2018-I |
Component: | SysAdmin | Keywords: | svn, openssl |
Cc: |
Description
Dear SAC,
since today I am unable to update GRASS SVN repo:
Updating '.': svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/grass/grass/trunk' svn: E120171: Error running context: An error occurred during SSL communication
Could be related to recent changes in Debian regarding OpenSSL (1). Is there anything related to OSGeo server or just my issue? Thanks for clarification. Martin
(1) https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html
Change History (42)
follow-up: 2 comment:1 by , 7 years ago
comment:2 by , 7 years ago
Priority: | normal → critical |
---|
Replying to neteler:
An upgrade of the server configuration would be a good idea.
So I am taking liberty to increase priority. For now I will try to downgrade openssl package on my PC.
comment:3 by , 7 years ago
It looks like it'd take manually compiling libssl and mod_ssl. Or upgrade to a still supported Debian version (even backports repository has been obsoleted)
comment:5 by , 7 years ago
It looks like The version of gnutls on that server already supports TLS1.2
$ gnutls-cli -l | grep TLS1.2 Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2
And the apache module is available, so could be a viable path to switch to that. Only it might taking tweaking some apache configurations (/etc/apache is under a local git repository though, which should help)
comment:6 by , 7 years ago
For the record: Ubuntu 17.04 does not ship mod_ssl anymore, but it does ship mod_gnutls.
comment:7 by , 7 years ago
Just a ping, confirming the same issue for me. And yes, this happens after the Debian OpenSSL upgrade.
comment:8 by , 7 years ago
quick workaround on an affected client:
apt-get build-dep openssl apt-get source openssl cd openssl-1.1.0f sed -i -e "s/disable-tls1 disable-tls1_1/# &/" debian/rules DEB_BUILD_OPTIONS="nocheck parallel" dpkg-buildpackage -us -uc -b sudo dpkg -i ../libssl1.1_1.1.0f-4_amd64.deb
comment:9 by , 7 years ago
For those like me who receive comments by mail: the suggested workaround is for clients, not server (post-submit edit of trac comments are not notified by mail, the info was added later)
comment:10 by , 7 years ago
Thanks for the workaround. Are there any plans of upgrading the server so it supports 1.2+ ?
comment:12 by , 7 years ago
I don't have time to work on it, but if anyone else does I suggest to look at GNU-lts module (is avalable as packaged for the version of OS on that system).
comment:14 by , 7 years ago
Priority: | critical → blocker |
---|
comment:15 by , 7 years ago
Sigh. Hit the same on a debian testing based distro. :(
svn --version svn, version 1.9.7 (r1800392) compiled Aug 17 2017, 02:50:12 on x86_64-pc-linux-gnu svn co https://svn.osgeo.org/gdal/trunk/gdal svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/gdal/trunk/gdal' svn: E120171: Error running context: An error occurred during SSL communication apt-cache show subversion Depends: libsvn1 (= 1.9.7-2), libapr1 (>= 1.5.0), libaprutil1 (>= 1.3.2+dfsg), libc6 (>= 2.4), libldap-2.4-2 (>= 2.4.7), libsasl2-2 apt-cache show openssl | egrep 'Version' Version: 1.1.0f-4
comment:16 by , 7 years ago
I have run into similar issues when using Caddy (for proxying). This just highlights the fact we are desperately in need of upgrading the trac server. The OS is just too old. It's running Debian 6 which at this point is ancient.
comment:17 by , 7 years ago
In order to resolve this issue I'm planning to upgrade the TracSVN VM this Friday (2018-02-16) to a more recent version of Debian Linux. Outages will occur at some point in the process, reboot will be synced with OSL staff.
Currently the following VM's still run an outdated distro, some of which I'd prepare to upgrade as well:
secure / projects / web / download / tracsvn / wiki
comment:18 by , 7 years ago
Great news, thank you ! Please make sure to update the VM information on the wiki at the end of the upgrade process.
comment:19 by , 7 years ago
Upgrade to Debian7 on TracSVN VM is almost complete, please report features which might have gone lost.
comment:20 by , 7 years ago
Upgrade to Debian7 on Download VM is almost complete, please report features which might have gone lost.
comment:21 by , 7 years ago
martin,
Not sure if the TracSVN upgrade and ssl changes is related, but I noticed I'm not seeing our bot badges on PostGIS anymore. As I recall I think I saw all of them the day before.
I have a related ticket in our postgis tracker. https://trac.osgeo.org/postgis/ticket/4019
I still see the bot badges on github and gitea and confirm the images are there if called directly.
The net calls for the badges shows they are being cancelled and I get this notice
Request URL:https://debbie.postgis.net/buildStatus/icon?job=PostGIS_trunk Referrer Policy:no-referrer-when-downgrade Provisional headers are shown Origin:https://trac.osgeo.org Referer:https://trac.osgeo.org/postgis User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Mobile Safari/537.36 job:PostGIS_trunk
comment:22 by , 7 years ago
Forgot to mention page badges show. Dronie badges are currently showing for me but not any of the others
comment:23 by , 7 years ago
EDIT: I think I figured what you mean and I confirm more badges are available from their respective sources than shown on the "postgis" Trac page. I also confirm the visible result is different depending on which browser you use.
Looking at the page source delivered to the browser I'm unable to identify any syntax or related differences which might be making the difference, will look again later today using a larger screen.
comment:24 by , 7 years ago
Problem page is: https://trac.osgeo.org/postgis
Drone badges come from drone.osgeo.org, others come from non-osgeo domains (in case that matters).
comment:25 by , 7 years ago
Firefox on Linux renders only the alternate text for non-OSGeo-domains, with a quick chat about TLS handshake in the status bar shortly before the Dronie badges show up.
Chromium on Linux renders broken image URLs in every field for non-OSGeo-domains plus the alternate text, but if you open the underlying image in a new tab, it renders correctly.
Therefore I'd go with Sandro's idea, to me this smells like modern browsers refuse to reach out for badges from external sites - but currently I don't know how to "do it right" in this (Trac) context. Assistance is appreciated.
During the Debian update on the TracSVN machine the Trac software saw a minor update as well, because reinstall in Python2.7 was required. In order not to introduce any feature changes, I took the latest release from the same line, which is 1.2.2, together with the plugins listed in https://wiki.osgeo.org/wiki/Trac#Plugins
Now I wonder wether the update from the preceding 1.2.1-dev is making the difference ....
comment:26 by , 7 years ago
I'd look at the suggested CORS header, maybe it was previously done by Trac, maybe by Apache. We know browsers did not change so the change must be on the server side (we can't get back to check and compare the headers now...)
Do new headers say anything about allowed-origins ?
comment:27 by , 7 years ago
BTW, this discussion about badges should go in a separate ticket, this ticket was just about SSL
comment:30 by , 7 years ago
I think one or two VM's (Secure, maybe the Wiki) still require updating, before they or their respective services finally get migrated elsewhere.
May I assume the Web VM is now obsolete ?
comment:32 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:33 by , 7 years ago
Milestone: | → Sysadmin Contract 2018-I |
---|
comment:34 by , 7 years ago
comment:35 by , 7 years ago
The Wiki VM has been upgraded to Debian7 as well, this makes overall maintenance a little bit easier.
I *think* the secret to get a working GRUB on OSGeo's VM's is to install the "grub-legacy" package. Surprisingly there wasn't such thing on the Adhoc VM - maybe it's been upgraded again after the last successful reboot.
comment:36 by , 7 years ago
The Web VM has now been upgraded to Debian7.
For the sake of backwards compatibility with the old Drupal setup I took care of keeping the old PHP5 packages. Thus, the old web site should behave as it did before. If it doesn't, please report.
comment:37 by , 7 years ago
Now there are two Debian6 VM's left:
- Projects: I think the remaining projects should get migrated over to Osgeo6. The VM might subsequently turn into a reboot-testbed.
- Secure: Upgrading this one is rather simple, because SLAPD is its only service and it's already in config directory format. Can OSGeo afford a little LDAP hiccup during upgrade ?
comment:39 by , 7 years ago
From my experience with other VM migrations, I'd say the hiccup would last less than 5 minutes, because there's so little to upgrade on this VM.
Alternatively, we could make the current LDAP directory read-only, set up a read-only clone on Osgeo6, switch the "ldap.osgeo.org" DNS to Osgeo6, upgrade the secure VM, switch the DNS back to the secure VM.
Ideas, votes ?
comment:40 by , 7 years ago
I find the idea of setting up a read only clone useful in general, we could keep it ready and document how to do it again next time it will be needed, for any reason.
comment:42 by , 6 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Your assumption could be right:
https://www.ssllabs.com/ssltest/analyze.html?d=svn.osgeo.org&latest
--> " The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.
An upgrade of the server configuration would be a good idea.