Looks like file names may be slightly different in Red Hat for the record the ca-bundle.crt on Ubuntu is by default in /var/lib/boinc-client/


For what it's worth, on Ubuntu that entry in boinc-client is a link to /etc/ssl/certs/ca-certificates.crt, which gets updated as necessary - I would expect most Linux distributions that have a properly curated BOINC client package to do something similar, but I could be wrong :-)

And I note that we still have the (internal to CPDN) PHP warnings at the top of every page, so it looks like Oxford have some sorting out to do anyway...

Cheers - Al.

[Edit...] P.S. The certificate bundle was most recently updated on 28th September, 2021, round about when this root certificate expired.

This is very interesting. My RHEL 8.4 release of Linux seems somewhat different from the one on Ubuntu. They agree on where the Boinc client stuff goes (/var/lib/boinc except Ubuntu calls it boinc-client. In RHEL8..4, the actual programs are in /usr/bin

[/usr/bin]$ ls -l boinc*
-rwxr-xr-x. 2 root root 1112736 Nov 11  2020 boinc
-rwxr-xr-x. 2 root root 1112736 Nov 11  2020 boinc_client
-rwxr-xr-x. 1 root root  359344 Nov 11  2020 boinccmd
-rwxr-xr-x. 1 root root 4078376 Nov 11  2020 boincmgr
-rwxr-xr-x. 1 root root  351128 Nov 11  2020 boincscr

Note that for some reason, both boinc and boinc_client are the same:
[/usr/bin]$ cmp boinc boinc_client
[/usr/bin]$

The following are the main differences between RHEL8.4 linux and alanb1951's version of Ubuntu. I do not think these differences are of much significance.

On RHEL8.4, $ locate ca-bundle.crt
(appears only in)
/etc/pki/tls/certs/ca-bundle.crt
[/usr/bin]$

There is no link in /var/lib/boinc (boinc-client) to /etc/ssl/certs/ca-certificates.crt. And the file itself is in a slightly different directory:
/etc/pki/tls/certs instead of /etc/ssl/certs, although there is a link from there to the directory where the file actually is:

[/etc/ssl]$ ls -l
total 0
lrwxrwxrwx. 1 root root 16 Jun 16 16:28 certs -> ../pki/tls/certs
Sep 30 11:13 /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

The fact that there is no link in /var/lib/boinc to the certificate might be important, but if so, why is there no problem with the main CPDN page and no problem with WCG, Rosetta, and Universe?

Also, another difference is where you say, "And I note that we still have the (internal to CPDN) PHP warnings at the top of every page, so it looks like Oxford have some sorting out to do anyway...:,

I do not get any warnings on the top CPDN page: https://www.climateprediction.net/, though I do on all other pages.

"P.S. The certificate bundle was most recently updated on 28th September, 2021, round about when this root certificate expired.}
Mine is a little later, but I do not accept updates every day.

Sep 30 11:13 /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

---

Problems at Oxford uni are most likely because they been having some re-cabling done, and probably other work as well, and things haven't gone well.

... why is there no problem with the main CPDN page ...

Because your browser will be handling the security for that page, not the BOINC client.

For what it's worth, on Ubuntu that entry in boinc-client is a link to /etc/ssl/certs/ca-certificates.crt, which gets updated as necessary - I would expect most Linux distributions that have a properly curated BOINC client package to do something similar, but I could be wrong :-)

Should have noticed that! So if I create a similar link in my WINE installation, that should also update automagically?

For what it's worth, on Ubuntu that entry in boinc-client is a link to /etc/ssl/certs/ca-certificates.crt, which gets updated as necessary - I would expect most Linux distributions that have a properly curated BOINC client package to do something similar, but I could be wrong :-)

Should have noticed that! So if I create a similar link in my WINE installation, that should also update automagically?

My Linux Mint machine is still using a certificate bundle dated 6 February 2021 - and it works just fine.

There's another reason why Windows machines are particularly prone to this. The BOINC client for Windows is still using outdated, buggy, security software (*). When it encounters the expired certificate, it should carry on checking the rest of the bundle. And if it did that, it would find a still-valid certificate further down the pile. But instead, it barfs on the expired certificate and gives up at that point.

(*) OpenSSL v1.0.2s

(*) OpenSSL v1.0.2s

I have openssl-1.1.1g-15.el8_3.x86_64 on my RHEL 8.4 Linux machine.

---

Exactly. The Windows client ships with v1.0, which is known to be well behind the times and faulty.

Site been Pownd?
Sorry to think so, maybe?
Can't attach to project.
All on this thread speculate ssl problems.
Tried those fixes
No help.
WTF?
Also -- checking local wu records vs website records -- big mismatch for wu's last few months
Or have I just lost my mind?
HELP!

---

Site been Pownd?
Sorry to think so, maybe?
Can't attach to project.
All on this thread speculate ssl problems.
Tried those fixes
No help.
WTF?
Also -- checking local wu records vs website records -- big mismatch for wu's last few months
Or have I just lost my mind?
HELP!

Or maybe it''s just the website blundering changing what I thought work-units stats that I've been recording all year to different stats now?

Yo no se.

Shirimasen

---

We are stuck until Berkeley wakes up? I do not believe in this statement. How has World Community Grid worked around this problem?

WCG - still supported by IBM for the time being - will be using a different security certificate. There are something like 130 different certificates in the bundle used by BOINC, and only one of them has expired so far.

A replacement version of BOINC requires the use of tools only authorised for use at the University of California, Berkeley. We'll have to wait for somebody to go to the lab - yes, you have to believe that - and there are signs that it may not take too long after that.

We are stuck until Berkeley wakes up?

It is now Friday so they have had all week.
Since I have no problems like this from WCG, Rosetta@Home, or Universe@Home, why is it that CPDN has this problem? Do none of the other projects use certificates?

---

There are some problems at Oxford that aren't affecting what little crunching is happening.
No need to worry, it'll be dealt with in time.

WU N216 only forty are in contact with the server. N144, only two are in contact with the server. Why cannot it be possible to clear up all these WU's out there in the wide blue yonder during this breakdown or whatever of CPDN? 25000 WU's of Wah2 are silent. So are others.

WU N216 only forty are in contact with the server. N144, only two are in contact with the server. Why cannot it be possible to clear up all these WU's out there in the wide blue yonder during this breakdown or whatever of CPDN? 25000 WU's of Wah2 are silent. So are others.

That is 40 or 33 in last 24 hours actually completing tasks, rather than in contact with the server. Also doing what you suggest needs someone to actually be physically present at the computer due to the way Oxford configure their firewall. A lot of those WU's will be quietly trundling away, occasionally gaining credit.

Besides what you suggest has been put to those in Oxford many, many times in the past. I don't see policy on this changing unless there is a major change of personnel in charge of the project and even then it isn't guaranteed that they will take a different view.

WU N216 only forty are in contact with the server. N144, only two are in contact with the server. Why cannot it be possible to clear up all these WU's out there in the wide blue yonder during this breakdown or whatever of CPDN? 25000 WU's of Wah2 are silent. So are others.

What does that mean, "in contact with the server?" I have 17 N216 WUs running and 63 Waiting to Run. Why aren't over 80 N216 WUs in contact with the server???

Oops, DJ explained in the following post I'd yet to read.

It's completely irrational to issue WUs with a 1 year deadline. They should have a one month deadline and have started or get a server abort. How many WUs go out and never come back??? Think about the aggregators like Charity Engine and Science United.

It's completely irrational to issue WUs with a 1 year deadline. They should have a one month deadline and have started or get a server abort. How many WUs go out and never come back??? Think about the aggregators like Charity Engine and Science United.

Personally I agree the deadline should be much shorter but as moderators we can do no more than let those involved at Oxford know what is being said on the boards and our own opinion.

WU N216 only forty are in contact with the server. N144, only two are in contact with the server. Why cannot it be possible to clear up all these WU's out there in the wide blue yonder during this breakdown or whatever of CPDN? 25000 WU's of Wah2 are silent. So are others.

What does that mean, "in contact with the server?" I have 17 N216 WUs running and 63 Waiting to Run. Why aren't over 80 N216 WUs in contact with the server???

Oops, DJ explained in the following post I'd yet to read.

It's completely irrational to issue WUs with a 1 year deadline. They should have a one month deadline and have started or get a server abort. How many WUs go out and never come back??? Think about the aggregators like Charity Engine and Science United.

As a side issue, if you’re running 17 CPDN WUs at a time, 63 WUs reserve is over a month’s worth. Any particular reason for holding that many?

Let´s try with 4 months... I produced two ghost WUs by re-attaching to the project on Thursday https://www.cpdn.org/results.php?hostid=1522605 after I disconnected the monitor to try it on another computer. The 2 WUs will never be processed on this computer at all as all files are whipped out!

---