perl contrib/bz_webservice_demo.pl --uri http://bugzilla.example.com/xmlrpc.cgit always errs out with 500 Error for Bugzilla.version.
error.log show that
xmlrpc.cgi: Can't use an undefined value as a subroutine reference at lib/SOAP/Transport/HTTP.pm line 384
If I hit another well know server like bugzilla.redhat.com ; it shows version perfectly. That means this server problem and not client related.
Bugzilla version 4.4.6
Uname - Ubuntu 14
In this file: bugzilla/lib/SOAP/Transport/HTTP.pm, comment out lines 384 and 452. These lines both pass some value to a new debug_logger that didn't exist in the SOAP/HTTP module in my previous Bugzilla installation. Since we're not trying to debug this module, there is no need for those lines anyway.
It's worth pointing out that the SOAP module is not part of Bugzilla's own code, and is not included with the files you download. It gets installed during the setup process. This means it doesn't matter what Bugzilla version you're running. This is something that was changed in the SOAP module, so if you tried to reinstall an older version of Bugzilla, it wouldn't fix the problem.
I have exactly the same on Ubuntu14 and Fedora20 Bugzilla4.4.6 boxes.
"500 internal server error", no bugzilla/errorlog entries,
but /var/log/httpd/error_log shows
xmlrpc.cgi: Can't use an undefined value as a subroutine reference at lib/SOAP/Transport/HTTP.pm line 384.
The perl cgi script needs to be debugged right?
Related
Several years ago I wrote a Perl CGI script that connects to an openLDAP server and starts TLS when available.
The script was running successfully with openLDAP-2.4.41 of SLES12 SP5 without a problem, but after updating some packages, the script cannot start TLS using $ldap->start_tls any more.
The error message is:
"Failed to set SSL cipher list error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list: no cipher match"
The updates installed were (AFAIK) openldap2-2.4.41-22.5.1 together with libopenssl1_1-1.1.1d-2.54.1. Specifically there was no update for the Perl LDAP modules.
My code does not specify a ciphers list, but is specifies the CA path and used require for certificate verification.
The part of the code that outputs the error message is:
$msg = $ldap->start_tls(%options);
if ($msg->code()) {
perr($q 'start_TLS() failed: ', $msg->error);
}
A truly odd thing is that a simple test case started on a different server (that should have the same software) succeeds with cipher AES256-GCM-SHA384.
Even when I run that script on the same server, it succeeds with the same cipher.
The code used in the test case basically is:
my $m = $l->start_tls(verify => 'verify');
$m->code() || print $l->cipher(), "\n";
While looking closer, I noticed that my CA path is /etc/ssl/certs which is a symbolic link to /var/lib/ca-certificates/pem updated about the same time as the other RPM packages.
Even when changing the CA path in the CGI to /var/lib/ca-certificates/pem I get the same error.
The web server being used was updated with the other packages, too; it it apache2-2.4.51-35.7.1.
The Perl code runs with PerlResponseHandler ModPerl::Registry, and the apache RPM changelog says it was "build against openssl 1.1".
What might be wrong or causing this, and how can I fix it?
As my CGI script magically worked again after having installed current SLES 12 SP5 updates, I must assume that there was a bad update causing the failure.
Suspecting that the packages causing that might have been apache2, perl, or openssl, I try to find the bad versions:
apache2-2.4.51-35.7.1
libopenssl1_1-1.1.1d-2.54.1
were probably the bad versions, while
libopenssl0_9_8-0.9.8j-106.33.1
apache2-2.4.51-35.13.1
openssl1_0_0-1.0.2p-3.48.1
fixed the problem again.
I just installed Nginx 1.2.4 and PHP 5.4.0 (from svn) (php fpm). CentOs 5.8 64
The problem I have is that PHP crashes the moment I run any social oAuth scripts. I have tried to log into Facebook, Twitter and Google with various scripts that I know work on my other servers. When I load the scripts I get a 502 error from Nginx. And I find these errors in the log:
in php-fpm log:
WARNING: [pool www] child 23821 exited on signal 11 (SIGSEGV) after 1132.862984 seconds from start
in nginx log:
ERROR: recv() failed (104: Connection reset by peer) while reading response header from upstream
From what I can see, it goes wrong when PHP tries to make a request to any of the oAuth servers.
https://github.com/mahmudahsan/PHP-SDK-3.0---Graph-API-base-Facebook-Connect-Tutorial-Source for example is one of the scripts that works perfectly on my other machines, but causes PHP to crash.
I found: Nginx + PHP-FPM 502 Bad Gateway which seems to be a similar problem, but I cannot find a way to solve it.
* ++++ UPDATE ++++ *
Now I have been doing some debugging in 1 of the scripts that is playing up.
If you go to line 808 http://pastebin.com/gSnzRtXb it runs the curl_exec()
command.
When that is ran, it crashes. If i echo'test';exit; just above that line, it
echo's correctly, if i do it below that line, php crashes.
Which means it's that line 808 which causes the crash.
So I made a very simple script to do some testing: http://pastebin.com/Rshnyhcm
which also uses curl_exec, but that runs just fine.
So I started to dig deeper into that query from the facebook script to see what
values the $opts array contains from line 806.
Output of that array is: http://pastebin.com/Cq9ffd3R
What the problem is, I still have no clue :(
solved it by updating PHP to 5.3.8
I'm trying to connect to a website via HTTPS, by sending a WWW::Mechanize get request and whenever I try and run my script I get this error:
This Application has faile to start because libeay32_.dll was not found. Re-installing the application may fix this problem
And inside the command prompt I get:
Error GETing http...: can't load 'C:/strawberry/perl/vendor/lib/auto/Crypt/SSLeay/SSLeay.dll for module Crypt::SSLeay: load_file: The specified module could not be found (Crypt::SSLeay or IO::Socket::SSL no installed) at ...
I don't understand the problem because I'm very new to programming with Perl. Crypt::SSLeay is installed, the .dll is in the proper location and IO::Socket::SSL is also installed, or whenever I try to install it via cpan i get the libeay error again. The libeay32_.dll is located in the C:\straberry\c\bin. I don't have full access right to the computer because I am doing this from work. If someone could explain to me the reason for the problem it would be appreciated.
I make an answer out of my comments so you can check this question as answered:
Add "C:\straberry\c\bin" to the PATH-environment variable
Close the explorer- and/or commandline-windows since running processes aren't notified if the environment changes and thus keep the old environment active (okay, in the command line you could apply the update manually by set PATH=...new path...).
Have you read the README.SSL file that comes with LWP? (WWW::Mechanize uses LWP to make the actual HTTP requests).
I'm working on a Perl script which is called from a server side include on an Apache 2 server. The script is displaying the generic "Internal Server Error" page rather than showing me the actual error. When I check the Apache error log, I see these messages:
unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/
How do I get a Perl script to show an error rather than "Internal Server Error"?
Update:
I should have asked a separate question for this, because I have since learnt that this does send errors to the browser (thanks brian):
use CGI::Carp qw(fatalsToBrowser);
However, if the problem is with the Apache config rather than the Perl script, then the error will not be sent to the browser because the Perl code is not being interpreted. In this case, we can tell that I am experiencing an Apache error (rather than a Perl error) because of this line:
suexec policy violation: see suexec log for more details
This occurs when Apache is running in SUexec mode (which seems to be common for shared hosting). I'm not sure what exactly has been changed to cause this error, but that's what I'm trying to find out.
Probably you are using shared hosting and you have this problem because your scripts directory or the script file does have other rights than 755.
Here is one case translated from Dutch.
Use CGI::Carp's fatalsToBrowser.
use CGI::Carp qw(fatalsToBrowser);
You might also want to see my Troubleshooting Perl CGI scripts.
From the error message, I'm guessing that you aren't allowed to execute CGI scripts from server side includes. Which version of your Apache are you running? If it's an old apache, see the suexec docs for apache 1.3, or if it's a newer apache, see the suexec docs for apache 2.0.
It's not for user friendliness, but often for security that we don't show users the exact error when the user can't do anything about it. For example, imagine that a back end server is unavailable. What can I, as a user, do to fix that in your web application?
In some cases, error messages will contain useful information, like "SQL Error: illegal syntax. Unmatched ' ". If the user had input a quote in their input, this feedback would indicate a SQL injection vulnerability.
Other benign looking messages are bad to show to users, as well. The key thing that the attacker wants is to know "something different happened." If the application prints out one error for one input,and another error for another iinput, then the attacker knows that something different has gone wrong, and that this is an interesting place to focus.
In a production site, errors should be logged to file, and, if appropriate, downloadable through your web interface - but be very careful to sanitize any output to the browser to avoid cross site scripting. And there should be no user-submitted option to reconfigure this between debug and production (don't control it via a POST or CGI parameter, but by a configuration file option).
This could be 3 factors:
Permissions level rwx set wrong (execution/writeness level)
UUID/GUID do not match Apache settings
Combination of 2 above.
Check apache suexec+errorlog for details
I've moved a WebBBS board from one server to another. Ever since the board doesn't work.
I'm getting an Apache error whenever I try to access the board. Don't even know where to start the debugging, I'm not a Perl person. The file paths remained the same and there isn't any DB involved.
http://gammonline.com/members/board/
Any ideas?
After a bit of testing I believe that the problem has something to do with the index.cgi which is located in that folder (not getting the error when renaming it).
Thanks,
Roy.
More information about this error may be available in the server error log.
Says it all. You will have to find the error log and look at it.
If you are using CGI, the first step is to check you have given it the right permissions so it is an executable script at all.
chmod 755 index.cgi
This is caused by Apache config errors. Set LogLevel debug and tail -f the error log. It will probably be something to do with .htaccess permission for override, or, it's requiring a module which isn't loaded. The error log will tell you instantly.