Anybody else experiencing a problem with PayPal

[kraken17]

We use WHM and Cpanel

The update script /usr/local/cpanel/scripts/upcp which runs every day updates all the pearl mods.

We couldnt find a way to get cpan (cpanel's perl manager) to NOT update that one module. (Crypt::SSLeay.)

We didnt want to turn off the daily updates, so in the end I changed the Actinic.PM file a suggested by gcamley and kraken17 above, and thats working ok.

Cheers, I forgot about the automatic updates, and wonderfully it stopped working this morning.

Implement gcamley's fix until the CPAN developer has sorted it.

[steveindigo]

ACTINIC.pm fix works

Apparently we don't get automatic updates but there was a manual one. we have now implemented Gordon's fix and its all working ... woo hoo.

Thanks Gordon Kraken and everyone for your support ... and the fix.

m

[feemish]

Sounds to me like the web hosting guy has not stopped the automatic updates of the CPAN modules. Best to modify the PM on the source computer and upload that to save any other problems.

We use WHM and Cpanel

The update script /usr/local/cpanel/scripts/upcp which runs every day updates all the pearl mods.

We couldnt find a way to get cpan (cpanel's perl manager) to NOT update that one module. (Crypt::SSLeay.)

We didnt want to turn off the daily updates, so in the end I changed the Actinic.PM file a suggested by gcamley and kraken17 above, and thats working ok.

[kraken17]

We are experiencing other issues now which may or may not be related. Basicaly our hosting guy rolled back the offending perl module and we lost all cgi-bin functionality (no add to cart or checkout all night arrrgh#!~)

So we did a purge and refresh this morning and add - to - cart / checkout etc worked again.

I tested it again about 15 minutes ago and it was broken again?

Purge and refresh fixed it again.

I'm now going to try the perl script fix but am obviously worried something else is going on.

Any clues greatly apprecieted as this is getting costly.

Sounds to me like the web hosting guy has not stopped the automatic updates of the CPAN modules. Best to modify the PM on the source computer and upload that to save any other problems.

[steveindigo]

Further issues

We are experiencing other issues now which may or may not be related. Basicaly our hosting guy rolled back the offending perl module and we lost all cgi-bin functionality (no add to cart or checkout all night arrrgh#!~)

So we did a purge and refresh this morning and add - to - cart / checkout etc worked again.

I tested it again about 15 minutes ago and it was broken again?

Purge and refresh fixed it again.

I'm now going to try the perl script fix but am obviously worried something else is going on.

Any clues greatly apprecieted as this is getting costly.

[gcamley]

If anyone is interested in following the bug trail for this problem please goto:

https://rt.cpan.org/Public/Bug/Display.html?id=78695

I have updated the bug report with how SellerDeck use Net::SSL so that the developer can see what our problem is and either fix the perl module or advise on how the module should be used since their recent changes.

[Golf Tee Warehouse]

The Actinic.pm mod has also worked here.

[Harts Of Stur]

Actinic.pm modification has worked.

[kraken17]

Bug tracking from Sinan - CPAN::SSLeay developer

If anyone is interested in following the bug trail for this problem please goto:

https://rt.cpan.org/Public/Bug/Display.html?id=78695

Regards

kraken17

[GraemeKustom]

gcamley's edit sorted the Internal server error on my site, all is good in the world once more.

[feemish]

Thanks Gordon for looking into this and coming up with a solution.

I have downgraded my pearl modules and will wait and see what the CPAN developer comes back with.

[gcamley]

There is a possible problem with the way it now works, if the last block of data is 1024 bytes then the same problem may occur unless the perl module still accepts an extra read and returns zero.

Tested and found that if the data is the size of the buffer then you cannot determine when you have read all of the data any attempt to read beyond the end of the data causes a script error the same as we have been seeing.

My fix works so long as the response is not 1024 characters. In testing the response was 288 characters so well below the limit.

[kraken17]

Further information

For information. Further information from CPAN developer.

Thank you. Don't worry about the environment variable right now, as
this seems to be related to the read routines. However, for future
reference, see http://stackoverflow.com/questions/3...able-in-apache

I'll try to figure this out as soon as I can, and give you a heads up.

-- Sinan

It is in the CPAN bug reporting area now, and I will be kept upto date about future improvements.

[gcamley]

I have a solution that does not involve downgrading the perl modules.

Edit Actinic.pm in the site folder using a text editor such as Notepad
Search for 'sub HTTPS_SendAndReceive'
Now search for 'ssl_socket->read'

you should see

  while ($ssl_socket->read($buf, 1024))
   {
   $sResponse .= $buf;
   }

replace the above with

my ($nBuf) = 1024;
 while ($nBuf == 1024)
  {
  $nBuf = $ssl_socket->read($buf, 1024);
  $sResponse .= $buf;
  }

Save and exit
Update site

The fix is supplied as-is without any warranty i.e. I just wrote it and tested once and it seems to be okay.

Tech comment: It would appear that the perl module no longer reports zero buffer length at end of read loop. There is a possible problem with the way it now works, if the last block of data is 1024 bytes then the same problem may occur unless the perl module still accepts an extra read and returns zero. The code has worked the same way for as long as I can remember (at least 10 years). No idea why it should be changed now.

[kraken17]

Contacting CPAN developer

This is the reply from the CPAN developer. I will submit a bug report and see if he can sort it out.

I will keep all followers of this thread updated.


Hello Tim:

I would love to fix it, but I need information on how to diagnose it.

Could you please open a ticket at
http://rt.cpan.org/NoAuth/Bugs.html?Dist=Crypt-SSLeay and provide me
with some more information. I would especially love to see any related
log entries to be able to figure out if the problem is due to LWP
actually checking certificates or due to my changes in the read/write
routines.

And, no, I haven't received any other reports so far, so your report
is the only thing I have to go on.

Thank you.

-- Sinan