Master-URL changed to use HTTPS
21 Sep 2022 8:49:06 UTC
Topic 228160
(moderation:
Hi everyone,
We changed our project's so-called "master-URL" to HTTPS (instead of HTTP) to further secure BOINC's initial communication with our project. Don't worry, even before this change the BOINC client communication was automatically upgraded to use HTTPS by our web server. This change now means this extra round-trip isn't required anymore so it will just slightly speed up the communication.
Please note that older clients might not recognize this change automatically if you're already attached to our project. In that case we recommend you update your BOINC client to a minimum version of 7.16.20. All BOINC versions starting with 7.16.20 support the automatic transition from HTTP to HTTPS on the next communication ("update") with the project's server.
Cheers,
Oliver
Einstein@Home Project
Oliver Behnke wrote: Please
)
I did not remember that, it's time for me to upgrade some of my clients as some Projects, not Einstein so far, are telling me to remove and reattach to them as they went to https also.
Oliver Behnke wrote:We
)
I guess this explains why all my hosts are suddenly complaining that:-
My hosts (around 140 of them) all started a programmed work cache top up just over an hour ago. They do so, one at a time and spaced out, in order to minimise the impact on the servers. This allows them to get a bunch of work in one hit rather than more frequent, single task requests. I do these top ups six times a day under script control. A single pass over all hosts takes around 90 mins.
My distro of choice refuses to package BOINC so I build it from source myself. My latest build is 7.16.11 but I've been building versions right from 7.6.33. My distro used to package BOINC but about the time there were almost daily releases of new point versions in the 7.2.x series, they decided it was too unstable and too crappy (their words, not necessarily mine) to justify the effort of packaging the never ending stream of these. I was using 7.2.42 then and when that got too old, I worked out how to build 7.6.33 for myself. I've built a number of versions since then.
I have some hosts with uptimes close to 900 days (and many others with multiple hundreds) so there are a variety of BOINC versions in play, not to mention versions of the OS itself and the OpenCL libraries. To upgrade all these machines to 7.16.20, as well as the huge number of OS/OpenCL upgrades that would be needed, is something that will probably take months to achieve.
From what I'm observing, the hosts are requesting and receiving work normally. I'm planning just to ignore the complaint in the event log, seeing as there doesn't seem to be any adverse consequences - for the present.
I'd be interested to know if there is any easier route to making my hosts 'compliant' - perhaps a tweak to some config file or something in the state file? Apart from the BOINC version, I've been upgrading some hosts to the latest version of the OS in recent months. That can take an hour or two and perhaps even longer if I decide to do a hardware upgrade (eg 20GB HDD to 128GB SSD) at the same time. If I try to do more than 3 or so in a day, I find myself going stir crazy. That's why it's going to take quite a while.
Cheers,
Gary.
Can I just edit some
)
Can I just edit some file(s)?
petri33 wrote:Can I just edit
)
That's what I was wondering.
Set up a script and iterate over all the hosts. Surely there's got to be an easy way :-).
Cheers,
Gary.
I have a host with a minimal
)
I have a host with a minimal work cache size that I've now set to NNT (no new tasks). When the current work has completed and been returned (about an hour), I'll stop BOINC and edit the master_url in the state file (client_state.xml) and also the URL in the account file (account_einstein.phys.uwm.edu.xml) which also has a master_url field. Interestingly enough, the account file has a whole bunch of gui_url fields which are already https rather than http, so just the master_url needs fixing by the look of things.
I'll then relaunch BOINC, allow new tasks and see what happens on the first work fetch :-).
Cheers,
Gary.
The two edits mentioned in
)
The two edits mentioned in the previous message have been made. The single master_url entry in each file had an 's' added to 'http'. The client was then restarted and a work fetch was allowed. New tasks were downloaded and crunching commenced without any further complaints in the event log.
Looks like the solution is pretty simple.
Cheers,
Gary.
Thank you!
)
Thank you!
No problem. I suspect that
)
No problem.
I suspect that setting NNT and returning all existing tasks before performing the edits is not necessary.
I intend to write a small script and deploy it to each host, using an existing script that already is able to deploy stuff, large data files, new app versions, updated configs, etc. This new script will run boinccmd to stop the client temporarily, then use sed to edit each file before finally running boinccmd again to restart the client. I'm assuming existing tasks will still generate complaints but once they've all been returned, the newer tasks will be fine.
I wrote the existing script a long time ago, mainly to deploy data (and save multiple downloads) but I did build in an option to deploy and execute other scripts. Looks like I'll get to use that functionality. Of course, I'll try it out on a single target before destroying the whole fleet :-).
Cheers,
Gary.
Oliver Behnke wrote: Hi
)
Yes, but you forget to update the "Add a Project" list so the "s" has to added each time.
Aurum wrote: Oliver Behnke
)
Einstein project has nothing to do with that. That is part of the BOINC client. The BOINC devs have to fix that with a new all_projects_list.xml file.