Re: Children dying
Hi Andrew, On Tue, 14 Aug 2001, Andrew Ho wrote: AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. [snip] AV[Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) [snip] A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Oooohh I do hope Doug doesn't read this... 73, Ged.
Re: Children dying
Andrew Ho wrote: A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. Alan Burlison
Re: Bug??
On Wed, 1 Aug 2001 13:12:44 +0200
Issac Goldstand [EMAIL PROTECTED] wrote:
based on the earlier discussion about detecting https :)
That will take care of standard http/https, but what if we have a custom
client connecting on weird ports _without_ putting the port in the URL?
Wouldn't it make sense to just take $ENV{SERVER_PORT} and join() _that_ to
make the unique filename? That'll take care of all the weird server
combinations possible including SSL, as only one listening socket can
physically bind to a port. It'll even transparently take care of weird
back-end server problems, as no matter how many servers seem to be on
http://frontend:80, the backends MUST be unique combinations of either
different hostnames or different ports...
Agreed here.
We've tried to set up development/production environment in the
same one server with config like following (simplified):
Listen 80# production
Listen 8080 # development
VirtualHost _default_:80
DocumentRoot /home/production
/VirtualHost
VirtualHost _default_:8080
DocumentRoot /home/development
/VirtualHost
Yeah, this will lead to mixups of the following two URLs, which we
don't want.
http://hostname/foo.cgi = /home/prodution/foo.cgi
http://hostname:8080/foo.cgi = /home/environment/foo.cgi
Patch follows, or do we have to make our own PortAwareRegistry
which inherits from Apache::RegistryNG ?
Thanks.
--- Registry.pm.origWed Aug 15 19:17:42 2001
+++ Registry.pm Wed Aug 15 19:18:19 2001
@@ -70,7 +70,7 @@
if ($Apache::Registry::NameWithVirtualHost $r-server-is_virtual) {
my $name = $r-get_server_name;
- $script_name = join , $name, $script_name if $name;
+ $script_name = join , $name, $r-get_server_port, $script_name if $name;
}
# Escape everything into valid perl identifiers
--
Tatsuhiko Miyagawa
mailto:[EMAIL PROTECTED]
Re: Children dying
Vasily S. Petrushin wrote: Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. Fine, point us please to documentation how to do it. http://cpan.valueclick.com/authors/Doug_MacEachern/mod_perl-1.26.tar.gz Alan Burlison
Socket Nightmare On NT.
Hello,
I am running mod_perl 1.2 on NT. I have been working with it for over 4
months, and am beginning to understand it. But for the past 4 months, I have
complained about a socket problem using IO socket. The only answer I got was
to turn the max child from 50 to 1. When I do that the IO::Socket module
works. But the site runs in a serial mode. Why use mod_perl then? It is
slower than running on a Macintosh. Anyway, I have to talk sockets for my
product to work.
The code below works under cgi-bin all day long. But as I said it blows up
(works once) under mod_perl.
Is there anything I can do to get the sockets to work under mod_perl? Or
should I go back to cgi-bin applications? I am at the end of my rope and
could use some sound information. Anyone out there lend a hand?
Thanks,
Scott Purcell
### simple socket code ###
#! perl
use CGI;
use CGI::Carp qw/fatalsToBrowser/;
my $q = new CGI;
print $q-header();
print $q-start_html(HELLO);
use IO::Socket;
$socket = IO::Socket::INET-new(PeerAddr = 'xxx.238.162.xxx',
PeerPort = '9000',
Proto= 'tcp') or
die(No connect iosocket. $@\n);
my $username = 'VBO';
my $password = 'VBO';
open (ISCRYPT, d:/Apache/mod_perl/vb/iscrypt \$password\ |)
or die(Cannot encrypt password for verification.);
my @password = ISCRYPT;
my $ePassword = $password[0];
close ISCRYPT;
$message = 999\tUSERLOGIN\t$username\t$ePassword\n;
my $msgsize = length($message);
print $socket \%BEGIN\t$msgsize\n$message\n;
print Message to $productName :\npre$message/pre\n\n;
GetMessage($socket);
sub GetMessage {
my $fh = shift;
my $err = 0;
my $header;
my $response;
while ($err 50) {
if (read($fh, $cc, 1, 0) == 1) {
$header .= $cc;
print $headerbr\n;
if ($header =~ /^\%BEGIN\s+(\d+)\r?\n/) {
# we've acquired one line's worth of response
my $rspsize = $1; # how much response to read
if (read($fh, $response, $rspsize, 0)) {
if ($response =~ /RESPONSE\s*OK/) {
print $response is responsebr\n;
return (1, $response);
} else {
return (-1, $response);
}
} else {
return 0;
}
} elsif ($header =~ /\%CONTINUE\s*\r?\n/ || $header =~
/\%END\s*\r?\n/) {
undef $header;
} elsif ($header =~ /\n$/) {
squawk(unknown mediabank response: $header);
return -1;
} else {
# keep going haven't hit a newline yet
}
$count++;
} else {
$err++;
}
}
return 0;
}
close ($socket);
undef ($socket);
Re: Socket Nightmare On NT.
I am running mod_perl 1.2 on NT. I have been working with it for over 4 months, and am beginning to understand it. But for the past 4 months, I have complained about a socket problem using IO socket. The only answer I got was to turn the max child from 50 to 1. When I do that the IO::Socket module works. But the site runs in a serial mode. Why use mod_perl then? Were you not aware that mod_perl always runs in serial mode on NT? This won't change until mod_perl 2. Most people say that it's still faster than CGI. If you can't live with that, you should use CGI or PerlEx or something similar. - Perrin
mod_auth_digest
Hello list it's now the fifth time i went looking to find sth on the web, but i didn't find anything. So perhaps it could be a little bit ot, sorry for that. I'm running a project using apache (mod_perl/mod_ssl/mySQL) on Linux for which i would change the authetication mechanism to mod_auth_digest, and i've the following questions: is the digest-authentication really necessary, when using mod_ssl, or would a basic-authetication be enough? For the moment i'm using a authentication over a form with session-cookies. Perhaps it is secure enough if i expand it (make it unpossible, to make a bot trying every cookie-value, and so on ...)? i have created a browser-front-end for the user-management. How is it possible to add/delete over Perl a new user/passwort to the digest-pw-file? I tryed it with open(), system(), ... but without any success. Thank you for every hint or URL ;oP Thomas Bach think karo... bkaro.net
Re: mod_auth_digest
Thomas, You have a couple of options. First is to use calls to htpasswd() system($apacheroot/bin/htpasswd, -b, /path/to/passwordfile, username, password) The second, which is more efficient than starting a htpasswd process, is to use perl's crypt(), create a password, and then append it to your password file. It's my understanding, that if your form starts in HTTPS, you can use basic auth and SSL will protect that along with the rest of your data. regards, -- Cody Sherr Engineer Covalent Technologies phone: (415)536-5292 email: [EMAIL PROTECTED] On Wed, 15 Aug 2001, Thomas Bach wrote: Hello list it's now the fifth time i went looking to find sth on the web, but i didn't find anything. So perhaps it could be a little bit ot, sorry for that. I'm running a project using apache (mod_perl/mod_ssl/mySQL) on Linux for which i would change the authetication mechanism to mod_auth_digest, and i've the following questions: is the digest-authentication really necessary, when using mod_ssl, or would a basic-authetication be enough? For the moment i'm using a authentication over a form with session-cookies. Perhaps it is secure enough if i expand it (make it unpossible, to make a bot trying every cookie-value, and so on ...)? i have created a browser-front-end for the user-management. How is it possible to add/delete over Perl a new user/passwort to the digest-pw-file? I tryed it with open(), system(), ... but without any success. Thank you for every hint or URL ;oP Thomas Bach think karo... bkaro.net
Re: [off] giving call-back-func parameters...
On Tue, Jul 31, 2001 at 07:52:13PM +0300, raptor wrote:
script.pl
===
use Helper;
my $callbackFunc = \Helper::func;
my $obj = new BigOne ( vals = $callbackFunc);
BigOne.pm
==
my $vals = shift;
if (ref $vals eq 'CODE') {
...
my $kv = $vals( id = $selected, dbh = $$self{dbh} );
..
};
See $kv gets the return value from Helper::func(), everything is OK until
I need to pass one more parameter to this function which I don't know in
BigOne.pm but know at script.pl
my $callbackFunc = sub { Helper::func(something=$here, also=$this, @_) }
maybe?
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Children dying
Hello, AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. AHIn general, you want to compile mod_perl statically on Solaris because AHit will core otherwise. ABUntrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Problems installing libapreq
I'm trying to install libapreq on a new box on which I've rolled an apache-mod_ssl-openssl combo. As you may know this puts httpd in /usr/local/apachessl. Using the standard perl Makefile.PL make fails at make: In file included from apache_request.c:58: apache_request.h:5: httpd.h: No such file or directory apache_request.h:6: http_config.h: No such file or directory apache_request.h:7: http_core.h: No such file or directory apache_request.h:8: http_log.h: No such file or directory apache_request.h:9: http_main.h: No such file or directory apache_request.h:10: http_protocol.h: No such file or directory apache_request.h:11: util_script.h: No such file or directory *** Error code 1 Stop in /usr/tmp/libapreq-0.33/c. *** Error code 1 Stop in /usr/tmp/libapreq-0.33. So I followed the hint in INSTALL and did ./configure --with-apache-includes=/usr/local/apachessl/include which works fine, but make generates an error: [...] creating Makefile creating c/Makefile creating c/libapreq_config.h c/libapreq_config.h is unchanged Making all in c Makefile, line 278: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Line 278 in c/Makefile seems to say: -include $(DEP_FILES) Thanks for any help, nick ~~~ Nick Tonkin
Re: Children dying
Andrew Ho wrote: ABUntrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Humbly, And no need for that either! :-) Regards, -- Alan Burlison -- $ head -1 /dev/bollocks drive proximal infomediaries, going forwards
Re: [ANNOUNCE] Perl Templating Guide, v 0.9
On Wed, Aug 01, 2001 at 12:15:53AM -0700, Perrin Harkins wrote:
http://perl.apache.org/features/tmpl-cmp.html
The article Choosing a Templating System is now available at the above
URL. This is the same material I presented at the O'Reilly conference,
but a bit less rushed. It gives an overview of currently available
templating tools and their basic features.
This version is bound to have some bugs and general foolishness in it,
so please send me an e-mail if you spot anything.
only flaw i saw was it's (it is) that shoulda been its (his,
hers, its):
HTML::Mason ...but has since become it's own unique animal...
s/'//
nice job! very informative. i feel better about using mason, and
still i wanna learn about axkit. :)
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: Children dying
AB Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Problems installing libapreq
Nick Tonkin [EMAIL PROTECTED] writes: I'm trying to install libapreq on a new box on which I've rolled an apache-mod_ssl-openssl combo. ^^ Have you already built modperl into your apache server? You should do that first, if you haven't done so already. If you have, the include directories (-I) that apreq uses to find the header files are listed with % perl -MApache::src -wle 'print Apache::src-new-inc' apache_request.h:5: httpd.h: No such file or directory apache_request.h:6: http_config.h: No such file or directory apache_request.h:7: http_core.h: No such file or directory apache_request.h:8: http_log.h: No such file or directory apache_request.h:9: http_main.h: No such file or directory apache_request.h:10: http_protocol.h: No such file or directory apache_request.h:11: util_script.h: No such file or directory *** Error code 1 Somehow they are not getting setup right. -- Joe Schaefer
Apache::Request
I get the following error on my $i = Apache::Request-instance($r); Can't locate object method instance via package Apache::Request Why is that? Is the method not available? Are the docs outdated? Any comments welcomed... :) I am running mod_perl/1.22... -r
Re: Apache::Request
At 1:11 PM -0700 8/15/01, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); I think you want my $i = Apache::Request-new($r); I've never used or seen instance before, but I've only been doing mod_perl for about 20 months. Rob -- A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX.
Re: Apache::Request
I am reading the online docs... -r Robin Berjon wrote: On Wednesday 15 August 2001 22:11, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); Can't locate object method instance via package Apache::Request Why is that? Is the method not available? Are the docs outdated? Any comments welcomed... :) I am running mod_perl/1.22... Are you readiong the docs that come with 1.22 or some docs online (eg from search.cpan.org) ? $r-instance works fine here, but iirc it was introduced rather recently (though I could be wrong there). -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Machines take me by surprise with great frequency. -- Alan Turing
RE: Apache::Request
-Original Message- From: Robin Berjon To: [EMAIL PROTECTED] Sent: 8/15/01 4:39 PM Subject: Re: Apache::Request On Wednesday 15 August 2001 22:11, Rasoul Hajikhani wrote: I get the following error on my $i = Apache::Request-instance($r); Can't locate object method instance via package Apache::Request Why is that? Is the method not available? Are the docs outdated? Any comments welcomed... :) I am running mod_perl/1.22... Are you readiong the docs that come with 1.22 or some docs online (eg from search.cpan.org) ? $r-instance works fine here, but iirc it was introduced rather recently (though I could be wrong there). instance showed up officially in libapreq 0.31_3 HTH --Geoff
[ADMIN] can we have a reply-to header?
Am I the only one that always have to go *doh* after I replied to a message here? -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer
Re: [ADMIN] can we have a reply-to header?
http://www.unicom.com/pw/reply-to-harmful.html John [EMAIL PROTECTED]
Re: [ADMIN] can we have a reply-to header?
On Wed, Aug 15, 2001 at 04:30:05PM -0500, Dave Rolsky wrote: On Wed, 15 Aug 2001, John D Groenveld wrote: http://www.unicom.com/pw/reply-to-harmful.html NOOO!!! Make it stop. I swear to god that if this argument starts on this list (and I think its already been had) I will go to your homes and stuff chili peppers up your nose. If not for it's violently offtopic nature, I would respectfully offer: http://www.devbrain.com/reply-to-non-harmful.html Dave -- - Dave Baker : [EMAIL PROTECTED] : [EMAIL PROTECTED] : http://dsb3.com/ - GnuPG: 1024D/D7BCA55D / 09CD D148 57DE 711E 6708 B772 0DD4 51D5 D7BC A55D
RE: Children dying
On Wed, 15 Aug 2001, Rob Bloodgood wrote: AB Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Do virtual hosts need their own servers?
On Wed, 15 Aug 2001, Philip Mak wrote: When I have multiple virtual hosts running Apache::ASP (mod_perl), do they need to run their own instance of Apache? I've read through http://perl.apache.org/guide/multiuser.html and this is what I've gathered: 1. A hacker with access to a virtual host on a mod_perl Apache can steal the Apache::DBI database handles of the other virtual hosts on that Apache. suexec/cgiwrap won't work in mod_perl. this is true for anything that can be snooped. Apache::DBI is just an example. You don't even have to snoop, you have to run under the same uid/gid, which means you can just read the source code. 2. Scripts from one virtual host can call a script with the same path from the other virtual host. Setting $Apache::Registry::NameWithVirtualHost to 1 in startup.pl gets around this problem. So, it sounds like if I set $Apache::Registry::NameWithVirtualHost to 1, and the webmasters of the different virtual hosts trust each other, then it is safe to put them on the same Apache? yes. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: httpd PerlRequire error
On Wed, 15 Aug 2001, winnecon wrote: -- To anyone that can help! I have installed mod_perl 1.26 according to the instructions in the INSTALL file. You've messed up something. You shouldn't mungle with apache_xxx/src/Configuration see http://perl.apache.org/guide/install.html I checked apache_xxx/src/Configuration, to see if the make had added the following as it should have: AddModule modules/perl/libperl.a It was not present, so I added it myself. I also commented out ScriptAlias and added the following to my httpd.conf file: *** # ScriptAlias /cgi-bin/ /Library/WebServer/cgi-bin/ PerlRequire /Library/WebServer/startup.pl Alias /cgi-bin /Library/WebServer/cgi-bin Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Location When trying apachectl start I receive the following error: *** Syntax error on line 621 of /etc/httpd/httpd.conf: Invalid command 'PerlRequire', perhaps mis-spelled or defined by a module not included in the server configuration /usr/sbin/apachectl start: httpd could not be started Thanks, Brett _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
::Register bug?
I get the following: ... nothing special and no errors.. ...14:36:42 2001] file .\main\buff.c, line 213, assertion !rv failed ...14:37:15 2001] [error] Undefined subroutine Apache::Registry::handler called. ] [error] Undefined subroutine Apache::Registry::handler called. ] [error] Undefined subroutine Apache::Registry::handler called. ] [error] Undefined subroutine Apache::Registry::handler called. ] [error] Undefined subroutine Apache::Registry::handler called. etc... ...everything ok after restart ...and everything ok if I use ::PerlRun... In addition, I have now ideas about it... 8-( I use Apache::Register, mod_perl 1.25, W2kAS 8-( Active Perl... Frodo
cvs commit: modperl-site/embperl Changes.pod.1.html
richter 01/08/15 12:21:34 Modified:embperl Changes.pod.1.html Log: Embperl Webpages - Changes Revision ChangesPath 1.222 +1 -1 modperl-site/embperl/Changes.pod.1.html Index: Changes.pod.1.html === RCS file: /home/cvs/modperl-site/embperl/Changes.pod.1.html,v retrieving revision 1.221 retrieving revision 1.222 diff -u -r1.221 -r1.222 --- Changes.pod.1.html2001/08/15 03:29:08 1.221 +++ Changes.pod.1.html2001/08/15 19:21:34 1.222 @@ -21,7 +21,7 @@ [a href= HOME/a]nbsp;nbsp; [a href=Changes.pod.cont.htmlCONTENT/a]nbsp;nbsp; [a href=Changes.pod.cont.htmlPREV (Revision History - Content)/a]nbsp;nbsp; [a href=Changes.pod.2.htmlNEXT (1.3.3 (RELEASE) 6. Juni 2001)/a]nbsp;nbsp; brhr P -Last Update: Wed Aug 15 05:32:21 2001 (MET) +Last Update: Wed Aug 15 21:24:56 2001 (MET) P NOTE: This version is only available via A HREF=CVS.pod.1.html#INTRO CVS/A
