Re: Apache::Scoreboard on Digital Unix
Hi all, on Fri, 17 Nov 2000 Didier Godefroy wrote: I was trying to add the Apache::Scoreboard module [on Digital Unix/Compaq Tru64] to perl using cpan and it's giving out errors: cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_protocol.h, line 153: Invalid declara tion. __attribute__((format(printf,2,3))); ^ etc. I am experiencing the same behaviour, using Apache::Scoreboard 0.10 and mod_perl 1.25 with Digital cc (not gcc). I didn't see a reply to Didier's original message, is this problem solved somehow? Thanks! -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 It is more complicated than you think -- The Eighth Networking Truth from RFC 1925
Apache et perl
J'ai installé Apache 1.3.12, Perl 5.6.0 sous Mandrake 8.0. J'ai la page HTML suivante (sans les ) (dans /var/www/html): html head title Page de Test /title meta name=author content=denizot /head body form action=../cgi-bin/base.pl method=GET input type=Text name=saisie value= size=10 /form /body /html et le script perl (dans /var/www/cgi-bin) suivant: #!/usr/bin/perl -w # base.pl printf Content-type: text/html\n\n; print ca marche pas\n; J'ai modifie httpd.conf pour que /var/www/cgi-bin soit un Directory avec Options ExecCGI. Lorsque je tape http://nom_de_host et que je presse Enter apres la saisie, une page HTML Internal ERROR me saute au yeux. Par contre, lorsque je tape http://adresse_ip et que je fais la meme manip, une fenetre Enregistrer sous... apparait. Quelqu'un a-t-il eu le meme probleme ou comment le resoudre? _ Le journal des abonnés Caramail - http://www.carazine.com
[admin] Please post only English
Folks, This email is to remind you that you should use English when you communicate over this list, triggered by the last day's posts in French and German. If English is not your native language please try to do your best to express yourself in English. While you should spend some time to spell check your message and check that it's understandable by others, it is OK to make mistakes. Do not be afraid to post in this case and learn English as you go. But do make an effort to make it easier for us to understand your question and be able to answer it. If you really cannot express yourself in English, you should ask somebody who speaks your language to help you. But it'd be really a mess if the list starts talking in different languages, where most of subscribers won't understand what's going on. Please understand that I'm not trying to prevent people from seeking help in this forum. I'm just looking for a way to have everybody understand the language of the posts. Just like Perl has Perl Mongers groups all around the world, you may want to start your local mod_perl group, where you can communicate in your native language. Do we have here someone like brian d foy to do the same for mod_perl as brian did for the Perl community? You should also try contacting your local Perl mongers group, there are good chances that someone knows mod_perl there. Another idea would be to have people talking different languages to volunteer as a proxy for those who cannot express themselves in English. So we will have an emails of those volunteer and the languages they cannot be contacted by on the site, and these nice fellas will translate the question, post to the list and optionally propogate the answer back to the fellow in trouble in her native language. I wish we had a working model of the babel fish. (I'm talking about the original one and not of a poor implementations of it that available now). _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Apache et perl
Guillaume, Just this once, I have translated your message for you. Please bear in mind that most of the people on this list can understand only English! Any volunteers for translating the replies? HTH Sean START OF MESSAGE I've installed Apache 1.3.12, Perl 5.6.0 under Mandrake 8.0 I have the following HTML page (without the ) (in /var/www/html): html head title Page de Test /title meta name=author content=denizot /head body form action=../cgi-bin/base.pl method=GET input type=Text name=saisie value= size=10 /form /body /html and the following perl script (in /var/www/cgi-bin): #!/usr/bin/perl -w # base.pl printf Content-type: text/html\n\n; print Doesn't work\n; I've modified httpd.conf to make /var/www/cgi-bin a Directory with Options ExecCGI. When I type in http://name_of_host and press Enter, a HTML Internal ERROR page is displayed. However, when I enter http://ip_address and try the same thing, a Save As... window appears. Is there anyone who has the same problem or knows how to resolve it? END OF MESSAGE -Original Message- From: Guillaume Denizot [mailto:[EMAIL PROTECTED]] Sent: 29 June 2001 12:26 To: [EMAIL PROTECTED] Subject: Apache et perl J'ai installé Apache 1.3.12, Perl 5.6.0 sous Mandrake 8.0. J'ai la page HTML suivante (sans les ) (dans /var/www/html): html head title Page de Test /title meta name=author content=denizot /head body form action=../cgi-bin/base.pl method=GET input type=Text name=saisie value= size=10 /form /body /html et le script perl (dans /var/www/cgi-bin) suivant: #!/usr/bin/perl -w # base.pl printf Content-type: text/html\n\n; print ca marche pas\n; J'ai modifie httpd.conf pour que /var/www/cgi-bin soit un Directory avec Options ExecCGI. Lorsque je tape http://nom_de_host et que je presse Enter apres la saisie, une page HTML Internal ERROR me saute au yeux. Par contre, lorsque je tape http://adresse_ip et que je fais la meme manip, une fenetre Enregistrer sous... apparait. Quelqu'un a-t-il eu le meme probleme ou comment le resoudre? _ Le journal des abonnés Caramail - http://www.carazine.com
RE: Apache et perl
-Original Message- From: Sean O'Halpin [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 6:12 AM To: 'Guillaume Denizot'; [EMAIL PROTECTED] Subject: RE: Apache et perl Guillaume, Just this once, I have translated your message for you. and, sadly enough, it's not even a mod_perl related question... sounds like several things are wrong in your httpd.conf, like perhaps a missing SetHandler cgi-script and some DNS settings. we certainly would need more information to be of any help, but the question really is off-topic for this list and better suited to other forums... --Geoff [massive snipage]
Re: osx mod_perl
on 28.06.01 18.20, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Hi Chris, here is the head binary if you still need it. i've had the same problem and it seem to work out. i tried to install HTML::mason on top of mod_perl, but have no idea if what i did is correct i guess i need to do some server configurations, which i have no clue where to start. (See attached file: head) . Vitali Zhulkovsky thanks vitali! it works 'better' now, compiles with 1 error in the cgi tests when installing mod_perl from cpan. it installs and httpd -l and -V say reasonable things. but httpd doesn't keep running, it just stops after a sec. now i reinstalled osx and run tenon's itools which work really fine! but its only free for 14 days then its 500 USD . - has anyone run mod_perl on osx with success?? is there a how-to somewhere?? - cheers chris
RE: Help me!
- Original Message -
From: wac [EMAIL PROTECTED]
To: mod_perl Maillist [EMAIL PROTECTED]
Sent: Wednesday, June 27, 2001 5:48 AM
Subject: Help me!
Dear All,
I want to write a handler, function : log client request file size.
My code can't work:
Apache Config file
Location /test/
SetHandler perl-script
PerlLogHandler My::Test
Options ExecCGI
/Location
My::Test
package My::Test;
sub handler {
my $r = shift;
$r-send_http_header;
open (FILE,log.txt);
print FILE $r-filename .\t. $r-bytes_sent . \n;
close FILE;
}
this handler can log file name for request , but $r-bytes_sent is 0 at
all time.
Your friend,
wac
RE: osx mod_perl
- Original Message - From: Christian Wattinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 29, 2001 12:25 PM Subject: Re: osx mod_perl on 28.06.01 18.20, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Hi Chris, here is the head binary if you still need it. i've had the same problem and it seem to work out. i tried to install HTML::mason on top of mod_perl, but have no idea if what i did is correct i guess i need to do some server configurations, which i have no clue where to start. (See attached file: head) . Vitali Zhulkovsky thanks vitali! it works 'better' now, compiles with 1 error in the cgi tests when installing mod_perl from cpan. it installs and httpd -l and -V say reasonable things. but httpd doesn't keep running, it just stops after a sec. now i reinstalled osx and run tenon's itools which work really fine! but its only free for 14 days then its 500 USD . - has anyone run mod_perl on osx with success?? is there a how-to somewhere?? - cheers chris
setting httpd cookie domains
- Forwarded message from will trillich [EMAIL PROTECTED] - From: will trillich [EMAIL PROTECTED] Date: Tue, 1 May 2001 21:58:41 -0500 To: [EMAIL PROTECTED] Subject: OT -- setting httpd cookies Pointers welcome, of course, to which FM i should R: In setting cookies via cgi or whatever, there's rules on having to include at least two portions of your domain in the cookie, such as for hyperarchive.lcs.mit.edu the minimum domain allowable would be mit.edu, right? But you still have to put the two dots in, as for example, .mit.edu. Would this allow cookies from smith.mit.edu and www.mit.edu AND mit.edu to be set properly? Or would they go into the bit bucket, for greenpeace-friendly recycling? Or for more hypothetical instance, cpu.subnet.org.tld can set cookies with domain=.org.tld and so can www.org.tld but can plain old prefix-challenged org.tld work cookies, in this case? -- I'd concentrate on living in the now because it is fun and on building a better world because it is possible. - Tod Steward [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
On Wed, Jun 27, 2001 at 10:59:16AM -0700, Rob Bloodgood wrote:
me, on the other hand, i don't see the problem with
on incoming request
if has-cookie 'session'
{
update serverside 'accesstime' for session[this] to NOW
Oh yeah? HOW???
$dbh-do(update sesssion_rec set visit = ? where id = ?,time,$session{id});
or maybe even just
$session{when} = time;
if not-modified-since
report same
else {
send headers w/ cookie
generate page
}
}
else
redirect to login page
doesn't look unmanageable to me (until someone shows me the
light, of course)...?
How many sessions/day are you running? How big is your DB? How much
processor do you have to throw at this? (these are the hurdles for storing
serverside info).
maybe it doesn't scale well, i don't know; it works well for our
purposes. at least you don't have to worry about being unable to
send a new cookie on 'no-changes-since...'. just use the session
id of the existing cookie to 'touch' the session record, updating
the timestamp.
but maybe it's trickier than that for some cases...?
OTOH, what *benefit* is derived from storing all of this stuff serverside?
all in this case is 'timestamp-of-last-request'.
--
I'd concentrate on living in the now because it is fun
and on building a better world because it is possible.
- Tod Steward
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: API Design Question
Adam Worrall wrote: SD == Shawn Devlin [EMAIL PROTECTED] writes: SD My first thought is to break the API up so that there is a SD module per API call (there are some 70 calls in the API). My SD reasoning is that I can modify existing calls and add new ones SD without affecting everything else. Does this make sense or is it SD better to have the API as one large program as I have it now? I'd have thought you'be best to put the API in a large module, and then make calls to it from mod_perl handlers. You oculd even write a generic handler which chose which function to execute based on the arguments. Having a module per function may start to do your head in :) The bulk of the API is in 4 or 5 .pm files. My cgi script basically determines the call being made, vets the parameters, calls vaious functions in the .pm files, and then returns the result. The current format for the call is server.com/cgi-bin/api.pl?command=fooparm1=parm2= What I want to have is server.com/api/foo?parm1=parm2= The module that handles foo would check the parameters, make it's calls to the various internal functions, and then compose and send the results. What I like about this is I can add a new function without needing to disturb the existing code. Also, each function call is then self-contained. Currently, my existing API script is essentially a big switch statement. My concern is that each handler links the .pm files so with 50 or so functions I will have 50 or so copies of the various .pm files in memory. Yes - when some Perl in an Apache child process executes DBI::connect (which has been overridden by Apache::DBI), it first looks in a hash of existing connections before opening a new one. Good news ! Thanks for the conformation. Shawn
Re: API Design Question
James G Smith wrote: [snip] My first thought is to break the API up so that there is a module per API call (there are some 70 calls in the API). My reasoning is that I can modify existing calls and add new ones without affecting everything else. Does this make sense or is it better to have the API as one large program as I have it now? If it's an API, I'd not make one module per function, if by function you mean a call (e.g., fork() is a function in the Unix kernel API). Instead, I'd group them by functionality (as in OS/2 - VIO, KBD, DOS, ...). So one module might handle customer accounts, another handle news items, etc. What advantages do I gain by grouping the functions based on functionality? As per my response to Mr. Worrall, one of my concerns with placing each function call into its own module is the amount of memory used by the various .pm files that will be loaded numerous times. I can see that grouping functions based on functionality would reduce the number of .pm files in memory. However, if I go that route, then would I not be better just to leave the API as one file? Thanks, Shawn -- This communication is intended to be received by the individual or entity to whom or to which it is addressed and it contains information that is privileged, confidential and subject to copyright of Recognia Inc. Any unauthorized use, copying, review or disclosure is prohibited. If received in error, please contact me by phone at 613-623-6159 or by email at mailto:[EMAIL PROTECTED].
RE: setting httpd cookie domains
will trillich [EMAIL PROTECTED] wrote: Pointers welcome, of course, to which FM i should R: In setting cookies via cgi or whatever, there's rules on having to include at least two portions of your domain in the cookie, such as for hyperarchive.lcs.mit.edu the minimum domain allowable would be mit.edu, right? But you still have to put the two dots in, as for example, .mit.edu. Would this allow cookies from smith.mit.edu and www.mit.edu AND mit.edu to be set properly? Or would they go into the bit bucket, for greenpeace-friendly recycling? http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html Here is how to compare domains from section two in the document: }} Hosts names can be specified either as an IP address or a FQHN }} string. Sometimes we compare one host name with another. Host }} A's name domain-matches host B's if }} }}* both host names are IP addresses and their host }} name strings match exactly; or }} }}* both host names are FQDN strings and their host }} name strings match exactly; or }} }}* A is a FQDN string and has the form NB, where N }} is a non-empty namestring, B has the form .B', and }} B' is a FQDN string. (So, x.y.com domain-matches }} .y.com but not y.com.) }} }} Note that domain-match is not a commutative operation: }} a.b.c.com domain-matches .c.com, but not the reverse. Here is section 4.3.2 which specifies under what criteria a user agent should reject a cookie: }}* The value for the Domain attribute contains }} no embedded dots or does not start with a dot. }} }}* The value for the request-host does not }} domain-match the Domain attribute. These two should answer your question. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: setting httpd cookie domains
David Harris [EMAIL PROTECTED] wrote: These two should answer your question. You may also need to read section 4.3.4, Sending Cookies to the Origin Server, to determine what cookies will be sent to what servers. The criteria you are probably looking for is this: }} The origin server's fully-qualified host name must }} domain-match the Domain attribute of the cookie. David
RE: API Design Question
Shawn, We have taken the approach here of a format like the on laid out below: (in startup.pl - use lib '/usr/local/apache/lib'; - add the directories to @INC) /usr/local/apache/lib/APP - where APP is the main name of our application. In this directory we will have perl modules that are shared by all the handlers that make up the application. Inside this directory we have a directory for our handlers - the handler would relate to the 'command=foo' part of your current call - like: /usr/local/apache/lib/APP/Command Inside the directory for the handler we have at least a Handler.pm which is reference in out perl.conf something (well exactly like): Location /command SetHandler perl-script PerlHandler APP::Command::Handler /Location Inside the Handler.pm perl module is a sub called handler that processed the requests made to that command. We also have a perl module for each action related to a command, like: List.pm - to process things related to a /command?action=list call. For out situation, this works well because it allows several developers to work on different parts of the same Command without stepping on each others toes, so to speak. Of course, this does add a level of complexity to project, that in the beginning was met with some resistance by long time perl programmers - myself included and I thought of the layout, but in practice it has let our team cut development times significantly. Of course a good versioning system will allow multiple users to access the same file and not cause problems, and we use CVS to provide version control. As with anything, you milage may vary with this method. I'm sure there are hidden pitfalls involved with this method, but for the timebeing it does seem to work for us. I hope this helps. Good Luck Joe Breeden -Original Message- From: Shawn Devlin [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 1:18 PM To: [EMAIL PROTECTED] Subject: Re: API Design Question Adam Worrall wrote: SD == Shawn Devlin [EMAIL PROTECTED] writes: SD My first thought is to break the API up so that there is a SD module per API call (there are some 70 calls in the API). My SD reasoning is that I can modify existing calls and add new ones SD without affecting everything else. Does this make sense or is it SD better to have the API as one large program as I have it now? I'd have thought you'be best to put the API in a large module, and then make calls to it from mod_perl handlers. You oculd even write a generic handler which chose which function to execute based on the arguments. Having a module per function may start to do your head in :) The bulk of the API is in 4 or 5 .pm files. My cgi script basically determines the call being made, vets the parameters, calls vaious functions in the .pm files, and then returns the result. The current format for the call is server.com/cgi-bin/api.pl?command=fooparm1=parm2= What I want to have is server.com/api/foo?parm1=parm2= The module that handles foo would check the parameters, make it's calls to the various internal functions, and then compose and send the results. What I like about this is I can add a new function without needing to disturb the existing code. Also, each function call is then self-contained. Currently, my existing API script is essentially a big switch statement. My concern is that each handler links the .pm files so with 50 or so functions I will have 50 or so copies of the various .pm files in memory. Yes - when some Perl in an Apache child process executes DBI::connect (which has been overridden by Apache::DBI), it first looks in a hash of existing connections before opening a new one. Good news ! Thanks for the conformation. Shawn
Re: API Design Question
- Original Message - From: Shawn Devlin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 29, 2001 8:18 PM Subject: Re: API Design Question What I like about this is I can add a new function without needing to disturb the existing code. Also, each function call is then self-contained. Currently, my existing API script is essentially a big switch statement. I see the point in separating it. I do the same thing myself. My concern is that each handler links the .pm files so with 50 or so functions I will have 50 or so copies of the various .pm files in memory. That's not quite right. In its simplest form, I can say that Apache gets one copy of each module per *child*, not per file, so 50 files doesn't mean you'll have 50 modules loaded. For example, if one child serves /api/foo, and /api/foo loads API1.pm and API2.pm, those will stay in memory, so that when the same child serves /api/bar, and /api/bar attempts to use API1.pm and API2.pm, the perl interpreter will find out that these 2 modules have already been loaded, and not reload them. But if you use preloading, as you should do, you get even more benefit from shared memory. If you preload your modules in starup.pl or with PerlModule in httpd.conf, they'll stay shared in memory, thus reducing the memory overhead. Per Einar Ellefsen
OT: Is there a comperable Apache list (besides anounce)?
Hi all, The only list I found on apache.org was [EMAIL PROTECTED]. I see from thearchives that this question was asked in this group a year or two ago, butnobody had a very good answer. ---Rodney BroomProgrammer: Desert.Net
mod_perl + mod_ssl + mod_fastcgi + mm can't compile Apache
Dear All, I'm having some troubles in compiling apache with such modules. I'm using the following sources: (linux-2.4.5.tar.gz) apache_1.3.20.tar.gz mm-1.1.3.tar.gz mod_fastcgi.tar.gz mod_perl-1.25.tar.gz mod_ssl-2.8.4-1.3.20.tar.gz openssl-0.9.6a.tar.gz and I'm compiling like this: OpenSSL: cd /usr/src \ tar xvzf openssl-0.9.6a.tar.gz \ cd openssl-0.9.6a \ ./config -fPIC make make test make install MM cd /usr/src \ tar xvzf mm-1.1.3.tar.gz \ cd mm-1.1.3 \ ./configure --disable-shared make make test make install Apache (1): cd /usr/src \ tar xvzf apache_1.3.20.tar.gz \ cd apache_1.3.20 \ ./configure make mod_perl: cd /usr/src \ tar xvzf mod_perl-1.25.tar.gz \ cd /usr/src/mod_perl-1.25 \ perl Makefile.PL \ EVERYTHING=1 \ APACHE_SRC=../apache_1.3.20/src \ USE_APACI=1 \ PREP_HTTPD=1 \ DO_HTTPD=1 \ make make test Everything runs just fine and smooth, until this last make test. At this point, it ends like this: (...) make[1]: Entering directory `/usr/src/mod_perl-1.25/Util' make[1]: Leaving directory `/usr/src/mod_perl-1.25/Util' cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.20/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c Syntax error on line 3 of /usr/src/mod_perl-1.25/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration 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 111 [root@linux2 mod_perl-1.25]# What's missing? What did I make wrong? I took a look at /usr/src/mod_perl-1.25/t/conf/httpd.conf and it seems very messed, starting like this (head): #PerlOpmask default =pod =head1 NAME mod_perl test configuration file =head1 DESCRIPTION is this rigth? I'm completely ignorant on perl matters, so forgive me by any mistake. Afterwords, I'll compile and install mod_ssl, suexec, mod_bandwidth, fastcgi, php... Marcio Merlone - Analista de Sistemas Pleno e-mail: [EMAIL PROTECTED] VIA NET.WORKS BRASIL - Atuação Local Alcance Global Fone.:+55 11 3049-1180 ramal 1298 Fax:+ 55 11 3842-4588 Vamos falar de segurança? http://www.viasecurity.com.br Esta mensagem contém informações confidenciais e privilegiadas. Se você não é o destinatário final desta mensagem, ou não está autorizado a recebê-la em nome do destinatário, você não pode copiar, utilizar, divulgar ou agir baseado nesta mensagem ou qualquer informação nela contida. Se você recebeu esta mensagem por engano, por favor comunique-se com quem a enviou respondendo à mesma e delete-a. Obrigado por sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: mod_perl + mod_ssl + mod_fastcgi + mm can't compile Apache
On Fri, 29 Jun 2001, Marcio Merlone dos Santos wrote: Dear All, I'm having some troubles in compiling apache with such modules. I'm using the following sources: (linux-2.4.5.tar.gz) apache_1.3.20.tar.gz mm-1.1.3.tar.gz mod_fastcgi.tar.gz mod_perl-1.25.tar.gz mod_ssl-2.8.4-1.3.20.tar.gz openssl-0.9.6a.tar.gz and I'm compiling like this: OpenSSL: cd /usr/src \ tar xvzf openssl-0.9.6a.tar.gz \ cd openssl-0.9.6a \ ./config -fPIC make make test make install MM cd /usr/src \ tar xvzf mm-1.1.3.tar.gz \ cd mm-1.1.3 \ ./configure --disable-shared make make test make install Apache (1): cd /usr/src \ tar xvzf apache_1.3.20.tar.gz \ cd apache_1.3.20 \ ./configure make mod_perl: cd /usr/src \ tar xvzf mod_perl-1.25.tar.gz \ cd /usr/src/mod_perl-1.25 \ perl Makefile.PL \ EVERYTHING=1 \ APACHE_SRC=../apache_1.3.20/src \ USE_APACI=1 \ PREP_HTTPD=1 \ DO_HTTPD=1 \ make make test Everything runs just fine and smooth, until this last make test. At this point, it ends like this: (...) make[1]: Entering directory `/usr/src/mod_perl-1.25/Util' make[1]: Leaving directory `/usr/src/mod_perl-1.25/Util' cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.20/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c Syntax error on line 3 of /usr/src/mod_perl-1.25/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration Marcio, please peruse the mailing list archive to search for the solutions before you ask the list. for example here is one of the answers I've digged for you: [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/rimpsovo/[EMAIL PROTECTED] Usually your starting point is http://perl.apache.org/#general-list (see the archives list). On the other hand you may want to read the guide. A few scenarios of how multiply components are built with mod_perl are covered in details here: http://perl.apache.org/guide/install.html#Installation_Scenarios_for_mod_p This should help. 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 111 [root@linux2 mod_perl-1.25]# What's missing? What did I make wrong? I took a look at /usr/src/mod_perl-1.25/t/conf/httpd.conf and it seems very messed, starting like this (head): #PerlOpmask default =pod =head1 NAME mod_perl test configuration file =head1 DESCRIPTION is this rigth? I'm completely ignorant on perl matters, so forgive me by any mistake. Afterwords, I'll compile and install mod_ssl, suexec, mod_bandwidth, fastcgi, php... Marcio Merlone - Analista de Sistemas Pleno e-mail: [EMAIL PROTECTED] VIA NET.WORKS BRASIL - Atuação Local Alcance Global Fone.:+55 11 3049-1180 ramal 1298 Fax:+ 55 11 3842-4588 Vamos falar de segurança? http://www.viasecurity.com.br Esta mensagem contém informações confidenciais e privilegiadas. Se você não é o destinatário final desta mensagem, ou não está autorizado a recebê-la em nome do destinatário, você não pode copiar, utilizar, divulgar ou agir baseado nesta mensagem ou qualquer informação nela contida. Se você recebeu esta mensagem por engano, por favor comunique-se com quem a enviou respondendo à mesma e delete-a. Obrigado por sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: OT: Is there a comperable Apache list (besides anounce)?
On Fri, 29 Jun 2001, Rodney Broom wrote: Hi all, The only list I found on apache.org was [EMAIL PROTECTED] I see from the archives that this question was asked in this group a year or two ago, but nobody had a very good answer. Here are some pointers: http://perl.apache.org/#maillists http://apache.org/foundation/mailinglists.html I admit that the last one is not easy to find if you don't know where to look for. _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
