Re: is morning bug still relevant?
On Thu, Dec 14, 2000 at 07:54:06PM +0100, Stas Bekman wrote: On Thu, 14 Dec 2000, Tom Brown wrote: On Thu, 14 Dec 2000, Stas Bekman wrote: On Thu, 14 Dec 2000, Tim Bunce wrote: On Thu, 14 Dec 2000, Stas Bekman wrote: and the script was dying on that error. The infamous Cping() method Why is/was ping() infamous? Something becomes infamous when it solves a big problem :) no, that would be famous ... infamous is bad in a big way... e.g. well known pirates are infamous ... Apologies Tim, somehow I always thought that 'infamous' is better than just 'famous'... See http://www.thesaurus.com/cgi-bin/search?config=rogetwords=infamous Vice Excerpt: "..., shameful, scandalous, infamous, villanous, of a deep dye, heinous..." Improbity Excerpt: "..., treacherous, perjured. infamous, arrant, foul, base, vile,..." Disrepute Excerpt: "..., dedecorous; scandalous, infamous, too bad, unmentionable; ribald..." :-) I meant the 'famous'... sorry about that. I've corrected it in the guide. Thanks Stas. Tim.
Re: Advocacy idea ...
Let's create a "Mod_perl League" - it gives us at least one line on the first page of LWN.net
Apache::LogSTDERR
I read in the guide about Apache::LogSTDERR, but I don't seem to be able to find it on CPAN. Can anyone tell where I can find this? Kees
Re: fork inherits socket connection
On Fri, 15 Dec 2000, Kees Vonk 7249 24549 wrote:
Stas writes:
How about
close STDOUT;
close STDIN;
close STDERR;
in your child code?
check this out:
http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subprocess
it's explained there.
I have tried closing STDOUT, STDIN and STDERR, but that
doesn't make any difference.
What I do at the moment is:
1. Start the long running process (runs indefinitly for the
purpose of this test), which closes STDOUT, STDIN and
STDERR and then calls setsid().
Why do you call setsid()?
Are you spawning a process with shell or fork?
* If you spawn the process with fork remove setsid() and it'll work.
* If you spawn the process with ``/system it works with what you've
described.
I've tested both on my machine.
I think the following might be the solution, we have done
that in a (not internet related) C program here to solve
almost the same problem.
Vivek writes:
KV72 Has anyone got an idea how to get around this? Can I get to
KV72 the inherited socket connection and close it when I have
KV72 detached from the calling process?
After you fork, why not close all open file descriptors you are not
using?
What Vivek meant I suppose is the same: STDOUT and STDIN.
I have had a look throught the camel book. How do I close a
file descriptor (or find out if it is open), the perl close
function only accepts file handles.
% perldoc -q descriptor
Found in /usr/lib/perl5/5.6.0/pod/perlfaq5.pod
How do I close a file descriptor by number?
This should rarely be necessary, as the Perl close()
function is to be used for things that Perl opened itself,
even if it was a dup of a numeric descriptor, as with
MHCONTEXT above. But if you really have to, you may be
able to do this:
require 'sys/syscall.ph';
$rc = syscall(SYS_close, $fd + 0); # must force numeric
die "can't sysclose $fd: $!" unless $rc == -1;
Or just use the fdopen(3S) feature of open():
{
local *F;
open F, "=$fd" or die "Cannot reopen fd=$fd: $!";
close F;
}
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: HTML::Embperl::Execute modifying 'output' only once
I wrote some code for a forum, that displays user entered text,
turning all URLs found into real links. Here it is:
[- @t = split(/\x0d\x0a/, $message); $r = '';
{
local $/ = "\x0d\x0a"; # for chomp below
for($i=0;$i lt; scalar @t;$i++) {
$out = ''; $t = $t[$i];
HTML::Embperl::Execute({'escmode' = 1,
'input' = \$t,
'output' = \$out,
'mtime' = undef});
chomp $out;
$out =~ s@((?:ftp|http|news)://[^ ]*[^ .,:;!?lt;gt;()])@lt;A
HREF="$1"gt;$1lt;/Agt;@gi;
$r .= "lt;BRgt;\n" if $r;
$r .= $out;
}
} -]
[+ local $escmode=0; $r +]
It may not be optimal, but it works well. I tried to put that code in
a Perl module, since it looks quite reusable:
package XXX;
use strict;
use lib qw(..);
use Exporter ();
use HTML::Embperl ();
use vars qw(@ISA @EXPORT_OK);
@ISA = qw(Exporter);
@EXPORT_OK = qw(UserText);
sub UserText($) {
my($Text) = @_;
{
local $/ = "\x0d\x0a"; # for chomp below
return join("BR\n",
map { my $out;
HTML::Embperl::Execute({'escmode' = 1,
'input' = \$_,
'output' = \$out,
'mtime' = undef});
chomp $out;
$out =~ s@((?:ftp|http|news)://[^ ]*[^ .,:;!?()])@A
HREF="$1"$1/A@gi;
$out }
split(/\x0d\x0a/, $Text)
);
}
}
1;
Why do you Execute every line spepartely? Why not just process the while
file at once. That will be much faster...
It looks like HTML::Embperl::Execute() only modifies $out during the
first loop.
You should give a name to your code for Embperl cache management. Try to add
the inputfile parameter and set it a any value
HTML::Embperl::Execute({'escmode' = 1,
'input' = \$_,
'output' = \$out,
'inputfile' = 'mycode'});
Also you can leave out the mtime = undef (but it doesn't hurt)
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: Apache::LogSTDERR
I read in the guide about Apache::LogSTDERR, but I don't seem to be able to find it on CPAN. Can anyone tell where I can find this? It was mentioned here: http://forum.swarthmore.edu/epigone/modperl/vixquimwhen I suppose I've documented it too early, it was never released. Doug? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: greetings and questions
On Thu, 14 Dec 2000, Darren Duncan wrote: Thanks to everyone who answered my questions in some form or other. As it is, I *had* been reading whatever manuals I found, but those were the documentation that came with the mod_perl distribution on CPAN. I was not aware of the existence of "http://perl.apache.org/guide/" and if I had been then I would have looked there. I had seen a number of documents on the perl.apache.org server, but not that one. Come'n, are you sure you have ever looked at perl.apache.org? http://perl.apache.org/#docs Books and Documentation: Writing Apache Modules with Perl and C book by Lincoln Stein and Doug MacEachern. == Start learning mod_perl with the mod_perl Guide by Stas Bekman. Quick guide for moving from CGI to mod_perl. mod_perl_traps, common traps and solutions for mod_perl users. The mod_perl plugin reference guide by Doug MacEachern. mod_perl FAQ by Frank Cringle. mod_perl performance tuning guide by Vivek Khera. mod_perl reference card by Andrew Ford. Popular Perl Complaints and Myths by Adam Pisoni. Perl FAQTS -- a Perl knowledge base online. mod_perl.faqts Perlfaq Prime online PerlFAQ:mod_perl Hmm, should I add font size=+7/font around it? Do others find it hidden? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Email (mod_perl) Apache module?
Jeremy Howard wrote: IMHO, the best open source WebMail servers are PHP based true, I am using and patching TWIG quite a lot, and that made me see how messy PHP gets when dealing with libraries and things. It's not nice to see a large app written in PHP... at least not this one. I have this dangling idea of building a TWIG lookalike (in Perl), with a 'plug-in'/'module' structure, so I may write the email client, and others fill with their desired modules. Anyway, it's a seriuos undertaking, but it's in my plans to rip as much code and design choices from stable OS webmails as possible. It's just a way to soak up all my holidays in perl code ... martin
Re: fork inherits socket connection
Stas,
I had the following in my code:
my($nOrgPID) = fork;
exit if $nOrgPID;
die "Could not fork: $!" unless defined $nOrgPID;
close STDIN;
close STDOUT;
close STDERR;
setsid() or die "Could not start new session: $!";
but that didn't work, however when I changed it to this:
my($nOrgPID) = fork;
exit if $nOrgPID;
die "Could not fork: $!" unless defined $nOrgPID;
require 'sys/syscall.ph';
for (my $i=0; $i=255; $i++) {
syscall(SYS_close, $i + 0); # must force numeric
}
setsid() or die "Could not start new session: $!";
the socket got released and I could restart the server. I
know it is a little crud, but it seems to work.
Kees
Re: greetings and questions
Hi Stas, On Fri, 15 Dec 2000, Stas Bekman wrote: Come'n, are you sure you have ever looked at perl.apache.org? [snip] Hmm, should I add font size=+7/font around it? How about blink :) /blink 73, Ged.
Re: fork inherits socket connection
On Fri, 15 Dec 2000, Kees Vonk 7249 24549 wrote:
Stas,
I had the following in my code:
my($nOrgPID) = fork;
exit if $nOrgPID;
die "Could not fork: $!" unless defined $nOrgPID;
close STDIN;
close STDOUT;
close STDERR;
setsid() or die "Could not start new session: $!";
but that didn't work, however when I changed it to this:
my($nOrgPID) = fork;
exit if $nOrgPID;
die "Could not fork: $!" unless defined $nOrgPID;
require 'sys/syscall.ph';
for (my $i=0; $i=255; $i++) {
syscall(SYS_close, $i + 0); # must force numeric
}
setsid() or die "Could not start new session: $!";
the socket got released and I could restart the server. I
know it is a little crud, but it seems to work.
But you don't need to call setsid() when you fork. Why looking for
complicated workaround when you can do it properly without any workaround.
Have you ever seen an example of fork that uses setsid?
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: greetings and questions
Stas Bekman wrote: Come'n, are you sure you have ever looked at perl.apache.org? http://perl.apache.org/#docs Books and Documentation: Writing Apache Modules with Perl and C book by Lincoln Stein and Doug MacEachern. == Start learning mod_perl with the mod_perl Guide by Stas Bekman. ... I remember when I started with mod_perl last year, I didn't notice the guide until I saw it mentioned on the list. perl.apache.org is a long page, and it's not obvious what order to read the various links in... The FAQ linked to on this page includes 'What documentation should I read?' and doesn't include the Guide in the answer... The link to the guide is the 32nd of 97 links on this page... It is one of 11 documentation links... So I guess what I'm trying to say is that it's not that obvious ;-) Maybe the mod_perl site could start with: New to mod_perl? First, a href="http://perl.apache.org/dist/"download/a it and then a href="http://perl.apache.org/guide/install.html"learn/a to install it. Now read a href="http://perl.apache.org/guide/""The Guide"/a and become and mod_perl guru! ...or something like that.
Re: fork inherits socket connection
Stas Bekman wrote: But you don't need to call setsid() when you fork. Why looking for complicated workaround when you can do it properly without any workaround. Have you ever seen an example of fork that uses setsid? But your Guide says: A much better approach would be to spawn a sub-process, hand it the information it needs to do the task, and have it detach (close STDIN, STDOUT and STDERR + execute setsid()).
Re: greetings and questions
On Sat, 16 Dec 2000, Jeremy Howard wrote: Stas Bekman wrote: Come'n, are you sure you have ever looked at perl.apache.org? http://perl.apache.org/#docs Books and Documentation: Writing Apache Modules with Perl and C book by Lincoln Stein and Doug MacEachern. == Start learning mod_perl with the mod_perl Guide by Stas Bekman. ... I remember when I started with mod_perl last year, I didn't notice the guide until I saw it mentioned on the list. perl.apache.org is a long page, and it's not obvious what order to read the various links in... The FAQ linked to on this page includes 'What documentation should I read?' and doesn't include the Guide in the answer... The link to the guide is the 32nd of 97 links on this page... It is one of 11 documentation links... So I guess what I'm trying to say is that it's not that obvious ;-) Let me ask you this question. When you are looking for something in a fat book, do you just read all the pages and then say, ouch this item I was looking for was placed on page 789. No you don't -- you look at the Table of Contents or the index pages. So the perl.apache.org/index.html has its TOC: Download Take23: News and Resources for the mod_perl world Perl Apache Modules Help with Perl Apache Modules Wanted === Books and Documentation mod_perl in Magazines Mailing Lists and Contact Info and then when you click on the obvious link, you get to another list, where the guide is listed after the eagle book. Maybe the mod_perl site could start with: New to mod_perl? First, a href="http://perl.apache.org/dist/"download/a it and then a href="http://perl.apache.org/guide/install.html"learn/a to install it. Now read a href="http://perl.apache.org/guide/""The Guide"/a and become and mod_perl guru! ...or something like that. It used to be like that, but then people didn't see other documents available. It just shows that people don't really look at the available resources. And no, don't tell me that I know where to find things because I already know where they are. I've spent time thinking how this should be done so it'd be as obvious as possible where things are to be found. Moreover when you subscribe to the mailing list, you receive a special email explaining what are the available resources are and where to find them. Please don't take it personally, it's just that quite many people came here asking questions that were long time ago answered and documented. It just shows people's ignorance, lack of respect and wish to get things the easy way. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: fork inherits socket connection
On Sat, 16 Dec 2000, Jeremy Howard wrote: Stas Bekman wrote: But you don't need to call setsid() when you fork. Why looking for complicated workaround when you can do it properly without any workaround. Have you ever seen an example of fork that uses setsid? But your Guide says: A much better approach would be to spawn a sub-process, hand it the information it needs to do the task, and have it detach (close STDIN, STDOUT and STDERR + execute setsid()). True, it's a mish-mash of two techniques. I'm working at this very moment to make things clear. My follow-up was based on the fact that I told Kees in the original reply that setsid shoudn't be used with fork. Will be fixed in the next release, sorry about that. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: fork inherits socket connection
On Fri, 15 Dec 2000, Stas Bekman wrote: On Sat, 16 Dec 2000, Jeremy Howard wrote: Stas Bekman wrote: But you don't need to call setsid() when you fork. Why looking for complicated workaround when you can do it properly without any workaround. Have you ever seen an example of fork that uses setsid? But your Guide says: A much better approach would be to spawn a sub-process, hand it the information it needs to do the task, and have it detach (close STDIN, STDOUT and STDERR + execute setsid()). In fact this is correct. You've taken this snippet out of the context. It was in the section talking about spawning a process without fork. So it's absolutely correct. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: fork inherits socket connection
Stas Bekman wrote: 1. Start the long running process (runs indefinitly for the purpose of this test), which closes STDOUT, STDIN and STDERR and then calls setsid(). Why do you call setsid()? He's probably thinking of traditional the traditional way in which you background a daemon by forking, setsid'ing, then forking again to prevent the process from ever reacquiring a controlling terminal (your point, that this isn't needed here, is well taken). -- Richard Goerwitz[EMAIL PROTECTED]
RE: [OT]: Open Source ... was Re: Advocacy idea ...
OK, you probably don't want it to be another mailing list
then. But a web
bbs that allows you to post replies to code.
kind of ... I would like to see someplace to post _working_ code (complete
or snippets) with an explanation of what you are trying to accomplish, and
with any issues/special circumstances that you had to take into account. You
would post to one of several categories (Database, XML, OOP, etc.). Maybe
have the functionality for reviewers to alter the code and have the site
produce a diff automagically from the changes. You could maybe see the code
with changes that were made by a select number of people (maybe people who
have highly moderated suggestions/code?).
Possibly have in each section for links to resources that can be moderated
for usefulness in each of these categories (this may already exist -- if it
does, please let me know where! :))
Yet such code reviews are
extremely time
consuming so I could see people donating time once a month to
do it but not
much more realistically (based on the fickle *real* workload
we all have).
This is very true, and I also think there would be the whole "critical mass"
issue (people won't use it until it's big / it won't be big until people use
it). I think there would certainly need to be clear guidelines as well (TBD)
Anyway, however you want to go about it, good luck.
I think that I will try to come up with a proposal over the weekend (or at
least by the end of the week - Saturday is my b-day :)). Perhaps at that
time a consensus of whether this is worthwhile could be achieved?
Usually people go to the archive when they have a problem not
pre-emptively. And I think that although the code someone has
posted for
comments on the main mailing list may no longer be there, the
comments
about that code remain and usually with snippets of the code
in question.
{snip}
I don't think this list lacks for discussion on code that
people might post
(although lately its this advocacy stuff). So although it is
better to have
a separate code repository, I am not sure that people would
flock to it
enough to make it better than posting the code to the list
(as a URL) and
discussing it here.
This could even go beyond coding (I am brainstorming here ... unencumbered
by the thought process). Perhaps create an area for project plans, hardware
setup, etc. (of course relating to mod_perl). I find that my biggest issue
is usually not coding problems per se, but "what is the best way to go about
doing this?" or "did I miss something in the code that I will regret
later?". These are my biggest itches. As I mentioned previously, I have no
one to bounce things off of. I am in Ohio which is the land of MS/ASP/VB. I
have been able to convince my employers that mod_Perl is good technology
(mostly based upon speed). I don't want to prove the decision wrong by some
silly mistake (I've been OK so far).
Most of the resources that I can find on the net have to do with "I can't
get this to work" and not "Is this good?". I realize that most of this
knowledge comes with experience, but this could be a place to bounce ideas
around and perhaps jumpstart that experience. Your earlier comment about
this being what open source is all about may be very accurate here. Am I
describing SourceForge? CPAN? ML's? something else?
Also please let me know if this is trailing too far off topic. Is there a
more appropriate place to discuss this?
Best Regards,
Dave Homsher
Webmaster,
MACtac IT
Re: greetings and questions
Hi All, On Fri, 15 Dec 2000, Stas Bekman wrote: Please don't take it personally, it's just that quite many people came here asking questions that were long time ago answered and documented. It just shows people's ignorance, lack of respect and wish to get things the easy way. C'mon, Stas, lighten up! Maybe the guy's just frantically busy! (Although that first post _was_ a bit long:) 73, Ged. (Too frantically busy to read some of these threads:)
Re: fork inherits socket connection
On Fri, 15 Dec 2000, Kees Vonk 7249 24549 wrote: But you don't need to call setsid() when you fork. Why looking for complicated workaround when you can do it properly without any workaround. Have you ever seen an example of fork that uses setsid? Ok, here is my confusion: I call the the long running process from the modperl script with a system() call that was why I was using the setsid() (in the longrunning process). I have now changed the code my long running process to: my($nOrgPID) = fork; exit if $nOrgPID; die "Could not fork: $!" unless defined $nOrgPID; close STDIN; close STDOUT; close STDERR; and that does not work, I have also tried putting it in the modperl script instead but that doesn't work either. Kees, if you are doing system() call just put setsid back, and add this: tie *OUT, 'Apache'; close OUT; Apache keeps the socket tied. Tell me whether this works for you. I'll document these things shortly and post for your review. What am I doing wrong and why would the setsid() be a showstopper, especially as it is called after the close statements (it doesn't reopen the filehandles does it). I could understand that it would possibly be unnecessary, but how could it stop this code from working? Another (more detailed) run through. 1. modperl script starts long running process (lrp) with a system() call. 2. lrp runs the code above (fork + close (tried this with and without setsid)). 3. stop apache 4. start apache - fails (port in use) 5. netstat -na reveals port in LISTEN state. 6. kill lrp 7. netstat -na reveals port no longer in use. 8. start apache - now starts fine I think I am doing something wrong somewhere, but I am not sure where. Is it right that I have to do the system call and the fork? Kees _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: fork inherits socket connection
But you don't need to call setsid() when you fork. Why looking for
complicated workaround when you can do it properly without any workaround.
Have you ever seen an example of fork that uses setsid?
Yes, the following is taken straight out from the perlipc documentation:
-
Complete Dissociation of Child from Parent
In some cases (starting server processes, for instance) you'll want to
completely dissociate the child process from the
parent. This is often called daemonization. A well behaved daemon will also
chdir() to the root directory (so it
doesn't prevent unmounting the filesystem containing the directory from
which it was launched) and redirect its standard
file descriptors from and to /dev/null (so that random output doesn't wind
up on the user's terminal).
use POSIX 'setsid';
sub daemonize {
chdir '/' or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '/dev/null'
or die "Can't write to /dev/null: $!";
defined(my $pid = fork) or die "Can't fork: $!";
exit if $pid;
setsid or die "Can't start a new session: $!";
open STDERR, 'STDOUT' or die "Can't dup stdout: $!";
}
The fork() has to come before the setsid() to ensure that you aren't a
process group leader (the setsid() will fail if you are). If your system
doesn't have the setsid() function, open /dev/tty and use the TIOCNOTTY
ioctl() on it instead. See tty(4) for details.
-
Am I missing something?
You don't miss anything, the above code is an example of daemonization.
You don't really need to call setsid() for a *forked* process that was
started to execute something and quit.
It's different if you call system() to spawn the process. But since it's a
child of the parent httpd it's not a leader anyway so you don't need the
extra fork I suppose. Am I correct?
In fact it's good that you've posted this doc snippet, I'll use it as it's
more complete and cleaner. Thanks.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: fork inherits socket connection
At 04:02 PM 12/15/00 +0100, Stas Bekman wrote: Am I missing something? You don't miss anything, the above code is an example of daemonization. You don't really need to call setsid() for a *forked* process that was started to execute something and quit. It's different if you call system() to spawn the process. But since it's a child of the parent httpd it's not a leader anyway so you don't need the extra fork I suppose. Am I correct? In fact it's good that you've posted this doc snippet, I'll use it as it's more complete and cleaner. Thanks. Thank goodness! I like this thread -- It's been hard keeping up with all the posts just to see if PHP or Java is better than mod_perl ;) Stas, will you please post your additions/notification about this when you are done? I do hope you go into a bit of detail on this, as I've posted questions about setsid a number of times and locations and I'm still unclear about when or when not to use it, why to use it, and how that might relate to mod_perl and why it makes a difference between system() vs. fork. I've just blindly followed perlipc's recommendations. BTW -- this isn't related to the infrequently reported problem of an Apache child that won't die even with kill -9, is it? Eagerly awaiting, Bill Moseley mailto:[EMAIL PROTECTED]
offer of resources for Take23
i don't think my responses to yesterday's discussion made it to the list, so here's a summary: Smith Renaud or Perl Mongers can donate rack space, infrastructure, and other support to a new, canonical mod_perl site. we can either provide a box (which we then control, sysadmin and policy-wise), or put a donated box in our rack (which someone else could control). we can also supply a squid box in front of either of those. we have the things you would expect (backup power, backups, etc) and if someone needs something else (console server, reboot server, etc) that is not a huge problem. Matt mentioned that take23 is now behind a 64k leased line, so i'm sure that the dual T3s leading out of our facility (which are shared with all of our other things) might look attractive. ;) if this offer is attractive i can even try to get someone to donate a box if the idea of a sponsor link or some such is okay. and, if no-one likes any of that, we could at least mirror it. ;) -- brian d foy [EMAIL PROTECTED] Director of Technology, Smith Renaud, Inc. 875 Avenue of the Americas, 2510, New York, NY 10001 V: (212) 239-8985
Re: greetings and questions
On Fri, Dec 15, 2000 at 01:21:04PM +0100, Stas Bekman wrote: Hmm, should I add font size=+7/font around it? Do others find it hidden? In fact I do. Also, are the other documents being maintained? Do you really want users to go read the other ones? Another thing I observed: The Guide is becoming almost TOO big and unwieldly. New people can get overwhelmed. How about arranging the Table of Contents into Chapters and moving topics around a little as follows: 1. Introduction - Incentive Credits - Overview - Downloading s/w and documentation 2. mod_perl Administration - mod_perl Installation - mod_perl Configuration - Controlling and Monitoring the Server - Choosing the Right Strategy - Real World Scenarios - Choosing an o/s and h/w 3. mod_perl Programming - Perl reference - CGI to mod_perl Porting - Frequently mod_perl Problems Workarounds - Troubleshooting Index - Code Snippets - Debugging - Working with Apache::* modules 4. Conclusion - Getting Help and Further Learning - mod_perl Advocacy If you want I can give you patches against CVS to re-arrange the TOC as above. Ajit
mod_perl tutorials
I've been following this thread and just wanted to offer up my services at an html coder for a mod_perl website. Joe Grastara Project Assistant Digital Media Center The Skirball Institute Of Biomolecular Medicine New York University Medical Center 540 First Ave., New York City, NY 10016 USA [EMAIL PROTECTED] http://www.med.nyu.edu/graphics
Re: fork inherits socket connection
"KV72" == Kees Vonk 7249 24549 [EMAIL PROTECTED] writes:
KV72 require 'sys/syscall.ph';
KV72 for (my $i=0; $i=255; $i++) {
KV72 syscall(SYS_close, $i + 0); # must force numeric
KV72 }
KV72 the socket got released and I could restart the server. I
KV72 know it is a little crud, but it seems to work.
No, it is not crud. If you want your forked process to act like a
daemon, you must make sure to perform the necessary actions. That
includes closing all open file descriptors you are not using.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: fork inherits socket connection
"SB" == Stas Bekman [EMAIL PROTECTED] writes: SB In fact this is correct. You've taken this snippet out of the context. It SB was in the section talking about spawning a process without fork. So it's SB absolutely correct. How exactly does one spawn a process without fork() in unix? (It is a rhetorical question, in case you didn't figure that out.) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Perl 5.6.1 - When? [Was Re: Segmentation fault]
On Fri, Dec 15, 2000 at 09:43:05AM -0500, Vivek Khera wrote: Is there some place that has collected the "recommended" patches for 5.6.0? There don't seem to be any patches for it on CPAN... You'd think that 5.6.1 would come out by now to fix up the problems people have been having with 5.6 especially in mod_perl... 5.6.1-trial1 expected by this weekend. That should include all the recommended list of patches for 5.6.0. See: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00586.html Ajit
Re: fork inherits socket connection
On Fri, 15 Dec 2000, Vivek Khera wrote: "SB" == Stas Bekman [EMAIL PROTECTED] writes: SB In fact this is correct. You've taken this snippet out of the context. It SB was in the section talking about spawning a process without fork. So it's SB absolutely correct. How exactly does one spawn a process without fork() in unix? (It is a rhetorical question, in case you didn't figure that out.) Hold on folks, gimme a little time and I'll come up with a clear explanation of all the mess that I admittedly created. I'll post the fresh corrected docs and then you will tell me if some things are still vague... Ok? Thanks for your patience. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: greetings and questions
On Fri, Dec 15, 2000 at 01:21:04PM +0100, Stas Bekman wrote: Hmm, should I add font size=+7/font around it? Do others find it hidden? In fact I do. Also, are the other documents being maintained? Do you really want users to go read the other ones? I'm cannot tell users not to read other documents. You should ask their respective owners whether they find their documents still unique and whether they should stay online, since the guide has swallowed long time ago most of the material in these, but not all of it. Another thing I observed: The Guide is becoming almost TOO big and unwieldly. I can tell you that it's stable now. Most of the work done within the existing material and no new material is added (well very little). I still have a bunch of outstanding emails with very good info that should enter the guide, but I didn't get to them yet. New people can get overwhelmed. New people are always overhelmed. Whether you have a little or no documentation or too much of it. How about arranging the Table of Contents into Chapters and moving topics around a little as follows: 1. Introduction - Incentive Credits - Overview - Downloading s/w and documentation 2. mod_perl Administration - mod_perl Installation - mod_perl Configuration - Controlling and Monitoring the Server - Choosing the Right Strategy - Real World Scenarios - Choosing an o/s and h/w 3. mod_perl Programming - Perl reference - CGI to mod_perl Porting - Frequently mod_perl Problems Workarounds - Troubleshooting Index - Code Snippets - Debugging - Working with Apache::* modules 4. Conclusion - Getting Help and Further Learning - mod_perl Advocacy If you want I can give you patches against CVS to re-arrange the TOC as above. This is planned long time ago, but I won't do anything before the book will be completed. It's long time overdue. Once the book will be out, you won't need the guide anymore. Believe me that the book will have a proper TOC and organization. Currently I cannot use your TOC since: 1) it's automatically created 2) your toc grouping doesn't reflect the order the chapters should be read in, the guide is mainly a "guide" (designed for sequantial reading) and when used as a reference the search is to be used. The chapters aren't linked in the random order but in the predefined one. 3) your toc has omitted a few chapters. I'll highlight the guide though as suggested by a few users in the private emails. Also if you go to take23.org and you should, the guide is outstanding there. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: greetings and questions
On Fri, Dec 15, 2000 at 05:23:05PM +0100, Stas Bekman wrote: Currently I cannot use your TOC since: 1) it's automatically created I was proposing patching the CVS so that it Automatically generates the new format 2) your toc grouping doesn't reflect the order the chapters should be read in, the guide is mainly a "guide" (designed for sequantial reading) and when used as a reference the search is to be used. The chapters aren't linked in the random order but in the predefined one. Agreed. Its almost like we need a Mini-Me (TM) Guide to The Guide :) 3) your toc has omitted a few chapters. Oh, I was just giving an example.. But if you are working on the book, thats just fine! Just trying to help here.. not criticize :)
ApacheCon 2001 Proposals: Less than a week left! (fwd)
don't miss the deadline!!! submit those mod_perl and related talks... -- Forwarded message -- Date: Fri, 15 Dec 2000 11:31:40 -0500 From: Rodent of Unusual Size [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Apache Announcements [EMAIL PROTECTED], ApacheCon Announcements [EMAIL PROTECTED], Apache Developers [EMAIL PROTECTED], ASF members [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Newsgroups: comp.infosystems.www.servers.unix, comp.infosystems.www.servers.ms-windows, comp.infosystems.www.servers.misc, de.comm.infosystems.www.servers Subject: ApacheCon 2001 Proposals: Less than a week left! Please pardon the spam.. There is less than a week left for presentation proposals to be submitted for the ApacheCon 2001 conference, which will be held in Santa Clara, California, USA, on 4-6 April 2001. Presenters whose proposals are accepted have registration fees waived, reasonable travel expenses paid, and part or all of their lodging expenses paid as well. To submit a proposal, go to http://ApacheCon.Com/2001/US/html/cfp.html Thanks for reading! There may be one more message about this deadline. -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/
Re: Mod_perl tutorials
Hi all; This is my first post in this mailing list. I am very interested in helping out getting the modperl tutorials out. I have experience with Photoshop, Illustrator and M$Office. I can help with the slices and web design. Please let me know where I can help out. -Max - Original Message - From: "Nathan Torkington" [EMAIL PROTECTED] To: "mod_perl list" [EMAIL PROTECTED] Sent: Thursday, December 14, 2000 10:06 AM Subject: Re: Mod_perl tutorials Gunther Birznieks writes: However, I am willing to concede that as a first cut, fancy slides are probably not worth it because the slides will change too often. Once v1 is released, then someone can transcribe the slides to PPT (or maybe a tool will exist by then) as a "stable release" if they want to (probably someone like me.) Getting anything done with a mailing list full of programmers is nearly impossible. Everyone wants to write tools, but nobody has said "give me the slides for a week and I'll make them better". Instead we're arguing about the best source format :-) I developed the slides in a POD-like slide format that Tom Christiansen uses. One of his trainers developed a slide2rtf converter, and the rtf can then be imported into PowerPoint. That doesn't work with StarOffice, as importing RTF immediately drops you into the WordProcessor. I think that my slides are pretty close to a v1. I don't know that the subsequent tweaks will be worth the hassle of PPT conversion. I'd rather not revert back to the POD-like format. Importing into PPT is a pain in the arse. I'd rather find someone who wants to work on the class and say "ok, it's yours for a week--fix it". So consider this a call to arms: anyone with StarOffice/Powerpoint want to bang on the class? Nat
Re: mod_perl tutorials
I would like to offer my services as HTML coder for the website. I Also have experience with Adobe Photoshop and Illustrator. -Max
SSL / Apache / .vtml
Folks, I got this message from a vendor as to why they couldn't do SSL on their site...or that they couldn't, what does Apache say ? IDI Solutions Newsroom Manager and Grassroots Manager utilize not just the standard Apache web server, but create custom HTML pages for each user through the use of the modperl module of Apache with custom built scripts to parse an Oracle database. You will notice that the site has pages with the .vtml extension. Our application interacts with Apache to parse these pages through the database to create valid HTML code. Utilizing SSL with Apache is indeed a very simple modification to Apache when there is not database parsing happening in the same process. IDI has attempted to have SSL and our custom scripts to operate simultaneously and after several attempts we realized that it was a much larger undertaking. thx, mlb
Apache::AuthCookie and SSL
I'm having the problem with being logged out then I switch to a secure document. I have to log back in to get to the page. And when I go from a SSL page to a plain page it logs me out again. Any advise? Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a Apache::AuthCookie is version 2.011 I'm also using Embperl v1.2.1 from .htaccess in the protected directories AuthType Apache::AuthCookieHandler AuthName Apollo PerlAuthenHandler Apache::AuthCookieHandler-authenticate PerlAuthzHandler Apache::AuthCookieHandler-authorize require valid-user from httpd.conf PerlModule Apache::AuthCookieHandler PerlSetVar ApolloPath / PerlSetVar ApolloLoginScript /Protected/Login/login.epl # This is the action of the login.epl script above. Files LOGIN AuthType Apache::AuthCookieHandler AuthName Apollo SetHandler perl-script PerlHandler Apache::AuthCookieHandler-login /Files Thanks, John -- John Walstra CNET Networks Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 Phone: 630.438.7000 x1304Fax: 630.775.0555
Re: Advocacy idea ...
Nathan Torkington wrote: I like the idea. Is there a threaded discussion package for mod_perl? mwForum does a nice job, and runs under Apache::Registry. It allows both the usual threaded messaging and file uploads/downloads, so it's a natural for associating files and comments. I use it for a low-traffic customer requests/comments page, and it's been fine. See the home page, http://www.mawic.de/mwforum/ ..Theo -- Theo Petersen mailto:[EMAIL PROTECTED] When angry, count to four; when very angry, swear.-- Mark Twain
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: I have this dangling idea of building a TWIG lookalike (in Perl), with a 'plug-in'/'module' structure, so I may write the email client, and others fill with their desired modules. Anyway, it's a seriuos undertaking, but it's in my plans to rip as much code and design choices from stable OS webmails as possible. (speaking as the author of a proprietary mod_perl webmail...) DO IT!! twig's the best thing out there and it's highly functional but aesthetically atrocious. i use it but i wish there was a good mod_perl alternative. i'm not terribly interested in hacking php. i don't know if i could legally help write code or not. might not be an issue at all, dunno. but i can certainly give advice.
Re: Apache::AuthCookie and SSL
might wanna modify the source to set the domain to .yourdomain.com, as its probably now being set as secure.yourdomain.com or www.yourdomain.com i have the same setup here, it works fine.. John Walstra wrote: I'm having the problem with being logged out then I switch to a secure document. I have to log back in to get to the page. And when I go from a SSL page to a plain page it logs me out again. Any advise? Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a Apache::AuthCookie is version 2.011 I'm also using Embperl v1.2.1 from .htaccess in the protected directories AuthType Apache::AuthCookieHandler AuthName Apollo PerlAuthenHandler Apache::AuthCookieHandler-authenticate PerlAuthzHandler Apache::AuthCookieHandler-authorize require valid-user from httpd.conf PerlModule Apache::AuthCookieHandler PerlSetVar ApolloPath / PerlSetVar ApolloLoginScript /Protected/Login/login.epl # This is the action of the login.epl script above. Files LOGIN AuthType Apache::AuthCookieHandler AuthName Apollo SetHandler perl-script PerlHandler Apache::AuthCookieHandler-login /Files Thanks, John -- John Walstra CNET Networks Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 Phone: 630.438.7000 x1304Fax: 630.775.0555 -- __ JR Mayberry e-Vend.net Corporation Programmer and Systems Administrator(888) 427-8743 x226 tel [EMAIL PROTECTED]http://www.e-vend.net The information in this message (including attachments) is confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ***
Re: Apache::AuthCookie and SSL
actually you should be able to do a PerlSetVar to set that as well PetSetVar ApolloDomain .yourdomain.com i think will work John Walstra wrote: I'm having the problem with being logged out then I switch to a secure document. I have to log back in to get to the page. And when I go from a SSL page to a plain page it logs me out again. Any advise? Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a Apache::AuthCookie is version 2.011 I'm also using Embperl v1.2.1 from .htaccess in the protected directories AuthType Apache::AuthCookieHandler AuthName Apollo PerlAuthenHandler Apache::AuthCookieHandler-authenticate PerlAuthzHandler Apache::AuthCookieHandler-authorize require valid-user from httpd.conf PerlModule Apache::AuthCookieHandler PerlSetVar ApolloPath / PerlSetVar ApolloLoginScript /Protected/Login/login.epl # This is the action of the login.epl script above. Files LOGIN AuthType Apache::AuthCookieHandler AuthName Apollo SetHandler perl-script PerlHandler Apache::AuthCookieHandler-login /Files Thanks, John -- John Walstra CNET Networks Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 Phone: 630.438.7000 x1304Fax: 630.775.0555 -- __ JR Mayberry e-Vend.net Corporation Programmer and Systems Administrator(888) 427-8743 x226 tel [EMAIL PROTECTED]http://www.e-vend.net The information in this message (including attachments) is confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ***
Re: SSL / Apache / .vtml
"MB" == Mike Buglioli [EMAIL PROTECTED] writes: MB Utilizing SSL with Apache is indeed a very simple modification to Apache true. MB when there is not database parsing happening in the same process. no need for this qualifier. SSL and mod_perl are orthogonal technologies; the only interaction is that both require more CPU than static non-ssl pages do. basically, they're either 1) lazy, 2) incompetent, 3) ignorant, or 4) all of the above. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache::AuthCookie and SSL
"JW" == John Walstra [EMAIL PROTECTED] writes: JW I'm having the problem with being logged out then I switch to a JW secure document. I have to log back in to get to the page. And JW when I go from a SSL page to a plain page it logs me out JW again. Any advise? Figure out how to make your web browser send the cookie to both the SSL and non-SSL versions of your pages. You're not being logged out; the cookie just is not being sent to you. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
RE: Trouble with AxKit at runtime - XML parsing stage
I take your answer as a polite confirmation that I am the only one to make that mistake :-) Well, this seems to be the case. Now that I know the problem cause, this *is* obvious. Still, the guide doesn't clear things IMHO for one under the same weird false assumption that I had: "but the parent does not exit. Instead, the parent re-reads its configuration files, spawns a new set of child processes and continues to serve requests. It is almost equivalent to stopping and then restarting the server. " It seems a subtle point indeed - that although the libperl.so is external, it has already been mapped into the core back at the runtime loader stage, and will never be reloaded. Until I asked myself this question in this form (what exactly happens with the apache core and why isn't the module reloaded?) I didn't get it. I wonder why I was so sure that apache re-exec's itself. I am sure I saw it in some public domain server after our homegrown webserver implementation had done it that way, some 6 years ago. Was it cern httpd then, rather than ncsa/apache? Well, I could also notice there is no "-listen-fd 4" or smth. argument in the respawned httpd process cmdline, to tell the restarting process where to take the listening socket... I like this technique because it ensures there is no resource leak (other than, possibly, forgotten open fds) on restart. Do you know if really many people suffer from the memory leaks you mention at the link you gave? Should I patch apache so it has such restart semantics in addition to (as another sighandler? configurable?)/instead the current HUP behaviour? I mean, will such patch be really useful for someone? Vassilii -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 11:50 AM To: Khachaturov, Vassilii Cc: '[EMAIL PROTECTED]' Subject: RE: Trouble with AxKit at runtime - XML parsing stage Stas: maybe you could add a small section to your Guide elaborating on dependencies of things and what has to be remade when things are upgraded? (Or I am the only one to make such stupid mistake?) Well, it's documentated: http://perl.apache.org/guide/control.html#Restarting_Techniques Of course you cannot send a process the HUP signal and expect it to fully stop and re-start, unless you know that it does that. Isn't it obvious that when you upgrade some binary you should quit the program that's depending on it and restart it?
Re: Apache::AuthCookie and SSL
"JM" == JR Mayberry [EMAIL PROTECTED] writes: JM might wanna modify the source to set the domain to .yourdomain.com, as JM its probably now being set as secure.yourdomain.com or JM www.yourdomain.com no need to modify source to do that. AuthCookie has a config option to do it for you.
Warning, Apache Version 1.3.0 required
Ok, i've searched the archives and cannot find help for this problem there. I have compiled Apache v 1.3.14, without errors. I have then gone to compile mod_perl v1.24, below is my effort. The error/warning at the bottom states that i require Apache 1.3.0. Anyone shed any light on why this would happen? Thanks in advance, Richard Harrison [root@localhost mod_perl-1.24]# perl Makefile.PL DO_HTTPD=1 USE_APACHI=1 APACHE_PREFIX=/usr/local/apache Enter `q' to stop search Please tell me where I can find your apache src [] /usr/local/etc/apache/apache_1.3.14/src Appending mod_perl to src/Configuration Using config file: /root/mp/mod_perl-1.24/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard EXTRA_CFLAGS: -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED * WARNING * Apache Version 1.3.0 required, aborting... * WARNING *
Re: Email (mod_perl) Apache module?
brian moseley wrote: (speaking as the author of a proprietary mod_perl webmail...) DO IT!! my fear is that writing it as a mod_perl app, it'd be terribly niche, and we wouldn't get it rolling. I'd rather write a bunch of modules, that can be called from a CGI or a templating system. Then those modules can be reused on other apps. Plus, we should be writing that is pure-CGI compatible -- y'know, we won't be needing any actual mod_perl hooks, and CGI-compat means is more usable under other configs, and keeps you honest. martin
RE: Warning, Apache Version 1.3.0 required
This is a FAQ. Get mod_perl-1.24_01 where this is fixed. V. -Original Message- From: Richard [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 1:19 PM To: [EMAIL PROTECTED] Subject: Warning, Apache Version 1.3.0 required Ok, i've searched the archives and cannot find help for this problem there. I have compiled Apache v 1.3.14, without errors. I have then gone to compile mod_perl v1.24, below is my effort. The error/warning at the bottom states that i require Apache 1.3.0.
RE: Warning, Apache Version 1.3.0 required
-Original Message- From: Richard [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 1:19 PM To: [EMAIL PROTECTED] Subject: Warning, Apache Version 1.3.0 required Ok, i've searched the archives and cannot find help for this problem there. I have compiled Apache v 1.3.14, without errors. I have then gone to compile mod_perl v1.24, below is my effort. The error/warning at the bottom states that i require Apache 1.3.0. short answer: upgrade to 1.24_01 long answer: search the archives more closely ;) HTH --Geoff Anyone shed any light on why this would happen? Thanks in advance, Richard Harrison
Re: [heh] Larry Wall on CNBC
Only from someone on AOL ;) [EMAIL PROTECTED] wrote: We need to see Larry Wall on CNBC taking questions like "So it's free?" "yes" "And you don't get any money for it?" "Correct" "And you keep working on it?" "That's my perogative"short Bobby Brown move "And you don't charge anyone?" "S/he catches on quick, don't s/he folks?" "Does anyone use Perl?" "Probably more than any other language on the web" "You mean any free language, right?" "No, including the ones that cost thousands of dollars to license" "It doesn't work with anything else, does it?" "You couldn't name something it won't work with." "What can't I name?" sigh begin:vcard n:Thompson;Jimi tel;pager:877-309-2784 tel;cell:817-980-7863 tel;work:817-619-3612 x-mozilla-html:FALSE url:hww adr:;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Jimi Thompson end:vcard
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: brian moseley wrote: (speaking as the author of a proprietary mod_perl webmail...) DO IT!! my fear is that writing it as a mod_perl app, it'd be terribly niche, and we wouldn't get it rolling. I'd rather write a bunch of modules, that can be called from a CGI or a templating system. Then those modules can be reused on other apps. you'd be silly if you didn't layer your application this way. Plus, we should be writing that is pure-CGI compatible -- y'know, we won't be needing any actual mod_perl hooks, and CGI-compat means is more usable under other configs, and keeps you honest. up to you. if i was doing it i'd be using ao and mason :)
why is it so gay?
=] ok, i downloaded mod_perl 1.24_01 to see if that made any difference. YAY! Makefile.PL works, make works, make install works, make test.. =[ Now i the server will not startup: ### 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 log being: ### Server is not starting !? Subroutine main::pid redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 103. Subroutine main::access redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 104. Subroutine Outside::code redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 108. Subroutine PerlTransHandler::handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 114. Subroutine MyClass::method redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 121. Subroutine BaseClass::handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 127. Subroutine My::child_init redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 145. Subroutine My::child_exit redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 155. Subroutine My::restart redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 159. Subroutine Apache::AuthenTest::handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 167. Subroutine My::DirIndex::handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 189. Subroutine My::ProxyTest::handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 207. Subroutine handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 241. Subroutine new redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 263. Subroutine DESTROY redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/startup.pl line 265. [notice] Destruction-DESTROY called for $global_object Subroutine handler redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/stacked.pl line 6. Subroutine one redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/stacked.pl line 14. Subroutine two redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/stacked.pl line 25. Subroutine three redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/stacked.pl line 31. Subroutine four redefined at /usr/local/etc/apache/mod_perl-1.24_01/t//docs/stacked.pl line 37. [notice] Destruction-DESTROY called for $global_object [Fri Dec 15 18:52:27 2000] [warn] [notice] child_init for process 9416, report any problems to [no address given] ### Are you guys making it hard for me on purpose? Richard
Re: [heh] Larry Wall on CNBC
It only took you a month to come up with that1 Someone give the man a cigar! Jimi "Hendrix" Thomspson, writes: Only from someone on AOL ;)
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: I have this dangling idea of building a TWIG lookalike (in Perl), with a 'plug-in'/'module' structure, so I may write the email client, and others fill with their desired modules. Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. - Perrin
UPDATE: lingerd
I've just released lingerd version 0.92; you can get it at ftp://iagora.com/pub/software/lingerd/lingerd-0.92.tar.gz WHAT IS LINGERD? Lingerd is a daemon that greatly improves Apache's scalability by taking over the task of lingering on closing sockets. On dynamic page servers that don't serve their own images (and where keepalives are off), the effect of lingerd on Apache's load is similar to that of a proxy front-end server. STATUS Lingerd under Linux is running on production servers, and is no longer considered beta code. Lingerd on *BSD, Solaris and other Unix systems is still beta, and I'd really appreciate some feedback (compilation success, any compilation warnings, etc). CHANGES SINCE LINGERD 0.91b: . stopped logging some harmless condition as an error . minor documentation changes Btw, I won't be around until next thursday or so; I'll answer my emails as soon as I get back. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: SSL / Apache / .vtml
On Fri, 15 Dec 2000, Mike Buglioli wrote: Do you think it's because they are generating dynamic .vtml pages which could be causing them some problems ? mlb i don't knwo what they have done. i doubt that it is either an SSL, database, or mime-type problem. in my experience, and i've done some fairly wierd stuff, it didn't matter to my application if it was happening over SSL. whether SSL was used or not didn't affect anything and i could turn it off or on without a problem. it sounds like a design problem, although i wouldn't rule out a lack of documentation reading either. brian d foy wrote: On Thu, 14 Dec 2000, Mike Buglioli wrote: I got this message from a vendor as to why they couldn't do SSL on their site...or that they couldn't, what does Apache say ? Utilizing SSL with Apache is indeed a very simple modification to Apache when there is not database parsing happening in the same process. both of those work fine together. perhaps they are having other issues. -- brian d foy [EMAIL PROTECTED] Director of Technology, Smith Renaud, Inc. 875 Avenue of the Americas, 2510, New York, NY 10001 V: (212) 239-8985 -- brian d foy [EMAIL PROTECTED] Director of Technology, Smith Renaud, Inc. 875 Avenue of the Americas, 2510, New York, NY 10001 V: (212) 239-8985
Re: Email (mod_perl) Apache module?
martin langhoff wrote: brian moseley wrote: (speaking as the author of a proprietary mod_perl webmail...) DO IT!! my fear is that writing it as a mod_perl app, it'd be terribly niche, and we wouldn't get it rolling. I'd rather write a bunch of modules, that can be called from a CGI or a templating system. Then those modules can be reused on other apps. Plus, we should be writing that is pure-CGI compatible -- y'know, we won't be needing any actual mod_perl hooks, and CGI-compat means is more usable under other configs, and keeps you honest. martin i might suggest looking at my fave email module Mail::Sender http://search.cpan.org/doc/JENDA/Mail-Sender-0.7.04/Sender.pm for more info if this could be modperl comptible i think this would be a good thing btw: i have used this with HTML::Template before!
Apache::Reload and environment variables
Greetings, I tried using Apache::Reload: PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/ PerlModule Apache::DBI [...] PerlModule Apache::Reload PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off but when I do, the error log gets filled with "ORACLE_HOME not set!" Only one module (one that doesn't use DBI) has a 'use Apache::Reload" in it. Any one know why this happens? Cheers, Mark
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. it's an option, but it's got a large amount of dependencies, which makes it a tremendous effort for me to install on my system. for instance: 'On the frontend, install PostgreSQL. You may be able to use another SQL database, but (1) it must support transactions (this rules out MySQL unless someone rewrites Wing::Login in a way which doesn't require transactions). (2) it must support using ident lookups for authentication (or else you will have to tweak the DBI connection setup).' all in all, it's a somewhat daunting task. on the other hand, you've got me itching to give it a shot :)
re: gay thing
On Fri, 15 Dec 2000, Dave Rolsky wrote: It seems that you are using the word gay to indicate something bad or not working correctly. Some people might assume from that that you are a big asshole. Or you're 12. Or you're a 12 year old asshole. But my personal guess is you're just an asshole. -dave /*== www.urth.org We await the New Sun ==*/ Jesus, you guys are a little touchy? oh God no, please don't even think about writing a reply to this one. You make me laugh Dave, thanks for brightening up my day. It was your implication that homosexuals are bad, or not working correctly. If i were a 12 yr old asshole, i better watch my step with you eh? Richard.
Thanks for the help (.24_01 where the problem was fixed)
Thanks for the guys who answered the problem. :) now got to get this version installed! thanks. Richard.
Re: Email (mod_perl) Apache module?
On Fri Dec 15 11:28:03 2000 -0800 brian moseley wrote: On Fri, 15 Dec 2000, Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. it's an option, but it's got a large amount of dependencies, which makes it a tremendous effort for me to install on my system. for instance: 'On the frontend, install PostgreSQL. You may be able to use another SQL database, but (1) it must support transactions (this rules out MySQL unless someone rewrites Wing::Login in a way which doesn't require transactions). This rewriting doesn't take much effort, I have done it for one company. You will need much more effort adding other things to make it full-featured web-mail system. -- ☻ Ričardas Čepas ☺ ~~ ~
handling HEAD requests
Hi, I'm working on a modperl site that doesn't presently handle HEAD requests properly (it returns the entire content). That's definitely a waste (especially seeing how browsers bang on it with HEAD requests), is not compliant, and makes telnet debugging a pain. I know how to detect a HEAD and to return correctly. The problem is that there are a *lot* of content handlers and that would require patching them all. From the discussion we had around it, it seems that there are two solutions: either put the check in the TransHandler (it knows which urls map to which content handlers) which would return immediately a 404 or a 200, or put that in the part of the logic that deals with rendering the content (all content handlers use it) so that it would return only the headers and skip the actual content. Choosing between either is hard. The advantage of the TransHandler solution is that it would avoid potentially costly processing (lots of db requests) that happens in the content handlers. It's problem is that some of these content handlers might decide to return 404s themselves, or redirects, or 403s, etc... if certain conditions that require processing are not met. Thus the TransHandler would return false positives because it only knows whether there is a registered handler, not what that handler would actually return. The advantage of putting HEAD checks in the rendering code is that it would already know the return code for the request as it runs at the end of the content phase and would thus be able to return correct answers as well as to add content-length headers, which a certain number of search engines will probably very much like. However, all the costly processing will have happened for (next to) nothing, and we wouldn't be saving much. Does anyone else have experience in dealing with such problems or ideas on which choice is best ? -- robin b. Radioactive cats have 18 half-lives.
Re: Email (mod_perl) Apache module?
At 11:28 15/12/2000 -0800, brian moseley wrote: On Fri, 15 Dec 2000, Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. it's an option, but it's got a large amount of dependencies, which makes it a tremendous effort for me to install on my system. for instance: 'On the frontend, install PostgreSQL. You may be able to use another SQL database, but (1) it must support transactions (this rules out MySQL unless someone rewrites Wing::Login in a way which doesn't require transactions). Without looking at the code, that probably shouldn't be too hard. Otoh 1) MySQL now has some support for transactions and 2) if you really want this to be used widely it should probably factor out all db code and hide it under and API so that people could use it with whatever backend they see fit (rdbms or not). on the other hand, you've got me itching to give it a shot Wing has been widely tested in the field iirc, it's probably a good idea to base anything in that domain on it. -- robin b. Doctor: "Ah, ah that's a catch question. With a brain your size you don't think, right?" -- Dr. Who
Re: Email (mod_perl) Apache module?
Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? I've seen TWIG and its *very* clever, if ugly. It'll let you authenticate against a lot of things. Use IMAP or POP. Use News. Use mysql, Postgres, MySQL, or none. Use cookies or encoded links for state. It's *very* flexible, and I've come to like that a lot. That's why I'd like to base most of my design choices on it. martin
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, Robin Berjon wrote: Wing has been widely tested in the field iirc, it's probably a good idea to base anything in that domain on it. possibly. groupware applications aren't that complex really, tho (except for calendaring and scheduling); the main problem is that they're *large* when they become featureful, and in some ways it feels like a waste to build a new one just cos "i want to do it my way". i'd really like to see an app with a much more outlook-ish interface than twig. and i don't think wing has all of the pim functionality that twig has. can't say if wing is a good starting point for that or not.
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? I've seen TWIG and its *very* clever, if ugly. It'll let you authenticate against a lot of things. Use IMAP or POP. Use News. Use mysql, Postgres, MySQL, or none. Use cookies or encoded links for state. It's *very* flexible, and I've come to like that a lot. That's why I'd like to base most of my design choices on it. yup.
Re: handling HEAD requests
On Fri, 15 Dec 2000, Robin Berjon wrote: I'm working on a modperl site that doesn't presently handle HEAD requests properly (it returns the entire content). If all the information you need to generate a given page is in the URL, you can also let mod_proxy cache it and handle the HEAD requests for you. Even if these pages depend on cookies, you can use mod_rewrite in the proxy server to put them into the URL before requesting the page from the mod_perl server, creating a unique and cacheable (sp?) URL. Of course you could also do this caching on the mod_perl server yourself and let Apache handle these pages with core (i.e. as static), but that sounds like more work. - Perrin
Re: handling HEAD requests
At 12:16 15/12/2000 -0800, Perrin Harkins wrote: On Fri, 15 Dec 2000, Robin Berjon wrote: I'm working on a modperl site that doesn't presently handle HEAD requests properly (it returns the entire content). If all the information you need to generate a given page is in the URL, you can also let mod_proxy cache it and handle the HEAD requests for you. Even if these pages depend on cookies, you can use mod_rewrite in the proxy server to put them into the URL before requesting the page from the mod_perl server, creating a unique and cacheable (sp?) URL. Of course you could also do this caching on the mod_perl server yourself and let Apache handle these pages with core (i.e. as static), but that sounds like more work. That's indeed how I would handle it (and in fact, do handle it in other cases) if it were possible. However, a great majority of those pages are generated from a database that changes very very frequently so that caching/static writing wouldn't be really efficient in most cases. There's no telling when the db changes (which rules out caching) and writing all the possible pages to disk is, well, probably not really advisable in this case (lots of data and possible combinations). -- robin b. James Joyce -- an essentially private man who wished his total indifference to public notice to be universally recognized. -- Tom Stoppard
Re: Email (mod_perl) Apache module?
At 12:23 15/12/2000 -0800, brian moseley wrote: On Fri, 15 Dec 2000, Robin Berjon wrote: Wing has been widely tested in the field iirc, it's probably a good idea to base anything in that domain on it. possibly. groupware applications aren't that complex really, tho (except for calendaring and scheduling); the main problem is that they're *large* when they become featureful, and in some ways it feels like a waste to build a new one just cos "i want to do it my way". I agree, groupware is usually fairly easy modulo that you still have to write a lot of easy code. It would be a waste to start from scratch. Patching Wing could be an option. i'd really like to see an app with a much more outlook-ish interface than twig. and i don't think wing has all of the pim functionality that twig has. can't say if wing is a good starting point for that or not. I don't like outlook but as you said earlier the code should be handled in some place and the display elsewhere. I don't know twig but if a horrible interface is what plagues it, then it wasn't written that way. Ideally one would have an API for the mail logic (-list_mailboxes($user), -list_messages($user, $mailboxes), $message-content($msg_id), etc...) and the display would be totally separate. if the existing modules don't allow for such things, then a rewrite would be needed. But that doesn't exclude cannibalising code where it makes sense to :) -- robin b. Being schizophrenic is better than living alone.
Re: Apache::Reload and environment variables
Mark, If the variable ORACLE_HOME doesn't change why not just set it as an environment variable outside the program and export it? Mark Doyle wrote: Greetings, I tried using Apache::Reload: PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/ PerlModule Apache::DBI [...] PerlModule Apache::Reload PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off but when I do, the error log gets filled with "ORACLE_HOME not set!" Only one module (one that doesn't use DBI) has a 'use Apache::Reload" in it. Any one know why this happens? Cheers, Mark begin:vcard n:Thompson;Jimi tel;pager:877-309-2784 tel;cell:817-980-7863 tel;work:817-619-3612 x-mozilla-html:FALSE url:hww adr:;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Jimi Thompson end:vcard
Re: Apache::Reload and environment variables
On Friday, December 15, 2000, at 04:01 PM, Jimi Thompson wrote: If the variable ORACLE_HOME doesn't change why not just set it as an environment variable outside the program and export it? PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/ PerlModule Apache::DBI [...] PerlModule Apache::Reload PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off That snippet is from my httpd.conf file - it is globally defined there. Isn't that the same as what you are saying? Cheers, Mark
Re: Email (mod_perl) Apache module?
Hi - Original Message - From: "George Sanderson" [EMAIL PROTECTED] Sent: Thursday, December 14, 2000 22:47 Subject: RFC: Email (mod_perl) Apache module? The module would allow the users to read and send email. Now that would be advocacy;-) No, that would be spam. -- \js
backtick behavior
Hello, I know this isn't a list for beginners, but I am one of those folks who would benefit from the discussion of organization of docs :) I am on Win2000. When I run a script containing a backtick call, it behaves differently under mod_perl than when called normally (the backtick code is the same, obviously other parts of the script are different, it's a legitimate perlHandler, etc). When called under mod_perl, the command console visibly flashes up, and performance is slower. When called normally, a backtick command doesn't cause the window to pop up. Any pointers on where to look to understand this behavior? Or a more appropriate place to post? Doug
Re: fork inherits socket connection
At 04:02 PM 12/15/00 +0100, Stas Bekman wrote: open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; open STDOUT, '/dev/null' or die "Can't write to /dev/null: $!"; defined(my $pid = fork) or die "Can't fork: $!"; exit if $pid; setsid or die "Can't start a new session: $!"; open STDERR, 'STDOUT' or die "Can't dup stdout: $!"; You don't miss anything, the above code is an example of daemonization. You don't really need to call setsid() for a *forked* process that was started to execute something and quit. Oh, so that's the difference between system and fork/exec! That's what I get for following perlipc instead of the Guide. I've always done it the Hard Way (tm) before. That is, in my mod_perl handler I would fork, then waitpid, call setsid, fork again freeing Apache to continue (and double fork to avoid zombies), and then finally exec my long running program. With this method I had to call setsid or else killing the Apache parent would kill the long running process. Calling system() in the handler and then doing a simple fork in the long running program is much cleaner (but you all knew that already). I just didn't realize that it freed me from calling setsid. I just have to remember not to system() something that doesn't fork or return right away. But, I'm really posting about the original problem of the socket bound the by the forked program. I tried looking through mod_cgi to see why mod_cgi can fork off a long running process that won't hold the socket open but I my poor reading of it didn't turn anything up. Anyone familiar enough with Apache (and/or mod_cgi) to explain the difference? Does mod_cgi explicitly close the socket file descriptor(s) before forking? Thanks, Bill Moseley mailto:[EMAIL PROTECTED]
Re: Email (mod_perl) Apache module?
Leon Brocard wrote: Jeremy Howard sent the following bits through the ether: IMHO, the best open source WebMail servers are PHP based: In Perl, there's also WING: http://users.ox.ac.uk/~mbeattie/wing/ and my oh-my-god-it's-still-in-development-and-I'm-still-breaking- the-CVS-version-and-it-still-doesn't-have-the-features-I-want-it-to: http://astray.com/acmemail/devel/ I've heard of WING, but the information at that URL is really scarce, and missing things like screenshots and/or a demo version to give you a good idea of what it does. There are a lot of webmail systems out there... but I haven't seen any that have all the features that we needed. So, instead of trying them out, I just picked one that looked easy to extended and started adding the features that I needed. I've taken the stable version of acmemail, and hacked in what we needed: S/MIME encryption/decryption/verifiying, nested IMAP folders using MH, the ability to add/rename/delete folders, our own look, some user configurability (block sigs, poll times, icon/label prefs, etc, so far). I didn't realize that there was a devel version of acmemail in CVS, or I would have hacked on that instead. However, I'm hoping that my changes can get into CVS eventually, as CVS has message threading, better session stuff, theme support, and other stuff. As for scalability... the only problem I've seen, is when users open up a folder that is really big (20MB), and the load on the IMAP server goes up. Hopefully that problem will be gone when the server is replaced with a Dual PIII-800, loads of RAM, and multiple SCSI drives in Raid 5, instead of the Celeron 500 with a single IDE drive that it is right now. -- Regards, Wim Kerkhoff, Software Engineer Merilus Technologies, Inc. [EMAIL PROTECTED] S/MIME Cryptographic Signature
Re: backtick behavior
Doug Brewer wrote: I am on Win2000. When I run a script containing a backtick call, it behaves differently under mod_perl than when called normally (the backtick code is the same, obviously other parts of the script are different, it's a legitimate perlHandler, etc). When called under mod_perl, the command console visibly flashes up, and performance is slower. When called normally, a backtick command doesn't cause the window to pop up. On windows, some applications expect there to be a console. When you are in a console, none pops up because you already have one. In modperl mode you see it pop up :( If you want to make that console go away I believe there is something you can do to a windows executable to take away the console requirement if it has one, but I can't remember off the top of my head. I would check with the ActiveState perl win32 lists. -- Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
RE: Warning, Apache Version 1.3.0 required
-Original Message- From: Richard [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 1:19 PM To: [EMAIL PROTECTED] Subject: Warning, Apache Version 1.3.0 required Ok, i've searched the archives and cannot find help for this problem there. I have compiled Apache v 1.3.14, without errors. I have then gone to compile mod_perl v1.24, below is my effort. The error/warning at the bottom states that i require Apache 1.3.0. short answer: upgrade to 1.24_01 long answer: search the archives more closely ;) Or intermediate answer, read Geoff's weekly summaries (or search them) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Apache::Compress + mod_proxy problem
I've run into a problem with Apache::Compress in dealing with mod_proxyed content. The author of Apace::Compress suggested that I post the problem here. I'm running apache 1.3.14, mod_perl 1.24_01, Apache::Compress 1.003 on a RedHat 6.2 linux box. I get an internal server error when ever I try to request a file ending with .htm/.html on a proxied server. Meaning: www.company.com/local/index.html - OK, contents are compressed www.company.com/proxy/ - OK, contents are NOT compressed www.company.com/proxy/index.html - 500 error w/ Apache::Compress www.company.com/proxy/script.pl - OK, contents are NOT compressed Apache::Compress tries to map the URI to the filesystem and ends up with an undefined filehandle for content residing on the remote server and returns SERVER_ERROR. I've modified Apache::Compress to special case proxy requests, but I can't figure out how to do a redirect to mod_proxy from within Apache::Compress. Is this the best way to resolve this issue? I've been reading the eagle book and I'm guessing I could use a Translation Handler to handle this as well. Here are the relevant sections of httpd.conf: PerlModule Apache::Compress FilesMatch "\.(htm|html)$" SetHandler perl-script PerlHandler Apache::Compress /FilesMatch IfModule mod_proxy.c ProxyRequests On ProxyVia Off ProxyPass /proxy http://internalserver/ ProxyPassReverse/proxy http://internalserver/ /IfModule
Re:Advocacy idea ...
On Thursday, December 14, 2000, Homsher, Dave V. wrote the following about "Advocacy idea ..." HDV Hi all, HDV With all of the advocacy talk on the ML right now I've been HDV mulling around the idea of having a "peer review" forum where one could post HDV code that you are currently working on w/an explanation of what you are HDV trying to accomplish and have the community review/give suggestions HDV warnings, etc. or how to improve code (maybe /. style?). I know from my HDV experience that having others review your code is always helpful (well HDV almost always :) ). In my work situation right now I am the only person that HDV knows anything about mod_perl and we really only have one other person who HDV knows any Perl at all (and this was v. 4). So I know that some stupid things HDV are slipping through ... Perhaps as part of the "new" community on "Take23" ... Best Regards, Mike Miller [EMAIL PROTECTED]
RE: is morning bug still relevant?
Greetings, to say "ping doesn't work in all cases" without qualifiying why and/or which drivers that applies to. We've had to write our own -ping method for the MySQL DBD driver. Our developer tried to track down a maintainer for the DBD::msql/mysql module to submit a diff, but to no avail. It was easier to patch the MySQL driver than to start putting driver conditionals in our own code (our stuff runs on Oracle MySQL). Steve
unsuscribe
unsuscribe begin:vcard n:Girard;Jean-Denis tel;work:(+689) 48 35 27 x-mozilla-html:FALSE org:Essential Software adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Directeur associé x-mozilla-cpt:;19808 fn:Jean-DenisGirard end:vcard
