I have a basic Ubuntu server setup and I am attempting to run a CGI script on it but receiving the following error whenever I try running the script via the command line:
CGI will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /etc/perl/RABX.pm, line 583.
CGI::Util will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /usr/share/perl/5.20/CGI.pm, line 29.
Status: 400 Bad Request
Content-Type: application/octet-stream
Content-Length: 98
E1:0,3:513,82:No REQUEST_METHOD in environment; this script must be run in a CGI/FastCGI context,N
If I attempt to run the script in the browser I just get a 500 Internal Server Error.
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
The bit that really confuses me is the last line. Any advice would be greatly appreciated!
The full script can be seen here: https://github.com/mysociety/writetothem/blob/master/web/services/queue.cgi
Also, apologies if this question is better suited to ServerFault - I wasn't sure where was more appropriate.
whenever I try running the script via the command line
...
this script must be run in a CGI/FastCGI context
You get the error "No REQUEST_METHOD in environment" because you are not running within a CGI context but instead on the command line.
Please install the separate libcgi-pm-perl package
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
This is a warning, that you better install libcgi-pm-perl, because CGI.pm will not be included in core perl in the future. The CGI.pm in this package is the same as it was in core perl, so you don't need to worry about having a different module. Of course, it is probably a newer version than you used before. But this was also the case in the past when you used a new perl version.
Related
I'm doing this:
zef install Selenium::WebDriver
And I'm getting it stuck at:
===> Searching for: Selenium::WebDriver
===> Testing: Selenium::WebDriver:ver('0.0.1')
Cannot obtain a session after 10 attempts
in submethod BUILD at /home/user123/.zef/store/perl6-selenium-webdriver.git/5e3ff320d2f392e44df1433f0544201c154f2590/lib/Selenium/WebDriver/Wire.pm6 (Selenium::WebDriver::Wire) line 66
in block <unit> at t/05-firefox.t line 45
# Looks like you planned 91 tests, but ran 1
JavaScript error: , line 0: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIAppStartup.trackStartupCrashEnd]
My OS -- arch linux -- is up to date.
Summary
Like all Perl 5 or Perl 6 packages, the Selenium::WebDriver package includes a suite of tests that check that it appears to work properly on your system.1 This test suite gets run at the end of installation, i.e. the installer downloads the package, runs its builder code and only then runs its test suite. If there's an error, then (by default2) the installer displays error information and exits immediately. That's what it's done in your case.
The current Selenium::WebDriver package was successfully installing 2 months ago complete with the message showing success on an Ubuntu for the same test that is a fail on your system. Then again, a search of the #perl6 logs for 'selenium' suggests that there may be an intermittent error with one of the modules that Selenium::WebDriver uses; this may indeed be the root of the problem.
The README of the repo for Selenium::WebDriver begins with a link to a document that says the protocol it describes is "obsolete". The most recent item in the issue queue of the Selenium::WebDriver repo is titled "Add support for Firefox Marionette WebDriver". Please consider adding a comment to that issue pointing to this SO question if you think it's relevant.
If you look at the error messages you'll see a Firefox test failed. One possibility is that there's an error in Firefox, or some related software, beyond official latest arch linux.
Some plausibly simple responses to the Firefox error message:
Try manually loading Firefox before trying to install the Perl 6 package. Does that fix the problem?
I don't know what options you have for making the Selenium::WebDriver package not see your Firefox other than completely uninstalling it, but maybe you can do that? Then try installing again (and the package will presumably then test/use, say, Chrome instead of Firefox).
If that doesn't work, consider posting a new Selenium::WebDriver repo issue (and link to this SO question).
The top level error message is "Cannot obtain a session after 10 attempts". It's generated by line 66 of the package's lib/Selenium/WebDriver/Wire.pm6 file. I don't think that line helps much in this case but imo it's always worth taking at least a quick glance at the source code corresponding to error messages.
Looking at the next level down we see the error comes from "t/05-firefox.t line 45" which is my $driver = Selenium::WebDriver::Firefox.new;. It looks like it's trying to connect to Firefox and failing. Looking further up in that test script one can see that it thinks it found Firefox on your system (because the code block in unless which('firefox') { ... } clearly didn't trigger).
The deepest part of the error information shows that a "Javascript error" has been encountered, something to do with nsIAppStartup.trackStartupCrashEnd.
Often a problem is specific to the versions of software involved. The Selenium::WebDriver package version is clearly 0.0.1 but it would be nice to see the version info from the other main pieces involved including your Perl 6 compiler (perl 6 -V iirc), the installer (zef -V iirc), and your OS and Firefox. In this particular case I'm pretty sure the problem is not in your Perl 6 compiler (Rakudo) nor in the installer (zef) but I might be wrong and I still recommend you always consider including generous version info when you post your first version of a question.
1 The test suite for the Selenium::WebDriver package work as per Perl 6 testing guidelines in general and per the Testing section of the Selenium::WebDriver's repo README in particular.
2 You can usually force Perl installers to continue regardless if you know an error doesn't matter in your case. I think it's -force-test to force zef to continue testing rather than stop after the first error and -force-install to complete the install despite errors.
I moved my script to a new server with almost identical configuration (apache/centos) but the cgi-bin has been failing to work ever since. For past one week I have googled every possible solution and isolated the error by executing script from command line. Output i get is as follows for a simple test file:
[root /var/foo/public_html/cgi-bin]# perl -dd /var/foo/public_html/cgi-bin/test.cgi
Loading DB routines from perl5db.pl version 1.32
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(/var/foo/public_html/cgi-bin/test.cgi:2):
2: print "Content-type: text/plain\n\n";
Unknown error
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63
Term::ReadLine::Perl::new('Term::ReadLine', 'perldb', 'GLOB(0x18ac160)', 'GLOB(0x182ce68)') called at /usr/share/perl5/perl5db.pl line 6073
DB::setterm called at /usr/share/perl5/perl5db.pl line 2237
DB::DB called at /var/foo/public_html/cgi-bin/test.cgi line 2
Attempt to reload Term/ReadLine/readline.pm aborted.
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
END failed--call queue aborted at /var/foo/public_html/cgi-bin/test.cgi line 63.
at /var/foo/public_html/cgi-bin/test.cgi line 63
[root /var/foo/public_html/cgi-bin]#
The code of the test file I am using is:
#!/usr/local/bin/perl
print "Content-type: text/plain\n\n";
print "testing...\n";
I have checked the path to perl, perl version etc etc and everything seems to be ok. However the script is not exceuting and gives a 500 internal server error. I am running php5 with dso handler and susEXEC on. susEXEC logs does not say anything except that the cgi script has been called. This problem is completely baffling me and my little experience with cgi/perl is not helping. Can anyone point me in a right direction to solve this?
As someone commented already check the permissions and also try to run the file from the console.
A likely problem is that when you switched servers the path to perl changed and your shebang line is wrong. A common technique to avoid this is to use #!/usr/bin/env perl instead.
When you recieve a 500 error apache should also log something in the error log (your vhost config might define a custom error log instead the default one so check that if you're having trouble finding the error message.
Also there is no reason to run your script under the Perl Debugger, unless your goal is to experiment with the Perl Debugger (and with no variable defined it is pointless as an example). My advice is don't use the Perl Debugger. A lot of experienced Perl programmers, (probably a big majority) never or rarely use it.
I solved this eventually, posting it for the sake of posterity:
On moving server I mounted the filesystem on a different partition as the home partition ran out of memory. I forgot to give exec permissions to the new mountpoint, that's why the cgi scripts were not executing.
I have been using php for CGI scripting for some time now and recently got interested in lua.
I installed the latest version of luarocks(2.1.2) and the bundled version of lua(5.1.4). I wanted to start from the basics and hence installed cgilua(5.1.4-2) and all its dependencies using "luarocks install cgilua".
I am able to run simple lua scripts using the shebang line to point to my lua interpreter but when i use it to point to the cgi launcher "cgilua.cgi.exe" to run .lp files it just won't work. I edited my httpd configuration file to allow cgi execution in my htdocs and cgi-bin directory and used the cgi-script handler for .lp pages. I am trying to run the login.lp example in the cgilua examples directory. I even added the line "Content-type:text/html" to no avail. Executing the cgilua.cgi.exe file from the command line without arguments just closes the application with the message "cgilua.cgi.exe" stopped working".
Could anyone tell me what am I missing? Maybe the launcher is supposed to be used in a different way?
I don't suppose permissions have a part to play in this as in windows all users have at least read and execute permissions.
The url I'm trying to access is http://localhost/login.lp. My apache error log shows "Premature end of script headers: login.lp" with a 500 internal server error and the same thing if I access http://localhost/cgilua.cgi.exe
I don't know what your requirements are, but perhaps it will be easier to simply use apache's mod_lua.
http://httpd.apache.org/docs/trunk/mod/mod_lua.html
I'm trying to build apache from source on debian. The only reason I'm not using spt-get install is because in the apache cookbook, they recommend installing from source.I get the following error when I ./configure:
configure: error: invalid variable name: ' --with-mpm'
I also saw some warnings when I ./buildconf Is this something I should be concerned about? This is my first attempt at compiling from source, and I'd really appreciate any help.
I'm using the ./configure arguments directly from the apache cookbook:
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all \ --with-mpm=prefork
I'm running a minimum debian install in virtual box to train myself for deploying in the rackspace cloud soon.
EDIT: I'm building Apache 2.2.16
I suspect you are typing that entire build line you provided on one line, complete with the '\' in the middle.
You should get rid of '\', which in bash either treats the following as part of the same string, but the slash has to immediately follow a non-whitespace character. It is also used for special escape sequences, which I think is the case here and generating that message.
This should be the correct line in your case.
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all --with-mpm=prefork
On a side note, doesn't the Apache Cookbook say that building from source is one possibility for installing it, in addition to installing from a pre-packaged build like you can get from Debian's repositories? I suppose if you really wanted a far newer build or a more repeatable process to ensure consistency across a variety of distributions, building from scratch will do that for you, but otherwise I would try to utilize the distribution's package management as much as possible. Building from source removes you from the security patches and ease-of-upgrade path that Debian APT gives you.
I have been using the clone keyword to duplicate objects like so:
$x = clone $obj;
as per the manual.
This works fine when accessed by browser. phpinfo() reports PHP version 5.2.6.
However when run by cron or from the CLI I get
"Parse error: syntax error, unexpected T_VARIABLE"
from the clone keyword.
php -v reports PHP 4.4.9 (cli)
Is this error from a version conflict?
If I use clone() in my scripts like so:
$_SESSION['user'] = clone($userObject);
I get odd intermittent problems with the $_SESSION['user'] which do not occur when using the clone keyword.
Does this make any sense to anyone?
Any advice?
It seems that the clone $foo keyword is only available on PHP 5 and newer.
Also, if you're still using PHP 4.4.9, that may be a bigger problem.
Turns out the server has 4 and 5 installed and the CLI reports 4.4.9 simply due to PATH order:
From support:
"Running the "php -v" command in the shell will always return V4. That's because we have two separate installs for PHP on your server. One for V4 and one for V5, and the PHP 4 interpreter shows up in your PATH environment variable first. If you'd like to use V5 through the shell you'll need to be sure to use the full path"