Re: [Koha] premature end of script headers
Robert Lyon wrote:
Is that error from the koha error logs?
The apache error log
if so try looking at the apache error log too - it might give some idea but to me it looks like the acqui-home.pl might have the wrong file permissions on it and can't run
No, the script *used to* run fine. I found the cause of the problem by running the script in the shell. I could no longer connect to the MySQL database server since I had changed the name of the database user. Now the problem is fixed. This raises a couple of issues: 1. Why is the admin login username (to the Intranet) the same as the database username? The two should be separate, esp. for security reasons. 2. When the script that fails runs in the shell, I can clearly see the error: perl ./intranet/cgi-bin/mainpage.pl DBI connect('eesv2pre5:localhost','kohaadmin',...) failed: Access denied for user 'kohaadmin'@'%' to database'Koha' at /usr/local/koha/intranet/modules/C4/Context.pm line 411 Can't call method "prepare" on an undefined value at /usr/local/koha/intranet/modules/C4/Koha.pm line 388. Surely the same error message should be sent to the Apache log, rather than "premature end of script headers". I think the problem lies in the way Perl is being used. If Koha used mod_perl instead, this problem would not occur, since mod_perl can do things like ensure you have a valid database connection during Apache initialisation -- if there is a problem, mod_perl can be configured to abort the Apache startup. This would be a Good Thing (tm). Another Good Thing is mod_perl will run the scripts 100 x faster! A way to avoid the cryptic "Premature end of script headers" in scripts is to use the exception handling facility of Perl. For programmers only: each script is in an eval { } block and any errors caught, the HTTP headers output and then the error raised properly with Apache. I've been using this approach for years in LAMP apps -- works a treat, and no moer tears ;) My concern the the inordinate waste of hundreds of Koha users/installers time with the cryptic error message which can easily be ameliorated by a few programming tweaks. (This error is constantly being raised on the Koha user's mailing list) We can further discuss this on the koha-devel list if you wish. Advice to Koha users/installers: if you see the cryptic error message run the same script in the shell: PERL5LIB=/usr/local/koha/intranet/modules perl {FULL_PATH_TO_SCRIPT_HERE} cheers rickw
Rick Welykochy wrote:
I am running Koha/2.2.7 on LAMP.
One of the scripts is causing a 500 error. The error log does not show any perl error report, rather just the following:
[Fri Jan 19 00:14:18 2007] [error] [client 192.168.0.3] Premature end of script headers: acqui-home.pl
Any idea what causes this?
-- _________________________________ Rick Welykochy || Praxis Services The 7 R's of Windows support: retry, restart, reboot, reconfigure, reinstall, reformat and finally, replace with Linux.
I found the cause of the problem by running the script in the shell. I could no longer connect to the MySQL database server since I had changed the name of the database user.
Now the problem is fixed. This raises a couple of issues:
1. Why is the admin login username (to the Intranet) the same as the database username? The two should be separate, esp. for security reasons.
It isnt, or at least it doesnt need to be. This is just the login to Koha until you set up a librarian and assign them as superuser. The librarians should all be logging in with their own user codes.
2. When the script that fails runs in the shell, I can clearly see the error:
perl ./intranet/cgi-bin/mainpage.pl DBI connect('eesv2pre5:localhost','kohaadmin',...) failed: Access denied for user 'kohaadmin'@'%' to database'Koha' at /usr/local/koha/intranet/modules/C4/Context.pm line 411 Can't call method "prepare" on an undefined value at /usr/local/koha/intranet/modules/C4/Koha.pm line 388.
Surely the same error message should be sent to the Apache log, rather than "premature end of script headers". I think the problem lies in the way Perl is being used. If Koha used mod_perl instead, this problem would not occur, since mod_perl can do things like ensure you have a valid database connection during Apache initialisation -- if there is a problem, mod_perl can be configured to abort the Apache startup. This would be a Good Thing (tm). Another Good Thing is mod_perl will run the scripts 100 x faster!
It is, did you check the koha-error_log. There is nothing in the code to stop the error being sent, if its not in the error logs its something apache is doing. Also Koha can use mod_perl ... the reason it doesnt by default is you dont have to run Koha with apache, any webserver will do. Most of these things have been talked about in the past. Chris
Chris Cormack wrote:
It is, did you check the koha-error_log.
Yup. That is where I saw the cryptic error message: [Fri Jan 19 00:14:18 2007] [error] [client 192.168.0.3] Premature end of script headers: acqui-home.pl Nothing else accompanied that message to tell me what was wrong. OTOH in the shell I could clearly see what went wrong. IMHO, the koha-error_log should show the same error condition and messages as the shell.
There is nothing in the code to stop the error being sent, if its not in the error logs its something apache is doing.
Yes, Apache is overriding the error message since no headers have been output. This is documented at apache.org. My diatribe in my previous email is how to prevent such behaviour so that the programmer and Koha maintainer can actually see error messages. Anything that makes diadnosing errors and warnings on the web server is a blessing, from my experience :) cheers rickw -- _________________________________ Rick Welykochy || Praxis Services The 7 R's of Windows support: retry, restart, reboot, reconfigure, reinstall, reformat and finally, replace with Linux.
Rick Welykochy wrote:
Chris Cormack wrote:
It is, did you check the koha-error_log.
Yup. That is where I saw the cryptic error message:
Interestingly enough I have discovered as I think Bob was hinting, that when this happens Often if you look at the main apache error log, eg /var/log/apache/error_log It has the full cause of the error. Not always, but quite often. More so with Apache 2 than 1.3.x Chris
Chris Cormack wrote:
1. Why is the admin login username (to the Intranet) the same as the database username? The two should be separate, esp. for security reasons.
It isnt, or at least it doesnt need to be. This is just the login to Koha until you set up a librarian and assign them as superuser. The librarians should all be logging in with their own user codes.
I am familiarising myself with the Koha system. One thing I am doing now requires admin level login. Correct me if I am wrong, but isn't the admin-level login id and password found in the koha.conf file: database=eesv2pre5 hostname=localhost user=kohaadmin pass=qwpoijoiqjdjiojqwd Are the above 'user' and 'pass' passed on to mysql as authentication parameters for DBI->connect ($username, $auth) ? cheers rickw -- _________________________________ Rick Welykochy || Praxis Services The 7 R's of Windows support: retry, restart, reboot, reconfigure, reinstall, reformat and finally, replace with Linux.
Rick Welykochy wrote:
Chris Cormack wrote:
1. Why is the admin login username (to the Intranet) the same as the database username? The two should be separate, esp. for security reasons.
It isnt, or at least it doesnt need to be. This is just the login to Koha until you set up a librarian and assign them as superuser. The librarians should all be logging in with their own user codes.
I am familiarising myself with the Koha system. One thing I am doing now requires admin level login. Correct me if I am wrong, but isn't the admin-level login id and password found in the koha.conf file:
database=eesv2pre5 hostname=localhost user=kohaadmin pass=qwpoijoiqjdjiojqwd
Are the above 'user' and 'pass' passed on to mysql as authentication parameters for DBI->connect ($username, $auth) ?
Yes, but you dont need admin access. Make yourself a borrower, edit the borrowers permissions, make it a superlibrarian, and set a password on it. And you no longer need to use that username and password. You can then change them in mysql and koha.conf file if you want. And never use it to login again. IE its only there so that you can login the first time and set up a user. Hope this helps Chris
Chris Cormack wrote:
Yes, but you dont need admin access. Make yourself a borrower, edit the borrowers permissions, make it a superlibrarian, and set a password on it. And you no longer need to use that username and password. You can then change them in mysql and koha.conf file if you want. And never use it to login again.
IE its only there so that you can login the first time and set up a user.
Hope this helps
That's great, thanks Chris. It'll take me some time to learn all the ins and outs of Koha ... its appearing to be a pretty comprehensive system. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services The 7 R's of Windows support: retry, restart, reboot, reconfigure, reinstall, reformat and finally, replace with Linux.
Rick Welykochy wrote:
A way to avoid the cryptic "Premature end of script headers" in scripts is to use the exception handling facility of Perl.
One can also use CGI::Carp, i.e. use CGI::Carp qw(fatalsToBrowser); But (a) it does not show *all* error messages as one would see in the shell and (b) it should be removed once in production. It can prove useful while developing CGI scripts. -rw -- _________________________________ Rick Welykochy || Praxis Services The 7 R's of Windows support: retry, restart, reboot, reconfigure, reinstall, reformat and finally, replace with Linux.
participants (2)
-
Chris Cormack -
Rick Welykochy