Mark - thanks for jumping in the thread! Did Stretch ever start working for you again?
I tried installing the Stretch Boinc and dependencies on a jessie system and it was no joy. Right now, I have a fresh Jessie lite machin that I did apt-get upgrade on BEFORE I installed boinc. Going to install boinc now and see what happens.
ETA: ...and we're back. That did nothing at all!
25-Jan-2016 21:27:30 [---] This computer is not attached to any projects
25-Jan-2016 21:27:30 [---] Visit http://boinc.berkeley.edu for instructions
25-Jan-2016 21:27:31 Initialization completed
25-Jan-2016 21:28:38 [---] Running CPU benchmarks
25-Jan-2016 21:28:38 [---] Suspending computation - CPU benchmarks in progress
25-Jan-2016 21:28:38 [---] Running CPU benchmarks
25-Jan-2016 21:29:10 [---] Benchmark results:
25-Jan-2016 21:29:10 [---] Number of CPUs: 1
25-Jan-2016 21:29:10 [---] 341 floating point MIPS (Whetstone) per CPU
25-Jan-2016 21:29:10 [---] 1400 integer MIPS (Dhrystone) per CPU
25-Jan-2016 21:29:11 [---] Resuming computation
25-Jan-2016 21:29:16 [http://einstein.phys.uwm.edu/] Master file download succeeded
25-Jan-2016 21:29:21 [http://einstein.phys.uwm.edu/] Sending scheduler request: Project initialization.
25-Jan-2016 21:29:21 [http://einstein.phys.uwm.edu/] Requesting new tasks for CPU
25-Jan-2016 21:29:24 [---] Project communication failed: attempting access to reference site
25-Jan-2016 21:29:24 [http://einstein.phys.uwm.edu/] Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates
25-Jan-2016 21:29:27 [---] Internet access OK - project servers may be temporarily down.
Mark - thanks for jumping in the thread! Did Stretch ever start working for you again?
I have 3 Pi2's running Stretch without any problem.
The B+ was running fine until the libc6 came along and killed the 1.06 BRP4 app. That is when I went back to Jessie. As we can see it seems that ca-certificates for 2014 with the deb8u1 label looks like the culprit for the connection issue. I'm not sure if you can install the old ca-certificates and use that.
Another alternative might be to get fully upgraded to Stretch, which should fix the connection issue, get the source for the 1.06 BRP4 app and recompile it on Stretch. Along a similar line the project could also do it and have a "beta" version of the app that is suited to Stretch.
We "broke" one of bikemans Pi2 yesterday in an effort to reproduce. To me it seems that the ca-certificates version 20141019+deb8u1 which is a partial backport of 20150426 from Stretch, essentially missing these updates:
Quote:
* debian/postinst:
Set mode and group of /usr/local/share/ca-certificates based on current
/usr/local permissions and ownership. Closes: #611501
* sbin/update-ca-certificates:
Allow customisation of the paths used by update-ca-certificates.
Add an option to set the certs in a directory to the defaults.
Thanks for the patches, Paul Wise. Closes: #774059, #774201
Fix shellcheck warnings and a little indentation.
* sbin/update-ca-certificates.8:
Correct concatenated file name in man page from certificates.crt to
ca-certificates.crt. Closes: #782230
Next thing I would like to check is file/directory permissions in /etc/ssl/certs and /usr/local/share/ca-certificates. I'm installing the Jessie Image on a Raspberry and run some tests. There is something buggy with this deb8u1 update.
If that were the case, then wouldn't installing the stretch version of ca-certificates fix the issue (dated 2016 in stretch as of yesterday). That wasn't the case. I tried to do a dist-upgrade for stretch last night, but that didn't seem to work (almost certainly user error - it was late and I was in a hurry).
Thanks to everyone who has been trying to troubleshoot and fix the issue. Please let me know if there is any other information I can provide to be helpful.
I did a little more testing and here is my preliminary conclusion. The +deb8u1 update of ca-certificates removed the "Thawte Premium Server CA" certificate. Which is correct since this was superseded by "thawte SSL CA - G2". Our SSL certificates are cross-signed with both certificates so they also work on older Windows clients where "thawte SSL CA - G2" is not available. In order to allow such old Clients to verify this alternate certificate chain we have to send both chains. And here is the problem. Newer curl versions (Stretch is on 7.46.0-1) seem to check both chains and if one is verified the connection is established. The older curl version on Jessie (7.38.0-4+deb8u2) seems to behave different, in that it either only checks the first chain it gets or it checks both and both must be verified.
I cross checked this with WCG (they use the same chains) and I couldn't get a connection there either. Connections to our servers that don't have this dual chain work.
We'll discuss tomorrow on how to solve this from our end. The problem is that it affects all Jessie installation not only Raspberry ones and I have to test how old Windows BOINC Clients react to our changes.
The short term solution is to roll-back to 20141019 on Jessie and hold the package on this version.
Edit: Here is what I did to get the missing certificate back. Please make sure you have the package downloaded before purging!
I can't test this tonight. Also I tried to dist-upgrade from Jessie to stretch but now wireless won't work so I'll try a cleanly updated image tomorrow.
Is there something they will need to do to fix this in Debian? Even if you do something in Bonc, Jessie will still need to pick it up?
We'll discuss tomorrow on how to solve this from our end. The problem is that it affects all Jessie installation not only Raspberry ones and I have to test how old Windows BOINC Clients react to our changes.
What "it", the problem or the solution? I can only repeat that BOINC works for me on a fully updated Jessie amd64.
We'll discuss tomorrow on how to solve this from our end. The problem is that it affects all Jessie installation not only Raspberry ones and I have to test how old Windows BOINC Clients react to our changes.
What "it", the problem or the solution? I can only repeat that BOINC works for me on a fully updated Jessie amd64.
"It" means the problem that the client can't connect to scheduler.einsteinathome.org via HTTPS.
I setup a fresh Jessie VM on amd64 and can reproduce the problem. Are you sure you have curl 7.38.0 and the latest ca-certificates? It's the combination of the two that seems to be the problem. Stretch uses a newer curl version but essentially the same certificates and I don't see the problem there.
If your client still connects to einstein5.aei.uni-hannover.de it does not use SSL and therefore would be working. But as soon as the scheduler URL is updated to the SSL one you will have the problem described here.
By the way, libcurl3-gnutls is also installed but I don't see it being used. On Jessie both curl and boinc are linked against libcurl3 while on Stretch curl has switched to libcurl3-gnutls. Perhaps that matters somehow.
Edit: Ooops, just noticed the missing "s" in the URL. Will change that manually and see what happens.
Edit2: You are right, I'm locked out. Sorry for the noise.
I narrowed it down to openssl in the meantime. You are correct that curl on Stretch is build with GNUtls and doesn't have the problem. Also GNUtls on Jessie is also working. Only Openssl in Jessie can not correctly resolve the cross signed certificate chain (in Stretch this works). This can be verified by running the openssl client directly:
Jessie uses OpenSSL 1.0.1k 8 Jan 2015 and Stretch OpenSSL 1.0.2e 3 Dec 2015. We are still investigating if there is a quick fix we can apply but it seems that we have to escalate this to the Debian openssl or ca-certificates maintainers. I'll keep you posted.
Mark - thanks for jumping in
)
Mark - thanks for jumping in the thread! Did Stretch ever start working for you again?
I tried installing the Stretch Boinc and dependencies on a jessie system and it was no joy. Right now, I have a fresh Jessie lite machin that I did apt-get upgrade on BEFORE I installed boinc. Going to install boinc now and see what happens.
ETA: ...and we're back. That did nothing at all!
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: Mark - thanks for
)
I have 3 Pi2's running Stretch without any problem.
The B+ was running fine until the libc6 came along and killed the 1.06 BRP4 app. That is when I went back to Jessie. As we can see it seems that ca-certificates for 2014 with the deb8u1 label looks like the culprit for the connection issue. I'm not sure if you can install the old ca-certificates and use that.
Another alternative might be to get fully upgraded to Stretch, which should fix the connection issue, get the source for the 1.06 BRP4 app and recompile it on Stretch. Along a similar line the project could also do it and have a "beta" version of the app that is suited to Stretch.
BOINC blog
We "broke" one of bikemans
)
We "broke" one of bikemans Pi2 yesterday in an effort to reproduce. To me it seems that the ca-certificates version 20141019+deb8u1 which is a partial backport of 20150426 from Stretch, essentially missing these updates:
Next thing I would like to check is file/directory permissions in /etc/ssl/certs and /usr/local/share/ca-certificates. I'm installing the Jessie Image on a Raspberry and run some tests. There is something buggy with this deb8u1 update.
If that were the case, then
)
If that were the case, then wouldn't installing the stretch version of ca-certificates fix the issue (dated 2016 in stretch as of yesterday). That wasn't the case. I tried to do a dist-upgrade for stretch last night, but that didn't seem to work (almost certainly user error - it was late and I was in a hurry).
Thanks to everyone who has been trying to troubleshoot and fix the issue. Please let me know if there is any other information I can provide to be helpful.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
I did a little more testing
)
I did a little more testing and here is my preliminary conclusion. The +deb8u1 update of ca-certificates removed the "Thawte Premium Server CA" certificate. Which is correct since this was superseded by "thawte SSL CA - G2". Our SSL certificates are cross-signed with both certificates so they also work on older Windows clients where "thawte SSL CA - G2" is not available. In order to allow such old Clients to verify this alternate certificate chain we have to send both chains. And here is the problem. Newer curl versions (Stretch is on 7.46.0-1) seem to check both chains and if one is verified the connection is established. The older curl version on Jessie (7.38.0-4+deb8u2) seems to behave different, in that it either only checks the first chain it gets or it checks both and both must be verified.
I cross checked this with WCG (they use the same chains) and I couldn't get a connection there either. Connections to our servers that don't have this dual chain work.
We'll discuss tomorrow on how to solve this from our end. The problem is that it affects all Jessie installation not only Raspberry ones and I have to test how old Windows BOINC Clients react to our changes.
The short term solution is to roll-back to 20141019 on Jessie and hold the package on this version.
Edit: Here is what I did to get the missing certificate back. Please make sure you have the package downloaded before purging!
I can't test this tonight.
)
I can't test this tonight. Also I tried to dist-upgrade from Jessie to stretch but now wireless won't work so I'll try a cleanly updated image tomorrow.
Is there something they will need to do to fix this in Debian? Even if you do something in Bonc, Jessie will still need to pick it up?
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: We'll discuss tomorrow
)
What "it", the problem or the solution? I can only repeat that BOINC works for me on a fully updated Jessie amd64.
RE: RE: We'll discuss
)
"It" means the problem that the client can't connect to scheduler.einsteinathome.org via HTTPS.
I setup a fresh Jessie VM on amd64 and can reproduce the problem. Are you sure you have curl 7.38.0 and the latest ca-certificates? It's the combination of the two that seems to be the problem. Stretch uses a newer curl version but essentially the same certificates and I don't see the problem there.
If your client still connects to einstein5.aei.uni-hannover.de it does not use SSL and therefore would be working. But as soon as the scheduler URL is updated to the SSL one you will have the problem described here.
RE: Are you sure you have
)
Machine #12133872 has ca-certificates 20141019+deb8u1 and libcurl3 7.38.0-4+deb8u2 installed. The scheduler URL is http://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi.
By the way, libcurl3-gnutls is also installed but I don't see it being used. On Jessie both curl and boinc are linked against libcurl3 while on Stretch curl has switched to libcurl3-gnutls. Perhaps that matters somehow.
Edit: Ooops, just noticed the missing "s" in the URL. Will change that manually and see what happens.
Edit2: You are right, I'm locked out. Sorry for the noise.
I narrowed it down to openssl
)
I narrowed it down to openssl in the meantime. You are correct that curl on Stretch is build with GNUtls and doesn't have the problem. Also GNUtls on Jessie is also working. Only Openssl in Jessie can not correctly resolve the cross signed certificate chain (in Stretch this works). This can be verified by running the openssl client directly:
openssl s_client -connect scheduler.einsteinathome.org:443 -servername scheduler.einsteinathome.orgJessie uses OpenSSL 1.0.1k 8 Jan 2015 and Stretch OpenSSL 1.0.2e 3 Dec 2015. We are still investigating if there is a quick fix we can apply but it seems that we have to escalate this to the Debian openssl or ca-certificates maintainers. I'll keep you posted.