On which OS did you try version 5.10.45? I couldn't install it on Windows 7 three years ago; it was like "too old version". I don't remember the exact wording.
Turning the firewall completely off didn't help.
On which OS did you try version 5.10.45? I couldn't install it on Windows 7 three years ago; it was like "too old version". I don't remember the exact wording.
Turning the firewall completely off didn't help.
I did my test install on host 8864187 - keeping it well clear of the normal working directory. Being 64 bit Windows 7, I went to find 64 bit BOINC v5.10.45* - but that installed fine (in user mode, not service mode) and attached to the project OK, too. It all fell apart at 'project initialisation', so it never got allocated a HostID for the test installation.
The next ten days I don't need new tasks, but as soon as I do I will try it with another project with the new site software, e.g. setiathome. It is usually the first project with new site software. Like einstein now, it also has a comma following the date in the task list.
This w3.org specs regarding 301 redirects suggest - the user agent [boinc in this case] must not automatically redirect the request unless it can be confirmed by the user. Kapersky (acting as a proxy) has no way of getting that confirmation (from boinc), so drops the connection.
Sorry, but this is plain stupid!
1) As you say, BOINC is the user agent while Kaspersky acts as a transparent proxy. It's not up to it to just silently block traffic without giving the actual user agent a chance to comply with the spec (i.e. ask for confirmation).
2) If it interjects itself into the workflow then it should do so according to spec and let the user confirm the request.
Either way, Kapersky's current behaviour is just stupid and breaks the spec!
Anyhow, we're going to change the server setup in order to avoid the redirect. Done!
Either way, Kapersky's current behaviour is just stupid and breaks the spec!
Anyhow, we're going to change the server setup in order to avoid the redirect. Done!
Best,
Oliver
While I've not done tests beyond a simple update request on two different hosts, my initial trial of turning off the special over-ride by which I directed Kaspersky not to scan network traffic for the boinc client shows success under the newest configuration.
I don't "speak network" enough to have understood the evidence that the undesired Kaspersky behavior was specifically associated with the new redirect but I assume that far less was changed co-incident with this new change than was changed during the server migration, which seems to sharpen the evidence.
I've not yet formulated my complaint to Kaspersky, though I've collected some evidence in the form of logs, found the web site location at which to complain, and done some mental composition. I shall probably come back here and post some additional comments and request feedback before I say something to them. Having myself appreciable experience in the neighborhood of commercial software development, prioritization of revisions, and response to user complaints, I'm afraid I rate my chances of triggering a change in their application low, though I definitely plan to try.
Even if K changes, it seems likely to be needed at the application level, which is not, I suspect, routinely revised with the frequent signature updates. So the actual behavior seen by most users seems unlikely to change for most for a very long time.
In sum, Einstein project has done the Kaspersky users a favor, and the project an aversion of some computational output loss, in making this change. Sometimes "fixing the other guy's bug" turns out to be the right thing to do, overall.
On the other hand, my v7.6.9 host has been failing since around ~14:00 UTC today. "HTTP file not found" - I'll try loading the v5.10.45 again.
(removed un-needed log)
Ah - this is the one I put the non-standard scheduler url on. I'd better try undoing that first.
Edit - yes, using the official scheduler address fixed it. mea culpa.
Edit2 - yes, v5.10.45 is working too - although I got some odd effects, like no OS name (host 12132877), and an instruction to delete non-existent files (server log). Not a problem.
This w3.org specs regarding 301 redirects suggest - the user agent [boinc in this case] must not automatically redirect the request unless it can be confirmed by the user. Kapersky (acting as a proxy) has no way of getting that confirmation (from boinc), so drops the connection.
Either way, Kapersky's current behaviour is just stupid and breaks the spec!
I looked a bit deeper into this, and Kapersky is "piggy in the middle". Naughty stupid piggy or very strict stubborn piggy depends on your point of view.
It's raison d'etre **1 is to protect against bad things happening. So stopping "risky business" is what piggy does, it's there to keep you safe (despite the old browsers or other weak stuff you may have). This rather old but detailed page Redirect in response to POST shows this issue has always been troublesome and interpreted differently.
I would not like to see a redirect occur when i submitted my bank password for example to a website without being asked - "You are being redirected - Is this really ok?". That is the reason the MUST NOT redirect without asking in the w3 spec exists, and sadly some old browsers "ignore it" and that (allowing a POST to be redirected silently - no asking) is an exploit which is used in the wild, and this get piggy seeing red.
Redirecting after a POST is rare, (strict piggy frowns on rare behaviour) usually there is a GET first then redirect (no questions asked for a GET redirected - that is allowed and much loved - and this gets the new page, user sees the URL change, enters data presses submit) then the POST occurs.
When we test the .../cgi url with a browser we do a GET so it redirects no questions asked by piggy watching it go by.
Boinc is doing a POST and it then gets a redirect.
Does boinc ask the user "Is it it ok to redirect ?" No.
Should it? Yes- if follows the w3 spec truly.
Does boinc get a chance to ask user before piggy steps in with a frown and shake of the head? No
Should piggy be silent when it sees such fire? NO and this cost us a lot of time a simple "boinc is being phished" would have helped **2
Should piggy know that boinc plays with fire safely? No
Can piggy learn its ok for boinc to play with fire? Yes and that was the workaround (sort of)
A web developer will soon come along shortly and talk of many better options, but
One solution
a) boinc to do a GET first
b) boinc follow the redirects (up to some limit)
c) then POST to the redirected site.
This of course would take several years to filter through old boinc versions.
Anyway we have a better grasp of the problem and things are working, and piggy is happy. All is good on the farm Napoleon.
**1 i wish i could speak more French...
**2 buried deep in some log file does not count.
On which OS did you try
)
On which OS did you try version 5.10.45? I couldn't install it on Windows 7 three years ago; it was like "too old version". I don't remember the exact wording.
Turning the firewall completely off didn't help.
RE: On which OS did you try
)
I did my test install on host 8864187 - keeping it well clear of the normal working directory. Being 64 bit Windows 7, I went to find 64 bit BOINC v5.10.45* - but that installed fine (in user mode, not service mode) and attached to the project OK, too. It all fell apart at 'project initialisation', so it never got allocated a HostID for the test installation.
* http://boinc.berkeley.edu/dl/boinc_5.10.45_windows_x86_64.exe
The next ten days I don't
)
The next ten days I don't need new tasks, but as soon as I do I will try it with another project with the new site software, e.g. setiathome. It is usually the first project with new site software. Like einstein now, it also has a comma following the date in the task list.
RE: This w3.org specs
)
Sorry, but this is plain stupid!
1) As you say, BOINC is the user agent while Kaspersky acts as a transparent proxy. It's not up to it to just silently block traffic without giving the actual user agent a chance to comply with the spec (i.e. ask for confirmation).
2) If it interjects itself into the workflow then it should do so according to spec and let the user confirm the request.
Either way, Kapersky's current behaviour is just stupid and breaks the spec!
Anyhow, we're going to change the server setup in order to avoid the redirect.Done!Best,
Oliver
Einstein@Home Project
RE: Either way, Kapersky's
)
While I've not done tests beyond a simple update request on two different hosts, my initial trial of turning off the special over-ride by which I directed Kaspersky not to scan network traffic for the boinc client shows success under the newest configuration.
I don't "speak network" enough to have understood the evidence that the undesired Kaspersky behavior was specifically associated with the new redirect but I assume that far less was changed co-incident with this new change than was changed during the server migration, which seems to sharpen the evidence.
I've not yet formulated my complaint to Kaspersky, though I've collected some evidence in the form of logs, found the web site location at which to complain, and done some mental composition. I shall probably come back here and post some additional comments and request feedback before I say something to them. Having myself appreciable experience in the neighborhood of commercial software development, prioritization of revisions, and response to user complaints, I'm afraid I rate my chances of triggering a change in their application low, though I definitely plan to try.
Even if K changes, it seems likely to be needed at the application level, which is not, I suspect, routinely revised with the frequent signature updates. So the actual behavior seen by most users seems unlikely to change for most for a very long time.
In sum, Einstein project has done the Kaspersky users a favor, and the project an aversion of some computational output loss, in making this change. Sometimes "fixing the other guy's bug" turns out to be the right thing to do, overall.
This solved my problem too.
)
This solved my problem too. It didn't look like a firewall issue imho.
On the other hand, my v7.6.9
)
On the other hand, my v7.6.9 host has been failing since around ~14:00 UTC today. "HTTP file not found" - I'll try loading the v5.10.45 again.
(removed un-needed log)
Ah - this is the one I put the non-standard scheduler url on. I'd better try undoing that first.
Edit - yes, using the official scheduler address fixed it. mea culpa.
Edit2 - yes, v5.10.45 is working too - although I got some odd effects, like no OS name (host 12132877), and an instruction to delete non-existent files (server log). Not a problem.
RE: Sometimes "fixing the
)
Actually, I think you mean "accommodating" rather than "fixing" :-).
Good to see you will send then a bug report. If they care about their product, it shouldn't just be ignored.
Cheers,
Gary.
RE: RE: This w3.org specs
)
I looked a bit deeper into this, and Kapersky is "piggy in the middle". Naughty stupid piggy or very strict stubborn piggy depends on your point of view.
It's raison d'etre **1 is to protect against bad things happening. So stopping "risky business" is what piggy does, it's there to keep you safe (despite the old browsers or other weak stuff you may have). This rather old but detailed page Redirect in response to POST shows this issue has always been troublesome and interpreted differently.
I would not like to see a redirect occur when i submitted my bank password for example to a website without being asked - "You are being redirected - Is this really ok?". That is the reason the MUST NOT redirect without asking in the w3 spec exists, and sadly some old browsers "ignore it" and that (allowing a POST to be redirected silently - no asking) is an exploit which is used in the wild, and this get piggy seeing red.
Redirecting after a POST is rare, (strict piggy frowns on rare behaviour) usually there is a GET first then redirect (no questions asked for a GET redirected - that is allowed and much loved - and this gets the new page, user sees the URL change, enters data presses submit) then the POST occurs.
When we test the .../cgi url with a browser we do a GET so it redirects no questions asked by piggy watching it go by.
Boinc is doing a POST and it then gets a redirect.
Does boinc ask the user "Is it it ok to redirect ?" No.
Should it? Yes- if follows the w3 spec truly.
Does boinc get a chance to ask user before piggy steps in with a frown and shake of the head? No
Should piggy be silent when it sees such fire? NO and this cost us a lot of time a simple "boinc is being phished" would have helped **2
Should piggy know that boinc plays with fire safely? No
Can piggy learn its ok for boinc to play with fire? Yes and that was the workaround (sort of)
A web developer will soon come along shortly and talk of many better options, but
One solution
a) boinc to do a GET first
b) boinc follow the redirects (up to some limit)
c) then POST to the redirected site.
This of course would take several years to filter through old boinc versions.
Anyway we have a better grasp of the problem and things are working, and piggy is happy. All is good on the farm Napoleon.
**1 i wish i could speak more French...
**2 buried deep in some log file does not count.
I tested now without the
)
I tested now without the Kaspersky workaround. It seems to be running on my PCs.
Good job everyone!