Re: MP1 - libapreq1.2 broke apache / mod_perl installation
The latest version of ExtUtils::MakeMaker tickles a bug in libapreq's c/Makefile.PL. There has been quite a bit of discussion of this issue in the last week on apreq-dev, p5p, and on this list as well. aha! I'd noticed some threads about compiling libapreq - should have read them in detail. I always assume when i encounter a problem that it is my mistake/bug rather than the module's. Now and then it turns out it is the module. I should also get out of the habit of upgrading modules without discrimination... if i'd known of the conflict I'd have left MakeMaker unchanged as libapreq is of more use to me Michael Schwern [hope I spelled it right :] posted two patches to the apreq-dev list designed to fix these problems. As soon as enough folks decide which of his patches is best, we'll roll a 1.3 release that fixes the problem. I guess I'll just sit tight and wait, then. My mod_perl knowledge is not good enough to help here - and besides I am in a fight of my own with Apache::Session::Postgresql :( -- Iphigenie, [EMAIL PROTECTED] on 04/08/2003
MP1 - libapreq1.2 broke apache / mod_perl installation
Hi I am puzzled. I installed libapreq1.2 on a server the normal way (perl Makefile.PL, make, make test, make install) and now my server refuses to run Apache::Cookie or Apache::Request. It complains of [Sun Aug 3 18:09:29 2003] [error] Can't load '/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 What puzzles me is that it this worked perfectly on another near identical machine. Why does it want .so files? I thought that happened only if you installed it using the ./configure method, which I didnt. Apache Modperl installed from the official redhat 7.2 rpms Please help, I have a production server that is down and I cannot think straight at the moment. -- Joelle Nebbe, [EMAIL PROTECTED] on 03/08/2003
Re: MP1 - libapreq1.2 broke apache / mod_perl installation
I installed libapreq1.2 on a server the normal way (perl Makefile.PL, make, make test, make install) and now my server refuses to run Apache::Cookie or Apache::Request. It complains of [Sun Aug 3 18:09:29 2003] [error] Can't load '/usr/lib/perl5/site_perl/5.6.1/i386- linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 What puzzles me is that it this worked perfectly on another near identical machine. Why does it want .so files? I thought that happened only if you installed it using the ./configure method, which I didnt. I looked and I had files all over the place in my perl library tree, in Apache, libapreq, Apache/Cookie, Apache/Request, Apache/libapreq etc etc I reckon I had several versions in parallel and Dynaloader mixed and matched as it pleased. So I deleted all those Cookie.pm, Cookie.so, Request.pm, Request.so etc. etc. and reinstalled libapreq 1.0 My server works again so the panic is gone. The question remains: what did i naively do wrong the first time? Thanks
Re: MP1 - libapreq1.2 broke apache / mod_perl installation
Iphigenie [EMAIL PROTECTED] writes: [...] What puzzles me is that it this worked perfectly on another near identical machine. Why does it want .so files? I thought that happened only if you installed it using the ./configure method, which I didnt. The latest version of ExtUtils::MakeMaker tickles a bug in libapreq's c/Makefile.PL. There has been quite a bit of discussion of this issue in the last week on apreq-dev, p5p, and on this list as well. Michael Schwern [hope I spelled it right :] posted two patches to the apreq-dev list designed to fix these problems. As soon as enough folks decide which of his patches is best, we'll roll a 1.3 release that fixes the problem. [...] The question remains: what did i naively do wrong the first time? Probably nothing- this is a bug in libapreq. -- Joe Schaefer
Apache, Mod_PERL, and PERL
It was my assumption that apache allowed for the perl executable to be loaded into memory and called from then on without having to worry about creating the external process (ISAPI I think is what the reference said). When I touch a .pl from the web the perl executable runs =( Am I doing something wrong?
Re: Apache, Mod_PERL, and PERL
Hi there, On Sat, 31 May 2003, Ryan Farrington wrote: It was my assumption that apache allowed for the perl executable to be loaded into memory and called from then on without having to worry about creating the external process Well that sort of sounds right, but instead of making assumptions, why not read the Guide? You'll find it at http://perl.apache.org There's quite a lot to read (but around here we don't consider that to be an excuse for not reading it. :) (ISAPI I think is what the reference said). I have no idea what you're talking about. Can you at least read enough to be able to tell us what it is you've got there and what you've read that you don't understand? It will help us to help you if you tell us things like which operating system, versions of Apache and mod_perl, how you've configured them, what Perl modules you're trying to use, what your scripts are supposed to do... When I touch a .pl from the web the perl executable runs =( What else would you want it to do? 73, Ged.
RE: Apache, Mod_PERL, and PERL
Nm... -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: Saturday, May 31, 2003 4:59 PM To: Ryan Farrington Cc: [EMAIL PROTECTED] Subject: Re: Apache, Mod_PERL, and PERL Hi there, On Sat, 31 May 2003, Ryan Farrington wrote: It was my assumption that apache allowed for the perl executable to be loaded into memory and called from then on without having to worry about creating the external process Well that sort of sounds right, but instead of making assumptions, why not read the Guide? You'll find it at http://perl.apache.org There's quite a lot to read (but around here we don't consider that to be an excuse for not reading it. :) (ISAPI I think is what the reference said). I have no idea what you're talking about. Can you at least read enough to be able to tell us what it is you've got there and what you've read that you don't understand? It will help us to help you if you tell us things like which operating system, versions of Apache and mod_perl, how you've configured them, what Perl modules you're trying to use, what your scripts are supposed to do... When I touch a .pl from the web the perl executable runs =( What else would you want it to do? 73, Ged.
RE: [mp2] apache/mod_perl starup failure using cvs 09
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 9:23 PM
To: Beau E. Cox
Cc: Modperl
Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
[...]
why does Mason needs $r at the server startup? There is no
request object at
the server startup, so it's only fair that mp reports the error.
[...]
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
I see what you mean. In mp1 you relied on Apache-request's not
being defined
as a side-effect to test whether you are inside request or not.
I will explain why I've chosen to croak, rather than return 'undef'.
In mp1 Apache-request was either undef (outside of request) or
$r (during the
request). You couldn't control that. In mp2 in order to optimize things,
keeping the global request around is optional. So if you don't
need it you get
some speed improvement.
So if the user has the global request setting off and
Apache-request returns
undef, he may think that he is not inside the request phases
(precisely what
mason does), which is wrong.
Therefore if you still wish to rely on this (which is no longer
always valid
under mp2), you can do:
eval { $r = Apache-request}
to trap the croak.
may be you should use something else as a predicate to calling
Apache-request. For example you could use:
ModPerl::Util::current_callback() to figure out where you are.
Though it'll
incur a checking of several options. So perhaps we need a new
method or may be
not. Ideas are welcome.
Philippe has agreed with my reasoning when I've suggested the change and
nobody else has objected (or had any opinion at all), so it went
in. Since
nothing is cast is stone (yet) on the mp2 API, you may suggest your
explanation why it should behave differently if you think that my
idea is wrong.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Yea, Stas, I clearly see your reasoning. However, this is not a change
of behaviour between mp1 and mp2, but rather between mp2-08 and the
current cvs (09). I will continue using mp2-08 and talk to the mason
list - but it seems that folks over there are not too anxious to
do much in the line of mp2 development until the 'request' is converted.
My only concern is that mp2 and mason will eventually work well
together - I feel a little like I am caught in the middle ;)
Please don't spend any more time on this until I get a mason answer.
Aloha = Beau;
Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
Yea, Stas, I clearly see your reasoning. However, this is not a change
of behaviour between mp1 and mp2, but rather between mp2-08 and the
current cvs (09).
since 09 08, it *is* a change in behaviour between mp1 and mp2 ;) though
potentially not the final one.
I will continue using mp2-08 and talk to the mason
meanwhile you can continue using the lates cvs, but add to the beginning of
your startup to cheat on the latest change:
require Apache::RequestUtil;
no warnings 'redefine';
my $sub = *Apache::request{CODE};
*Apache::request = sub {
my $r;
eval { $r = $sub-('Apache'); };
# warn $@ if $@;
return $r;
};
list - but it seems that folks over there are not too anxious to
do much in the line of mp2 development until the 'request' is converted.
You mean Apache::Request?
My only concern is that mp2 and mason will eventually work well
together - I feel a little like I am caught in the middle ;)
if you don't mind to get frustrated here and there, that's the best position
to learn things ;)
Please don't spend any more time on this until I get a mason answer.
;)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2] apache/mod_perl starup failure using cvs 09
Hi Stas -
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 10:45 PM
To: Beau E. Cox
Cc: Modperl
Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
Yea, Stas, I clearly see your reasoning. However, this is not a change
of behaviour between mp1 and mp2, but rather between mp2-08 and the
current cvs (09).
since 09 08, it *is* a change in behaviour between mp1 and mp2
;) though
potentially not the final one.
I will continue using mp2-08 and talk to the mason
meanwhile you can continue using the lates cvs, but add to the
beginning of
your startup to cheat on the latest change:
require Apache::RequestUtil;
no warnings 'redefine';
my $sub = *Apache::request{CODE};
*Apache::request = sub {
my $r;
eval { $r = $sub-('Apache'); };
# warn $@ if $@;
return $r;
};
list - but it seems that folks over there are not too anxious to
do much in the line of mp2 development until the 'request' is converted.
You mean Apache::Request?
Yes...
[...]
Your fix works perfectly - I'm a happy camper. I passed our discussion
to the mason list - will keep you folks informed.
Aloha = Beau;
PS: Have you ever noticed the closer your deadline becomes, the more
things go wrong and the more mistakes you make?
[mp2] apache/mod_perl starup failure using cvs 09
-8-- Start Bug Report 8--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[Tue Mar 04 16:45:09 2003] [error] Can't load Perl file:
/srv/www/conf/simple-mason.pl for server TOMOKO.beaucox.com:0, exiting...
Apache error.log - no entries
Apache rcapache.log - Syntax OK
Apache access.log - no entries
mod_perl/mason (1.19) relevant entries in httpd.conf:
LoadModule perl_module /srv/www/modules/mod_perl.so
PerlRequire /srv/www/conf/startup.pl
Alias /perl/ /srv/www/perl/
Location /perl/
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
PerlRequire /srv/www/conf/simple-mason.pl
FilesMatch \.html$
SetHandler perl-script
PerlHandler MyMason::MyApp
/FilesMatch
/srv/www/conf/startup.pl
use Apache2 ();
use lib qw(/srv/www/perl);
use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Session ();
use CGI::Cookie ();
use APR::Table ();
use ModPerl::Registry ();
use Apache::Const -compile = ':common';
use APR::Const -compile = ':common';
1;
/srv/www/conf/simple-mason.pl
#!/usr/bin/perl
#
# A basic, functional Mason handler.pl.
#
package MyMason::MyApp;
#
# Setup for mod_perl 2
use Apache2 ();
use Apache::compat ();
# Preload CGI since we are using it for mod_perl 2
use CGI ();
# Bring in Mason with Apache support.
use HTML::Mason::ApacheHandler;
use strict;
#
# List of modules that you want to use within components.
{
package HTML::Mason::Commands;
use Data::Dumper;
}
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler-new (
args_method = CGI,
comp_root = /srv/www/htdocs,
data_dir= /srv/www/mason,
error_mode = 'output',
);
#
sub handler
{
my ($r) = @_;
my $status = $ah-handle_request($r);
return $status;
}
#
1;
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class-allowed_params(%defaults, %params);
573: if ( exists $allowed_params-{comp_root} and
my $req = $r || Apache-request ) # DocumentRoot is only available
inside requests
{
$defaults{comp_root} = $req-document_root;
}
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX= /usr/local/apache2
MP_GENERATE_XS = 1
MP_INST_APACHE2 = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
MP_USE_STATIC = 1
*** /usr/local/apache2/sbin/httpd -V
Server version: Apache/2.0.44
Server built: Mar 4 2003 14:35:52
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/worker
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/usr/local/apache2
-D SUEXEC_BIN=/usr/local/apache2/bin/suexec
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=/etc/httpd/mime.types
-D SERVER_CONFIG_FILE=/etc/httpd/httpd.conf
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.19, archname=i586-linux-thread-multi
uname='linux amdsim5 2.4.19 #1 wed mar 27 13:57:05 utc 2002 i686 unknown
'
config_args='-ds -e -Dprefix=/usr -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_g
dbm -Duseshrplib=true'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc',
Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
-8-- Start Bug Report 8--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[...]
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class-allowed_params(%defaults, %params);
573: if ( exists $allowed_params-{comp_root} and
my $req = $r || Apache-request ) # DocumentRoot is only available
why does Mason needs $r at the server startup? There is no request object at
the server startup, so it's only fair that mp reports the error.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2] apache/mod_perl starup failure using cvs 09
Hi Stas -
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 6:18 PM
To: Beau E. Cox
Cc: Modperl
Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
-8-- Start Bug Report 8--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using
simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not
available. Set:
PerlOptions +GlobalRequest
in httpd.conf at
/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[...]
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class-allowed_params(%defaults, %params);
573: if ( exists $allowed_params-{comp_root} and
my $req = $r || Apache-request ) # DocumentRoot is only
available
why does Mason needs $r at the server startup? There is no
request object at
the server startup, so it's only fair that mp reports the error.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Good point. However, I seemed to have given you the code of
mason's ApacheHandler out of context; the snip above is from the
'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler-new (
args_method = CGI,
comp_root = /srv/www/htdocs,
data_dir= /srv/www/mason,
error_mode = 'output',
);
In this trivial case it doesn't seem worthwhile to go to all
that trouble, but, as in my production server, when working
with a lot of (possible dynamic) vhosts, it works well.
If the Apache-request (or a request passed as the last -
odd - parameter to new) is defined, some further processing
occurs; but at startup, the request is neither expected to
be there nor needed.
I guess (looking at my result matrix) that some change was made
to mod_perl to prohibit even querying the presence of
Apache-request at startup. So now I (and other mason folks)
must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
Aloha = Beau;
Re: [mp2] apache/mod_perl starup failure using cvs 09
[...]
why does Mason needs $r at the server startup? There is no
request object at
the server startup, so it's only fair that mp reports the error.
[...]
Good point. However, I seemed to have given you the code of
mason's ApacheHandler out of context; the snip above is from the
'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler-new (
args_method = CGI,
comp_root = /srv/www/htdocs,
data_dir= /srv/www/mason,
error_mode = 'output',
);
In this trivial case it doesn't seem worthwhile to go to all
that trouble, but, as in my production server, when working
with a lot of (possible dynamic) vhosts, it works well.
If the Apache-request (or a request passed as the last -
odd - parameter to new) is defined, some further processing
occurs; but at startup, the request is neither expected to
be there nor needed.
I guess (looking at my result matrix) that some change was made
to mod_perl to prohibit even querying the presence of
Apache-request at startup. So now I (and other mason folks)
must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
I see what you mean. In mp1 you relied on Apache-request's not being defined
as a side-effect to test whether you are inside request or not.
I will explain why I've chosen to croak, rather than return 'undef'.
In mp1 Apache-request was either undef (outside of request) or $r (during the
request). You couldn't control that. In mp2 in order to optimize things,
keeping the global request around is optional. So if you don't need it you get
some speed improvement.
So if the user has the global request setting off and Apache-request returns
undef, he may think that he is not inside the request phases (precisely what
mason does), which is wrong.
Therefore if you still wish to rely on this (which is no longer always valid
under mp2), you can do:
eval { $r = Apache-request}
to trap the croak.
may be you should use something else as a predicate to calling
Apache-request. For example you could use:
ModPerl::Util::current_callback() to figure out where you are. Though it'll
incur a checking of several options. So perhaps we need a new method or may be
not. Ideas are welcome.
Philippe has agreed with my reasoning when I've suggested the change and
nobody else has objected (or had any opinion at all), so it went in. Since
nothing is cast is stone (yet) on the mp2 API, you may suggest your
explanation why it should behave differently if you think that my idea is wrong.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache, mod_perl, mod_proxy, mod_rewrite
Serguei Trouchelle wrote: error.log says following: [error] proxy:http://naive1.isd.dp.ua/cgi-bin/system-select-isd-request.pl not found or unable to stat But request to http://naive1.isd.dp.ua/cgi-bin/system-select-isd-request.pl was successful. What's up? I found what is up. Apache::Registry and Apache::PerlRun cannot handle request proxy:http://naive1.isd.dp.ua/cgi-bin/system-select-isd-request.pl So another question (sadly that nobody answers to first one): why request, meant to proxy, is sending to Apache::Registry or Apache::PerlRun? -- Serguei Trouchelle http://www.isd.dp.ua/
Apache, mod_perl, mod_proxy, mod_rewrite
Today I tried to change my cgi-scripts to mod_perl ones. I used mod_rewrite and mod_proxy just like this: RewriteRule ^/system/select/isd/request/$ /cgi-bin/system-select-isd-request.cgi [P] But when I tried to change to mod_perl RewriteRule ^/system/select/isd/request/$ /cgi-bin/system-select-isd-request.pl [P] I've got 404 Not Found error: The requested URL /system/select/isd/request/ was not found on this server. error.log says following: [error] proxy:http://naive1.isd.dp.ua/cgi-bin/system-select-isd-request.pl not found or unable to stat But request to http://naive1.isd.dp.ua/cgi-bin/system-select-isd-request.pl was successful. What's up? -- Serguei Trouchelle http://www.isd.dp.ua/
Re: Environment variable in Apache/mod_perl/IO::Socket
G'day Dean,
I just tried it and it seemed to work fine. (i just tried connecting to
my db instead and printed the value of $socket to STDERR). The only
question I have is where are $socket, $host and $port defined? They do
not seem to be local to the routine, so is it possible that is where the
confusion is happening?
Uru
-Dave
dhfg wrote:
Hi,
In my web application, I am using Apache server with mod_perl. In one of my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
RE: Environment variable in Apache/mod_perl/IO::Socket
Hi David,
The $socket, $host, and $port are all defined locally, ie. my $host, $port,
$socket (I missed them out while writing the email). What platform are you
trying it out. I have the socket client running within the Apache server on
the Solaris and making the connection to the Socket server running on a
Window XP PC. Wonder if this may cause the problem.
Cheers,
Dean
-Original Message-
From: David Dick [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 6 February 2003 7:17 PM
To: dhfg
Cc: [EMAIL PROTECTED]
Subject: Re: Environment variable in Apache/mod_perl/IO::Socket
G'day Dean,
I just tried it and it seemed to work fine. (i just tried connecting to
my db instead and printed the value of $socket to STDERR). The only
question I have is where are $socket, $host and $port defined? They do
not seem to be local to the routine, so is it possible that is where the
confusion is happening?
Uru
-Dave
dhfg wrote:
Hi,
In my web application, I am using Apache server with mod_perl. In one of
my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set
in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved
correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are
same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
Re: Environment variable in Apache/mod_perl/IO::Socket
I'm on Linux 2.4.20, with Apache 1.3.27, mod_perl 1.27, perl 5.6.1,
connecting locally to a postgres db. My previous guess had to be wrong
because you said the code
worked if you replaced
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
with
$socket = new IO::Socket::INET(
PeerAddr = 'gaia',
PeerPort = ,
Proto= 'tcp')
or die Cannot connect to $port at $host;
Have you tried just extracting the code to a small test program,
defining the environment variables on the command line and running it
through the perl debugger?
dhfg wrote:
Hi David,
The $socket, $host, and $port are all defined locally, ie. my $host, $port,
$socket (I missed them out while writing the email). What platform are you
trying it out. I have the socket client running within the Apache server on
the Solaris and making the connection to the Socket server running on a
Window XP PC. Wonder if this may cause the problem.
Cheers,
Dean
-Original Message-
From: David Dick [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 6 February 2003 7:17 PM
To: dhfg
Cc: [EMAIL PROTECTED]
Subject: Re: Environment variable in Apache/mod_perl/IO::Socket
G'day Dean,
I just tried it and it seemed to work fine. (i just tried connecting to
my db instead and printed the value of $socket to STDERR). The only
question I have is where are $socket, $host and $port defined? They do
not seem to be local to the routine, so is it possible that is where the
confusion is happening?
Uru
-Dave
dhfg wrote:
Hi,
In my web application, I am using Apache server with mod_perl. In one of
my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set
in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved
correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
Environment variable in Apache/mod_perl/IO::Socket
Hi,
In my web application, I am using Apache server with mod_perl. In one of my
Perl modules, I am creating a client socket using IO::Socket::INET which is
accepting the hotsname and port values from the environment variables set in
the Apache config file http.conf. For some reason, this didn't work
eventhough I have verified that the values were set and retrieved correctly.
Below is the extract of my codes:
In the config file http.conf:
PerlSetEnv AGENT_SOCKET_HOST 'gaia'
PerlSetEnv AGENT_SOCKET_PORT
In my AgentSocket.pm:
use strict;
use IO::Socket::INET;
sub new
{
$host = $ENV{AGENT_SOCKET_HOST}; # I have checked these values are
same
as
$port = $ENV{AGENT_SOCKET_PORT}; # those set in the http.conf
$socket = new IO::Socket::INET(
PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp')
or die Cannot connect to $port at $host;
:
return $socket;
}
The above socket did not get connect to the server but didn't die either.
But if I assigned
$host='gaia', $port='' within the AgentSocket.pm then it worked fine.
I have been tearing my hair out for days now and can't find the answer.
Perhaps you could help. Thanks in advance.
Regards,
Dean
windows and apache/mod_perl?
Is it worth installing apache 1.x and mod_perl 1.x on windows if apache2/mod_perl2/perl5.8 run on windows? Thanks
Re: windows and apache/mod_perl?
On Mon, 16 Dec 2002, Paul Simon wrote: Is it worth installing apache 1.x and mod_perl 1.x on windows if apache2/mod_perl2/perl5.8 run on windows? I guess it depends on what one is using it for ... For a development/learning system, the performance enhancements with apache2/modperl2 probably outweigh the disadvantages of using the more stable/tested apache1/modperl1 combination. But for a production system, it may be non-trivial to upgrade; in particular, many Apache::* modules may need either mod_perl-2's compatibility mode or some (small, or perhaps large) changes to work with mod_perl-2. -- best regards, randy kobes
Re: Copying Apache/Mod_perl/perl installation
Ged == Ged Haywood [EMAIL PROTECTED] writes: [...] If I can use RPM under SCO Open Server 5.0.6, and it gives me perl with all the modules, Apache, and mod_perl, I 'd definitely go for that. Anyone used RPM to copy installation under SCO? [...] My approach is to build perl, Apache, mod_perl, etc. in development mirroring the directory heirarchy that will exist on the deployed platform. Once this is done, I can work within its confines through unit test. Consequently I've been able to simply tar/gzip this entire tree from some common root, drop it onto the install target, undo it all at the same root and have it function as expected. I thought I'd be pushing the limits of shared library compatibility and other arch. details as I'm developing on Solaris 7 and the deployment target is Solaris 8 ... however it has not failed me yet. YMMV. Peace.
Copying Apache/Mod_perl/perl installation
Hi all, This is kinda installation question. I have installed perl, Apache, Mod_perl with some modules (GD, Apache FileManager, DBD-Chart etc.,) in my development machine. Is there anyway to copy the installation to a similar OS/architecture without going through all the installtion proceedures. In another words, can I copy the installed software/packages to another machine which is of same OS/architecture? Any help/url/RTFMs... 'd be appreciated. TIA, G-Man.
Re: Copying Apache/Mod_perl/perl installation
For the CPAN perl modules, check out the CPAN autobundle feature. It will make a Bundle file of every perl module installed on your machine, which you can then copy and install on the new machine. Installing the bundle file will make it download and install all the CPAN modules. For the rest, either copy and install the same RPM files, or put the installation steps into a script, copy the script and tarballs to the new machine and run the script there. Hope this helps, Wes Sheldahl Ganesan M [EMAIL PROTECTED] on 10/08/2002 10:31:09 AM To:[EMAIL PROTECTED] cc: Subject:Copying Apache/Mod_perl/perl installation Hi all, This is kinda installation question. I have installed perl, Apache, Mod_perl with some modules (GD, Apache FileManager, DBD-Chart etc.,) in my development machine. Is there anyway to copy the installation to a similar OS/architecture without going through all the installtion proceedures. In another words, can I copy the installed software/packages to another machine which is of same OS/architecture? Any help/url/RTFMs... 'd be appreciated. TIA, G-Man.
Re: Copying Apache/Mod_perl/perl installation
Hi there, (You forgot to cc the List. :) On Tue, 8 Oct 2002, Ganesan M wrote: If I can use RPM under SCO Open Server 5.0.6, and it gives me perl with all the modules, Apache, and mod_perl, I 'd definitely go for that. Anyone used RPM to copy installation under SCO? Never done it myself, and I have to say I'm not a great lover of RPM, but I'm sure you can - although you might need to work on it a litle. Take a look at http://www.rpm.org. 73, Ged.
Re: Copying Apache/Mod_perl/perl installation
Hi guys, On Tue, 8 Oct 2002, Geoffrey Young wrote: [snip] Is there anyway to copy the installation to a similar OS/architecture without going through all the installtion proceedures. In another words, can I copy the installed software/packages to another machine which is of same OS/architecture? try using the make targets tar_Apache and offsite-tar - [snip] RPM? 73, Ged.
newbie: apache, mod_perl, mod_ssl (openssl) installation...
quick question, probably a stupid one at that... do i need a secure certificate from thawte.com to install a secure server? if not, what's the point of the certificate? Can someone briefly explain the process... thanks __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
RE: newbie: apache, mod_perl, mod_ssl (openssl) installation...
Hey Anthony -- quick question, probably a stupid one at that... do i need a secure certificate from thawte.com to install a secure server? Not strictly. if not, what's the point of the certificate? The point is to raise $55 million so that Mark Shuttleworth can travel in space? Hehe... The serious reason is a bit more complicated. SSL provides encryption. That's the sole advantage for most uses. The third-party certificate vendors are not needed if all you want is encryption. Companies like Thawte/Verisign provide an additional facility: Authentication of the server to which you are sending data. In theory, they would prevent you from inadvertently submitting your super-secret data to amazone instead of amazon. Or something like that. In practice, the only real reason seems to be to prevent those annoying dialog boxes from popping up when you visit an unblessed SSL website. It's a protection racket if you ask me. Can someone briefly explain the process... To make your own self-signed certificate you run openssl: 1. Create a private key: $ openssl genrsa -out httpsd.key 1024 2. Create a Certificate Signing Request (CSR): $ openssl req -new -key httpsd.key -out httpsd.csr 2. Create self-signed certificate: $ openssl req -x509 -days 365 -in httpsd.csr -key httpsd.key -out httpsd.crt TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RedHat RPM for apache+mod_perl?
Has anyone here come up with an RPM for apache+mod_perl, with the following caveats: 1. mod_perl is statically compiled 2. I don't want SSL. This will be backend server. Only the frontend needs SSL. 3. can co-exist with a non-mod_perl Apache on the same system, meaning that it has its own config dir, pid file, logs, etc. 4. Including mod_rpaf would be a nice bonus, but adding this probably wouldn't be too hard. In other words, is there anything like the excellent apache-perl Debian package, but for Red Hat. ARGH, I really hate Red Hat. But in this case I'm stuck with it. I've been working on this myself for a few hours but I realized I should ask about it here first. -dave /*== www.urth.org we await the New Sun ==*/
Re: RedHat RPM for apache+mod_perl?
On Wed, 2002-09-25 at 18:11, Dave Rolsky wrote: Has anyone here come up with an RPM for apache+mod_perl, with the following caveats: I use Apache ToolBox to get all these items and have been very pleased with. It allows you the option of creating a RPM as well, so if that part works for you (mine didn't) you would have something you could take from machine to machine. The process allows for you to modify the install path so it will play nice with other versions of Apache on the same machine. You can configure evey part and it even prompts you to edit the configuration files during the process. I have tested this on: Custom Linux, the OS was assembiled from various GNU parts Installed Apache/mod_perl/php/mod_ssl Mandrake 8.2 Linux Installed Apache/mod_perl/php/mod_ssl/mod_layout Red Hat 7.? Installed Apache/mod_perl/php/mod_ssl/mod_layout I have only tested the recently RPM support one time under Mandrake so I am not sure how well it might work on other platforms. Even if the RPM portion doesn't work the Toolbox takes away most of the grunt work. http://www.apachetoolbox.com 1. mod_perl is statically compiled 2. I don't want SSL. This will be backend server. Only the frontend needs SSL. 3. can co-exist with a non-mod_perl Apache on the same system, meaning that it has its own config dir, pid file, logs, etc. 4. Including mod_rpaf would be a nice bonus, but adding this probably wouldn't be too hard. In other words, is there anything like the excellent apache-perl Debian package, but for Red Hat. ARGH, I really hate Red Hat. But in this case I'm stuck with it. I've been working on this myself for a few hours but I realized I should ask about it here first. -dave /*== www.urth.org we await the New Sun ==*/
apache mod_perl compiled with gcc 3.1 or Intel C/C++?
Hi, has someone experiences in gcc 3.1 or Intel C/C++ compiler for apache, perl mod_perl on a production system with P4/XEON RedHat. At this time I use gcc 2.96. I heard with gcc 2.96 the code optimization for P4/XEON is not good. Any ideas? Sven. -- Sven Geislere-mail: [EMAIL PROTECTED] Senior Developertel:(+49 30) 53 62 16 27
Re: apache + mod_perl -- chunk mode trailer
* Fang Cheng [EMAIL PROTECTED] [2002-08-13 23:06]: If you do an apache code trace, set the breakpoint at apache_src/main/http_protocol.c function ap_finalize_request_protocol, you will see the r-chunked == 0 even though it was set to be 1. You can also use snoop to see that the trailers \0\r\n was missing. Are you using any subrequests? (darren) -- Laziness is often mistaken for patience.
Re: apache + mod_perl -- chunk mode trailer
What is subrequests? It is HTTP POST request, and that invokes some perl CGI script. No matter what CGI script it is invoking, this problem is always there for a 200 response... Fang --- darren chamberlain [EMAIL PROTECTED] wrote: * Fang Cheng [EMAIL PROTECTED] [2002-08-13 23:06]: If you do an apache code trace, set the breakpoint at apache_src/main/http_protocol.c function ap_finalize_request_protocol, you will see the r-chunked == 0 even though it was set to be 1. You can also use snoop to see that the trailers \0\r\n was missing. Are you using any subrequests? (darren) -- Laziness is often mistaken for patience. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
apache + mod_perl -- chunk mode trailer
I have a problem with the HTTP response in the chunk mode using mod_perl. When apache sends a response in the chunk mode, the mod_perl handler invokes the ap_send_http_header() function in the apache src/main/http_protocol.c file, and the r-chunked flag is set to 1 (by the ap_keep_alive() function). However when apache calls the ap_finalize_request_protocol() before sending out the request, the r-chunked is 0. Indeed, all changes that mod_perl/perl script made to request_rec (r) does not show up there at the stage the ap_finalize_request_protocol function was called. That caused the chunked content trailer was not sent to the client. I am running the apache on SUN unix box. The apache version is 1.3.12 and set the (keepAlive on). The mod perl version is 1.24. Version 1.27 also has this problems as well. If you do an apache code trace, set the breakpoint at apache_src/main/http_protocol.c function ap_finalize_request_protocol, you will see the r-chunked == 0 even though it was set to be 1. You can also use snoop to see that the trailers \0\r\n was missing. Is this a well known bug? Any way to solve it? Tx... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName add to /etc/hosts: 127.0.0.1 localhost.localdomain localhost [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So it starts normally. perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have installed perl into /usr/local/bin and /usr/bin comes earlier in the path so it picks 5.6.0. Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries though I can see that you will have dependencies problems. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with Apache/Mod_perl Server
My apologies. Thought I posted to the list Thanks for the help. Alfred, Alfred Vahau wrote: The server's up and running. Thanks for the /etc/hosts tip I actually had the line as 127.0.0.1 bullen localhost.localdomain localhost So I commented out that and entered it as 127.0.0.1 localhost.localdomain localhost and sure enough that served the Apache page as it should for the first time. I appreciate the help. I will continue to look into Perl 5.6.0 and 5.6.1 paths though. Good, but please reply to the list, so others know that your problem has been solved. --- This is off topic but ever hear of the site naver.com? The postings to modperl had been intercepted and returned to me with encrypted messages and a naver.com site with Korean or Japanese characters. Not a clue about the site. I suspect that this posting is going to be intercepted and copied to me. Wonder if its a robot? no clue --- Alfred, Stas Bekman wrote: Alfred Vahau wrote: Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName add to /etc/hosts: 127.0.0.1 localhost.localdomain localhost [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So it starts normally. perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have installed perl into /usr/local/bin and /usr/bin comes earlier in the path so it picks 5.6.0. Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries though I can see that you will have dependencies problems. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache mod_perl + suid question
[EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
apache/mod_perl help
I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel
RE: apache mod_perl + suid question
Thanks a lot. That really does help. regards, -Tushar -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 6:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: apache mod_perl + suid question [EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache/mod_perl help
Dinesh Patel wrote: I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! It's too early to upgrade to mod_perl 2.0. Not all features are implemented (which is the case with Perl sections). For more info see: http://perl.apache.org/docs/2.0/user/index.html I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Problems with Apache/Mod_perl Server
Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] 3. Then I backup into the apache_1.3.26 directory and issue make install I am congratulated for a successful installation. 4. The I issue (as root) /usr/local/apache/bin/apachectl start and the error message from the /usr/local/apache/logs/error_log [Tue Jul 30 16:01:52 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Apache.pm failed to load!. [Tue Jul 30 16:37:55 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Tue Jul 30 16:37:55 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. [Wed Jul 31 12:27:57 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 12:27:57 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. I think the failure is due to incomplete mod_perl installation. As I pointed out earlier, the earlier versions of mod_perl and apache were installed successfully. I was configuring the httpd.conf file to run some cgi scripts which did not execute very well but I think can fix that. I've spent the past 48 hours trying to trouble shoot the trouble as much as I can but access to information is so very frustrating from this end of the world.. I am using Perl 5.6.1 on Linux 7.1. I installed the mod_perl and apache packages which came with the box but did not use them so had them unstalled. Any pointers to where I can start meaningful trouble-shooting would be greatly appreciated. Thanks in advance, Alfred Vahau School of Natural and Physical Sciences Uni. PNG
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with Apache/Mod_perl Server
Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. Thanks, Alfred, Stas Bekman wrote: Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RES: apache mod_perl + suid question
Insecure dependency in `` while running with -T switch at /usr/sbin/usermod_wrapper.pl line 27 These means that you can't use ``. You need to use system command. $command = /path/you/need; system($command); All the additional vars need to be passed through vars : $var1 = login; $var2 = password: system($command,$var1,$var2); If it does not run under -T switch, will not run in mod_perl. So to get over this problem, I should chown apachectl to the Apache group ? No. And secondly, if I am running Apache as non-root, then I will have to use the system command ? I cannot use the $ret = `$wrapper` command. Is this true ? Even running apache as root, you need to follow the tainted mode rules. Regards, Vitor -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 8:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Tushar, It's not recommeded to run apache as root. (Security issues). I have some applications that uses system command under mod_perl without problems. Try to execute you wrapper script in command line. Execute it with /usr/bin/perl -T (tainted mode), that checks if your script is safe. If you got error results, you will know why it's not working. $ret = `$wrapper` , also should work in you configuration (running apache as root). Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 20:13 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RES: apache mod_perl + suid question
I think you can't get out of tainted mode under mod_perl. You will have a big security role if you quit tainted mode. Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sábado, 27 de julho de 2002 12:06 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Vitor, The thing is also that I can run the wrapper from the command line without the -T switch, and I do succeed, i.e. the password does get changed. Seems like mod_perl by default has the taint mode on. How do I get rid of this taint mode from mod_perl. At present I have the following use calls in mod_perl: use Apache::Constants qw(:common); use Apache::Debug(); use CGI '-autoload'; Do I need to add something here or take out something from here to get rid of the tainted mode ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 8:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Tushar, It's not recommeded to run apache as root. (Security issues). I have some applications that uses system command under mod_perl without problems. Try to execute you wrapper script in command line. Execute it with /usr/bin/perl -T (tainted mode), that checks if your script is safe. If you got error results, you will know why it's not working. $ret = `$wrapper` , also should work in you configuration (running apache as root). Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 20:13 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RE: apache mod_perl + suid question
Vitor, Yes, I get the following error when I use the -T mode: Insecure dependency in `` while running with -T switch at /usr/sbin/usermod_wrapper.pl line 27 Please bear with me, if I am going through your answer again. Please let me know if the following would be the correct way to go: So to get over this problem, I should chown apachectl to the Apache group ? And secondly, if I am running Apache as non-root, then I will have to use the system command ? I cannot use the $ret = `$wrapper` command. Is this true ? Thanks much for your help. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 8:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Tushar, It's not recommeded to run apache as root. (Security issues). I have some applications that uses system command under mod_perl without problems. Try to execute you wrapper script in command line. Execute it with /usr/bin/perl -T (tainted mode), that checks if your script is safe. If you got error results, you will know why it's not working. $ret = `$wrapper` , also should work in you configuration (running apache as root). Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 20:13 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RE: apache mod_perl + suid question
Vitor, The thing is also that I can run the wrapper from the command line without the -T switch, and I do succeed, i.e. the password does get changed. Seems like mod_perl by default has the taint mode on. How do I get rid of this taint mode from mod_perl. At present I have the following use calls in mod_perl: use Apache::Constants qw(:common); use Apache::Debug(); use CGI '-autoload'; Do I need to add something here or take out something from here to get rid of the tainted mode ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 8:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Tushar, It's not recommeded to run apache as root. (Security issues). I have some applications that uses system command under mod_perl without problems. Try to execute you wrapper script in command line. Execute it with /usr/bin/perl -T (tainted mode), that checks if your script is safe. If you got error results, you will know why it's not working. $ret = `$wrapper` , also should work in you configuration (running apache as root). Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 20:13 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RE: apache mod_perl + suid question
Ahhh...forgot to mention...but the below approach did't work :-( It does not even go into the wrapper script when I use the system command. thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:13 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RE: apache mod_perl + suid question
Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
RE: apache mod_perl + suid question
Yes, I am running it as /usr/sbin/usermod. I can run my wrapper with a simple perl script written on linux. The problem appears when I try to run it through the apache mod_perl. thanks. -Tushar -Original Message- From: Philip Mak [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 6:50 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: apache mod_perl + suid question On Fri, Jul 26, 2002 at 06:40:31PM -0400, [EMAIL PROTECTED] wrote: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? Try '/usr/sbin/usermod' instead of 'usermod'. It may be a path issue. Also, 'usermod' might have to be run interactively (rather than reading from standard input), so you may have to create a virtual terminal in order to interface with usermod. (I might be wrong on this, and I can't elaborate further.)
apache mod_perl + suid question
Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
Re: apache mod_perl + suid question
On Fri, Jul 26, 2002 at 06:40:31PM -0400, [EMAIL PROTECTED] wrote: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? Try '/usr/sbin/usermod' instead of 'usermod'. It may be a path issue. Also, 'usermod' might have to be run interactively (rather than reading from standard input), so you may have to create a virtual terminal in order to interface with usermod. (I might be wrong on this, and I can't elaborate further.)
RES: apache mod_perl + suid question
Tushar, It's not recommeded to run apache as root. (Security issues). I have some applications that uses system command under mod_perl without problems. Try to execute you wrapper script in command line. Execute it with /usr/bin/perl -T (tainted mode), that checks if your script is safe. If you got error results, you will know why it's not working. $ret = `$wrapper` , also should work in you configuration (running apache as root). Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 20:13 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Assunto: RE: apache mod_perl + suid question Thanks Vitor... I have something very similar to what you mention below..only that I am taking the username and passwd from the apache gui. Then I encrypt the passwd and send that to wrapper(i.e. suid_file) script. So I have something like system($wrapper), where $wrapper = suid_file.pl encrupted passwd username. I changed the suid_file to 4750 and have the ownership and group as root,root. I am also runing Apache as root. I don't have httpd as a user or group. Do I need to ? Also do I need to use the ystem command, can't I just do $ret = `$wrapper` ? thanks. -Tushar -Original Message- From: Vitor [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 7:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RES: apache mod_perl + suid question Hello Tushar, Try this : $suid_file = file_path/suidfile.pl; $user = nobody; $passwd = kdsak; (system($suid_file,$user,$$passwd)) or die Error in suid operation $! ; Note that suid_file need the following commands : - chmod 4750 - chown root:httpd Regards, Vitor -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviada em: sexta-feira, 26 de julho de 2002 19:41 Para: [EMAIL PROTECTED] Assunto: apache mod_perl + suid question Hello, I am trying to write a password changing program. For this I have a mod_perl subroutine from where I am trying to execute a perl script(with suid permissions 4711), which is a wrapper and in turn calls the usermod command on linux with the old and new passwords. The problem I am having: 1: The usermod command doesn't get executed. I have tried debugging this...by having a log file(/usr/local/apache/logs) and the mod_perl process does open the wrapper script..but then does nothing. It does not execute the command. What am I doing wrong ? I know there might be some quirks with suid permissons and I would like to know how can I overcome this. I have something like below from mod_perl subroutine: my $ret_val = `$wrapper`; Within the wrapper perl script, I call usermond with the passwds by doing: $ret = `$usermondcmd 21` Any help would be much appreciated. thanks a lot. -Tushar
Re: [win32] new perl/apache/mod_perl binary
On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote: Hi, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This I've update configure-apache.pl to match. See: http://savage.net.au/index.html First timers: configure-apache.pl simply patches a few Perl and Apache config files when you install these packages on a drive other than C:. The entire installation process is documented, including the environment, some security issues, installing and starting Apache as a service, and some MS Windows-specific DNS issues. -- Cheers Ron Savage, [EMAIL PROTECTED] on 10/07/2002 http://savage.net.au/index.html
Re: [win32] new perl/apache/mod_perl binary
On Tue, 9 Jul 2002, Ron Savage wrote: On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote: Hi, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This I cannot get this to start properly under WinNT. Symptoms: 1) shellApache.exe -n Apache -k install 2 lines of output appear: Installing the Apache service The Apache service has been installed successfully. and then a Windows error box, containing: The instruction at 0x... referenced memory at 0x The memory could not be 'read'. Nevertheless, Apache is installed, and can be uninstalled. [ ... ] Does it start OK, and give the server signature, if you just do C:\Apache Apache.exe I think the problem might be in Embperl - try commenting out the Embperl directives towards the bottom of httpd.conf and see if that helps in starting the service. Neverthless, as you say, things seem to work OK even with these errors on start-up. best regards, randy
Re: [win32] new perl/apache/mod_perl binary
On Tue, 9 Jul 2002 02:25:41 -0500 (CDT), Randy Kobes wrote: Randy On Tue, 9 Jul 2002, Ron Savage wrote: On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote: Hi, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This I cannot get this to start properly under WinNT. Symptoms: 1) shellApache.exe -n Apache -k install 2 lines of output appear: Installing the Apache service The Apache service has been installed successfully. and then a Windows error box, containing: The instruction at 0x... referenced memory at 0x The memory could not be 'read'. Nevertheless, Apache is installed, and can be uninstalled. [ ... ] Does it start OK, and give the server signature, if you just do C:\Apache Apache.exe Yes. I think the problem might be in Embperl - try commenting out the Embperl directives towards the bottom of httpd.conf and see if that helps in starting the service. Neverthless, as you say, things seem to work OK even with these errors on start-up. Yes, the problem is Embperl. Commenting it out (lines 1084 to 1096 of httpd.conf) fixed things. Phew. Thanx for your help. -- Cheers Ron Savage, [EMAIL PROTECTED] on 09/07/2002 http://savage.net.au/index.html
Re: [win32] new perl/apache/mod_perl binary
Yes, the problem is Embperl. Commenting it out (lines 1084 to 1096 of httpd.conf) fixed things. Phew. I have also seen this problem with Embperl when installing Apache service. It's not special to this binary version. Since Apache gets always installed correctly, I never had taken the time to track it down. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: [win32] new perl/apache/mod_perl binary
Greetings [...] there's a better way - if anyone's familiar with this, could you drop me a mine, privately? Thanks. ^ Are you sure this is *really* what you want? : (Sorry I could not resist). Cheers, alf
Re: [win32] new perl/apache/mod_perl binary
On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote: Hi, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This Randy I cannot get this to start properly under WinNT. I've tried installing in C:\ and D:\. I've updated (but not uploaded) my configure-apache.pl to patch these 3 files: D:\perl\lib\Config.pm D:\perl\lib\CPAN\Config.pm D:\apache\conf\httpd.conf so the install on D:\ should be correct. Symptoms: 1) shellApache.exe -n Apache -k install 2 lines of output appear: Installing the Apache service The Apache service has been installed successfully. and then a Windows error box, containing: The instruction at 0x... referenced memory at 0x The memory could not be 'read'. Nevertheless, Apache is installed, and can be uninstalled. 2) If I try shellapache -k start without the install, and try a -k stop in another DOS window, I get the same error box (in the -k stop window) with _exactly_ the same 2 memory addresses. Nevertheless, Apache stops. 3) If I try shellapache -n Apache -k install and ignore the error, and then try: shellapache -n Apache -k start I get 2 lines of output: The Apache service is starting. The Apache service has started. with about 6 seconds between the msgs, then straight after the 2nd msg, the error box with _exactly_ the same 2 memory addresses. Nevertheless, Apache can be stopped, and it does serve pages. 4) access.log contains the expected. error.log contains nothing. ssl_engine_log contains this per start: -8- [07/Jul/2002 22:47:15 04016] [info] Server: Apache/1.3.26, Interface: mod_ssl/2.8.10, Library: OpenSSL/0.9.6d [07/Jul/2002 22:47:15 04016] [warn] You are using mod_ssl under Win32. This combination is *NOT* officially supported. Use it at your own risk! [07/Jul/2002 22:47:15 04016] [info] Init: 1st startup round (still not detached) [07/Jul/2002 22:47:15 04016] [info] Init: Initializing OpenSSL library [07/Jul/2002 22:47:15 04016] [info] Init: Loading certificate private key of SSL-aware server localhost:443 [07/Jul/2002 22:47:15 04016] [info] Init: Seeding PRNG with 136 bytes of entropy [07/Jul/2002 22:47:15 04016] [info] Init: Generating temporary RSA private keys (512/1024 bits) [07/Jul/2002 22:47:16 04016] [info] Init: Configuring temporary DH parameters (512/1024 bits) [07/Jul/2002 22:47:16 04016] [warn] Failed to release global mutex lock [07/Jul/2002 22:47:16 04016] [warn] Failed to release global mutex lock [07/Jul/2002 22:47:16 04016] [info] Init: Seeding PRNG with 136 bytes of entropy [07/Jul/2002 22:47:16 04016] [info] Init: Configuring temporary RSA private keys (512/1024 bits) [07/Jul/2002 22:47:16 04016] [info] Init: Configuring temporary DH parameters (512/1024 bits) [07/Jul/2002 22:47:16 04016] [info] Init: Initializing (virtual) servers for SSL [07/Jul/2002 22:47:16 04016] [info] Init: Configuring server localhost:443 for SSL protocol [07/Jul/2002 22:47:16 04016] [warn] Init: (localhost:443) RSA server certificate CommonName (CN) `www.snakeoil.dom' does NOT match server name!? [07/Jul/2002 22:47:18 04016] [info] Init: 2nd startup round (already detached) [07/Jul/2002 22:47:18 04016] [info] Init: Reinitializing OpenSSL library [07/Jul/2002 22:47:18 04016] [warn] Failed to release global mutex lock [07/Jul/2002 22:47:18 04016] [warn] Failed to release global mutex lock [07/Jul/2002 22:47:18 04016] [info] Init: Seeding PRNG with 136 bytes of entropy [07/Jul/2002 22:47:19 04016] [info] Init: Configuring temporary RSA private keys (512/1024 bits) [07/Jul/2002 22:47:19 04016] [info] Init: Configuring temporary DH parameters (512/1024 bits) [07/Jul/2002 22:47:19 04016] [info] Init: Initializing (virtual) servers for SSL [07/Jul/2002 22:47:19 04016] [info] Init: Configuring server localhost:443 for SSL protocol [07/Jul/2002 22:47:19 04016] [warn] Init: (localhost:443) RSA server certificate CommonName (CN) `www.snakeoil.dom' does NOT match server name!? -8- -- Cheers Ron Savage, [EMAIL PROTECTED] on 09/07/2002 http://savage.net.au/index.html
Re: [win32] new perl/apache/mod_perl binary
Hi Randy, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. Is this package binary compatible with ActiveState, i.e. can I do a ppm install to get additional packages? Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: [win32] new perl/apache/mod_perl binary
On Mon, 8 Jul 2002, Gerald Richter wrote: Hi Randy, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. Is this package binary compatible with ActiveState, i.e. can I do a ppm install to get additional packages? Gerald Hi Gerald, Yes, it's based on the sources of build 633 of ActiveState. I've also included the ppm utility for adding packages; some adjustments in Perl/site/lib/ppm.xml may be needed if Perl is installed to other than C:/Perl/. Competely off-topic, but I would like to be able to make up an msi package of this, so different components could be installed to desired locations, and a script then run to adjust accordingly the various config files. I got an add-on to Visual Studio to make msi packages, but as near as I can tell, you have to add files one at a time, which is a bit tedious ... Obviously there's a better way - if anyone's familiar with this, could you drop me a mine, privately? Thanks. best regards, randy
Re: E-commerce payment systems for apache/mod_perl
On 2 Jul 2002, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? There are a few 'clearing house' type services to which one can subscribe that do the actual cybercash-type transaction for you. it can be expensive and prohibitively complicated to set up the services yourself. For small sites, I have fired off perl scripts that use openssl to connect to a serice we hired, passing the info they need, and waiting for a response that i parse and display to the user, as i write it to our db2 db as well with dbd-dbi.. Damned if i can remember the name of the service we used. i wrote it for the 1998 superbowl. I can only imagine that the number of such services has proliferated since then, but i havent checked lately. ive been out of e-commerce since 2000. Ive had a devil of a time running the cybercash (and similar) services for myself as every option seemed to be expensive, buggy, or lacking on customer support when the end customer inevitably asked questions i couldnt answer. maybe they have improved in the last 2 years, butfiring it off to someone else (the classic SEP or 'somebody elses problem' theorem), waiting for a nice pleasant order number to be returned over ssl, and printing it to the screen branded as if my site did it all by itself is worth a small charge per transaction that youre going to end up paying anyway even if you do it all yourself. Do you have a particular company doing your order fulfillment? If so, they may have such an arrangement or service already in place. a lot i ran into did. -- gedanken
Re: E-commerce payment systems for apache/mod_perl
hi, I use two services for payment proccessing. One for digital money www.cyphermint.com/epay/ (quite complex for initial installing, i don't like it) and the second for cc processing (much more simple) you can just give them info about your contract (say id, price, amount) and redirect user on their site for payment processing (http://www.assist.ru/eng/about/cardpayments/) I don't thunk these services are suitable for, but you read some help on it and understand what exactly you need. -vlad Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re[2]: E-commerce payment systems for apache/mod_perl
We have been using ECHO for over 5 years and they have been an excellent company. They are strictly a credit card processing company - no order fulfillment. They also do online check processing and a whole bunch of other services. They are the only processing company that I have seen that really actively supports Open Source. From their website: ECHO's Free, Open Source, GPL Secure Payment Gateway ECHO is the only company on the Internet to provide both a Merchant Account AND Secure Payment Gateway services for only $19.95/month in fixed account fees!* We actually give away our real time processing software modules and gateway access. Even our Merchant Account's $19.95/month fixed account fee is waived for months with no activity. http://www.echo-inc.com/ http://www.openecho.com/ http://www.openecho.com/perl/example.pl http://www.openecho.com/download_files.html HTH, Christopher Taranto WWWarehouse, Inc. At 10:43 PM 7/2/02 -0500, you wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: E-commerce payment systems for apache/mod_perl
On Tue, Jul 02, 2002 at 10:43:14PM -0500, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? http://interchange.redhat.com/ - it's mature - we wrote our own but i'd use it instead if I had to start over http://www.ipaymentinc.com/ - reseller for authorize.net http://authorize.net/ - big transaction provider - supported cpan module (simple/trivial) http://www.dhl.com/ - we get really cheap rates for dhl's next day shipping service world wide (1-2 days continential us $6) (3-4 days door2door to pakistan from indianapolis $21) ... much, much cheaper than even the cheapest ups-residential-ground - ups has well developed xml API's, dhl dosn't Ed
Re: E-commerce payment systems for apache/mod_perl
Gedanken [EMAIL PROTECTED] writes: On 2 Jul 2002, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? There are a few 'clearing house' type services to which one can subscribe that do the actual cybercash-type transaction for you. it can be expensive and prohibitively complicated to set up the services yourself. Yes, that's what I've been half-expecting. [snip] I can only imagine that the number of such services has proliferated since then, but i havent checked lately. ive been out of e-commerce since 2000. Ive had a devil of a time running the cybercash (and similar) services for myself as every option seemed to be expensive, buggy, or lacking on customer support when the end customer inevitably asked questions i couldnt answer. maybe they have improved in the last 2 years, butfiring it off to someone else (the classic SEP or 'somebody elses problem' theorem), waiting for a nice pleasant order number to be returned over ssl, and printing it to the screen branded as if my site did it all by itself is worth a small charge per transaction that youre going to end up paying anyway even if you do it all yourself. I'm hoping I can sell the client this idea; it certainly matches *my* idea of easier. Do you have a particular company doing your order fulfillment? If so, they may have such an arrangement or service already in place. a lot i ran into did. New client (not hooked yet), but I don't believe they're likely to have anything in place from what I know so far. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Re[2]: E-commerce payment systems for apache/mod_perl
Christopher Taranto [EMAIL PROTECTED] writes: We have been using ECHO for over 5 years and they have been an excellent company. They are strictly a credit card processing company - no order fulfillment. They also do online check processing and a whole bunch of other services. They are the only processing company that I have seen that really actively supports Open Source. This looks very promising, thanks for the specific pointer. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: E-commerce payment systems for apache/mod_perl
On Wed, 3 Jul 2002, Vlad Safronov wrote: hi, I use two services for payment proccessing. One for digital money www.cyphermint.com/epay/ (quite complex for initial installing, i don't like it) and the second for cc processing (much more simple) you can just give them info about your contract (say id, price, amount) and redirect user on their site for payment processing (http://www.assist.ru/eng/about/cardpayments/) I don't thunk these services are suitable for, but you read some help on it and understand what exactly you need. -vlad Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info So does anyone have any recommendations for an epay (Pay-pal) system? -- ~~ Doug Silver Network Manager Urchin Software Corp. http://www.urchin.com ~~
E-commerce payment systems for apache/mod_perl
Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: missing .al files with apache/mod_perl
Hi there, On Wed, 26 Jun 2002, Perrin Harkins wrote: Furthermore, this file doesn't exist in my filesystem. How is it possible that (1) the module works without this apparently required file at the command line but (2) doesn't work with apache/mod_perl ? How is it possible? Two ways: you could be wrong about the existence of the file, or the situtation that requires the file might only arise when you use it with mod_perl. I'd suggest you start debugging it by looking at the things that are different when running it from mod_perl: the user, environment variables, working directory, ways that you call it, etc. One of those things is probably responsible. 'Perl -V' would tell us what's in INC amongst other things... 73, Ged.
missing .al files with apache/mod_perl
Hi, I asked about this before, but didn't get a response, so here we go again... I'm able to use MPEG::LibMPEG3 in a command line perl script, but if I try to use it under mod_perl, I get an error: [error] Can't locate auto/MPEG/LibMPEG3/dimensions.al in INC ... Furthermore, this file doesn't exist in my filesystem. How is it possible that (1) the module works without this apparently required file at the command line but (2) doesn't work with apache/mod_perl ? -Allen
Re: missing .al files with apache/mod_perl
Allen Day wrote: Furthermore, this file doesn't exist in my filesystem. How is it possible that (1) the module works without this apparently required file at the command line but (2) doesn't work with apache/mod_perl ? How is it possible? Two ways: you could be wrong about the existence of the file, or the situtation that requires the file might only arise when you use it with mod_perl. I'd suggest you start debugging it by looking at the things that are different when running it from mod_perl: the user, environment variables, working directory, ways that you call it, etc. One of those things is probably responsible. - Perrin
FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
(Apologies if you see this twice -- I sent it from an unsubscribed email address first.) Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
I came across the same problem while trying to install a bunch of XML modules via the CPAN module. It was pretty frustrating when the module installations kept dying when it got to expat, even after a installed the expat port time and time again. I think I solved the problem similarly to the way you did, either that or I just decided I didn't need the XML modules installed. Mike -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 10:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. The expat issue has been discussed quite a bit on this list, and is documented here: http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X ML_Parser Sorry to hear you had trouble finding it. That section of the guide is the first place you should look when you're having segfault problems. - Perrin
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Yeh, it does apply on other BSD platforms--but I don't think it's specific to BSD(s). I use the same args on Net and Open on Apaches I've built on those platforms. I came across this issue with AxKit. There's tons of references on the web as well: http://www.google.com/search?hl=enie=UTF8oe=UTF8q=disable-rule%3Dexpat -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 7:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
On Sun, Jun 09, 2002 at 12:43:38PM -0400, Perrin Harkins wrote: I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. The expat issue has been discussed quite a bit on this list, and is documented here: http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X ML_Parser Sorry to hear you had trouble finding it. That section of the guide is the first place you should look when you're having segfault problems. - Perrin Eeek! Thanks the for the pointer to the warnings and errors guide. I guess when I first tried to find out what was going on by STFW, I thought it was something OpenSRS specific. Later, when I'd found something that seemed to work, I didn't go back and search for expat or XML_Parse. It's reassuring to see that the fix that I'd guessed at is the right one to use, though. Thanks again, -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Apache/mod_perl still not ready for OS X?
Hi, I've been postponing to move my Linux Apache/mod_perl development to my highly appreciated iBook running Mac OS X due to all the required tweaks until now. I would imagine things have been sorted out by now so I downloaded apache 1.3.24 to give it a go. The system I'm working on has a self-contained build-script which fetches everything from CVS, executes the right build commands etc. without me having to think. This has a built-in step to compile mod_perl statically (i.e. not DSO as i don't want that) into Apache. Now I find that out that the part that compiles Apache bails out with this: env LD_RUN_PATH=/opt/ttgp/dev/applications/perl/lib/5.6.1/darwin/CORE cc -c -I.. -I/opt/ttgp/dev/applications/perl/lib/5.6.1/darwin/CORE -I../os/unix -I../include -DDARWIN -DMOD_PERL -DUSE_PERL_SSI -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -DUSE_HSREGEX -DNO_DL_NEEDED -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing `../apaci` alloc.c alloc.c: In function `spawn_child_core': alloc.c:2291: `STDOUT_FILENO' undeclared (first use in this function) alloc.c:2291: (Each undeclared identifier is reported only once alloc.c:2291: for each function it appears in.) alloc.c:2297: `STDIN_FILENO' undeclared (first use in this function) alloc.c:2303: `STDERR_FILENO' undeclared (first use in this function) make[4]: *** [alloc.o] Error 1 make[3]: *** [subdirs] Error 1 make[2]: *** [build-std] Error 2 make[1]: *** [build] Error 2 make: *** [apaci_httpd] Error 2 I almost find this appalling. It can't find something basic as STDOUT_FILENO (which is in /usr/include/unistd.h)... So I went back to Google to find solutions and the first hit sends me to stepwise.com to a tutorial that tells me in detail what commands to type in. Great, but it forces me to use DSO which I don't want! So, what is missing in the Apache configuration part that will make this work in a sensible way? Regards, Bas. ps. I know I'm a programmer that loves to tweak but when it comes to something as basic as this I'm just a user that's looking for the any key;)
Re: RPM for apache/mod_perl/mod_ssl
In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. Thanks, Fran Christof Damian wrote: On Wed, 05 Jun 2002, fliptop wrote: i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions. i got one for redhat 7.0, i am in the progress to update it to the current versions of apache/mod_perl/mod_ssl though. christof
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: In the spirit of the teach a man to fish proverb (sorry if that's a random reference), maybe I should really be asking what's involved in making such an rpm? Is it a case of just figuring out which files are installed by openssl/mod_ssl/mod_perl/apache and making a big ole spec file, or is there some configuration magic that needs to happen? If this is straying too far off-topic I'll take the discussion off-list, but I really should learn how to do this properly for myself. it probably is ot, so i'll make this short. a good place to start is http://www.rpm.org/max-rpm/
RPM for apache/mod_perl/mod_ssl
We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. I have used my limited experience with RPM to try to build this kind of thing, but so far the closest I've gotten is to have an RPM that includes the four tarballs with a shell script to compile them on the target machine. Of course this really isn't in the spirit of RPM and also, fails miserably when the target machine is a hardened machine with no compiler, for example. :-) Does such a thing exist, and what are some pros and cons of going this route? Personally, I would hate to have to rely on an RPM like this, not least because I'd have to learn how to modify it if it doesn't meet our needs, but we need to make the application install as easy as possible for the data center folks. Thoughts? Thanks, Fran
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. what o/s and version are you running? i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions.
Re: RPM for apache/mod_perl/mod_ssl
fliptop, I'll take a copy of that spec file, if you don't mind!!! --Jon Robison fliptop wrote: Fran Fabrizio wrote: We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. what o/s and version are you running? i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions.
Re: RPM for apache/mod_perl/mod_ssl
Thanks Stas for that link, but none of those have mod_ssl and I'm not skilled enough with RPM to make that heavy of an adjustment, to be honest. I think I'll take a gander at fliptop's specs and see if they are close enough to do what I need. Thanks all! -Fran Stas Bekman wrote: Fran Fabrizio wrote: We're currently struggling for an easy way to distribute our apache/mod_perl/mod_ssl-based application to our data center folks who are in a different state and whom we must presume know nothing about apache, mod_perl or mod_ssl and are capable of nothing more complicated than using RPM to install/update a package. As such, does there exist such a thing as an RPM that installs apache with mod_perl AND mod_ssl enabled? I presume this would also have to include openssl. I can only imagine what a pain it would be to create this beast, but if it's been done, I'd like to give it a try. I have used my limited experience with RPM to try to build this kind of thing, but so far the closest I've gotten is to have an RPM that includes the four tarballs with a shell script to compile them on the target machine. Of course this really isn't in the spirit of RPM and also, fails miserably when the target machine is a hardened machine with no compiler, for example. :-) Does such a thing exist, and what are some pros and cons of going this route? Personally, I would hate to have to rely on an RPM like this, not least because I'd have to learn how to modify it if it doesn't meet our needs, but we need to make the application install as easy as possible for the data center folks. Thoughts? Take an existing src RPM (.spec) and adjust it the way you want. Here are some RPMs: http://perl.apache.org/release/download/binaries.html#RedHat_Linux __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: RPM for apache/mod_perl/mod_ssl
On Wed, 05 Jun 2002, fliptop wrote: i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i run on redhat 6.2. i'd be glad to give you the .src (or the .rpm if you also run redhat 6.2) if you would like it. or, i could just give you the .spec if you'd like to build a new rpm with the latest versions. i got one for redhat 7.0, i am in the progress to update it to the current versions of apache/mod_perl/mod_ssl though. christof -- Christof Damian Technical Director, guideguide ltd.
Embed Apache+Mod_perl into a application
Hello Folks, Does anybody tried to embed mod_perl and apache inside an windows application ? Thanks, Vitor
RE: XML::LibXSLT / Apache / MOD_Perl Segfaults
The issue below could be corrected by *not* linking into the XML::LibXSLT module libexslt libraries. Even if you do not call any functions in the library, but still link in the libraries the apache process will not start. I guess I will go fire off a bug report to the libxslt guys. Thanks for your suggestions. On Tue, 30 Apr 2002, D. Hageman wrote: Yes, I have done that as well. On Tue, 30 Apr 2002, Clayton Cottingham wrote: Have you compiled apache with noexpat in the apache? -- Clayton Cottingham Air Games Wireless Inc. Suite 204, 309 W. Cordova St. Vancouver BC V6B 1E5 Canada Tel: +1.604.408.2228 Cel: +1.604.720.3510 Fax: +1.604.408.2649 Email: [EMAIL PROTECTED] Web: www.airg.com -Original Message- From: D. Hageman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:56 PM To: Matt Sergeant Cc: D. Hageman; [EMAIL PROTECTED] Subject: Re: XML::LibXSLT / Apache / MOD_Perl Segfaults I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: D. Hageman wrote: I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
XML::LibXSLT / Apache / MOD_Perl Segfaults
I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl I have removed all of the mod_perl runtime directives to hopefully ease the debugging. Additional notes is that I have rebuilt the perl RH package to use -Ubincompat5005 as per instructions from one of the mod_perl guides to hopefully avoid common segfaults on startup. Any help that you can give me to track down this little issue would be greatly appreciated. The back trace is down below ... #0 0x404b53df in Perl_share_hek () from /etc/httpd/modules/libperl.so #1 0x404b3c05 in Perl_hv_store () from /etc/httpd/modules/libperl.so #2 0x404b3809 in Perl_hv_fetch () from /etc/httpd/modules/libperl.so #3 0x4047aefd in Perl_gv_fetchpv () from /etc/httpd/modules/libperl.so #4 0x4049b47f in Perl_newXS () from /etc/httpd/modules/libperl.so #5 0x404fc42f in Perl_boot_core_UNIVERSAL () from /etc/httpd/modules/libperl.so #6 0x40475d78 in S_parse_body () from /etc/httpd/modules/libperl.so #7 0x40475513 in perl_parse () from /etc/httpd/modules/libperl.so #8 0x40455978 in perl_startup () from /etc/httpd/modules/libperl.so #9 0x4045c3c1 in perl_section () from /etc/httpd/modules/libperl.so #10 0x080550a5 in ap_clear_module_list () at eval.c:41 #11 0x08055972 in ap_handle_command () at eval.c:41 #12 0x080559de in ap_srm_command_loop () at eval.c:41 #13 0x08056008 in ap_process_resource_config () at eval.c:41 #14 0x08055f5c in ap_process_resource_config () at eval.c:41 #15 0x080567fc in ap_read_config () at eval.c:41 #16 0x0805ffdd in ap_child_terminate () at eval.c:41 #17 0x080609d3 in main () at eval.c:41 #18 0x40177627 in __libc_start_main (main=0x8060550 main, argc=3, ubp_av=0xbb04, init=0x804f32c _init, fini=0x8074e10 _fini, rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xbafc) at ../sysdeps/generic/libc-start.c:129 -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
Re: XML::LibXSLT / Apache / MOD_Perl Segfaults
D. Hageman wrote: I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt.
Re: XML::LibXSLT / Apache / MOD_Perl Segfaults
I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: D. Hageman wrote: I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
RE: XML::LibXSLT / Apache / MOD_Perl Segfaults
Have you compiled apache with noexpat in the apache? -- Clayton Cottingham Air Games Wireless Inc. Suite 204, 309 W. Cordova St. Vancouver BC V6B 1E5 Canada Tel: +1.604.408.2228 Cel: +1.604.720.3510 Fax: +1.604.408.2649 Email: [EMAIL PROTECTED] Web: www.airg.com -Original Message- From: D. Hageman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:56 PM To: Matt Sergeant Cc: D. Hageman; [EMAIL PROTECTED] Subject: Re: XML::LibXSLT / Apache / MOD_Perl Segfaults I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: D. Hageman wrote: I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
RE: XML::LibXSLT / Apache / MOD_Perl Segfaults
Yes, I have done that as well. On Tue, 30 Apr 2002, Clayton Cottingham wrote: Have you compiled apache with noexpat in the apache? -- Clayton Cottingham Air Games Wireless Inc. Suite 204, 309 W. Cordova St. Vancouver BC V6B 1E5 Canada Tel: +1.604.408.2228 Cel: +1.604.720.3510 Fax: +1.604.408.2649 Email: [EMAIL PROTECTED] Web: www.airg.com -Original Message- From: D. Hageman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:56 PM To: Matt Sergeant Cc: D. Hageman; [EMAIL PROTECTED] Subject: Re: XML::LibXSLT / Apache / MOD_Perl Segfaults I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: D. Hageman wrote: I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: Perl use XML::LibXSLT; /Perl It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
Re: Apache/Mod_Perl in Production Env-- NOT Recommended in Windows?
At 03:48 18.04.2002, Arul, Rex wrote: Friends, I know Apache/Mod_Perl on OS other than Windows to be the trend du juor. However, I am in jitters seeing this explicit warning given in http://www.perl.com web-portal. NOTE: it is not recommended to use Windows for production Apache/mod_perl servers; Apache/mod_perl 1.x is not able to scale well on this platform; Apache/mod_perl 2.x is addressing the fundamental architectural disagreements that cause this. The article is here:http://www.perl.com/pub/a/2002/03/12/axkit.html?page=2 Has anyone in this list use Apache/Mod_Perl in **WINDOWS OS** under **Production Environment **? Well, the issue on Windows is that the mod_perl server can only serve one request at a time. So clearly, it's a problem. However, some people have reported that it would still give them a great performance increase, by following some special steps. Get a proxy setup like described at various places in the guide http://perl.apache.org/guide/ : the proxy serves most of the requests, and sends some requests off to the backend mod_perl enabled server. Good caching should be a plus: the less requests sent to the mod_perl-enabled server the better. This isn't all too different from standard mod_perl setups, but you have to watch out even more when running on Windows. You might even want to try and setup several backend mod_perl servers and load balance between them, all depending on how much memory you can spare. -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: Re: Apache/Mod_Perl in Production Env-- NOT Recommended inWindows?
Thanks Per. But should the stoic silence for this poser of mine, be construed as there are NO takers out there who have their Web Sites in Production, running out of Apache 1.XX and Mod-Perl 1.XX on Windows NT/2000? Primarily we are a Microsoft shop, and I would like to answer this question to my bosses (if possible). Thanks, Rex Per Einar Ellefsen [EMAIL PROTECTED] wrote: This isn't all too different from standard mod_perl setups, but you have to watch out even more when running on Windows. You might even want to try and setup several backend mod_perl servers and load balance between them, all depending on how much memory you can spare. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
RE: Re: Apache/Mod_Perl in Production Env-- NOT Recommended inWindows?
At 16:57 18.04.2002, Arul, Rex wrote: Thanks Per. But should the stoic silence for this poser of mine, be construed as there are NO takers out there who have their Web Sites in Production, running out of Apache 1.XX and Mod-Perl 1.XX on Windows NT/2000? Primarily we are a Microsoft shop, and I would like to answer this question to my bosses (if possible). Well, I wouldn't say it's undoable. You could try it out and see if it works for you. But I wouldn't take my word for it, because it depends on many factors (especially the number of concurrent connections). What I can suggest is that you take a look at PerlEx from ActiveState. For Windows, it might be a better choice, although it costs a little money. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Non-web use for Apache/mod_perl
Bas A.Schulte wrote: Hi, I've been meaning to write an article about how I used Apache/mod_perl to implement a mobile SMS application platform as it demonstrates use of Apache/mod_perl outside the Web realm, something I hadn't seen so far. Time constraints (as always) have prevented me from doing this properly, however, I'll try to give a short description of the system. The goal kinda is to see if others are using Apache/mod_perl in a similar way to share experiences, discuss issues that arise or discuss alternatives (I'd love someone to tell me I'm an idiot for handling all this lowlevel stuff myself and move to J2EE/java at once, if he can convince me I could have implemented this with the same budget and time frame). Very nice, Bas. Thanks for sharing with us. For J2EE in Perl see http://p5ee.perl.org/. Very early alpha though. For protocol server httpd-2.0/modperl-2.0 is exactly what you want, since it supports protocol servers and other useful things you will most likely benefit from (e.g. filtering), but don't hold your breath yet, since httpd-2.0 is not out yet. Though if you plan doing a next generation some time in the future, you probably better off start looking at modperl-2.0. We already have Eliza protocol example running as one of the tests: t/TEST -v protocol/eliza protocol/eliza1..6 ok 1 # send: Hello Eliza # recv: Hi. What seems to be your problem? ok 2 # send: How are you # recv: You're not really talking about me -- are you? ok 3 # send: Why do I have core dumped? # recv: That's quite interesting. ok 4 # send: I feel like writing some tests today, you? # recv: That is interesting. Please continue. ok 5 # send: good bye # recv: That is interesting. Please continue. ok 6 ok All tests successful. This is the client: http://cvs.apache.org/viewcvs.cgi/~checkout~/modperl-2.0/t/protocol/eliza.t This is the server: http://cvs.apache.org/viewcvs.cgi/~checkout~/modperl-2.0/t/protocol/TestProtocol/eliza.pm Also, can we adapt your story for our success stories collection? http://perl.apache.org/stories/ If so, can you please send me an adapted version, or I can simply throw it in as is :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Non-web use for Apache/mod_perl
Bas A.Schulte wrote: Hi, I've been meaning to write an article about how I used Apache/mod_perl to implement a mobile SMS application platform as it demonstrates use of Apache/mod_perl outside the Web realm, something I hadn't seen so far. Time constraints (as always) have prevented me from doing this properly, however, I'll try to give a short description of the system. The goal kinda is to see if others are using Apache/mod_perl in a similar way to share experiences, discuss issues that arise or discuss alternatives (I'd love someone to tell me I'm an idiot for handling all this lowlevel stuff myself and move to J2EE/java at once, if he can convince me I could have implemented this with the same budget and time frame). [snip] I actually implemented a similar system, although it's not SMS specific. Basically, I have a central system in Apache/mod_perl. The eventual design is for full I/O in many protocols, including HTTP, SMTP, FTP and a handful of other protocols. So far the output is pretty much ready, and I think I'm going to wait for Apache 2 before I do the inputs. I _could_ write mod_perl handlers to understand other protocols, but Apache 2 is being designed around this, as far as I understand, so I'm going to do that around Apache 2 (as soon as I get off my ass and learn the new API :-)) Issac
Re: Non-web use for Apache/mod_perl
Issac, On Thursday, March 21, 2002, at 11:01 AM, Issac Goldstand wrote: Bas A.Schulte wrote: Hi, I've been meaning to write an article about how I used Apache/mod_perl to implement a mobile SMS application platform as it demonstrates use of Apache/mod_perl outside the Web realm, something I hadn't seen so far. Time constraints (as always) have prevented me from doing this properly, however, I'll try to give a short description of the system. The goal kinda is to see if others are using Apache/mod_perl in a similar way to share experiences, discuss issues that arise or discuss alternatives (I'd love someone to tell me I'm an idiot for handling all this lowlevel stuff myself and move to J2EE/java at once, if he can convince me I could have implemented this with the same budget and time frame). [snip] I actually implemented a similar system, although it's not SMS specific. Basically, I have a central system in Apache/mod_perl. The eventual design is for full I/O in many protocols, including HTTP, SMTP, FTP and a handful of other protocols. Well, this proves again that everything we software developers do has been done umteen times before ;) The system I described actually isn't tied to SMS as well; it has been designed with other devices in mind as well. The virtual SMSC component as I described it really should have a better name as it really is a protocal handler and serializing/deserializing component that is capable of handling other protocol and formats. In fact, I am considering enhancing it to be able to use it in a WAP or i-Mode context (if we can only find a way to get paid by the mobile subscriber using WAP which is easy with SMS). So far the output is pretty much ready, and I think I'm going to wait for Apache 2 before I do the inputs. I _could_ write mod_perl handlers to understand other protocols, but Apache 2 is being designed around this, as far as I understand, so I'm going to do that around Apache 2 (as soon as I get off my ass and learn the new API :-)) Yep; Apache 2 combined with mod_perl sure sounds interesting, now if it only had the stability that 1.x has ;) Regards, Bas.
