An interesting topic ... heading out to cast vote now.
In our environment, about 6 years ago we informally identified the gap
(grey area, war, however it is described) between server / network
managers and developers / Librarians as an obstacle to our end goals and
have put considerable effort
On Tue, Nov 24, 2009 at 11:18 AM, Graham Stewart
wrote:
> We run many Library / web / database applications on RedHat servers with
> SELinux enabled. Sometimes it takes a bit of investigation and horsing
> around but I haven't yet found a situation where it had to be disabled.
> setsebool and c
twork_connect 1".
Thanks to everyone who helped -- I learned a lot.
Joys
Ken
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Greg
McClellan
Sent: Tuesday, November 24, 2009 10:04 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] calling an
lot.
Joys
Ken
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Greg
McClellan
Sent: Tuesday, November 24, 2009 10:04 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] calling another webpage within CGI script
Hi,
I had a similar problem a while
Hi,
I had a similar problem a while back which was solved by disabling
SELinux. http://www.crypt.gen.nz/selinux/disable_selinux.html
-Greg
number actually are)
regards
Dave Pattern
University of Huddersfield
From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Ken Irwin
[kir...@wittenberg.edu]
Sent: 23 November 2009 19:41
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] calli
On Mon, 23 Nov 2009, Ken Irwin wrote:
Hi Joe,
That's really helpful, thanks.
Actually finding out what the error message is nice:
HTTP Error : 500 Can't connect to www.npr.org:80 (connect: Permission denied)
I've tried this with a few websites and always get the same error, which
tells me th
Of Joe
Hourcle
Sent: Monday, November 23, 2009 2:29 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] calling another webpage within CGI script
I'd suggest testing the results of the call, rather than just looking for
content, as an empty response could be a result of the server you
On Mon, 23 Nov 2009, Ken Irwin wrote:
Hi all,
I'm moving to a new web server and struggling to get it configured properly. The problem of the
moment: having a Perl CGI script call another web page in the background and make decisions
based on its content. On the old server I used an antique P
Ken,
I tested your script on my server and it also worked for me on the command
line and failed via my web server. All I did was add "/usr" to your path to
perl and it worked:
#!/usr/bin/perl
Roy
On 11/23/09 11/23/09 8:17 AM, "Ken Irwin" wrote:
> Hi all,
>
> I'm moving to a new web server
Hi Ken,
This may be obvious, but when running from the command line, stdout and
stderr are often interleaved together, but on the web server you see stdout
in the browser and stderr in the web server error log. Your script is
probably exiting with an error either at the 'get' line (line 6) or at
Ken,
The difference is when you run through command script you are executing
the file as /"owner"/ and as "/Other/" when you access it through the
browser. Looking at the error message you sent, I believe it might not
be executing the complete script. Try setting permissions as 707 or 777
to
Hi all,
I'm moving to a new web server and struggling to get it configured properly.
The problem of the moment: having a Perl CGI script call another web page in
the background and make decisions based on its content. On the old server I
used an antique Perl script called "hcat" (from the Pelic
13 matches
Mail list logo
