Hi!
1. How do I run perl scripts on the toolserver? do I have to use the cgi-bin or may I use public_html? If a script does not work on the toolserver but works at my webserver at another server, how am I able to find the bug? Presently http://toolserver.org/~seth/cgi-bin/grep_regexp_from_url.cgi gives an internal server error 500.
2. Is it possible to use .htaccess-files? I tried to redirect my errorlogs but failed.
3. How can I look at the apache errorlogs?
4. Shall I put your answers to https://wiki.toolserver.org/view/Web_hosting?
thx! seth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth:
- How do I run perl scripts on the toolserver?
i assume from the subject you're talking about Perl CGI scripts. either put them in ~/public_html/cgi-bin, or put them in ~/public_html and name them with a .cgi extension. in either case they have to be executable.
If a script does not work on the toolserver but works at my webserver at another server, how am I able to find the bug? Presently http://toolserver.org/~seth/cgi-bin/grep_regexp_from_url.cgi gives an internal server error 500.
in this case, the problem is your script has Windows line endings.
$ ./grep_regexp_from_url.cgi - -su: ./grep_regexp_from_url.cgi: /usr/bin/perl^M: bad interpreter: No such file or directory
you should configure your text editor to save it with Unix line endings before uploading it.
- Is it possible to use .htaccess-files?
yes.
I tried to redirect my errorlogs but failed.
you'll have to be more specific.
- How can I look at the apache errorlogs?
access and error logs are in /var/log/http
- Shall I put your answers to https://wiki.toolserver.org/view/Web_hosting?
it's a wiki, so if there's useful information that isn't already there, feel free to add it.
- river.
Hi!
River Tarnell wrote:
- How do I run perl scripts on the toolserver?
i assume from the subject you're talking about Perl CGI scripts. either put them in ~/public_html/cgi-bin, or put them in ~/public_html and name them with a .cgi extension. in either case they have to be executable.
I guess .cgi in ~/public_html is not executable be default. my browser just showed me the source code.
After I created a .htaccess with Options FollowSymLinks ExecCGI MultiViews AddHandler cgi-script .cgi .pl it works now.
Presently http://toolserver.org/~seth/cgi-bin/grep_regexp_from_url.cgi gives an internal server error 500.
in this case, the problem is your script has Windows line endings.
$ ./grep_regexp_from_url.cgi
- -su: ./grep_regexp_from_url.cgi: /usr/bin/perl^M: bad interpreter: No such file or directory
Oops, I feet a bit sheepish about that. I did not know that $ perl grep_regexp_from_url.cgi works even when the line endings are dos-styled. Anyway, :set fileformat=unix did the job, and now everything works fine.
- Is it possible to use .htaccess-files?
yes.
I tried to redirect my errorlogs but failed.
you'll have to be more specific.
Right, sorry.
ErrorLog /home/seth/logs/error.log did not put the above mentioned 500-errors into /home/seth/logs/error.log
- How can I look at the apache errorlogs?
access and error logs are in /var/log/http
bash: cd: /var/log/http: No such file or directory
I tried another one, too, but bash: cd: /var/log/apache2/: Permission denied
- Shall I put your answers to https://wiki.toolserver.org/view/Web_hosting?
it's a wiki, so if there's useful information that isn't already there, feel free to add it.
Ok, I'll do that after everything is clear.
bye seth
seth schrieb:
Hi!
River Tarnell wrote:
- How do I run perl scripts on the toolserver?
i assume from the subject you're talking about Perl CGI scripts. either put them in ~/public_html/cgi-bin, or put them in ~/public_html and name them with a .cgi extension. in either case they have to be executable.
I guess .cgi in ~/public_html is not executable be default. my browser just showed me the source code.
Did you indeed set the x bit?
After I created a .htaccess with Options FollowSymLinks ExecCGI MultiViews AddHandler cgi-script .cgi .pl it works now.
Presently http://toolserver.org/~seth/cgi-bin/grep_regexp_from_url.cgi gives an internal server error 500.
in this case, the problem is your script has Windows line endings.
$ ./grep_regexp_from_url.cgi
- -su: ./grep_regexp_from_url.cgi: /usr/bin/perl^M: bad interpreter: No such file or directory
Oops, I feet a bit sheepish about that. I did not know that $ perl grep_regexp_from_url.cgi works even when the line endings are dos-styled.
That'S because *perl* doesn't have a problem with them. It's whatever bit of linux is looking at the "shebang" line (the one starting with #!) to find out what interpreter to use. It reads the Windows line ending as part of the interpreter's name (which is very very silly, but that's how it is).
- How can I look at the apache errorlogs?
access and error logs are in /var/log/http
bash: cd: /var/log/http: No such file or directory
Try this on the web server (hemlock), not on nightshade.
I tried another one, too, but bash: cd: /var/log/apache2/: Permission denied
We no longer use apache, we are using ZWS now.
-- daniel
Hi!
Daniel Kinzler wrote:
seth schrieb:
River Tarnell wrote:
I guess .cgi in ~/public_html is not executable be default. my browser just showed me the source code.
Did you indeed set the x bit?
yes, it was (and still is) set: -rwxr-xr-x+
$ ./grep_regexp_from_url.cgi - -su: ./grep_regexp_from_url.cgi: /usr/bin/perl^M: bad interpreter: No such file or directory
Oops, I feet a bit sheepish about that. I did not know that $ perl grep_regexp_from_url.cgi works even when the line endings are dos-styled.
That'S because *perl* doesn't have a problem with them. It's whatever bit of linux is looking at the "shebang" line [...] to find out what interpreter to use. It reads the Windows line ending as part of the interpreter's name (which is very very silly, but that's how it is).
oic!
- How can I look at the apache errorlogs?
access and error logs are in /var/log/http
bash: cd: /var/log/http: No such file or directory
Try this on the web server (hemlock), not on nightshade.
ah, ok.
bye seth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Kinzler:
I tried another one, too, but bash: cd: /var/log/apache2/: Permission denied
We no longer use apache, we are using ZWS now.
it's likely he was looking on nightshade here, which does run apache, but as it holds no user tools, the logs are private.
- river.
toolserver-l@lists.wikimedia.org